Work in Progress: Get a Grip on Your WIP

Limiting Work In Progress (WIP) is one of the cornerstones of Agile.

When WIP is low:

• Multitasking goes down
• Feedback goes up
• Errors get caught sooner

Today we'll look at practical steps to bring your WIP down.

Back to the factory floor

Many of the systems we apply today in software development can trace their origins back to the factory floor.

In many ways, we have it easy.

If we want to change the layout of our "factory", we can do so with a white board marker.

Or the click of a mouse.

For example, it's easy to split a column into two columns.

Splitting a machine in two. Not so easy.

But the factory floor does have some advantages.

When partly-processed stock builds up, it's obvious.

In a factory, when you want to reduce the WIP, you could reduce the space available for WIP.

Do it right, and it's a hard limit.

Fill up the space here, and this machine has to be stopped.

There's no if or buts.

Practical steps

In our Agile teams, we don't have such hard physical limits.

But there are couple of things we can do to keep ourselves honest.

And make teams responsible for their own WIP - more on that in a moment.

1. Impose WIP limits

• If you're using a physical board, make the columns shorter. Less space for cards.
• If your using Jira, set a WIP limit.
• If you're using Trello: as far as I know, Trello does not support WIP limits. But there is a Chrome extension that adds the capability.

2. Distinguish between "In progress" and "waiting"

The first Kanban board I used in anger made a clear distinction between "waiting" and "in progress"

Each column had a "buffer zone" on the left and an "in progress zone" to the right.

It certainly does the job of distinguishing between waiting and in progress, but it's not perfect.

Take a look at this board.

There's a ton of work in the Test Team's buffer column.

An un-enlightened observer might be forgiven for thinking that the Test Team is out of control.

You and I know that the Test Team has done nothing wrong: it's the Dev Team that's out of control!

We can make this explicit by swapping the "buffer" and "in-progress" zones.

Same cards, same situation, slightly different board.

But it's now obvious that it's the Dev Team has created the excess WIP.

Buffer zones for Jira and Trello?

We mentioned Jira and Trello earlier.

I confess that I've only used "buffer zones" on physical boards - never on an electronic board.

If you're have experience of adding buffer zones to a Jira or Trello , I'd love to hear from you.