The value is in what gets used, not in what gets built.

— Kris Gale, Clover Health (formerly with Yammer)

Transitioning from Projects to a Lean Flow of Epics

This is article four in the SAFe for Government (S4G) series. Click here to view the S4G home page.

Traditional ‘project management’ processes for technology development are deeply ingrained in government policy, procedures, and tools. Guidelines for project governance often suggest a waterfall, phase-gate lifecycle model. However, what we’ve learned from decades of challenged projects is that the nature of technology development is inherently empirical, requiring an iterative and incremental process similar to the scientific method commonly found in R&D labs.

This differs from the defined process model of planning all the work in detail at the beginning of the project. To get better results, we need to place greater focus on the value delivered versus the meticulous planning of tasks, especially early on when the cone of uncertainty is the greatest. This represents a significant shift in how government leaders might think about their technology initiatives. The good news is that once the mental hurdles are cleared, the practices for iterative product development are well defined, and are even recognized as a best practice in the GAO Agile Assessment Guide [1].

This article describes the shift from organizing technology efforts as projects to a continuous flow of product-centric features in a value stream. It provides best practices for managing that flow using a SAFe construct called ‘Epics’.

Details

Move from Projects to Products using Epics

Historically, government agencies have developed and maintained mission-enabling technologies through a sequence of start-stop projects. For new systems, the first “greenfield” project provides the initial operating capability (IOC), while subsequent projects deliver ongoing operations, maintenance, and enhancements of the system. Miscellaneous ancillary projects are also needed to field the new capability. These projects provide:

• Technical infrastructure
• Security (DevSecOps)
• Independent validation and verification (IV&V)
• Training and fielding
• Systems engineering and technical assistance (SETA)

Each project typically starts with a ramp-up effort, followed by a series of projects often referred to as the ‘sustainment tail.’ These disconnected initiatives and their associated contracts (and re-competes) make it difficult to holistically manage the costs and ongoing effort associated with each discreet capability.

Additionally, the traditional project management process assumes a waterfall approach where all of the requirements are defined upfront, followed by all the design, all the development, all of the testing, and finally the deployment of the finished product.

The flaw in this model is that most modern technology initiatives have too many unknowns in the beginning to develop accurate, detailed plans and designs up-front. Decades of failed projects prove that a different approach is required.

These challenges can be solved, in part, by shifting from building capabilities through disparate start-stop projects that manage tasks, to a holistic product management paradigm that encompasses all the efforts and resources needed to field and maintain a long-lived capability. The collection of people (government and contractors), systems, information, and material needed to provide a mission-enabling capability is referred to as a Value Stream. A value stream can contain one or more products (or systems) that work together to provide a capability.

The example in Figure 1 shows a fighter jet as the Solution produced by a value stream—a collection of products (in this case, systems) that include airframe, propulsion, avionics, communications, navigation, targeting, safety, and many more. Collectively, they provide a technological ecosystem that delivers a critical capability to support the missions required for air superiority.

Instead of organizing the work in a value stream into dozens of disconnected projects, SAFe’s Lean-Agile product approach uses epics—large initiatives, whose cost and scope warrant analysis, ROI assessment, a lean business case, and approval. Epics are visualized and managed in flow using Kanban and the principles of Lean thinking, as described in the Lean-Agile Mindset, SAFe Principle #6 Make Value Flow without Interruptions, and Portfolio Flow articles.

As Figure 2 illustrates, Epics are in turn decomposed into Features; these represent the new functionality built, deployed, and maintained by one or more Agile Release Trains (ARTs). Epics typically take more than one PI to deliver, but ideally no more than two to four PIs to keep batch sizes small (even at this larger scale).

They provide more frequent opportunities to deliver value, to learn, and to change the approach if necessary. Epics also contain all of the work (development, testing, IV&V, infrastructure, etc.) needed to provide a capability that was previously contained in numerous unrelated projects.

In the fighter jet example, an epic might be required to add functionality to use a newly developed missile. That enhancement could:

• Necessitate changes to multiple software, firmware, and hardware components
• Involve many teams over several PIs
• Call for a significant investment

Epics in SAFe provide the appropriate planning, budgeting, and governance elements to deliver this modification in flow using Lean practices.

Apply the Lean Startup Cycle to Epic Development

One of the most valuable shifts in thinking provided by moving from projects to products using epics is the ability to deliver only those features that provide the required value. This reduces wasteful spending and avoids investing in unnecessary functionality.

Research by The Standish Group in 2002, updated in 2014, shows that 80% of the features in custom application development are used infrequently if ever. And only 40% of successful software projects (those that met the triple constraint of time, cost, and scope) delivered high or very high value.  [4] Citation: https://www.standishgroup.com/sample_research_files/Exceeding%20Value_Layout.pdf

In SAFe, this is accomplished by decomposing epics into features, and then prioritizing them in a backlog so that the next most valuable feature (greatest mission value for the smallest job size) is always completed next by teams on one or more ARTs. Once the Minimum Viable Product (MVP – the smallest set of features that collectively meet the mission requirements) is delivered, agency leaders can determine if the remaining features are worth the additional investment. Or, they can decide that those development funds would be better spent elsewhere.

As an example, the epic to support a new missile on a fighter jet might be decomposed into 100 features, of which the first 70 in priority order would represent the MVP (i.e., the minimum required to achieve the mission). Once the first 70 features are built, tested, and deployed, agency leaders have full control over how much additional investment—via the remaining 30 features—is required. If the decision is made to deliver an additional 10 and then stop, the 20 lowest priority features simply would not be built. The agency, and taxpayers, would then save the cost of developing and maintaining those 20 potentially wasteful features over the entire useful life of the system!

Traditional projects do not provide an equivalent mechanism. Once the time, cost, and scope are established, programs and their contracted industry partners are contractually and financially incentivized to deliver everything in the scope, regardless of the real value of the lowest priority features.

Visualize the Flow of  Value

At any given time, an agency will have multiple epics proceeding through various stages of the lifecycle process. To achieve Lean flow, it’s important to be able to visualize all of the work-in-process (WIP). For that reason, SAFe embraces the best practices of Kanban, supporting Lean disciplines such as enforcing WIP limits to enable sound decision-making and avoid overloading development capacity. This helps manage expectations while making development commitments visible and predictable. It also facilitates collaboration among key stakeholders as facts change, allowing trade-off decisions—such as prioritization and resource allocations—be made transparently and quantitatively.

Figure 4 below provides an example of how an agency might visualize the flow of epics using Kanban.

Other than the first (Funnel) and last (Done) columns, all other columns have WIP limits. This visualization can help an agency avoid making commitments beyond its capacity to deliver, thus ensuring a smooth flow of epics from initiation to completion. This results in delivering the highest amount of value in the shortest sustainable lead time with quality, given the technology development dollars invested. Note that the transitions between each column in the Kanban process can also provide natural alignment points to existing governance stage gates until Lean practices have been applied to the government model as well.

Enable Variability and Learning by Rethinking “Requirements”

Shifting from projects to product-focused epics is more than a simple change in terminology. The language used to define an epic is fundamentally different. Instead of the traditional “shall statements” that articulate detailed requirements up front, epics use the language of intent. This provides maximum flexibility to determine the best solution to meet the agency mission. Some elements of a solution must be fixed (for example, the protocols and frequencies used by the fighter jet to communicate to the military GPS network). But the best capabilities emerge when the variable elements of the solution evolve through innovation and sound engineering practices, such as model-based systems engineering and set-based design. In the broadest possible terms, agencies should define epics focusing on the problem to be solved or the functionality required. ARTs can then be provided all the freedom needed to rapidly prototype and deliver high-value solutions based on validated learning and rapid iterative development.

Moving Forward

The next key concept for adopting SAFe in Government is Adopting Lean budgeting aligned to value streams.