Value Stream

There is a state where everyone's own stage is fast and the whole thing is slow. Planning finishes in two days, design in two, development in three. And the gap between the day a request arrives and the day a customer sees it is twelve days.

Mia asked about that at Pagedeck. Why does one wording change take two weeks? The answers came back: Noa said design was two days, Theo said development was three, and both were true. Nobody described their own stage as slow, and the whole was slow.

What was missing sat between the stages. The four days a finished plan waited its turn with design, the two days a finished mockup waited for review, the three days a change waited on code review — none of it landed in anybody's working time. Looking only at your own stage, that time appears on nobody's screen, and no status report has a column for it either. A value stream changes the unit of observation from a person to a single piece of work, in order to make that time visible.

Lay out the path one piece of work travelled, with the times attached. Five steps.

1. Pick one item that actually finished. It has to be something that really shipped last month, not an imagined procedure. Choose a representative, ordinary size and avoid the largest and smallest, because the outliers tell you about themselves rather than about the path.
2. Write the stages it passed through in order. Request received, planning, design, design review, development, code review, release. This is not the org chart transcribed. The unit is the journey of one item rather than one person's job, so a single team can split across two stages and two teams can share one.
3. Record two numbers per stage: time actually worked and time spent waiting. Separating those two is the whole point of the picture. Merged into one cell, a stage that took four days looks like four days of work. Split into three days waiting and one day working, it becomes obvious that what needs fixing there is not design speed but the way work queues for a turn.
4. Look at the totals. The whole span from arrival to finish is lead time, and the share of it that was worked on is flow efficiency. Three days of work inside twelve is 25 percent. Teams measuring for the first time usually land under 15 percent.
5. Pick the single longest wait. The slowest stage, the one that sets the pace for everything, is the bottleneck, and improvement only registers there. In the example above it is the four days waiting for design, not the three days of development that feel like the biggest number on the board.

A low number does not mean the team is idle. While one item waits, that person is holding another one. So the direction this picture points is not toward making people busier but toward removing the waiting. It is also why waiting counts as waste at all: four days when nobody worked are still four days the customer waited.

Its most common use is choosing what to improve. Improvement ideas always arrive several at a time, and this picture lets you pick the one that shortens the total. Chosen on instinct, the target is usually a visible working stage, and those are already fast. Buying a faster build machine feels like progress next to asking someone to review twice a week, and only one of the two moves the total.

It also settles arguments at team boundaries. The places where work stalls longest tend to be stages nobody thought of as theirs. Two days of a finished mockup waiting for review belongs neither to design's time nor to development's, so it never comes up in a meeting until it is written on the picture.

It is not a product-development-only idea. The path from an application being submitted to someone joining, from a support ticket arriving to being resolved, from a contract entering review to being signed — all of it maps the same way. In hiring, the days between an interview and the write-up moving to the next stage are a common bottleneck, and during those days the candidate collects other offers.

Two cautions. One is that a single item proves nothing. Map five to ten and you find out whether the stall is always in the same stage or moves around. A queue that appears in eight of ten is structural; one that appears twice was somebody's holiday. The other is the picture becoming the goal. Spend three days producing something to pin on a wall, improve nothing, and those three days are new waste. One stage fixed beats a complete map nobody acts on.

"Every stage is fast and lead time is twelve days. We need to look between them."

The answer is in the waiting, not in the working.

"This round we're only touching the four-day wait for design review. Everything else stays."

Concentrating on one bottleneck to shorten the total.

"Turns out this stage never had an owner."

Drawing the picture surfaced a stage nobody was responsible for.

Mia took eight wording-change items and wrote out the time per stage. Worked time averaged three days; the total averaged eleven. The longest wait was the queue for design review, caused by Noa batching all reviews into one day a week.

Splitting reviews across two days a week brought the same kind of work down to seven days on average. Not one hour of working time was removed. Theo saw the result and split code review the same way, which took another two days out of the same path.

The most common mistake is treating a value stream as a process flowchart. Boxes joined by arrows look identical either way. The difference is whether time is written on it. A picture of the sequence alone confirms what everyone already knew; a picture with worked time and waiting time per stage surfaces queues nobody knew about. Left in place, teams draw the diagram and cannot find anything to fix. The conclusion from an arrows-only diagram is usually to remove a stage, and the queue that was eating the time stays exactly where it was afterwards.

The second is assuming that speeding up one stage speeds up the whole. If the stages add up to the total, that follows. In practice, improving anything outside the bottleneck leaves the total almost unchanged. Cut development from three days to two while code review still waits three and twelve days becomes eleven. Meanwhile the four-day queue goes untouched, and the team that got pushed for that one day is the one that was already fast.