Kanban and linear workPosted: January 20, 2011
Alan Shalloway is very helpfully documenting some Myths of Kanban. One myth that caught my eye in particular was “Kanban suggests linear work and requires too many handoffs.” I’ll be talking about this aspect of Kanban in my presentation on whole-team approach at the Agile and Beyond conference, so I liked what Alan wrote — as an aside, what he calls linear, I call sequential (contrasted with simultaneous):
Lean manufacturing may assume linear work, but not Lean software development (nor Kanban). Kanban boards may often appear to be linear but Kanban boards reflect the way people are doing the work. Hence, if people are working linearly, the board will reflect that. However, Kanban boards can also reflect non-linear work. One must also recognize that a Kanban board does not reflect the people doing the work but rather reflects the flow of the work being done. Hence if a board looks like:
Backlog — Analysis — Design — Code — Test — Done
it is not suggesting that the work be done by different people and hand things off. It just shows the states the work progresses through. In this case, it’s on the backlog, in analysis, being designed, coded, tested or completed. It could very well be the same person doing the work. The second misconception is that the board tells you to break things down into these steps. Actually, it doesn’t (or shouldn’t). The board should be a reflection of the work being done. So different columns on the board should reflect the different steps the team is doing. If the team swarms on multiple steps, then the Kanban board should only have one column for that. Essentially the Kanban board has one column for each type of work the team is doing. The explicit policy for how it gets to that step and out of that step also needs to be stated, but is not necessarily written on the board. Bottom line – if you don’t like the process that you see on the board, change it (and then update the board). The board is there merely to reflect on your work so you can better change how you work.
I think Alan is right when he says, essentially, that the board is “identity-neutral” as to who is doing the work. The problem that I have seen is breaking out the queues in such a way as to encourage non-simultaneous work behavior (e.g., separating code and test). This is why I still prefer fewer queues to many.