There might be a software team somewhere that doesn’t have a backlog that will last them years1. I don’t exclude that they exist and pardon my ignorance and naivety for overlooking them. In my experience though, people always have more ideas than they can physically build. “Backlogs” becomes a blackhole to the point where answering “it is in our backlog” is neither a re-assuring statement, nor does it feel an ingenuous response.
Work is like a liquid, it is incompressible. The time required for a task is the time it takes. You can look for more skilled people, you can gamble on quality, or you can trim the scope, but overall with the cards you are dealt and the goal you need to achieve, you need to achieve a raw amount of work that cannot be compressed.
People are inherently incapable of truly multi-tasking. At any given time, a person can work only on a single thing. The common statement “I’m working on too many things” is incorrect. What is actually meant is: I’m serializing2 different tasks, and I have too many of these tasks.
Maximum capacity is an interesting concept that civil engineers use when designing highways. When more than a certain number of cars are travelling on the highway at the same time, the flow breaks, and the entirety of the traffic slows down. Some high density areas have set-up red-lights on highway exchanges to help reducing the actual flow on the highway, increasing the overall flow. Solution is proven and works.
Like a highway, people have a maximum capacity for these serialized tasks, after which adding more breaks the flow entirely. This maximum capacity is often 1, and can go a bit beyond for tasks that involve a lot of waiting on others. For software engineers, whose work involves a lot of thinking and deep work, it is not much higher than 1.
Let’s beat that dead horse again: when you actually work on one task, you cannot physically work on another. Taking two tasks means that in the best case, the time it will take to deliver both “parallelized” tasks will be the sum of the work, which, as we said, is incompressible. More realistically it will be even worse than that because of context switching. Of course there’s some nuance there because most work requires some interaction that will put it on pause, and so the highest you can do efficiently is probably slightly over 1. But you get the idea.
What is true at a personal level is true at a team level, with the additional complexity created by cross-dependencies. If you are waiting on someone else to give you a piece of software but they’re working on something else, the whole system’s output decreases. This is nothing new, work in process needs to be limited. Lean and all that good stuff. Limiting WIP is the same thing as a red light on the highway entrance: you set a limit to make sure that your team still outputs stuff.
If you have WIP limits3, then you are already using maximum capacity. You are foot to the floor. There is nothing more you can juice out of the team. When you - or most likely, someone else - wants your team to start more work, it is not about capacity. You don’t have more capacity. It is about priority.
The highway is flowing freely, but the light is red and there’s a line-up. There are only three things you can control:
- the order of the cars at the red-light.
- if an emergency vehicle comes with its lights out, stop some of the cars already on the highway to the side and let it go through (knowing that these cars will arrive late or fail to restart). If you have emergency vehicles often, consider lowering maximum capacity and reserving a line for such cases.
- use another highway whose cars are not as important.
All three are just a variation of where you change the priority: in-flight, in the backlog, or in another team’s/person’s backlog.
Stop asking “do you have capacity?”. It is never about capacity, it is always about priority.
Review what’s planned next and re-prioritize, hopefully with an economic framework and data, or lacking that, using your best judgement. If it is a real emergency, stop some of the work, and accept that it will be delivered later. If nothing can be re-prioritized in this team, look for another one that might be working on something less important.
Don’t ask “do you have time to” or “is someone in your team free to” or “is there capacity in your team to”, ask “where in your prioritized todo list can I sort this thing that I’m bringing”.