Tolerance #3 - Are We Doing Kanban or Not?

Posted on July 29, 2012 by admin

Returning to my series of posts on tolerance and variation after a 3 month break, I’d like to examine a question I’m often asked, “Are we doing Kanban or not?”

Such a question can have several possible roots. It might be a tribal question seeking reassurance of worthiness to be a member of the Kanban community. It may be asked in a management context seeking reassurance on expectations for improvements that might be observed. It might be a pre-cursor to seeking training or consulting. It may simply be asked to confirm understanding of the method or clarification of its definition. Regardless of the motive, the benchmark is generally the definition of core practices I provided in chapter 2 of Kanban: Successful Evolutionary Change for Your Technology Business.


The core practices (recently expanded to explicitly articulate a 6th) are:

  1. Visualize
  2. Limit WIP
  3. Manage Flow
  4. Make Policies Explicit
  5. Implement Feedback Loops
  6. Improve Collaboratively, Evolve Experimentally (using models and the scientific method)

Together these 6 practices have been observed in organizations that have successfully adopted a Kaizen Culture catalyzed through the use of virtual kanban systems. It is this combination that gives us the Kanban Method, named for its catalyst mechanism, the adoption of virtual kanban systems.


So the question has been, “Do we have to be doing all 6 in order to be doing Kanban?” Or in some cases, “We are only visualizing, are we still doing Kanban?” or, “We are only limiting WIP, are we still doing Kanban?”

My response has always been that it is a matter of intent, not merely practices observed, and that the answer is never a binary, black and white, yes or no. An assessment of “Are we doing Kanban?” is a matter of depth. With this I have set the expectation that shallow implementations are likely to produce limited results, while deeper implementations are likely to produce more dramatic results similar to those that I and others have reported at a series of conferences since 2007.


Over time since 2009, I have played with the wording of these practices and the general theme has been one of removing specifics and moving towards a more general looser definition. Hence, “visualize workflow” has become simply “visualize” as the general problem is making invisible work visible. It is about more than just workflow. “Measure and Manage Flow” simply became “Manage Flow” as measurement could be deemed to be an optional, higher maturity behavior.

What has remained a constant since 2009, is “Limit WIP”. Despite the Kanban Method being named for the use of virtual kanban systems, the advice has always been merely to limit WIP, not to implement a virtual kanban system. This was inspired by Corey Ladas’ discovery in 2007 that any pull system is likely to act as the catalyst to improvement: kanban, drum-buffer-rope, CONWIP and CapWIP systems are all viable alternatives.

The advice to Limit WIP has been shown to be inspired. Merely limiting WIP rather than implementing a kanban system has provided permission for simpler solutions such as Personal Kanban. The general advice to Limit WIP also enable solutions that merely control multi-tasking such as a per person WIP limit, or limits only to the “in-progress” work in a workflow. In such system designs, the “done” columns in the workflow have infinite limits. They are effectively chains of decoupled “personal kanban in the office” systems. Richard Turner has coined the term “Proto-Kanban” to describe these solutions that do not implement an end-to-end pull system.


I think the loose definition of Kanban practices has proven to be a strength rather than a weakness. It has enabled shallow solutions that work well in lower maturity organizations. Merely “limiting WIP” provides a lower barrier to entry. We’ve seen numerous case studies emerge where the initial step was a proto-kanban and that initial stage lasted for 9 to 12 months before the organization was ready to take a step up and implement a full virtual kanban system and develop a deeper Kanban implementation. If the barrier to entry was defined as “implement a virtual kanban system” then many organizations would give up before they even got started. This would have denied these businesses significant improvements and the workforce genuine relief from challenging circumstances.

So, my conclusion is that doing Kanban is a matter of intent. If the intent is ultimately to evolve an existing process implementation by adding a full end-to-end virtual kanban system and then evolve further from there but for now all you are doing is some visualization and a per person limit to control multi-tasking and personal overburdening, then yes, you are doing Kanban. If on the other hand, you’ve created a card wall to visualize your work and facilitate collaboration but no intent to pursue the grander benefits of Kanban as a method that controls unevenness in flow, eliminates overburdening, provides a platform to better manage business risk in knowledge work, and catalyzes emergence of a continuous improvement culture, then you are not doing Kanban.


As Mike Burrows explained in Back from #KLRAT Hakan Forss questioned whether or not the core practices were in the right order from a shallow to deep perspective. The following discussion showed us via various anecdotes that the shallow to deep sequencing of practices could not be predicted. This led to a new model appearing - see the linked presentation “How Deep is Your Kanban?” This represents some of the bleeding edge innovation in the Kanban community. There is some hope that this work will mature into a model for Kanban adoption and maturity. For now it suffices to provide a visualization for the depth of a Kanban implementation.

Related Posts:

Related Download: