Lesson 91
Every handover leaks
Every children's party has a round of Chinese whispers. Twelve kids in a line. The first one hears "Grandma's bringing a trifle". By the end of the line it's "Grandad's got a rifle", and somebody's crying.
Software delivery is the same game, played over six months with a much bigger budget. A user says something true in a research session. The researcher writes it up. The business analyst turns the write-up into requirements. The product owner turns those into a backlog, the ranked list of work to do. The designer draws the backlog. The developer builds the drawing. The tester checks the build against the backlog, which nobody has compared with the research since March. Then it ships, and the user who said the true thing gets a rifle.
None of those stages is wrong. The lifecycle hasn't changed: market insight, user research, analysis, product decisions, build, release, then measure and learn. All of it still happens on every good team I've worked in. The leak is in the gaps. Every handover is someone summarising for someone who wasn't in the room, and a summary is a lossy file format. The why goes first, then the edge case, then whatever the client said in the lift.
Here's the relay, leg by leg. The stage names vary by organisation, and so do the job titles, but every team I've worked in runs some version of it.
| Stage | What happens | Traditionally done by | What gets handed on | What typically leaks |
|---|---|---|---|---|
| Insight | Spotting a problem worth solving: complaints, numbers, a rival's launch | Strategy people, a director, the HiPPO | A business case, or a slide | The evidence. By the time it's a slide, it's an opinion with a logo |
| Research | Watching and talking to the people who have the problem | User researchers | A report, some personas | The user's own words, and anything that didn't fit a theme |
| Analysis | Turning findings into what the system must do | Business analysts | A list of requirements | Why each requirement exists |
| Product | Deciding what gets built first, and what never does | Product owner, designers | A ranked backlog and some designs | What was turned down and why, and the awkward edge cases |
| Build | Writing the code and checking it works | Engineers and testers | Working software | The shortcuts taken and the bits marked "out of scope" |
| Release | Getting it to real users safely | An operations team, a change board (the committee that approves releases) | A release, and a change ticket | Who it was for and what to watch for |
| Measure and learn | Checking whether it did what we hoped, and choosing what next | Analysts, product | A dashboard, a slide for the steering committee | The original question. Nobody remembers what "better" meant |
Read the last column top to bottom. That's the trifle turning into a rifle, one perfectly reasonable summary at a time.
I did a maths degree, so you get a diagram. Mathematicians have a word for a chain that doesn't leak. They call it exact.
Delivery has never been exact. If each handover keeps 85% of what it was given, which would be a very good day, six handovers leave you 38% of the original. That's a game of whispers with a Gantt chart.
Now look at the product review in lesson 87. Two of us, a recorder running, the live site on the screen. In the five-minute huddle afterwards I hit go, and ten minutes later the changes are in. The insight, the decision and the build happened with the same two people inside a quarter of an hour. Nothing got summarised, so nothing leaked.
The faster build is nice. The missing handovers are what make it work.
Same stages, new shape. Look back at the diagram in lesson 86: every one of the 7 stages is still there, with a person deciding and an agent typing. What changes is the gaps. Insight and research happen with the user on the call. Analysis and product decisions get made in the room, while the build happens on the screen in front of them. Release is a button, and measuring gets built in on day one, so learning starts the morning after. Part 5 goes round the lifecycle in that new shape, stage by stage.
The lessonThe lifecycle stays the same, but every handover between its stages loses something. Do the stages together, with the people who know, and there's nothing to hand over.
Why it works
Handovers exist because building was slow. When the build took months, you needed a relay of specialists: one to find out, one to write it down, one to decide, one to make. Every baton was a document. Now the person who heard the user can watch the change appear while the user's words are still warm.
It ends the blame game, too. In a relay, every leak happened somewhere else. "That wasn't in the requirements." "That wasn't in the design." In one room there's nobody to blame but the people in it, and they can fix it before the coffee goes cold.
Context switching is a handover to yourself. Put the work down on Tuesday, pick it up the following Monday, and you're the seventh kid in the line trying to remember whether it was a trifle or a rifle.
- Draw your lifecycle on a whiteboard and put a red cross on every handover. Remove the most expensive one first.
- Bring the build into the workshop. Have someone producing the thing while the people who know are still in the room.
- Record your reviews and act on them in the huddle afterwards, not next sprint.
Some whispers are worth their loss. A security review or an audit should be done by someone who wasn't in the room. They haven't drunk your Kool-Aid, and that's the job.
A big programme won't fit in one room. Keep the rooms small and the batons few, and write the decisions down where everyone reads them (lesson 99).