Kanban Is Process Control, Not A Process For Adding Value To WIP
There’s some very interesting conversation on Chris McMahon’s blog titled “against kanban”. In general, I don’t agree with what he is saying. I think that he is largely basing his current opinion on some misguided “expert” opinions rather than doing the research for himself… but that’s another post / response entirely. I wanted to point out an issue that I have with the way people approach Kanban, in general. And while this is somewhat spurred by Chris’ post, it has more to do with what I am seeing in the comments and discussion after the post, combined with a lot of discussion on the Kanbandev list.
What Kanban Is Not
A Kanban system does not tell you how to get your work done. It will not ask you to change the value-add steps in your process or tell you how to add value to work in process (WIP). It does not tell you how to hand off the WIP between various steps, how those steps interact, what those steps should be, or what order the steps should be performed in.
“Kanban is about the notion that ‘your system is truly different’ and ‘we will not impose a process upon you.’” – David Anderson, via the Kanbandev list.
What Kanban Is
A Kanban system is form of process control, not a process for adding value to WIP. It asks you to control the flow of work by limiting the WIP and pulling the work through the steps that it must go through.
“Process control is a statistics and engineering discipline that deals with architectures, mechanisms, and algorithms for controlling the output of a specific process. See also control theory.” – Wikipedia
WIP Limits and Pull
What Kanban does do, is ask you to control the amount of WIP that is currently in a system. It then asks you to pull the WIP through the system rather than push.
Take your current process and create some sort of representation of the steps that WIP goes through. Most agile people and most Kanban people will end up with the same type of representation: a board with labeled steps. Call it a task board, a Kanban board, a scrum board, or whatever you want. It’s all a form of visual management. Once you have the board laid out to represent your actual process, track every piece of work as it flows through the board. At this point, we’re describing scrum, XP, Kanban, or any of a number of other methods of process control.
Now that you can see the WIP, start putting limits into the number of tasks that are in process, for any given step or for the entire system, or both. Setting WIP limits is the first step to change from scrum / xp / whatever, to Kanban. Once you have limits in place, pull should naturally happen.
Your Process
I think Jim Benson said it best in the comments of Chris’ post, when it comes to choosing your current process.
“There is no process truth. Agile isn’t evil. Kanban isn’t god. Any process that claims to be “the true process” is a liar and the experts are riding it for the income.
In the end, you are a manager, you have a group, that group operates in a certain way. If it works well with Scrum, great.”
Why Kanban
Chris Matts then summarized why I am involved in Kanban, quite nicely in the comments of McMahon’s post.
“There is a law of diminishing returns when we improve things. From Waterfall to Agile was an 80/20 move, but there is only 20% more efficiency to find. Kanban took us from 80% to 90% ( ignore the numbers, its the reduced increase in efficiency ). Toyota are continuing to seek out the final 0.000001% as they see the value in it.”
I don’t entirely agree with this, honestly. I don’t think there is such thing as “100% efficiency”. Rather, there is a point where the perspective of one team cannot see the waste from the perspective of another team. That is, one team will be so much more efficient than another, that it appears to be 100% efficient in comparison. A more thorough examination will prove this to be false, though.
Anyways, the point of quoting Chris Matts, was to illustrate how I see Kanban giving us the next step in productivity improvements.
What’s Next
Its not that I think Scrum and XP, or any of the other “agile” processes are no longer useful. On the contrary, I’m still an advocate for them in my office because they are producing results far more consistently than the previous chaos we have been running under. However, I recognize the limitations of the current agile processes, due to my own experience with those limitations. I found Kanban to be a very liberating process control system at the end of 2008 and into early 2009. It helped take a team that was running into constant failed iterations, due to factors outside of our control, and provide a system and structure that we were able to be successful within. I’m now exploring this further and learning the detail and implementation of Kanban, the same way I explored and learned Scrum and XP.
I see Kanban as the next logical step, how Chris Matts eluded to the next improvement jump in his response, above. I don’t expect Kanban to be the end-all process control system for software development, though. In fact, if the Lean Thinking philosophies and processes hold true to software development, as I expect they will, then we will eventually see that
“the kanban is an organized system of inventory buffers and, according to Ohno, inventory is waste, whether it is in a push system or a pull system. So kanban is something you strive to get rid of, not to be proud of”
– Jeffrey K. Liker, “The Toyota Way”, p. 110.
We are simply exposing the inherent waste, with Kanban, not glorifying it. We are making it explicit instead of implicit. We are advertising our inefficiencies to the world on the basis that transparency keeps us honest, builds trust, and provides motivation for further improvement.