“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.

About Derick Bailey

Derick Bailey is an entrepreneur, problem solver (and creator? :P ), software developer, screecaster, writer, blogger, speaker and technology leader in central Texas (north of Austin). He runs SignalLeaf.com - the amazingly awesome podcast audio hosting service that everyone should be using, and WatchMeCode.net where he throws down the JavaScript gauntlets to get you up to speed. He has been a professional software developer since the late 90's, and has been writing code since the late 80's. Find me on twitter: @derickbailey, @mutedsolutions, @backbonejsclass Find me on the web: SignalLeaf, WatchMeCode, Kendo UI blog, MarionetteJS, My Github profile, On Google+.
This entry was posted in Kaizen, Kanban, Management. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Why has the software community been almost entirely focused on only one component of Lean rather than on the whole?

  • @scott,

    good question. marketing? wanting to fit in with ‘the next big thing’? Joe Ocampo has been saying this for a while and I’m finally starting to see the problems with this focus, as well – hence my statements about kanban being one step in a long journey. we’re leaving out so many possibilities and tremendous opportunities.

    there’s an obvious value in kanban systems – but it’s far from the only value we should seek in Lean systems.

  • Kanban is the most material, mechanical aspect of Lean, and thus the most visible. It’s the most obvious target for the existing Agile celebrities to gain a purchase and perpetuate visibility and perceived relevance.

    Whether of not we believe that The Toyota Way applies to Lean Software Development, we should at least pause to consider Toyota’s leaders’ historic observations that Lean adoption usually fails when it is done naively, taking on only the most materialistic and mechanical aspects of Lean, while not realizing that it’s central thrust and its inherent power lies in the creation of learning organizations, and all the powerful subtitles that learning organizational mechanics imply that illuminates and activates the rest of the Lean principles system.

    We’re walking straight into the belly of the beast with the clearest and sagest voices calling to us to tell that we’re making the same mistake already made countless times by others who’ve gone before us.

    Meanwhile, back in the software Kanban camp, while we’re distracted with the installation of yet another clique, the learning, questioning, and deepening of perspective and understanding continues to be under-served.

    Yes We Kanban.

  • I wish I could convince Scrum teams of a similar truism.

    “The purpose of scrum is to eliminate the scrum”

    That’ll ruffle some feathers!