- 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
This chapter is from the book
This chapter is from the book
This chapter is from the book
Principle #3: Assume variability; preserve options
Generate alternative system-level designs and subsystem concepts. Rather than try to pick an early winner, aggressively eliminate alternatives. The designs that survive are your most robust alternatives.
—Allen C. Ward
System developers are inclined to try to reduce variability. That’s just human nature. It seems that the more you think you know and have already decided, the further along you think you are. In reality, though, that’s often not the case.
While it’s true that variability can lead to bad outcomes, the opposite case can also be true.
Variability is inherently neither bad nor good. Rather, the economics associated with the timing and type of variability is what determines the value of the outcomes. A focus on eliminating variability too soon perpetuates a risk-avoidance culture, in which people feel they can’t make mistakes and learn from experience what works and what doesn’t.
Other than a general understanding of system intent, Lean knowledge workers recognize that oftentimes very little is actually known at the beginning of a project. (If it were, they would have already built it!) Traditional design practices, however, tend to drive developers to quickly converge on a single option—an agreed point in the potential solution space—and then modify the proposed design until it eventually meets the system intent.
This can be an effective approach—unless, of course, the team picks the wrong starting point. Then subsequent iterations to refine that solution can waste time and lead to a suboptimal design [1]. Sadly, the bigger and more technically innovative the system is, the higher the odds are that the agreed starting point was not the best one.
A better approach, referred to as Set-Based Design (SBD) or Set-Based Concurrent Engineering (SBCE), is illustrated in Figure 1 [2].
)
Figure 1. Set-Based design
In this method, developers cast a wider design net initially, considering multiple design choices at the start. Subsequently, they continuously evaluate economic and technical trade-offs—typically as exhibited by the objective evidence presented at integration learning points. Then, they eliminate the weaker options over time and ultimately converge on a final design, based on the knowledge gained to that point.
This process leaves design options open for as long as possible, converges when necessary, and produces more optimal technical and economic outcomes.