One of the main challenges when adopting Kanban is the limitation of work-in-progress (WIP). No matter the size, industry or age of the company; the concept of limiting the WIP in order to improve time-to-market and productivity is counterintuitive and a strong blow against conventional mindset.
But let’s be clear with this. You cannot benefit from Kanban if WIP is not limited. In order to implement PULL you have to limit your WIP. Creating a dashboard with some stickers is not Kanban it is just a board with some stickers.
What we do when adopting Kanban is to start by balancing demand with current capacity of the system. From there we move on and start our evolutionary improvement. And we can only balance demand with capacity if we implement PULL.
What arguments did I hear about limiting WIP
“And why would we want to implement PULL if we want to do many things at once and we want to put pressure on the delivery teams so they can deliver more?”
If you want to deliver more, that’s exactly the opposite of what you have to do. Implementing PULL is the starting point for improvement with Kanban. We balance demand with capacity, leaving the system in its optimum state of productivity without touching anything else, and from there we start the evolutionary improvement that will lead to more productivity, less time-to-market and more adaptability.
“But if we limit the WIP we will do less things. What we have to do is size development teams so they can do more things”
That’s not correct, for several reasons:
- Every production system has a maximum productivity that depends upon a single constraint, the weakest link. If we improve anything but the weakest link we are not improving. We might actually be making it much worse.
- When the system is overloaded with WIP we can not see where the problems are. There is so much in progress that we find it difficult to detect the critical points of action. It’s like looking for a needle in a haystack.
- By adding more people we make the system more complex. If you want to do more by adding more people you will need to restructure your organization and technology.
- The Lean approach to doing more consists of removing waste from the value stream, not adding more.
“I don’t want to balance demand with capacity, what I want is to increase capacity to be able to absorb all demand. I want to do everything!”
Balancing demand and capacity is the means to and end. It is not the purpose of Kanban but part of the method to achieve better productivity, time-to-market and agility. Below, there is an explanation of how we do this by applying Theory of Constraints.
If you want more, in this article, David Anderson tells us about the benefits of implementing PULL at the organizational level.
One of the six foundational principles of Kanban is “start with what you do now”, which is a nice principle, because we want to start with the current situation, accept what we have and don’t make any changes from the beginning. But, this is not quite like that. A proper Kanban adoption requires a huge mental shift from the beginning that generates a lot of resistance. Limiting WIP and going from a resource efficiency culture to a flow efficiency culture is a big step.
My recommendation here is very clear. Like any other important change in an organization, if C-level and management are not onboard with this change and don’t understand the implications, it is just not going to happen. You need to be able to explain the benefits of limiting wip and manage expectations accordingly.
In organizations where people is used to being busy all day, multi-tasking and pushing stuff downwards they freak out when I tell them they have to start pulling stuff from upstream, focusing on one thing at a time and finishing everything before starting anything else.
Based on my experience the two key sources of resistance are:
- At executive and senior management level it is mostly a lack of understanding of queueing theory and systems thinking. They believe that by adding more people more will get done. Fair enough, but false.
- At a team level it is basically fear. Fear of saying no, fear of having slack, fear of losing their job if they are not busy all day like frantic bees.
Aging – an easy way to demonstrate excess WIP
Aging is a metric that measures the amount of time a task spends in progress. In other words, the time a task spends from Commitment Point until before Delivery Point. And we demonstrate an excess of WIP by showing that Aging is much higher than Lead Time.
An aging much higher than lead time is a clear sign that there is too much WIP in the system. There is a lot of work in the system that is waiting or has been de-prioritized but still in the system consuming resources, people’s time and complicating delivery. Meanwhile, other work in the system goes through quickly.
- Why did any of that work got into the system in the first place?
- What is the criteria for committing to deliver on something?
- Why aren’t we working on the old tasks any more?
- What is preventing us from finishing old tasks?
- Why are we keeping things in progress and delaying them? Could we cancel those? Could we deliver them?
- Why are we adding more stuff if we still have a lot of stuff that has been there for weeks?
If you are using any electronic tool you can easily calculate this. Or you can also upload your data into here. If you see a result like the following one, you have a problem:
In this real example you can see a Lead Time of 140 days and an Aging of 344 days. In a balanced system percentile 85% of lead time and percentile 85% of aging should be similar. This is one of the basic assumptions that needs to be true in order to be able to apply Little’s Law.
Theory of Constraints and Demand Management
First of all we reduce intake and limit WIP in the system. This way we implement pull and we have the system operating at its maximum capacity with current constraints and without generating queues and delays.
Recommendations for limiting WIP
- Reduce WIP to the point that it starts hurting and forcing you to take decisions you didn’t have to take because you were multi-tasking with a hundred things every day. It is not until someone says “today I don’t have anything to do” that your WIP limits are starting to have some positive effect. It is not until someone says “we cannot pull anything into development although everything is done, because WIP is full because QA guys cannot pull anything because they are full”. It is not until you wonder what is the most critical task you should take next that WIP limits are working.
- If you don’t know what limit to put in you Ready to Pull / Backlog / Commitment Point put the same number as items get out of the system per replenishment cadence. For instance, if your system throughput is 5 items per week, and your replenishment cadence is weekly, limit your Ready to Pull to 5.
- Once you have designed your Kanban System push back out of the system all the items exceeding WIP limits. Starting from the right of your board, start pushing backwards any items exceeding WIP limit and decide at each step backwards which stay and which go. This is the fastest way to benefit from Kanban, instead of having to wait until your system reloads.
- Don’t freak out if you don’t have anything to do. That’s not real in most situations, and might probably be because you are too specialized. You can use your slack for many things. As an example:
- Working upstream
- Cleaning your workplace
- Helping another team member
- Talking to customers
- Helping another team
I hope this helps. If you need help with your Kanban adoption or you are thinking about an alternative path to business agility. Contact me!
Thanks for reading and sharing.