The Problem with Kanban
The Agile Zone is brought to you in partnership with Hewlett Packard Enterprise. Discover how HP Agile enterprise solutions can help you achieve high predictability and quality in your development processes by knowing the status of your projects at any point in time.
Since moving from more of a Scrum-dominant Agile variant to a Lean one, things have been a lot better. Mind you, one of the biggest problems with the Scrum approach was we were first using XPlanner, which was not sufficiently feature complete, then went to Rally which was a bloated homunculus. (Ok, I‘m kind of obsessed with that word…) You don‘t really get more visibility or control from the heavier process, and there are things the Kanban will show you that you will never see in the other systems. Finally, the 2nd Law rapidly overtakes the likes of Rally while the board has a very effective built in defense (limits on the number of items in each column).
The biggest problem with Kanban is that it‘s designed for a world where things go through the line once (e.g. a carmaker). In software, this is almost never the case. The real masters of software are the ones who figure out how to put enough meat in each sausage and then keep the machine running, consistently, providing newer versions of prior incarnations without stopping the machine. This is one of the other parts of the Apple Phenomenon that confounds the old (broken) models: their competitors still live in a one-pass world of retooling and trying to arrange each product as a separate milking occasion.
In practice, the potential remedies for this are mostly unsatisfying. You can describe something conceptually and then parse out the details of what will be complete in the first version in the tasks, but then how does the remainder get re-enqueued? (Again, beginnings and ends that are process rather than product serving.) The other possibility is to just describe the waves of versions of a thing in separate stories. That‘s really unsatisfying because there is no way to keep them together.
Some might say that I am taking Kanban too literally, but I disagree: the whole point of Lean is to mind the VSM. Turns out that the minding is scoped and linear in the real world, but in software, we not only rarely do things that way, at the micro level, it‘s one of the worst anti-patterns there is: people trying to think every story through to some absurd logical completeness. Software is like Fresco painting: you have to get the shapes down and fill in some of the colors before you get crazy finalizing details. Frankly, if there‘s one thing software needs desperately its tools that make this process of roughing then refining easier to do in teams. Kanban is great, but it‘s got a big hole in it.