Do nothing when it’s time rather than obstruct pipes
This is the 9th post from my sincere dev manifesto series.
Every time a task is blocked, we stop… and in general, we move to another task. Our biases make us scared of the void. We need to feel useful, by taking tickets on the board, by doing something. Every time we do so, we violate a more or less explicit agreement we have in the team: we agreed that the blocked task was a priority in the first place, so our duty is to concentrate our time and effort on unblocking it.
When we move tasks with less priority while higher-priority tasks still ask for moving forward, we don’t only take capacity from high-priority tasks. We also add noise to the system, further reducing our capacity in general.
Fear of the void is central to flow management and WIP limits. WIP limit means: we agree to have no more than N things in a given state at a given time. When we reach the limit in a state, we agree to stop pulling things to this state. Because we know that when we push more water into a pipe that it can handle, it spits it back at us. “Stop” is the word to remember here.
In general, I see people stop… pulling tickets, and anticipate tickets from the previous column anyway. You can see this when there’s a rush to open pull requests as soon as a slot is freed by an item moving to the next column. Several tickets were already developed on devs machines.
When some constraint capacity is full, we can do more than our basic job, by:
- Helping accelerating downstream tasks. We all have preferences, but when we are more useful providing a suboptimal help, we just need to do it.
- Helping colleagues traditionally working in the same column as us, by pairing or mobbing.
- Preparing future tasks, with the constraint that we must remain interruptible anytime, and be able to go back to priorities when the stream has room for them.
- Learning, training, understanding.
All of these mean, from the backlog’s point of view, do nothing. It’s the right thing to do, and it’s always a struggle, with yourself and with your managers. You can always try to explain that items flying around are immobilized cash, who knows.
The theory of constraints says that to optimize the flow of a system:
- Identify the system’s constraint(s).
- Decide how to exploit the system’s constraint(s).
- Subordinate everything else to the above decision.
- Elevate the system’s constraint(s).
- Go back to step 1.
Oh by the way. In lean, when the WIP limits does not block tasks anymore, we decrease them on purpose, in order to expose the next problem to solve, and thus understand and improve.
I commit to leaving room for high priorities, by doing nothing when they already take the capacity of a constraint.
AAAgile 
One comment