During the fire drill in our office the other day an interesting thing happened. Rather than taking the exit nearest to us, we rushed to the middle of the building to take the stairs next to the elevators. The additional loading created congestion on the middle staircase and a long queue. As a result, we weren’t able to evacuate the building in the desired time. Basically, our “cycle time” to get to the bottom was much longer during the fire drill than normal.
Whilst this might sound irrelevant, we actually experience a similarly complex situation every day when delivering software solutions. If we start working on too many requirements or push a large package of work onto a team we see the very same slowdown in the speed of delivery.
Unlike the stairwell (where we see people piling up), or in a manufacturing factory (where we see physical parts and components piling up), in software development the work-in-progress and queues are mostly invisible. The congestion is hidden from most of us in partially-completed work that we temporarily store as bits and bytes on very large hard drives. In software development, queues are in the form of information: half-understood problems, and half-discovered solutions. Bits of analysis here and there, often on emails. Half-written specifications or use cases. Testing scripts that aren’t quite complete.
It is not only amount of work-in-progress that creates congestion but also the time we spend switching focus from one piece of work to another, and back again. Every time you switch tasks you need to reset, remember the problem and your thoughts about how it might be solved, and then get set up to tackle the next bit of the task. All of this takes time and slows down delivery. We might be extremely busy working on several things at the same time but not getting very far at all. Motion is not progress. Being busy is not the same as getting things done.
As our Fire Drill demonstrated – congestion in the pipeline slows down delivery.
How might we prevent the congestion that slows down software development?
Step 1. Visualise your Work-in-Progress
Visualise your Work-In-Progress on a Kanban board, focus on visualising the End-to-End process not only your part of the process! This gives you a snapshot of the current status of your pipeline and you can easily spot your queues and congestion.
Step 2. Actively manage Work-in-Progress
We need to be actively managing our work-in-progress to make sure that teams neither starve, nor get over-loaded with work. Preventing starvation is relatively easy: make sure that there are requirements available for the delivery team to “pull” from a “Backlog” whenever they have capacity (but don’t let it pile up, analysis goes stale very quickly). Preventing congestion is a bit more of a black art. We should experiments with setting a WIP limit. This is rather a counter-intuitive practice, so it’s perfectly natural for our brains to reject this. On the other hand setting a WIP limit is a safe to fail experiment that you can run with – set the limit, measure cycle time and adjust.