Base milestones on objective evaluation of working systems.
—SAFe Lean-Agile Principle #5
Milestones are used to track progress toward a specific goal or event. They mark specific progress points on the development timeline, and they can be invaluable in measuring and monitoring the evolution and risk of a program. In the past, many progress milestones were based on phase-gate activities. In SAFe, however, progress milestones are better indicated by the fixed cadence of Iterations and Program Increments (PIs).
Planning in SAFe often takes three types of milestones into account:
PI milestones – These support the ability to objectively evaluate progress toward the technical or business hypothesis. They occur on the PI cadence.
Fixed-date milestones – Not everything, however, occurs on cadence. Software and systems engineering involves many factors that rely on external events, third-party deliverables, and external constraints. These often call for fixed-date milestones that are distinct from the development cadence.
Learning milestones –These milestones help validate business opportunities and hypotheses.
When applied properly, each type of milestone can bring focus to the work, help provide effective governance, and enable better business outcomes.
The development of today’s large systems requires substantial investment—an investment that can reach millions, tens of millions, and even hundreds of millions of dollars. Together, Customers, development teams, and other stakeholders have a fiduciary responsibility to ensure that the investment in new Solutions will deliver the necessary economic benefit. Otherwise, there is no reason to make the investment. Clearly, active engagement of stakeholders is needed throughout the development process to help ensure the realization of the proposed economic benefit, rather than just relying on wishful thinking that all will be well at the end.
To address this challenge, industry has historically employed phase-gated (waterfall) development processes, whereby progress is measured—and control is exercised—via a series of specific progress milestones. These milestones are not arbitrary, but are generally document based; they follow the apparently logical and sequential process of discovery, requirements, design, implementation, test, and delivery.
But as Oosterwal notes in The Lean Machine [1], such milestones don’t really work. The cause of this problem is the failure to recognize some critical errors with the basic assumption that phase gates reveal real progress and thereby mitigate risk. For example:
Using documents as a proxy for solution progress. Not only do these documents create a false sense of security for solution progress, but they also drive various measures and Metrics, such as work breakdown structures, earned value measures, and others, that may actually impede flow and real value delivery.
Centralizing requirements and design decisions in siloed functions that may not be integrally involved in building the solution.
Forcing too-early design decisions and “false-positive feasibility” [1].
Assuming that a ‘point’ solution exists, early in ‘cone of uncertainty,’ and that it can be built right the first time.
These examples highlight the flaws with phase-gate milestones, which typically do not reduce risk. Instead, they encourage picking a ‘point’ solution far too early in the development process, resulting in the late discovery of problems (see Figure 1).
Against this backdrop, it becomes clear that a different approach to milestones is needed, as is described in the rest of this chapter.
SAFe provides a number of means to address the problems associated with the traditionally used milestones. In particular, Principle #4: Build incrementally with fast, integrated learning cycles, especially when used in conjunction with set-based design, provides elements of the solution.
With this approach, the system is built in increments, each of which is an integration and knowledge point that demonstrates evidence of the viability of the current in-process solution. Further, this is done routinely, on the PI cadence, which provides the discipline needed to ensure periodic availability and evaluation, as well as predetermined time boundaries that can be used to collapse the field of less desirable options. Each PI creates an objective measure of progress, as illustrated in Figure 2.
This is true for both the Program and Large Solution levels, where solution/system integration and validation happen. Of course, what is actually measured at these critical integration points depends on the nature and type of the system being built. Nevertheless, the system can be measured, assessed, and evaluated frequently by the relevant stakeholders throughout development. Most importantly, changes can be made while there is still time to make them, as shown in Figure 3. This provides the financial, technical, and fitness-for-purpose governance needed to ensure that the continuing investment will produce a commensurate return.
In SAFe, the PI milestones are the most critical learning milestones that control solution development—so critical that they are simply assumed as credible and objective milestones. In other words, every PI is a learning milestone of a sort. But there are other milestones as well, as described in the following sections.
In addition to the PI milestones, other learning milestones can be used to support the central goal of building a solution that satisfies customer needs and generates value for the business. It is critical that the value proposition behind a new solution, or a large initiative, is treated as a hypothesis that requires conceptualization and validation against actual market conditions. Translating a hypothesis into business demand is the science and art of Lean-Agile product management. It involves a great deal of intermediate organizational learning. Learning milestones can help. For example:
Do the new product Capabilities have a market that is ready to pay for them?
Do they solve the user problem for the users being targeted?
Are the necessary nonfinancial accounting measures available to demonstrate real progress [2]?
How much revenue can the organization expect?
Is there a viable business model to support the new product or capability?
These and many other business concerns formulate the basic hypothesis for any large initiative. Learning milestones provide the necessary means to understand the feasibility of the solution and frame the right set of capabilities. Testing a concept of a new capability with a focus group, building and releasing a Minimum Viable Product (MVP), and validating Lean UX assumptions for a Minimum Marketable Feature (MMF) are examples of learning milestones. Such milestones do not necessarily occur on PI boundaries and may require significant effort to achieve, not only from the product development organization but also from other business functions in the enterprise, such as sales, marketing, operations, and finance.
Every learning milestone assumes that there is a certain degree of uncertainty that needs to be translated into knowledge and, ultimately, into business benefits for the organization. This requires set-based design thinking and the ability to pivot, if necessary, to a different concept of the solution.
Since the outcome of any learning milestone impacts the understanding of intent, milestones are planned incrementally, as Figure 4 suggests. Other elements, including the solution Vision, Solution Intent, and the Economic Framework, also evolve with the learning.
But learning doesn’t stop even when new product capabilities hit the market and start to generate business benefits. Every new capability and every significant nonfunctional aspect of the system needs facts to replace assumptions about anticipated value. In a Lean Enterprise environment, learning is an integral part of development, even for mature products. Meaningful learning milestones can help.
Every Lean-Agile enterprise wants to operate with minimal constraints. In part, that’s the driving force for pursuing agility. The real world, however, has different concerns, and fixed-date milestones are common in both traditional and Lean-Agile development. For example, fixed dates may arise from the following sources:
Events such as trade shows, customer demos, user group meetings, and preplanned product announcements
Release dates that are controlled by other internal or external business concerns
Contractually binding dates for delivery of value, intermediate milestones, payment, and demonstrations
Scheduling of larger-scale integration issues, including hardware, software, supplier integration, and anything else where a fixed date provides an appropriate forcing function to bring together assets and validate their interoperability
Many more examples could be cited, of course. In Lean terms, fixed dates have a nonlinear cost of delay. That is, required system Features become a much higher priority as the date comes closer, as failure to meet the milestones has negative economic consequences. This is directly incorporated into Program and Solution Backlog prioritization via the Weighted Shortest Job First (WSJF) model; the ‘time criticality’ parameter gets higher as the fixed date gets closer, thereby increasing WSJF priorities for elements dependent on that date. In any case, any fixed-date milestones should be reflected on the relevant program or value stream Roadmap so all stakeholders can plan and act accordingly.
In addition to the milestones discussed previously, other concerns must often be addressed to ensure the economic success of product development, such as filing patents, certifying the system, auditing certain regulatory requirements, and so on. In many instances these milestones influence content or priorities of work; they may even alter the development process itself. For example, the need to perform solution certification may increase the transaction cost of accepting a new Release into production and may drive teams to seek alternative ways of acquiring feedback before release. Again, any such milestones should appear on the relevant roadmap.
An understanding of which types of milestones are required to support value creation may originate from different sources. It may be communicated to portfolios from the enterprise, or identified during the analysis state in the Portfolio or Solution and Program Kanban systems, or even specified during the planning and roadmapping process for value streams and Agile Release Trains. Eventually, teams will have to create a specific plan of action during the PI planning process, build specific Stories in support of a milestone, reflect the milestone in their roadmaps and PI Objectives, understand and address dependencies with other teams and trains, and negotiate scope and time trade-offs with program stakeholders. Thereafter, execution of milestones happens incrementally. Progress is demoed every PI.
Successful execution of milestones requires having criteria for what ‘success’ means, so there can be value in associating specific measures and metrics with milestones. For example, a milestone of ‘capturing 25 percent market share’ may require an understanding of revenue or usage indicators. A learning milestone of ‘a search engine being able to reliably identify persons’ names on a web page’ could be supported by a limited percentage of false positives across the pages in the ‘gold collection’ of web data. In any case, thoughtful measures make for more meaningful milestones.
LEARN MORE
[1] Oosterwal, Dantar P. The Lean Machine: How Harley-Davidson Drove Top-Line Growth and Profitability with Revolutionary Lean Product Development. Amacom, 2010.
[2] Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Business, 2011.
