In Never Pick It Up Twice I said that limiting Work-in-Progress (WIP) was the hardest of the three Toyota lessons. This short is about why, and what the fix looks like. The fix has a name: backpressure.
Backpressure is how slow consumer communicates to a fast producer. In a stream, a queue or a network stack, the downstream side signals that it's full and the upstream side stops (or slows) sending. Without it, buffers grow until something falls over[1]. Any system that moves work between parts running at different speeds needs it, and a developer with a team of agents is exactly that kind of system.
Toyota had backpressure before software had the word. "Kanban" means signboard, or card. On the line it was a physical card attached to a bin of parts. When the bin emptied, the card went back upstream as the signal to make more. There was a fixed number of cards in circulation, so there was a fixed amount of inventory on the floor, and upstream could not outrun downstream however fast it wanted to go[2].
The board came later. When software adopted Kanban, the columns survived and the pressure became a setting. A physical column holds about as many cards as fit on the wall. A digital column holds as many as you like, and in my experience the WIP limit is the first thing to be turned off or ignored[3].
We kept the skeuomorph of the card and discarded the constraint. The constraint was the point. The backlog can just grow.
Agents remove whatever backpressure was left. Starting used to cost something: a ticket, a branch, an hour of getting into it. That cost was a brake, even if nobody designed it as one. Now starting costs a prompt. The producer got fast and the consumer, which is me reviewing and merging, did not. Inventory piles up before you notice, and every open Pull Request (PR) is a context I'll eventually have to reload. I run 5-10 epics at a time, each in its own thread, and even with that structure the PRs underneath multiply if nothing pushes back.
So I have to put the pressure back by hand. For me the card is the PR. Not the ticket, not the epic, not the chat thread. The PR is the unit that conflicts, that waits on review, that needs me to come back to it. So that's where the limit goes.
The mechanism doesn't need to be complex. Three versions that work for me:
-
Cap the open PRs. Pick a number. When you're at it, you don't start anything. You review, fix, merge or close until a slot opens. That's it. The limit is what turns push into pull: the next thing I do is whatever gets an existing PR out the door, not whatever looks interesting.
-
Give the automated agents their own cap. Automated agents make this far worse. I have automations for bugfixes, patching and FIXMEs, and left alone they'd fill the queue by lunchtime. So each one is held to a fixed number of open PRs. If a PR merges on its own, great. Otherwise the agent waits for a slot before adding to the pile. The work then becomes getting more of those PRs to merge with no intervention from me.
-
Use a pomodoro. The first two limit the count. This one limits the time. Set a timer, and while it runs, start whatever you like. When it goes off, stop prompting and drain: review, merge, close, until the queue is empty or the next timer starts. It's the same card in a different shape. It's a processing loop for me. I burn down the list before I can run off and create more work.
All three are the cheapest way to never pick something up twice. A PR that merges within the hour gets touched once. A PR that sits for two days behind nine others gets re-read every time I go near it, and that reloading is where my attention actually goes.
To be fair, this is the one I'm worst at. The limit feels arbitrary when an agent has a finished PR ready and I'm telling it to wait. But the physical card was arbitrary too. Nobody on the line argued for more bins. The number was the system.
Manage WIP. Set the number, and when you hit it, finish before you start. The agents won't slow down on their own - nor do you want them to. So the pressure has to come from you.