In the wake of organizations just beginning to reap benefits from agile practices, some of them are already starting to look for the next thing. A natural way to look now is towards Lean product development companies as they seem to have a firm grasp of development practices since decades ago that we in the software industry have been somewhat oblivious to.
Being an early adopter myself, it’s hard to argue against trying out new stuff. But when it comes to organizations that find it too hard to navigate their political climate into adopting Scrum, I become a little concerned when they instead jump on flow development, which is inherently even more difficult to grasp and implement.
A brief look at Kanban
Kanban originally was a technique deviced by Toyota to allow workers at different stations in the production halls to signal upstream that more (or less) parts were needed, allowing the workers to control and maintain the optimal flow at any given time. Instead of just sending a note to Buck telling him to “hey, send me more parts, I’m running out”, information about the velocity was added. “Hey Buck, why don’t you send me five extra units as well, I’m picking up steam here”.
The interesting thing about Kanban is when upper limits are applied, essentially giving a tool to limit work in progress thus constraining the flow to the theoretical (and indeed often practical) maximum.
Transferred to our world, one of the key benefits of Kanban limits is actually to stop us from working on too many things in parallel. It’s actually faster to focus on finishing a few things instead of starting many things. I believe most people know this, deep within, but some of us still like to surround ourselves with freshly started projects and half-baked code rather than to actually finish some of it. Kanban limits helps us, in the smug way that only scientific arguments can have, to be faster at what we do, even when it feels counterintuitive.
There’s just one catch. Kanban comes from manufacturing, not development.
In the world of software development, Kanban has almost become synonymous with “whiteboard”. Blurring the concepts of visual planning and Kanban, the typical Kanban board in software departments now often consists of a backlog with sticky notes, and a number of stages the task will go through, each with a WIP limit stating the maximum number of open tasks allowed at that particular stage.
There are primarily two pitfalls to watch out for when trying this technique:
Variation in task size
A consequence of product development is the fact that tasks will not be uniform in size, and they may change in size during their lifetime. For a Kanban to work properly, all tasks need to be of a defined size and stay that way. It doesn’t make much sense to have a WIP limit of three tasks at a certain stage, if the first task will take two hours and the other two three days each.
As Donald Reinertsen often likes to point out, much waste in product development actually comes from trying to minimize the variability of development tasks, instead of accepting and managing it. “Kanban” used this way may put focus back on trying to remove variability, in a bad way.
Handovers
Manufacturing may have handovers from one station to another, meaning that work in progress will pass through a number of stations on the way to become done. This is why I, and many others, have had success with implementing Kanban in support- and operations departments, where work is typically more consistent in size and has defined stages to go through.
In software development, much uncertainty and quality issues comes from the fact that we often organize from a manufacturing standpoint, where documents and half-baked code is passed from requirement specialists to designers, to coders, to QA and so on. Scrum has showed to many of us that it is more efficient and gives more control to work in cross-functional teams that are able and skilled to produce complete functionality, thus adding value to the product in small increments.
What worries me is that I start seeing “Kanban” boards appear in project rooms, that have states such as “Design”, “Code”, “Test” and “Ship” as states, thus implying a sequence of events and that different people will be doing different things to code as it flows through.
Congratulations, you’ve just re-invented waterfall development in your own organization, but under a new and catchy name.
Conclusion
I think it is time for me to finally answer the question posed by my headline: Should we ban Kanban?
The answer is: Of course not. It is a great tool when used under the proper circumstances. Just make sure you know why you use it, when to use it, and what results you expect from it.
Personally, I would be careful to use it for product development, unless tasks are well defined and has inherently low variability.