For most of my career the teams I worked on ran several projects at once. It never felt like a decision. There were four things the business wanted and eight engineers, so everyone had two. Nobody wrote that down as a strategy. It just happened, the way a kitchen drawer fills up.
Two years ago I ran an experiment with a team of six. For twelve months we would work on exactly one thing at a time. Not one thing each. One thing, for all of us, until it shipped or we killed it.
What we expected
We expected to be slower. The roadmap had nine items on it and the arithmetic looked bad: if each took six weeks with everybody on it, we would finish about eight. Running three in parallel, the plan said we would finish all nine with room to spare.
The plan was wrong, which plans usually are, but it was wrong in an interesting direction.
How we chose the order
The hard part was not the working. It was the queueing, and we argued about it for a fortnight before agreeing three rules and stopping:
- Anything blocking another team went first, however small. Our backlog was not the only backlog in the building.
- Of the rest, we took whatever we understood best, not whatever was biggest. A well-understood six weeks beats a vague three.
- Nothing jumped the queue without something else leaving it. If the sales team wanted their integration next, they had to say which of the nine would wait, out loud, to the person who had asked for that one.
The third rule did more for our roadmap than any prioritisation framework I have used. It turned “everything is urgent” into a conversation between two people who both wanted something, and that is a conversation that resolves.
What actually happened
The first quarter was worse. We shipped one thing where we would normally have shipped three half-things, and the people waiting for the other two were not pleased. I spent a lot of that quarter explaining that their project was next, which is a sentence nobody enjoys hearing.
Then it turned. By the end of the year we had shipped eleven things, not nine. Some of that was luck: two turned out to be far smaller than we thought once we were inside them. Most of it came from four changes I had not predicted:
- Code review stopped being a queue. When everyone is in the same code, everyone already has the context, and reviews came back in an hour instead of a day and a half.
- Decisions got made in the room. Nobody needed a meeting to catch up, because nobody was missing anything.
- Nothing sat at ninety per cent. Parallel work builds a shelf of almost-finished things, and the last tenth of each one is where the bugs live.
- Testing got sharper. After three weeks in one part of the system, people know where it is thin, and QA stopped being an archaeology exercise.
The numbers
I am suspicious of tidy metrics, but two of ours moved far enough that I think they mean something.
Median cycle time, first commit to production, went from thirty-four days to eleven. Almost all of the difference was waiting rather than working: waiting for review, waiting for someone to return to a branch they had abandoned, waiting on a decision from a person who was inside a different project that week.
Escaped defects, the bugs our customers found rather than we did, fell by roughly half over the second half of the year. I would not claim the experiment caused all of that. I would claim that finishing one thing properly leaves fewer half-open trapdoors than finishing three things roughly.
The number that did not move was hours worked. This was not a productivity trick. The same people worked the same week, and more of that week turned into something finished.
What it cost
It was not free. Some people found it boring, and one very good engineer left partly because of it; she wanted a thing of her own, and I understand why. Urgent work still arrived and had to jump the queue, and every time it did we paid for the switch in lost days.
It also made the waiting visible. When three projects run at once, everybody’s project is technically in progress, and that feels like being looked after. With one at a time, people can see exactly where they are in the line. That is more honest and considerably less comfortable, and twice I nearly abandoned the whole thing to make a stakeholder feel better.
The support rota was the one exception we allowed ourselves. One person a week took the interruptions, the bugs and the questions, and the other five stayed on the thing. Without that valve I think it would have collapsed by March.
What I would do differently
I would not insist on one. Two is probably right for most teams: one main thing, and one small thing that can be dropped without guilt. What I would insist on is that the number is chosen, written down and defended, rather than being whatever the drawer happens to hold that month.
I would also put the queue on a wall where other teams can see it, and update it on the same day each week. Most of the anxiety about “when do you get to mine” is really anxiety about not knowing, and a list on a wall answers that for nothing.
The thing I remember most is how quiet the year was. Fewer status updates, fewer handovers, fewer Friday afternoons spent working out where something had got to. I had assumed the noise was the work. It turned out to be mostly the cost of doing several pieces of work at once.
Leave a Reply