--- title: ['The Importance', 'of Backpressure'] description: "Kanban cards were backpressure in physical form: a fixed number in circulation, so upstream could not outrun downstream. Software kept the board and dropped the pressure. With agents producing faster than I can merge, I have to put it back. My card is the PR." --- In [Never Pick It Up Twice](/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. Pen and ink sketch of a delighted bear riding a tricycle, one leg kicked out, spinning two plates on poles, with broken plates in the grass behind. 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](/more-attention-not-less/) 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: 1. **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. 1. **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. 1. **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](/more-attention-not-less/) 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. ### FOOTNOTES [^1]: [Backpressure](https://www.reactive-manifesto.org/glossary#Back-Pressure) in software: reactive streams, TCP flow control and bounded queues are all the same idea, a consumer telling a producer to wait. [^2]: The original [kanban](https://en.wikipedia.org/wiki/Kanban) was Taiichi Ohno's scheduling system at Toyota, and the cap on cards was the cap on inventory. [^3]: David Anderson's [Kanban](https://en.wikipedia.org/wiki/Kanban_(development)) made the WIP limit explicit policy for software in 2010, but in most digital tools it's an optional number on a column, and optional tends to mean off.