In the earlier posts I have listed a number of positives and negatives about the Kanban Method’s use of WIP limits on columns (work-states). Naturally the question arises: are column WIP limits good or bad? Should you use them or not?
The majority of organizations will gain great benefits from adopting the Kanban Method with column WIP limits, because — notwithstanding that the improvements may occur by happenstance — improvement by happenstance is way better than no improvement at all.
Column WIP limits…
… are invaluable when starting out with Kanban, because they will prepare the team and the organization to have open discussions about problems that are revealed through the visualization of work on the Kanban board.
This is an essential skill that needs to be well honed and exercised before moving to the more sophisticated methods.
Once you feel comfortable with the patterns of interaction and communication that emerge within the process of visualizing disruption of work flow, then you will be ready to look beyond column WIP limits, in order to overcome their negatives.
When you introduce Kanban for the first time in an organization or in a team, you should always start by using work-state WIP limits.
If you do not, the organization will not have the skills necessary to take advantage of the approach I describe in Tame the Flow. It is essential to gain the habits that are enabled through column WIP limits before trying my approach, because then…
… we will replace work-state WIP limits with another mechanism, which gives more subtle and less disruptive signals about where problems are materializing. The team needs to be well trained in doing a collective effort in resolving process problems before it can work with this alternative. […] the signals will be more subtle: the team might need to be collaborating already, just to recognize the signals themselves.
Without the skills learned by using column WIP limits, it will be much more difficult to successfully transition to my approach.
Column WIP limits…
… must be used as training wheels; and they should be taken off once the organization has found the balance and is ready to speed up!
Who Should Do This?
A consequential question is about if and when an organization needs to do this. The answer comes from the domain I am investigating: that of hyper-productive organizations. You should try this only if you feel that your implementation of the Kanban Method has “maxed out.”
With reference to Bob Marshal’s Right-shifting model, the majority of organizations will never need to try this. In fact, they will be culturally unable to do so, as they are solidly positioned on the “left-side” of the model.
For the majority of organizations, the improvements enabled by the Kanban Method will be well beyond their expectations, and they will be more than satisfied.
However, those organizations that aspire to become hyper-productive, and go well beyond the highest expectations in their respective markets, there is a lot to be gained by looking beyond column WIP limits.
This is the Kanban Method’s Core Practice 6 in Action
Highlighting that there are negatives with column WIP limits does in no way diminish their value, nor that of the Kanban Method. My approach is not an alternative to the Kanban Method. It is in fact a natural evolution of the sixth core practice:
Core Practice 6: Improve Collaboratively, Evolve Experimentally (using models and the scientific method).
My approach is the result of using the Theory of Constraints as the reference model when striving to use the Kanban Method and to improve by using models.
When one applies the Kanban Method with an experimental and scientific mindset, one should also be prepared to improve, even if that means letting go of precepts that are otherwise founding and fundamental in the initial stages.
The approach described in Tame the Flow is an outcome and result of the evolutionary change promoted by the Kanban Method, exercised with the Theory of Constraints as the reference model in core practice six.
To learn more about this, read Tame the Flow.