The president’s doctor isn’t busy with other patients but instead waits to be ready for when the president needs them. Similarly, a doctor optimizes their time to be as productive as possible for worker efficiency whereas a president’s doctor optimizes the president’s time for work-unit efficiency.
While Agile and the Toyota Way were created to solve the problem of how to get things done while everyone is busy, most developers still continue to face a common problem wherein their work is slowing down and impacting productivity.
A worker will be responsible for an individual stage and move the work unit onto the next stage only once they have completed their task at the previous one.
There are often multi-stage workflows, which can add to the delay in getting work done when multiple parallel projects attempt to be juggled at the same time, causing work to drastically slow down.
The only way to optimize waiting is to ensure that the queue of work-units is in priority order, where whenever something waits, it does so because the current work-in-progress provides more value.
Partitioning a task into smaller-sized parts and keeping a work-in-progress limit are ideal ways to combat multitasking inertia and optimize for work-units, not workers. Similarly, it is essential to walk the board during daily syncs and deal with `Blocked` labels as soon as possible.
Improving throughput can only be possible when the work to do “Next” is prioritized, with the work already in progress being higher priority than anything else, so that getting that work done sooner will provide meaningful value earlier.
Projects can be optimized for work-unit efficiency, but the waiting times have a cost. Cumulatively, the delay becomes a significant detriment to throughput and productivity.
It is essential to experiment with WIP limits to reduce the number of work-units at any stage, which is an ideal forcing function for increased focus and gets things done quickly.
Waiting deceptively sits “in progress” when nothing constructive is happening, leading to delay, which has a severe impact on productivity. Therefore, optimizing for work-unit efficiency and not just the worker is essential to improve code reviews’ turnaround time.