Queuing Theory/ Work In Progress
Queuing theory is the mathematical study of waiting lines. It shows that the amount of time some work items are waiting to be worked on increases when the utilization of the people working on them increases. The project’s speed, efficiency, and quality of output decrease when the plates of the team members working on it fill, no matter how skilled the team is.
Product and delivery managers should be aware of the serious side effects of high utilization. Google allows its engineers one day a week to work on anything they want, which provides some slack time and extra capacity if a project falls behind schedule.
Experiments have shown that the above-mentioned queuing theory applies to repetitive tasks as follows: Add 20% more work and it will take 20% more time to complete it.
Most product development is unpredictable and complex, and by adding more work, it significantly increases the time it takes to complete. High utilization of the team creates queues and idle time waiting for the capacity to become available, which negatively effects the team’s morale and increases the length of product development.
Some of the effects of queues are as follows:
- Delay in feedback, causing developers to be on unproductive path longer.
- Context switching, during idle time developer tend to start working on something else and when the waiting time is over there is again context switching coming back to original task.
- Hard to adjust to the changing market needs and detect weakness in the product before it’s too late.
Here is how mostly queues become longer:
- If the size of work item is larger, the queue time will be larger too as each step will take more time to complete and in turn making the queue longer E.g. more time in coding, more time in review, more time in testing. Average time it takes to complete a work item is directly proportional to the size of work item.
- Trying to get it right the first time, increase the time work item remains in progress contributing to longer time in each step of the process and contributing to longer queue. Tolerance for getting it wrong the first time proved to be better strategy, as long as team is doing quick iterations and learning from their failures at fast speed. Fail early and fail often concept help teams to eliminate the poor options quickly and give them time to focus on more promising alternatives.
- Focusing on starting the work, instead of finishing, add waiting time and delays, as more items in progress increases chances of having queues. So it is critical to rigorously control the rate at which work is started.
The importance of reducing the amount of in progress work and not have queue of work or waiting time, for product management, is evident from Little’s law which states on average cycle time is proportional to the size of the queue divided by the processing rate, e.g. if you have 10 work items to do and you can finish 2 work items in one day, the wait time for everything to be completed is 5 days.
The cycle time can be reduced by raising the processing rate i.e. finishing 3 tasks instead of 2 in a day so wait time for work completion will be a bit over 3 days or by reducing the in progress work items i.e. having 8 items in progress instead of 10 and the wait time of the work completion will be 4 days instead of 5. Note that it is with the assumption that the size of each work item is relatively the same.
