Ten times faster at eight per cent of the job

TL;DR: In a typical software shop, building takes about one hour in twelve of a task’s life. Work spends the other eleven waiting, before the build and after it. A model ten times faster shortens the one hour, so we will measure the eleven before we pay for speed.

The insight

In a software factory the build is the smallest slice of a piece of work’s life. A task starts as an idea, waits for someone to decide it is worth doing, waits for room in the queue, gets built, then waits for review, for a test machine and for a release. The building is the part everyone can see and the part every vendor sells. It is also the part that takes the least time.

That changes what a faster model is worth. If the build is a twelfth of the whole, agents that build ten times faster can cut at most a twelfth from the total, and in practice less, because the finished work then joins a longer queue at the next stage. Mik Kersten, in his book Output to Outcome from IT Revolution, compares it to a jammed motorway on-ramp: the capacity of the road beyond does not matter while you are stuck waiting to merge. What we took from him is the order of operations, which is to measure how long work waits at each stage before touching how fast the builders run. Almost every factory owner, me included, reaches first for a faster or cheaper model, and the evidence says that buys almost nothing until you know how long work waits on either side of the build.

In practice

Only the middle slice of that bar is building. Work spends the rest waiting for a business case, an approval, capacity, a test or a release.

Kersten’s book reports that Vanguard instrumented its own pipeline and found that building a feature took twenty days on average, releasing it fifty, and deciding to do it a hundred and twenty. The cause was load rather than slow builders: each team had more than fifty major items in progress at once. Cutting that load instead of speeding the builders improved flow by more than a third in ten months, over double the target the team had set.

What we’ll try next

Our stages are not departments passing paper to each other. They are queues between agents: a task waits for one of the factory’s loops, the small scheduled programs that do the work, to wake; waits for a reviewer; waits for the one test machine; and waits for Peter’s thumb. An earlier post, “Shrink the question until a thumb can answer it”, priced one of those waits, the human decision, by the time the factory idles while it stands open. The change now is to price all of them the same way. We are building a table with one row per stage of a task’s life and one column for how long work sits there. Until that table exists and shows that the build is the slice that matters, we will not change which model does the building.

One honest number

Eight per cent. That is the share of a work item’s end-to-end flow time spent creating software, from the first figure in Kersten’s book, with the data behind it from Planview’s industry report; the other 92 per cent splits 48 upstream and 44 downstream. Our own figure will differ, because our waits sit between loops rather than between departments, and we do not yet know whether it is higher or lower. That is the point of building the table before spending on the agents. Until it is done, buying speed is paying to shorten the shortest part of the job.