There was in fact no correlation between exiting phase gates on time and project success…the data suggested the inverse might be true.

—Dantar P. Oosterwal, The Lean Machine

Principle #5 – Base milestones on objective evaluation of working systems

The Problem with Phase-Gate Milestones

Developing today’s large systems requires substantial resources—investments that can total millions and even hundreds of millions of dollars. Developers and customers have a mutual fiduciary responsibility to ensure that investments in new Solutions will deliver the necessary economic benefits. Otherwise, what is the reason to proceed?

Clearly, stakeholders must collaborate in ways that help ensure the potential to realize the prospective economic benefit throughout the development process, versus engaging in wishful thinking until the end. The industry has generally applied a sequential phase-gated (waterfall) development process to address this challenge, measuring and controlling progress through a series of specific milestones.

These phase-gate milestones are not arbitrary. They follow a seemingly logical and sequential process: discovery, requirements, design, development, test, and delivery. Of course, it hasn’t always worked out all that well, as Figure 1 shows.

The cause of the problem is the failure to recognize the four critical errors in the assumption that phase gates reveal real progress and thus mitigate risk:

• Centralizing requirements and design decisions in siloed functions that do not actually build the system.
• Forcing too-early design decisions and false-positive feasibility. [1]
  • An early choice is made for the best-known option at that time.
  • Development proceeds under the assumption that everything is on track.
  • Later it’s discovered that the chosen path is not feasible. (Principle #3)
• Assuming a point solution exists and can be built correctly the first time. This ignores the variability inherent in the process and provides no legitimate outlet for it. Variability will find a way to express itself.
• Making up-front decisions creates large batches of requirements, code, and tests, and long queues. This leads to large-batch handoffs and delayed feedback. (Principle #6)

Base Milestones on Objective Evidence

Clearly, the phase-gated model does not mitigate risk as intended. A different approach is needed. Principle #4 – Build incrementally with fast, integrated learning cycles provides elements of the solution to this dilemma.

Throughout development, the system is built in increments, each of which is an integration point that demonstrates some evidence of the feasibility of the solution in process. Unlike phase-gated development, every milestone involves a portion of each step—requirements, design, development, testing—together producing an increment of value (see Figure 2).

Further, this is done routinely on a cadence (Principle #7), which provides the discipline needed to ensure periodic availability and evaluation and predetermined time boundaries that can collapse the field of less desirable options.

What is actually measured at these critical integration points is subject to the nature and the type of system being built. But the point is that the system can be measured, assessed, and evaluated by the relevant stakeholders frequently throughout the solution development life cycle. This provides the financial, technical, and fitness-for-purpose governance needed to ensure that the continuing investment will produce a commensurate return.

Based on this principle, SAFe makes some milestones explicit. For example, the PI system demo is designed specially to deliver objective metrics on progress, product, and process, as Figure 3 illustrates.

Progress metrics determine if the organization is on track to achieve the current mission for the solution. Product metrics provide objective data on how the solution is performing in the market and provide insights into future needs. Process metrics bring visibility to improvement items that are currently in flight. Together these objective metrics enable stakeholders to frequently assess and evaluate business and technical progress and decide whether to continue to invest in the solution or allocate investments elsewhere.

Learn More

Last update: 1 August 2022