- Your Starting Condition
- The Kickstart Process
- The Kickstart Event
- Some Final Thoughts
- Tying It All Together
Some Final Thoughts
We’ve encountered a common misconception among Agile consultants and coaches regarding Scrumban implementations—the notion that because kanban systems are grounded in queuing and systems theories, there is no value in implementing them until the systems in which they’re used are stabilized.8
For example, WIP limits should ultimately be established based on the characteristics of the stable system to which they apply. However, initial-WIP limits can be used to bring a system into stability. I’ve pursued this path in many contexts, and this approach is specifically cited in the Siemens Health Services Scrumban story. It’s worthy to call out some of the particulars here.
By way of background, the Siemens group elected to refrain from imposing WIP limits on their initial rollout. They soon discovered that the absence of WIP limits did nothing to stabilize or reverse their existing trend of ever-increasing cycle times. A cumulative flow diagram generated from their data showed the system was out of balance, with teams accepting new work faster than they were delivering completed work (Figure 5.10). Past patterns of increasing cycle times had not been influenced.
Figure 5.10 A cumulative flow diagram showing effort being committed to new work increasing faster than existing work can be completed.
Upon establishing initial-WIP limits, the teams immediately began to see a stabilization in both system lead times9 and overall system performance (Figure 5.11 and Figure 5.12).
Figure 5.11 System lead times being stabilized.
Figure 5.12 Cumulative flow diagram indicating a stable system.
The moral of the story is clear: Yes, systems need to be stable before we can improve them, but they also afford us mechanisms to achieve the stabilization needed to undertake our true journey.