Limiting Work in Progress

L

In many organisations being busy is valued more than delivering the results. At first sight, it may sound quite reasonable – after all, we’re all paid for having hands full of work, aren’t we?

Unfortunately, it doesn’t work that way. In a vast majority of cases, the more tasks we try to complete, the less we really accomplish. And pushing yourself to work even harder doesn’t change anything.

Why is that?

The scenario described above is quite common for many teams and it’s usually caused by an excessive Work in Progress (WiP). WiP is anything that is started but not yet completed. It’s a User Story that was started, but hasn’t been Done yet – it’s either blocked, or awaiting QA, or resides in any other halfway state.

Excessive Work in Progress is harmful for several reasons that, among others, include the following:

  • It leads to mistaking activity to accomplishing valuable work.

Limiting WiP introduces slack time which is regrettably not acceptable in far too many organisations that blindly follow “100% utilisation” approach. The truth is that fair amount of slack time is desirable; it happens when any team member, for whatever reasons, is “blocked” because of WiP limits and cannot do regular work. I’ll cover slack time and 100% utilisation myth in a separate blog post.

  • It diverts our attention from what’s of the highest priority to less important tasks.

When we get blocked it’s much easier to move on to something else rather than bend over backwards to get an original task or blocker resolved. Unfortunately, in most cases it implies an implicit, ad-hoc prioritisation instead of following an original order of work (after all, an original task was of a higher priority – otherwise you wouldn’t be working on that, right?).

  • It’s exhausting mentally.

Please bear in mind that anything you have started but not finished occupies some part of your available mental capacity. And the more WIP, the more mental energy is consumed with trying to keep track of it all. Although one can argue that even with many tasks started people work only on one of them at the time, unfortunately, it’s not true – Zeigarnik Effect suggests is that our brains will be switching context despite what we consciously think it would do.

  • Context switching is a cost.

Context switching prevents us from getting into flow which is a key to being highly productive. Usually, it’s exemplified by talking about distractions and interruptions (instant messages, phone calls, etc.), but having too many tasks in progress causes the same problem – it works counter to flow. We’re most efficient when allowed to complete one thing uninterrupted. Switching between tasks requires context change and it takes time we need to get at full speed back again. Multitasking  harms our productivity.

Now, as you know that Work in Progress should be limited, the question arises how it can be achieved? The solution may differ from team to team, but the common idea is to disallow to have more stories in “in-progress-like” status (In Progress, Awaiting QA, Awaiting Code Review, Blocked, etc.) than an upfront agreed threshold. It basically means that none of the team members can take on a new item if a given number of tasks are already being processed.

This approach is usually backed with a simple guidance that whenever you finish work on an item you should check if there aren’t any unassigned tasks starting from the rightmost part of the board (that’s closest to the Done column). And you either pick one or you move one column to the left (towards To Do column) and keep repeating the whole process until you find something to work on.

Agile is not about being busy, but about delivering value to the clients. Delivering it fast to foster learning and outperform competitors. And Work in Progress limits encourage a culture of “done”. Moreover, WiP limits make impediments, blockers and bottlenecks visible and enable the team to swarm around them to get them resolved as soon as possible. WiP limits smooth the flow and increase overall team’s productivity.

So, please stop starting things and start finishing them!

 

About the author

Piotr

Head of Engineering, Agile Coach, PMP, PSM, SPS, PAL I, PAL-EBM

1 comment

By Piotr