The Nature of Flow
Why software development processes stall easily, and what you can do about it.
In the last koan, a developer tells a Master that the more work they’re given, the less work gets done.
That’s a wink to Little’s Law, a concept in queueing theory. According to Little’s Law, the time to complete a task is a function of the number of tasks coming in, multiplied by the average time needed to complete each task.
Put simply, lead times increase with every task that you add to the backlog.
As long as you’re a team of one, this increase is more or less predictable. But once more people are involved, another, more insidious force comes into play.
In team work, tasks need to be handed over. And it’s critical how these handovers are managed.
What happens in most teams is that everybody keep themselves busy. Intuitively, that seems like the most efficient thing to do – after all, things can’t go faster than when everyone is working all the time, right?
Unfortunately, things don’t work that way. On the contrary, working to maximum capacity is a sure-fire way to cripple a development process.
What we need to find instead is “flow” — the sweet spot where tasks are completed at a pace that achieves maximum economic value.
At what backlog size do we achieve “flow”? You can only find out by measuring it, but in any event it is somewhere between:
- one task (where waiting time is zero), and
- as many tasks needed to keep everyone busy (where almost nothing gets done).
To put it simply, you can have:
- either, tasks moving fast,
- or, people moving fast,
but you can’t have both at the same time.
At one extreme, the task progresses quickly, because people are always available to work their part on it. On the flip side, that means they’ll be idling most of the time.
In the second extreme, the task barely moves, because whenever it is handed over, the next person isn’t available to work on it.
With a grasp of this principle, experimenting over a few development cycles will help you find the sweet spot.
You will notice that that sweet spot is more like a range: there is some room for error, and you’ll get most of the payoff by getting close enough.
Whatever you do, avoid planning to full capacity. Control your backlog to keep it close to its optimum size. Before planning more, think of Little!