Managing queues inspired by D. Reinertsen’s Principle of Product development flow

According to principle of product development flow by Reinartsen: Queues are the hidden source of most development waste. They are concealed as it is composed of information. Queues increase cycle time, expenses, variability and risk. They slow feedback, reduce quality and decrease motivation.

Queues are caused by variability and high capacity utilization. Increasing capacity utilization increases queues exponentially.

1.and 2.principle of controlling queue size of the book Principles of Product Development Flow:

Principle Q13:Don’t control ccapacity utilization, control queue size

Capacity utilization allows us to predict:

1. The percent of time arriving work will find the resource busy
2. The average number of items in queue
3. The average number of items in the system
4. The percent of overall cycle time that is queue time
5. The ratio of cycle time to value added time

Capacity utilization is a powerful predictor, however capacity utilization is a useless lever due to our inability to estimate demand and capacity accurately.

Small changes in capacity utilization lead to big changes in cycle time and queue.

Fortunately, there is direct impact of queue size to capacity utilization. A wide range control of queue size will force the system into a very tight range of capacity utilization.

We can affect our queues by the structure of our queuing systems for instance. For instance, by variability pooling, i.e. having 1 common queue being served by multiple servers. This is not a novel concept as people of supermarkets will now. When the queue stacks, there is people who are working in the store directly coming and prioritizing opening the cashier and serving the increased demand. In Product development this could be served as several teams are drawing from one common backlog.

In product development context the variability due to wrong estimation, incidents, customer support could less impact our queue, if we smoothly pool the demand as one queue and let it be pulled across all 4 teams while planning in the expectation for development work via small batches, buffer, stretch goals and disciplined using WIP.

Principle Q14: Don’t control cycle time but control queue size

Cycle time in it-self is a lagging indicator compared to queue size, as the cycle time first increases when the item went through the development cycle. E.g. the queue sizes doubles now and the cycle time doubles first after several weeks.

What is the size of our queues?

Finding the queue size within the system:

Feature delivered per time span X. Amount of features in the system at the time t divided by velocity is equal to the queue size. E.g. Feature amount in Funnel divided by Feature delivered per PI.

Another way would be: Take the jobs concluded in a week, divide them by the hours work in the week (hours of work* people). Compare the time with the cycle time via dividing, this results in the % of value added time (v) and queue time, i.e. 100% – v.

Queues size is a powerful indicator, however the most important is the economics of the cost of queue in relation to cost of capacity. The optimal queue size is normally the top of a  U curve and without looking into the specifics one can assume to try to always avoid the 100% end. A suggestive sweet spot could be 80%.

 Another lever improving the economics despite of same queue size is queuing discipline.

Queuing discipline reduces cost at the same queue size by servicing the jobs first which have a high cost of delay first.