3 Steps to Successfully Implement WIP Limits

Hey there my friend, happy Thursday! Lately, I’ve been thinking about the quickest and the most effective approaches to process improvement and something came up to my mind right on the get-go.

The practice of applying WIP Limits is a game-changer when it comes to getting work done faster. However, there are also challenges to getting started. Today, we’ll look at why limiting work in progress is so powerful, and reveal the 3-step guideline to implement it successfully.

A WIP limit is exactly as its name suggests: a limit to how much work in progress you can have at a given time.

WIP limits draw a hard line in the sand, keeping you and your teams focused on delivering outstanding tasks, rather than starting new ones. They encourage team members to come together and resolve process bottlenecks to enable a smooth flow of work.

WIP limits are game-changing because they simultaneously enable you to:

• Relieve overburden
• Avoid delays
• Eliminate multitasking
• Prevent context-switching

Most importantly of all, they reduce your delivery times because the focus of the team moves from starting new things to getting things done.

I’m going to share some (very) simplified math to help illustrate the power of WIP limits even further. It’s known as Little’s Law, and it can be represented in the following way:

Cycle Time = WIP/Throughput

According to Little’s Law, in order to decrease times you need to either 1) increase throughput or 2), decrease the work in progress.

You can try to increase your throughput, but that’s usually way more challenging than putting a limit on the number of work items in progress.

While this at first may sound like you’re getting less done, the reality is the exact opposite. Because you are narrowing your focus on just a few important items at a time, you are finishing the work sooner, which in turn means that you’re delivering value to your customers faster.

The Obstacles to Getting Started with WIP Limits

So, why is it so hard to get started?

Imagine that you manage a highly specialized team and you’ve reached the amount of work in progress allowed on your Kanban board. Now, let’s say that one of your tickets requires design work and the only designer on your team is on sick leave.

None of the team members are able to move the needle so the item remains stuck.

Now, imagine that there is another item already in progress, however, the requirements are ambiguous and the team doesn’t actually understand what needs to be done altogether. The work remains stuck again.

Imposing WIP limits by sticking a number on your columns right from the start is a risky move.

If you haven’t performed your analysis upfront and this sounds like your team, the practice of limiting WIP will only lead to discouragement and frustration because there is not much they can do at this point and now they won’t be able to start new work either.

So, let’s talk about how to introduce WIP limits in a way that’s both strategic and realistic.

How to Strategically Implement WIP Limits in Your Process

See, the common misconception is that WIP limits represent a number and that’s not always the case. There are so many ways to limit your work in progress and today, I’ll reveal the three steps you can follow that’ll help you make the most of your improvement efforts.

1. Start with a Simple Policy

In the beginning, you don’t even need to bring up WIP limits. The main goal behind this practice is to focus on getting work done. So, how can we achieve the same results without putting a number on your columns?

Bring your team together and brainstorm ideas on how to achieve your desired outcome. Create an explicit process policy and gain an agreement to respect and continuously improve that policy.

It might look something 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.“

A policy like this helps you guide your team toward the exact same outcome as you’d have by restricting the number of items on the board. What it does differently is to create some space for experimentation.

As you begin using this policy, observe the outcome. Are your teams doing a good job of handling each other’s tasks? Do they feel confident using this new approach to managing the work? Do they feel empowered to identify opportunities for improvement and speak up? Awesome – it may be time to put actual WIP limits in place!

Are they still having trouble adjusting? Do they feel stuck due to obstacles outside of their control?

Then it’s time to investigate and see what the obstacles are.

Are there team members who are too specialized to work on each other items? Maybe the priorities aren’t clear, or there are way too many dependencies outside of your control. Tackle them first before you move forward with the implementation of WIP limits.

2. Move to a Per Column WIP Limit

If your team is comfortable implementing the initial simple policy and the outcomes have been positive, you’re ready to begin using actual WIP limits.

First of all, make peace with the fact that any WIP limit you impose at the beginning will be adjusted afterwards.

What’s important here is that your team is the one that decides what the limits on the work should be – because they know their own capacity best. (Also, if the team members set their own WIP limits, there won’t be a reason to break them).

Whatever number of items your team choose as the limit for each column, it should ensure that no one has to multitask and that everyone has something to do.

At this point, your team members should be comfortable enough taking on each other’s work; if the QA team needs extra help with certain tasks, for example, the development team should be able to jump on those tasks.

A word of caution here! Your board design plays a crucial role in how your team members see the work: if the column names are too focused on specializations, team members will subconsciously be more reluctant to take on work in columns outside their “area.”

Your board design should be both creative and inclusive enough that your team members see each item not as “my work”, or “their work,” but as “our work.”

3. Apply a Limit on the Entire System

Once (and only once) your team is comfortable using WIP limits on a column level can you begin transitioning to a constant work in progress: CONWIP.

A limit on the entire system simplifies and streamlines the work even further. There is no longer a limitation on a column level. Instead, we apply a limit to all cards in the Kanban system.

P.S. This practice can also be replaced with a simple process policy:

“No new work should be started before an outstanding work is delivered.”

I recommend this approach only to a team that’s already managing the flow of work effectively, and in complete unity – i.e., in which there is no focus on individuals’ performance at all but on the team’s performance as a whole.

Bonus: The Secret Hack to Revealing the Immediate Impact of Your WIP Limits

I couldn’t end this article without sharing this simple but amazing tip for how to immediately see the impact of the WIP limits you’ve implemented.

You see: when you transition to a WIP limit your positive results might actually be hidden.

For example, here we see the results of a team who has implemented a WIP limit starting in June.

A few weeks later, they used the Cycle Time Scatterplot to analyze their results and they were not delighted.

Needless to say, they felt discouraged when they looked at their results and saw that their performance didn’t really improve.

In the period between the end of June (when they first implemented WIP limits), up until the end of July, their cycle times actually remained very inconsistent and even went up.

Here is why this happens. The items that appear on the chart with a very high cycle time are the aging items they have released. These items had already been started at the moment they adopted the practice.

The reason for this, though, isn’t because the WIP limits haven’t been working: it’s because the chart is showing the completion times of work items started before their change management initiative.

So, in order to see your immediate positive results, you have to switch it up a bit:

Instead of visualizing your data on the X-axis by end date, organize it by start date.

Looking into the Cycle Time Scatterplot organized by “Start date”, it became crystal clear that their delivery system was actually behaving in a very predictable and consistent manner right after the implementation of WIP limits.

Not only is this a more accurate way to gauge the results of your WIP limits, but it also has the potential to boost team motivation and engagement with your business agility initiative!

Here is your action item: Go ahead and connect Nave to your management platform. It’s free for 14 days, no CC required! Analyze your Cycle Time Scatterplot by looking specifically at how your performance has changed after you’ve implemented WIP limits.

Spoiler alert! This approach goes hand in hand with any change management initiative you have started. Analyzing your scatterplot by start date will immediately reveal whether your improvement efforts are actually paying off.

I hope this article helped you feel more confident about how to implement WIP limits in your own teams and it would mean so much to me if you took a moment to share it with a colleague on your favorite social media channels.

Thanks so much for tuning in, and I look forward to seeing you next week, same time and place, for more managerial goodness! Bye for now.