“The purpose of kanban is to eliminate the kanban”
I found the quote that title’s this blog post in Mike Rother’s Toyota Kata book – the origin is simply stated as “a Toyota person”.
Kanban: We’re Doing It Wrong
The title quote plays hand in hand with a quote from The Toyota Way:
“kanban is something you strive to get rid of, not to be proud of”
What does this really mean? It means we are probably doing Kanban wrong or for the wrong reasons.
If we’re setting our WIP limits to the team’s capacity currently or something above current capacity, then we’re likely doing it wrong. If we’re not using a Kanban system as a tool, a means to identify and solve systemic issues, then we’re likely doing it wrong. If we are using Kanban and WIP limits as ends in themselves, then we are certainly doing it wrong.
One Step In A Long Journey
According to Rother, the reason most kanban implementations fail is because we expect to be able to implement the system and have it stabilize immediately. This is wrong. We must instead use the desired state of the Kanban system as a target goal. When we first define our process and our WIP limits, they must hold fast as the target we are aiming for – not a hard and fast rule of what must happen now. By changing our focus from “this is what we must be doing” to “this is what we are striving for”, we allow ourselves the opportunity to truly improve the system that we are working in. When we try to enforce the WIP limits, the Kanban system will hold up a bright spotlight and reflecting mirror, exposing the real problems that prevent the team from achieving the stated process and WIP limits. It is then our responsibility to face those problem head on and overcome them – not work around them, not ignore them, not give up because we don’t think Kanban can work for us, but to eliminate the problems by addressing and removing their root causes.
Therefore, a Kanban system is not something that should model our team’s current process and capacity. Rather it should model the process and capacity that we want to have, next. It should represent the output of the current improvement efforts as well as the input into the next improvement efforts. It should be a “target condition” that moves us toward our “vision”, as Rother states it. Or a “defining objective” that moves us toward a “thematic goal”, as Patrick Lencioni states it. The point of these authors is the same and is one that I have touched on briefly in my blogging and more extensively in my coaching and change management efforts. A Kanban system is not an end in itself, but only one of many tools to help us see our system’s problems and eliminate them by giving us focus and direction.
Enforcing WIP Limits May Not Be The Right Thing To Do
When we are using a specified state for a Kanban system as a goal that to strive for, then we need to recognize that enforcing the WIP limits within the current goal may be dangerous. It is possible for an artificial WIP limit enforcement to cause financial damage by neglecting the needs of the business and/or the customers. We need to understand the cost of delay for priority situations that come up unexpectedly.
For example, when an urgent request comes in – say a production bug that must be fixed immediately, or risk loss of business and revenue – there are at least a few options to consider: queuing the work to be done (likely at the top of the queue if it is a priority), having one or more team members stop what they are doing and get it done immediately, or possibly bringing in additional resources to work on the issue. The right answer, of course, depends on the situation and understanding of the cost of delay for the priority issue vs the cost of delay for the current work in progress.
There will be some scenarios where the work should be queued and done when capacity is available. There will also be some scenarios where the work needs to be done immediately, recognizing that we are not yet able to meet our WIP limit goals. When we run into scenarios that need immediate attention and WIP limit violations, we need to ask ourselves “what problems are causing us to not be able to meet our WIP limit goals?”, and then work to correct those problems.
The Continuous Improvement Cycle
By solving the root causes of problems that prevent us from working to your WIP limit goals, we will eventually be able to meet those goals. If we find ourselves and/or our team in a position to routinely meet the process and WIP limit goals, then we are now back at square one. We need to set new goals that we know are not currently attainable and begin the hunt for and elimination of our new problems.
The goal is not to use a Kanban system. The goal is to eliminate the need for a Kanban system.