Limiting WIP When You Cannot Block Incoming Work
The most common WIP limit objection — 'we can't block incoming work.' How to apply WIP constraints even in environments where new requests cannot be refused.
A concern that comes up frequently when you start talking about applying a WIP limit is:
“So, what I understand from you is that at some point you will block incoming work requests if the WIP limit is reached, yes? Well, we cannot do that. We cannot tell people we will not work on their items. That will not fly around here”.
I think that is a reasonable concern. In Don Reinertsen’s Lean Product Development workshop this week in Paris (highly recommended btw…) he frequently used the Emergency Room (ER) metaphor. So let’s borrow it.
In my view both the waiting hall and the treatment area are WIP since they both affect the overall service time.
Two ways to apply a limit
You can apply a limit in at least two ways. The first can be to apply a limit to the overall WIP. Once this limit is reached you will indeed turn away patients. Fans of ER themed TV series will recall episodes where the ER closes shop and turns ambulances and walk-ins to other hospitals.
This happens very infrequently though. Their WIP is set to a high level and it is understood that the waiting area might have a very high occupancy leading to very long service times before the situation is so dire that you start blocking people. (A client that attended Don’s workshop with me commented that you might want to invest in stronger security if this happens often as it typically leads to some violence towards staff…)
The second way is to limit “Treatments in Process” to make sure that once patients are in treatment they go through as fast as possible and staff don’t multi-task too much and the treatment area is not too crowded. You will notice this style of WIP limit DOESN’T turn away patients. It accepts them and queues them.
Yes the service time might be high if there is a long waiting queue but you will still be serviced. I don’t know what ERs actually do since my personal experience with them is quite limited but I think they either explicitly or implicitly do a mix of both.
Back to knowledge work
To return to our knowledge work environment I advocate using this approach as well.
Yes you should have some WIP limit on your incoming queue. That WIP limit might be high if you want to minimize blocking and prefer to provide long service times. That is probably what the evolutionary resistance-minimizing approach would be.
More importantly I would start with a limit on the actual work in processing. This will achieve a more sustainable and effective processing both for the work as well as for the people doing it. This will also have the effect of reducing the average waiting times and overall service level of your system.
A higher maturity level
Now, in your environment you might also have a better chance of shaping demand and occasionally blocking work in a way that is acceptable to your clients. But that is a higher maturity level of Kanban. (Klaus would call it a higher flight level) Don’t give up on starting with WIP limits just because you cannot do it early on in your journey or if you think you will not be able to do it even later on.
Improving flow means fewer bottlenecks, faster feedback, and less wasted capacity. Explore flow advisory or let’s talk.
Yuval's practical guide to Kanban for knowledge work — distilled from 17+ years applying Kanban inside real product and technology organizations.
Yuval Yeret helps product and tech leaders move from agile theater to evidence-informed delivery. Work with Yuval →
