- Principle #1: Take an economic view
- Principle #2: Apply systems thinking
- Principle #3: Assume variability; preserve options
- Principle #4: Build incrementally with fast, integrated learning cycles
- Principle #5: Base milestones on objective evaluation of working systems
- Principle #6: Visualize and limit WIP, reduce batch sizes, and manage queue lengths
- Principle #7: Apply cadence, synchronize with cross-domain planning
- Principle #8: Unlock the intrinsic motivation of knowledge workers
- Principle #9: Decentralize decision-making
Principle #6: Visualize and limit WIP, reduce batch sizes, and manage queue lengths
Operating a product development process near full utilization is an economic disaster.
To achieve the shortest sustainable lead time, Lean enterprises strive for a state of continuous flow, which allows them to move new system Capabilities quickly from concept to cash. Accomplishing this aim requires eliminating the traditional start–stop–start project initiation and development process, along with the incumbent phase gates that hinder flow (Principle #5).
There are three major keys to implementing flow:
Visualize and limit work in process (WIP)
Reduce the batch sizes of work items
Manage queue lengths
Visualize and Limit WIP
Overloading teams and programs with more work than they can accomplish is a common and harmful practice. Having too much WIP confuses priorities, causes frequent context switching, and increases overhead. It overloads workers, scatters focus on immediate tasks, reduces productivity and throughput, and increases wait times for new functionality. Burnout is a painfully common result.
The first step to correct the problem is to make the current WIP visible to all stakeholders (see Figure 1). This Kanban board illustrates the total amount of work at each state and serves as an initial process diagnostic, showing the current bottlenecks. Often, simply visualizing the current volume is the wake-up call that causes practitioners to start addressing the systemic problems of too much work and too little flow.
Figure 1. Visualizing work in progress
The next workflow state is to start balancing the amount of WIP against the available development capacity. When any step reaches its WIP limit, no new work is taken on.
Limiting WIP, however, requires knowledge, discipline, and commitment. It may even seem counter-intuitive to those who believe that the more work you put into the system, the more you get out. That relationship can hold true up to the point of nearly full capacity, but thereafter the system becomes turbulent and throughput decreases. There is no substitute for effectively managing WIP.
Reduce Batch Size
Another way to reduce WIP and improve flow is to decrease the batch sizes of the work—the requirements, designs, code, tests, and other work items that move through the system. Small batches go through the system more quickly and with less variability, which fosters faster learning. The reason for the faster speed is obvious. The reduced variability results from the smaller number of items in the batch. Since each item has some variability, the accumulation of a large number of items has more variability.
The economically optimal batch size depends on both the holding cost (the cost for delayed feedback, inventory decay, and delayed value delivery) and the transaction cost (the cost of preparing and implementing the batch). Figure 2 illustrates the U-curve optimization for batch size .
Figure 2. Determining the optimal batch size
To improve the economics of handling smaller batches—and thus increase throughput—teams must focus on reducing the transaction costs of any batch. This typically involves increasing the attention to and investment in infrastructure and automation, including considerations such as Continuous Integration and the build environment, DevOps automation, and system test setup times. Such a focus is integral to systems thinking (Principle #2) and a critical element in long-view optimization.
Manage Queue Lengths
The last method to achieve flow is to manage queue lengths and reduce them. Little’s law—the seminal principle of queuing theory—tells us that the wait time for service from a system equals the ratio of queue length divided by the average processing rate. (While this might sound complicated, even the line at Starbucks proves the validity of Little’s law.) Therefore, assuming any average processing rate, the longer the queue, the longer the wait.
For solution development, this means that the longer the queue of work awaiting implementation by the team, the longer the wait time, no matter how efficient the team. So, to achieve faster service, you must either reduce the length of the queue or increase the processing rate. While increasing the processing rate is a worthy goal, the easiest method to reduce wait time is to reduce the queue length. Keeping backlogs short and largely uncommitted allows new, higher-priority work to enter and leave the system with less wait time. Visualizing the work helps identify ways to streamline the process, while shortening the queue size decreases delays, reduces waste, and increases predictability of outcomes.
The three primary ways of implementing flow—visualizing and limiting WIP, reducing the batch sizes of work items, and managing queue lengths—provide powerful approaches to increase throughput. Implementing them can trigger fast and measurable improvements in customer satisfaction and employee engagement, benefiting Agile teams and their customers.