The Work In Progress limit (WIP limit from now on) is one of the most powerful butĀ counter-intuitive concepts I had the fortune to encounter in my work life.
When suggesting teams to introduce a WIP limit to their boards, I hear objections like āare you saying that doing less things at the same time is going to make you faster? You must be wrong? If I startĀ 10 things Iāll finish earlier than if I can only do 2 at the same time!ā
or āWorking on one thing at the time only? Thatās NOTĀ efficient!ā
It is indeed a counter intuitive concept, proven by the fact that most people object to it based on common sense.
You might say, why donāt you explain the reasons behind the value of WIP?
Donāt get me wrong, IĀ am familiar with queuing theory, Littleās law and the relation between resource utilization andĀ queue size, but these concepts areĀ not something that can be explained easily every time that the objections are brought forward. Funnily enough, explaining them, is not really efficient.
I have beenĀ helping teams use Kanban and the Kanban methodĀ for a while now and I have used different approaches around WIP limits to identify theĀ one that gives the best results forĀ the teams.
I have come to the conclusion that the most efficientĀ way to go about this is by (I hate the word)Ā imposing the WIP limit at the very beginning of the adoption, as part of Shu in the Shu Ha RiĀ learning pattern.
The great thing about having aĀ WIP limit is that itĀ gives strong signals to the team
- Whatās the most important problem we have to solve now?
- Whatās the highest risk our kanban board is telling us about?
If your board has a WIP limit you will have to answer the questions and act, if you donāt have one, you can always pick the easy cop out of taking a new less important task. TheĀ questions posed by the WIP limit are uncomfortable ones, they wonāt allow the team to take the easy option. Thatās why I believe that teams will benefit from having them since day one.
I have seenĀ WIP limits cause turmoil in teams, people initially feel uneasy. I believe, the feelingĀ derives from the fact that team membersĀ donāt believe yet WIP limits will work, and this is due to their aforementioned counter-intuitive nature.
Eventually teams will internalise the fact that WIP limits help the team focus on delivering instead of retreating to more comfortable, less valuable tasks and it does indeed improve flow. But thatās after a while.
My point is, that if we donāt impose the limit at the beginning, the team might not get there on their own.
As I said before I tried many different coaching approaches, the one that worked for me better so far is this:
- AĀ session with the team in which I go into the details of the mathematical reasons why WIP limits improve flow Ā (most people wonāt believe everythingĀ but will have some context and hopefully some curiosity)
- Get the team started with a system that includes a WIP limit initially setĀ by me andĀ low enough to be uncomfortable (see above)
- Attend teamāsĀ standups,Ā to discourage breakingĀ WIP and ask the difficult questions I mention above if the team is not able yet to read them from the board
- Facilitate a retrospective after 2 weeks of use and have a conversation around whether the limit is too low or too high
What was your coaching experience? Can you share alternative paths?
| Reference: | What I learned about helping teams use WIP limits from our JCG partner Augusto Evangelisti at the mysoftwarequality blog. |
