© 2021 Scaled Agile, Inc. All rights reserved.

“ 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

Principle #3 – Assume variability; preserve options

Solution development is an inherently uncertain process. Technical variability and market variability are
present throughout the development process. Innovative new systems have, by definition, never been
developed before, so there is no guaranteed path to success. If there were, it wouldn’t be innovation.
That’s why we love this business.

To assure forward progress, system developers are inclined to reduce variability as quickly as possible.
The more deterministic things are, the better we feel. That’s just human nature. It seems that the more
we think we know and have already decided, the further along we think we are. And that’s true up to a
point, but even then variability is a constant presence.

Variability is inherently neither bad or good—it just is what it is. But it’s the economics associated with
the timing and type of variability that determines outcomes. The goal is to manage variability, and to
preserve options, providing the controls and flexibility teams need to build great solutions.

This article describes how to manage variability and preserve options with set-based design. For more on
managing variability, see Principle #7—Apply cadence; synchronize with cross-domain planning.

Preserve Options with Set-Based Design

Acknowledging the continued presence of variability in development causes us to reexamine our

approach. Traditional, sequential, stage-gated development practices drive developers to quickly
converge on a single option—an agreed to point in the requirements and design solution space—and
then modify the design until it eventually meets the full system intent. Everyone feels good that they
have the right requirements and the right design. At least for a while.

Indeed, this can be an effective approach—unless, of course, one picks the wrong starting point. Then
subsequent iterations that are done to refine that solution can waste time and lead to significant delivery
subsequent iterations that are done to refine that solution can waste time and lead to significant delivery
problems, as illustrated in Figure 1 [2].

Figure 1. Picking a point solution too early in the cone of uncertainty

There just isn’t enough time to recover. This is because, knowingly or not, we are operating early in the
‘cone of uncertainty’ [3] and attempting to force certainty by freezing requirements and design.  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 2 [4].
 Figure 2. Set-Based Design provides multiple design options

In this approach, developers cast a wider design net initially, considering multiple design choices at the
start. After that, they continuously evaluate economic and technical trade-offs—typically as exhibited by
the objective evidence presented at integration-based learning points. Then, as Figure 3 illustrates, they
eliminate the weaker options over time and ultimately converge on a final design, based on the
knowledge gained to that point.

Figure 3. Set-based design—coupled with cadence-based learning milestones—produces better outcomes

This process leaves the design options open for as long as possible, converges when necessary, and
produces more optimal technical and economic outcomes.

(Note: Due to the scope and economic impact of big systems, set-based design is a fundamental
construct of Large Solution SAFe. For more information, including guidance on applying set-based
design to fixed schedule commitments, planning impact, and economic tradeoffs, read the Set-Based
Design article and the guidance in the Enterprise Solution Delivery competency article.)

Learn More
[1] Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product
Development. Celeritas, 2009.

[2] Iansiti, Marco. Shooting the Rapids: Managing Product Development in Turbulent Environments.
California Management Review, 38. 1995.
 [3] McConnell, Steve. Software Project Survival Guide. Microsoft Press, 1997.

[4] Ward, Allan C., and Durward Sobek. Lean Product and Process Development. Lean Enterprise Institute
Inc., 2014.

Last update: 10 February 2021

he information on this page is © 2010-2021 Scaled Agile, Inc. and is protected by US and International copyrigh
ws. Neither images nor text can be copied from this site without the express written permission of the copyrig
older. Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc. Please visit Permission
FAQs and contact us for permissions.