Reducing time spent in queues

Many teams across DWP and government are now using kanban boards to visualise the work going on in their team. However, this is only one part of kanban. Whilst it is an important first stage to map out the flow work takes to delivery, and to visualise what work the team has going on, the main value of kanban comes in using it to then improve the flow of your work. The way kanban does this is through limiting work in progress. It is the most important aspect of kanban, but it is often neglected.

Why should we limit work in progress? Because we want to spend less time in queues.

There are generally two types of queues on a kanban board, the “done” queue in each column waiting to be picked up by the next stage, and the “doing” queue of partially done work. These queues cause several problems:

Increasing the time it takes to deliver

When a work item is sitting in a queue waiting to be picked up, no work is happening on that item it is just sitting there. The longer the queue is, the longer it will be sitting there waiting. A task that might only take half a day could be sat in a queue for many days with other work ahead of it. If that item of work has to go through multiple queues as it works its way along the kanban board, these delays start to add up. An item of work that you estimate will only take a few days because each stage is short will take much longer due to the time taken waiting to be picked up by each stage. The users want the finished product and they want it quickly, it doesn’t matter how fast you can do each stage if in between it sits waiting in a queue.

In my team we have found that work in progress limits encourage team members to help out elsewhere rather than adding to an internal queue. This speeds up the time it takes us to deliver partially completed work, rather than starting on new work and adding to our pile of partially done work.

Don’t add to your personal queue until you finish!

Work getting out of date

Whilst this work item is sitting in queues, it is also getting stale. Analysis might be out of date by the time the work comes to be coded, the code could be clashing with something else by the time it is released to live. The quicker the work item can get through the board, the less likely extra work will have to be done to it to get it ready again for release.

Because work in progress limits reduce the time between work getting started and being finished by reducing the length of each queue, the analysis and code has less time to go out of date.

Blockers don’t get removed

If you have a long queue work to do and a blocker comes up on one of them, you are likely to move on to something else rather than focusing on getting it fixed. You will then come back to that piece of work to find nothing has been done about the blocker.

Work in progress limits focuses the team on removing blockers as it prevents them from working on anything else.

Fix the blocker, don’t ignore it by working on something else

Context switching increases the time it takes to complete a task

The queue of partially done work needs to be kept short to prevent task switching. In each column, there will generally be a limited number of people who can do that work. If they have a long list of things they are working on, they will be switching between each of these items. Each time they drop one piece of work to pick up another, they need to spend time getting up to speed again. Again, a piece of work that should only take half a day will take much longer if you are working on other things at the same time.

Personal work in progress limits and a limit on the number of items available to pick up reduces time switching between tasks by focusing people on one or two tasks at a time. This is one that we can all try to apply, even if you aren’t working using a kanban board!

Working on multiple things at once makes you less efficient

Low priority work gets stuck at partially done

Long queues of partially done work often contain multiple items that have no work being done on them at all, and which keep getting deprioritised in favour of other things. These items will never get done.

We have found that personal work in progress limits discourages people from starting low priority work unless they know they can get it done quickly before a higher priority piece of work comes along, and encourages it to be finished if it does get started.

I’ve written a bit about how we limit our work in progress here. In short, we limit work in progress both in each column on our kanban board, and for each person on the team. The work in progress limit on the columns helps with the flow of work through the system, rather than creating internal “done” queues. The work in progress limit on team members is to reduce switching between tasks, and to reduce queues of work forming for one person. Both types of limits focus attention on getting blockers removed, and getting work done and delivered.