Does such physical-whiteboard-per-team management process exist in the literature?

Question

Does the following sound similar to some established (now or in the past) practice?

One big whiteboard per team.

Tasks are written down in a single short sentence(e.g. "refactor Frubnicator" or "add logging to solve bug XXX" or "read about Widgets"). Maximum possible estimated length for a task is 1 day. Anyone can add tasks to the board e.g. a developer requesting infrastructure enhancement and the admin picking it up because he's the obvious person to do it.

Every team member owns a whiteboard marker of unique colour. When they start work on a task, they circle it. All tasks are written in black and the creator is thus anonymous.

Thus everyone knows precisely on what is everyone else working (happy manager), employees are given the freedom to chose on what to work instead of being assigned, and the whole thing is physical and visual. Furthermore, interdependencies can be drawn with solid or dashed lines.

Answer 1

Sounds like Utopia

Unfortunately, this process is unlikely to exist in the real world.

Anyone can add tasks to the board

Looks like all work is internally generated by the team. If this is a product, it will lack a unified vision. It will be worse than design by committee. It can't be Kanban because Kanban is typically for work originating from outside the team. For example, when customers open tickets, the support team can use Kanban to work the tickets.

Maximum possible estimated length for a task is 1 day.

The person creating the task quite often is unable to estimate the effort level. Only the person doing the work can possibly know how long it will take. Also, what happens if the task is such that it will take longer than one day? Split it and have no way of testing the half-done task? By the way, you didn't say how any task gets closed - by testing it, by the Manager or by other means.

employees are given the freedom to chose on what to work instead of being assigned

Managers tend to get called by their bosses and their peers from other departments asking for things to be done ASAP. Also, difficult or 'not interesting' work may not get picked up at all and will continue to languish until it becomes a crisis.

interdependencies can be drawn with solid or dashed lines

It is not clear what happens after drawing the lines. Pray that the dependent task gets picked up by someone? Manager is not supposed to assign it, right?

Answer 2

Looks like something custom, possibly borrowed from, or resembling Kanban.

Kanban has two main principles:

• visualize work
• limit work in progress

Anything else falls into how you want to organize things according to other Kanban principles.

From what you mentioned:

• one big whiteboard could be a Kanban board (there is some common format for how a Kanban board looks like, but that's not prescribed; you can have it however you like);
• tasks are written down in a single short sentence. Like on a Kanban card;
• maximum possible estimated length for a task is 1 day. Work needs to be split in small pieces so that it helps limit work in progress and maximize throughput;
• when they start work on a task, they circle it and employees are given the freedom to chose on what to work instead of being assigned. Looks like a pull system. Kanban is a pull system (assigning tasks to people is "push"ing work).
• physical and visual. First principle of Kanban.
• seems you are doing operational work, which is a good match for using Kanban.

Kanban is used to manage and optimize workflows, so you should have some form of steps in this workflow of yours, but you don't mention that. Your board looks more like a repository of work than a workflow. So not really Kanban, but with similar ideas.

Answer 3

In more than thirty years of developing software and of managing others who do, I can tell you that "this is a pipe dream." This is "wasting time standing in front of a white board, sticky notes in hand, just because someone else said that you should do it." It is also advocating that each "team" (sic ...) member gets to decide for himself what he wants to do, and that everything that is to be done can be done in one day. That's not reality.

How would you feel if you were paying for someone to build or remodel your house, and you saw the crew standing around a white board with sticky notes, apparently trying to figure out what to do next? Uh huh.

A "team" engages in "team work." They work together to determine what is to be done, what is the best way to do it, and how to divide each task so that several people working simultaneously can advance the project faster than any one of them could do so if working alone. (And there was an architect involved, too.) The description and work-breakdown of any task might involve many pages and dozens of steps. It might take many weeks to complete, with development and planning always overlapping. Project management is a full-time occupation – the managers do not write software.

"There is no such thing as a 'Team of One.'" When you have that, you have "lone wolves." People who try to own "their" piece and to do without communicating or working with their so-called "teammates." Lots of developers seem to like it this way and to expect it to be this way – until they first find themselves in a situation where "many hands do make light work." Then, the white-boards and the sticky notes quickly go away. They're replaced with detailed design documents, productive meetings, explicit time and status recording, and Microsoft Project.®

Now, when you watch that team on the field, you see a team, not a dozen guys all fighting for the same football. Not people trying to figure out what the game is while the ball is in play. People who have been part of a truly successful, well-managed team don't want to be lone wolves anymore, because they can plainly see how their working lives just got a whole lot better. It works.