Introducing WIP limits is one of the most powerful approaches to reduce delivery times by aligning demand with capacity and keeping the focus on the most important work. 

Often though, introducing WIP limits meets resistance from within the team. People naturally tend to stick to what they’ve always been doing: just starting more work. When the focus is on getting more work started, rather than finishing old work, the consequences can be disruptive.

How can you address this problem? Ultimately, the first thing to do is to truly understand the challenges that you might be dealing with. Instead of enforcing the practice regardless, you first need to evaluate the current state of your workflow and the maturity of your team. This will enable you to proactively avoid resistance.

Adopting WIP Limits Is a Real Game Changer

There is no doubt about it, WIP limits are the ultimate game-changer. In one fell swoop, this practice relieves overburden, eliminates multitasking and prevents context switching. Delivery times also rapidly go down, which is one of the strongest motivational boosters. What’s more, now that there is less of it at a time to handle, you’ll find that work is being done with more precision and delivered at a higher level of quality.

You can see how this works on a conceptual level by looking at Little’s Law. Little’s Law equation connects the three main flow metrics – cycle time, throughput and work in progress, and the way in which each component influences the others is self-evident: 

Cycle Time = WIP / Throughput

The Law states that, in order to decrease cycle times, you need to either increase throughput (which normally comes with a cost) or decrease the work in progress, which is usually a much more convenient step. 

Implementing WIP limits is certainly worth the effort. So why is it so hard to get started?

The Challenge of Introducing WIP Limits

The main goal of having WIP limits in place is to stop starting and start finishing. The idea is to reduce the demand to a level that aligns with the team’s capacity. This way, the team is only working on as many items as they can handle at one time, which prevents ongoing work to age artificially.

When your work in progress has a limit, your team won’t be able to pull in new work until an outstanding work item has been completed. That way, the idle team members have to focus on tackling the rest of the work in progress in order to be able to deliver sooner.

Where does the challenge come from? What if you are maintaining a highly specialized team with individuals who are unable to handle each other’s work? What if there are dependencies outside the team’s control that block the work from moving further? What if there is no clear Definition of Ready, Definition of Done and Acceptance Criteria and there is no clear understanding of what needs to be achieved overall?

If that’s the case, introducing WIP limits will probably make things worse, as it will only force the team to remain idle while still nothing is getting finished. 

Why would the team resist? Often, this would arise as a result of a lack of confidence to take the initiative and work on outstanding tasks. We, as managers, are responsible for encouraging leadership at all levels, growing autonomous teams and enabling our workers to do their jobs.

Instead of jumping into introducing WIP limits right away, you ought to ask yourself whether you’re ready to adopt that practice. Before you start designing your new Kanban system, you first need to have a conversation with your team.

Begin your initiative in the most transparent manner possible. Step by step, explain to your team your goals and intentions and what might be the challenges for all of you. Emphasize why it’s worth it and how their work-life will become much more successful. Introducing WIP limits represents the means to achieve your goals, the practice is not the goal itself. 

So what’s the effective approach to introducing WIP limits, without putting your team on the offensive?

Switching the Direction of the Conversation Altogether

A smart way to approach the situation, before you even start to talk about implementing WIP limits, is to lead your team towards a mutual agreement on the way they select what work to take on next. For a development process, it could be an explicit policy that looks like this:

Once a piece of work is finished, instead of immediately pulling a new item from the backlog, first, go through the cards on the board. Start from the far most right side column (the one before Done), then go towards the beginning of the workflow.

Look for items that are not assigned to anyone, any issues that need to be fixed (even if they are not assigned to you), anything that’s waiting for code review or implement feedback from code review.

A new item of work should only be started if there is literally nothing that you can do to help the ongoing work items move forward in the process.

Essentially, that practice is already shifting the focus to stop starting and start finishing, except it doesn’t artificially reduce the number of the items available at any one time. The goal is not to enforce the practice but to evaluate whether your team is handling this approach well and whether they are actually capable of delivering outstanding work on their own.

If that’s not the case, then your focus should switch to resolving the obstacles that prevent your team from finishing their work and preparing the ground for further improvements.

If it is, then you should probably move forward and start slowly by introducing WIP limits on a personal level and as your team matures, switch to per-column WIP limits and eventually place a WIP limit on the entire system. The most important part here is to introduce one change at a time and measure the impact. If it works, move on to the next practice. If it doesn’t – revert it back, evaluate what caused the practice to fail, and work upon its prompt resolution.

Focus on the Outcomes

To that end, you can make that first step effective by focusing on the desired outcomes, rather than jumping straight in and forcing the WIP limit practice artificially. As managers, our job is to provide teams with clear guidelines about how to handle the work to be able to achieve better outcomes.

By focusing on finishing the outstanding work before starting new work, we can effectively limit the amount of work in progress, without implementing the practice explicitly. In turn, teams are likely to respond with much less resistance and you’ll be able to focus on the impediments that would otherwise create tension and poor results.

Even though we may not be putting static WIP limits in place right away, and the amount of WIP will fluctuate a bit, this doesn’t really matter. What’s more important is that, in this first step towards successfully introducing WIP limits, you will already see significant improvements to your team’s performance. It’s a great way to achieve impressive results, without taking the risk of failing your entire improvement initiative.

The main takeaway is that you should always consider your own context and you shouldn’t get too obsessed with practices. You can achieve just as much success by focusing on the outcomes and embracing the results. Ultimately, there are no best practices in this business. There are only good practices – success lies in starting with what you do now and focusing on what works best for your teams and your business.

1 Star2 Stars3 Stars4 Stars5 Stars How helpful is this article? 6 votes