Limit the work

Work in progress is waste

Lean, the way of working Toyota built and Kanban comes from, names seven kinds of waste: things that cost effort and give the customer nothing. One of them is inventory: parts made and not yet sold. In software, inventory is work started and not finished; Mary and Tom Poppendieck put "partially done work" first on their list of the wastes of software development.

Every card in progress on that wall is inventory. It has been paid for and it gives nobody anything yet. While it waits, its branch drifts away from everybody else's, the person who wrote it forgets the details, the reviewer has to learn it again, and the customer who asked for it is still waiting.

And less of it is how the wait gets shorter. On any board, the cycle time is the work in progress divided by what the team finishes: 24 cards at 10 a week is 2.4 weeks, the 12 days of the last chapter. A team cannot finish twice as much tomorrow, but it can hold half as much today, and at the same pace, half the cards in progress means half the wait. That is Little's Law, and it is the reason for everything that follows.

Limiting work

Same eight people, same skills, same work. Three numbers added to the wall, how many cards each phase may hold, and nothing else changed at all.

That is all Kanban asks of a team. Keep your steps, your roles, your titles and your way of working: draw them on a wall, agree what "done" means for each step, and limit how much each may hold. Nothing is thrown out, which is why it is quick to try and quick to judge.

Implement's limit is eight: one card per developer. The limit belongs to the phase, and Open and Done share it, because what is being limited is how much the team has started and not finished. Two columns sit outside the count on purpose: Locked, because a card nobody can move is not work it would help to block, and Validate › Done, because from there CI owns it and no person is holding it up. Backlog and Deploy get no limit at all: one is before the clock starts, the other after it stops.

What it does

The board

One card each: 8 · 3 · 3

Finished a week

9.6

In progress

12.5

Cycle time

6.5 days

Constraint

Implement

The team finishes about as much as before, 9.6 items a week instead of 10.0, and a change now takes 6.5 days instead of 12. Half the waste, half the wait, for the same work. The oldest card on the wall is a week old instead of more than two.

Moving work forward, as a team

A limit only helps if people do something useful when it stops them. With Implement full, a developer cannot start a ninth card. So what now?

It is natural to count your own work: the cards you finished. But a customer only gets a change once it has been built, reviewed, validated and shipped, and what the team wants low is the time that takes. So the useful move is to take a card somebody else built one step further: review it now, validate it now, pair on the one that is stuck. Lean calls this optimising the flow of the work rather than how busy each person is: flow efficiency over resource efficiency, in Modig and Åhlström's This Is Lean.

The same eight people, three ways:

When everybody builds their own cards and one person reviews, the developers are busy all day and the team finishes 5 items a week: what the reviewer can get through. The rest piles up in front of Review, for ever. Add the limits and the pile stops, but the developers now spend half their days waiting for room. Only when whoever is stopped by the limit reviews and validates does the team finish 9.6 items a week, twice as much, with the same people, in 6.5 days.

"Stop starting, start finishing" is the slogan for this, and a WIP limit turns it from a poster into a rule the board keeps on its own, at the only moment it is useful: when somebody is about to start another card instead of moving one forward.

Then you tune it

The limits are a first guess, and no book can tell a team the right ones. Tuning means changing them a little and watching two numbers, both on the stats page: the cycle time, and whether anybody spends days with nothing they are allowed to pick up. A good place to start: one card per person in the phase where the work is built, and two or three in Review and Validate, so there is always something waiting to be reviewed but never a pile of it.

The board

Loose: 12 · 3 · 3

Finished a week

9.2

In progress

16.3

Cycle time

8.8 days

Constraint

Implement

Too loose, and the juggling comes back. Twelve cards for eight developers means half of them can still carry two, and a change takes 8.8 days instead of 6.5. The board looks calm, and the wait is back.

The board

Too tight: 6 · 2 · 2

Finished a week

7.1

In progress

8.9

Cycle time

6.2 days

Constraint

Implement

Too tight, and people run out of work. Six cards for eight developers leaves two of them with nothing to build most days (28% of the developers' days go idle), and the week drops to 7.1 items while the cycle time hardly improves: a card was never waiting for a slot, it was waiting for a person.

So change one number at a time, give it a couple of weeks, and look at both numbers again. Keep tightening while the cycle time falls; stop when people start standing idle.

Three years of simulated working days for each board. Eight developers throughout; the only difference is the three limits. Press play on any of them:

One card per developer. Waiting on something, the only moves left are the useful ones: review, validate, help. The same work gets done in half the time.