Att komma i gång med WIP-gränser

Implementing WIP limits requires us to shift, or in some cases, totally uproot some of our deepest held beliefs about the way we work. Two concepts that can be difficult to embrace for people new to Kanban are slack time and the idea of a pull system.

Slack time isn’t just for slackers

It’s not important that workers stay busy; it’s important that the work keeps moving.

Hitting a WIP limit isn’t a failure or a problem to be avoided. If a team is at its WIP limit, and a team member can’t contribute to any of the working currently on the board, the worst thing they can do is pull new work onto the board.

This work can have a downstream impact on other team members which can slow down the speed of delivery. Instead, that person should allow some slack in the system.

Slack time is a sign of a healthy, sustainable system. Team members can use slack time to implement continuous improvement efforts, plan or brainstorm upcoming projects, relieve technical debt, consume educational content, or anything else that benefits the team.

Not having slack time is the real issue, which should be seen as an opportunity to change your system so it benefits the team and its effectiveness. You should run up against your WIP limits regularly. If you don’t, they’re probably not low enough.

Team buy-in is critical; let the team set its own WIP limit.

WIP limits won’t prevent our cultural proclivity for multitasking, but they will show you the detriments that task switching can have on your work.

Push vs. pull system

Kanban seeks to “pull” rather than “push” work through your process. A push system “pushes” finished work to the next step, whereas a pull system “pulls” work from the preceding step only when it has capacity.

Limiting WIP based on capacity (a pull system) can help work flow smoothly through the board at an optimal rate. Pushing large amounts of work into the system clogs it up and slows everything down (and often makes for poor quality, too).

Remember, buy-in across the team is important. Take some time to learn about why you need to implement WIP limits, and how they can benefit your team. Then, gather around your Kanban board and spend about 30 minutes doing this exercise from our Kanban Roadmap.

Gauge average cycle time

Consider how a piece of work flows through your system by looking at a card that’s recently made it to “Done.” Preferably, choose a card that several team members worked on while it moved through most of the defined workflow on your board.

Ask: “How long did that card take to complete?” For this example, let’s say that ten days passed between the card being pulled onto the board and reaching the “Done” lane.

Observe where work sits in queues

Now, ask each person who worked on the card how much time they spent actively working on it. You’ll probably hear a much smaller number. For this example, we’ll say that your team invested a total of six hours of active work. So why did the card take 10 days to complete?

One reason to consider is queues. When step one was finished, the card waited in line for 1.5 days before anyone picked it up to start step two. The card continued in this fashion until it reached the “Done” lane. It’s fairly typical – and sometimes even worse – for a card to spend 85 percent of its time in a queue. Using WIP limits, you can keep the size of the queues in your process lower, so that each item moves more quickly from step to step.

As a team, identify all of the queues in your process. (Any place a handoff occurs is most likely a hidden queue.) Now identify the largest queues.

Implement WIP limits in overburdened lanes

Add a WIP limit to your board to try to reduce the size of one or more of the largest queues. You may add the WIP limit to the lane that has the queue, or you may find that adding a WIP limit to the lane before or after the queue reduces WIP better.

Experiment with personal WIP limits

If a team member is consistently responsible for too many work items, experiment with personal WIP limits (e.g., “Jason has a WIP limit of three. Only three items can be assigned to him at any one time.”). In general, we recommend process stage WIP limits, but if there’s a particular person who is often overloaded, it’s appropriate to use personal WIP limits.

When you hit the WIP limit, make use of slack time

When you hit a WIP limit, stop doing the kind of work that adds to that queue. Instead, let the work continue to flow through the system. Go help a teammate or work on a task that doesn’t add WIP on the board. Read a book on Kanban. Start an online class. But whatever you do, don’t pile on more WIP at this point.

After completing this exercise as a team, spend some time (two weeks or more) observing how work flows through your system with the limits in place. At the end of this period, ask the following questions:

• How many times did we hit the WIP limit?
• What caused us to hit our limit?
• What did we do when we hit our limit?
• Did the WIP limits we implemented in specific lanes help to alleviate the bottlenecks in those lanes? Do we need to adjust them to further reduce pressure in this lane?
• How many people had slack time? How long did the slack time last before they were able to pull in new work?
• Were the personal WIP limits effective in reducing pressure on specific people?
• Did anyone hide work as a way to avoid hitting the WIP limit? How do we avoid this in the future?

Adjust the WIP limits as needed to optimize flow, to increase speed without sacrificing quality. Note that as conditions change – if the team structure changes, it adds new capabilities, or new members are added – WIP limits should continually change as well.

Optimizing flow with WIP limits is a journey that never truly ends, although it does become easier over time. You may notice that as your team adjusts to this new, more disciplined and collaborative way of working, you’ll start to experience the benefits you read about before you began.