Little’s law
In a stable system the average amount of time it takes to get something through a process is equal to the number of things in the process divided by the average completion rate.
Cycle Time = (Things in Process)/(Average Completion Rate)
To reduce cycle time either:
- Get things done faster (usually involves spending money)
- Reduce the number of things in process
Reducing Cycle Time
Queuing theory offers some more suggestions on reducing cycle time:
- Even out the arrival of work
- Minimise the number of things in process
- Minimise the size of things in process
- Establish a regular cadence
- Limit work capacity
- Use pull scheduling
On evening out the arrival of work
“Queues at the beginning of the development process may seem like a good place to hold work so that it can be released to the development organisation at an even pace. But those queues should be no bigger than necessary to even out the arrival of work…”
On minimising the number of things in process
“…Queues of work waiting for approval absorb energy every time they are estimated, reprioritised, and discussed at meetings. To-do queues often serve as buffers that insulate developers from customers; they can be abused to obscure reality and they often generate unrealistic expectations.”
On limiting work to capacity
“Time sometimes seems to be elastic in a development organisation. People can and do work overtime, and when this happens in short bursts they can even accomplish more this way. However, sustained overtime is not sustainable. People get tired and careless at the end of a long day, and more often than not, working long hours will slow things down rather than speed things up.”
Avoid the thrashing that occurs when there is too much work for the number of people available.
Some final thoughts
Some general rules when using queues:
- Queues must be kept short – perhaps two cycles of work.
- Managers can reorganise or change items at any time that they are in a queue. But once teams start to work on an item, they should not interfere.
- Teams pull work from a queue at a regular cadence until that work is done. It is the pull system that keeps the team busy at all times while limiting work to capacity.
- Queues should not be used to mislead people into thinking that their requests are going to be dealt with if the team does not have the capacity to respond.
See Implementing Lean Software Development: From Concept to Cash.