10. Value Stream Overview
Projects and practices fail when they optimize one part of the value stream at the expense of others or when the parts just don’t fit
—Allen C. Ward
Capabilities and the Value Stream Backlog
Defining and Building the Solution
Overview
The value stream level is optional and is designed to support those defining, building, and deploying the world’s most important and complex systems. These solutions are so substantial that they typically require multiple Agile Release Trains (ARTs), as well as the contribution of suppliers.
An example would be an organization that builds defense systems, which have significant safety, performance, and compliance demands. Building these systems may require hundreds of mechanical, electrical, and software engineers, as well as external suppliers. These systems are often mission-critical, and failure can have serious, even life-threatening, consequences.
Enterprises that build smaller and largely independent systems may not need this level. Even then, however, some of these systems are mission- or life-critical. They are far from trivial systems, and some elements of the value stream level may still be useful. For example, solution intent, set-based design, model-based system engineering, and Agile architecture practices can be adopted without implementing the entire value stream level. This is part of the scalability and modularity of the framework.
Lean-Agile development is now replacing traditional phase-gate development approaches, which haven’t scaled well to meet the challenges described here. To deliver the right business outcomes, as well as effective and safety-compliant solutions, a leaner, more Agile approach is needed. To achieve that, the value stream level offers additional practices, roles, and events to support implementation and coordination. These include the following:
• An economic framework to provide financial decision rules and boundaries for value stream decision-making
• Solution intent as a repository for intended and actual solution behavior
• Solution context, which describes the way the solution fits in the deployed environment
• Pre– and post–Program Increment (PI) planning, which helps multiple ARTs and suppliers build an aligned plan for the next PI
• Solution demo, which provides an integrated demo from multiple ARTs and suppliers
• Value stream backlog containing capabilities and enablers, which describe the larger behaviors of the solution
Similar to the program level, the value stream level is organized around PIs, providing cadence and synchronization of multiple ARTs and suppliers.
The value stream level also includes additional roles to facilitate coordination, as described next.
Value Stream Roles
Like the program level, the value stream level has its own “triad” of critical functions and roles needed to coordinate and advance the value stream solution, as Figure 10-1 shows.
• The Value Stream Engineer (VSE) is a servant leader and coach who supports and facilitates the work of all ARTs and suppliers. Similar to an RTE, the VSE is responsible for making sure that the value stream runs smoothly by identifying and resolving bottlenecks. The VSE facilitates events and meetings at the value stream level and monitors the kanban system and metrics for this level.
• Solution Management represents the customer’s overall needs across trains, as well as communicating the strategic themes of the portfolio vision. Solution Management collaborates with Product Management to define capabilities and splits them into features. Solution Management is the primary content authority for the value stream backlog and its prioritization via Weighted Short Job First (WSJF). Solution Management also contributes to the economic framework that governs decision-making across ARTs and Agile teams.
• Solution Architect/Engineering collaboratively defines the technology and architecture that connects the solution across trains. It works with the train’s System Architect/Engineering team to help guide their portion of the solution’s design.
In addition to the three roles, customers are shown in the value stream level in the four-level Scaled Agile Framework (SAFe), just as they appear in three-level SAFe. Although customers are displayed just once on the Big Picture, in reality they are involved at every level of SAFe, from team to portfolio. They are part of the value stream and are thereby inseparable from the development process. Customers work closely with Solution and Product Management and other key stakeholders to shape the solution intent, the vision, and the economic framework in which development occurs. They help define and prioritize the solution’s development and participate in solution planning, demos, and process improvement.
Economic Framework
The economic framework is designed to permit fast, effective decision-making, within the financial constraints of the value stream. This requires three things.
1. An understanding of the financial constraints and decision-making rules
2. Sufficient knowledge of the current local context and subject domain
3. Delegation of decision-making authority
Many aspects of the economic framework are directly embedded in various SAFe practices, including the following:
• Lean-Agile budgeting
• Epic funding and governance
• The principle of decentralized decision-making
• Job sequencing using Cost of Delay (CoD) and WSJF
Figure 10-2 illustrates where many of the decision rules and decision-making authority may occur within this framework. These four practices are briefly described in the following sections.
Lean-Agile Budgeting
SAFe suggests a Lean-Agile funding model, where budgets are allocated to long-lived value streams instead of projects. Unlike projects, the cost for each PI is largely fixed, and the scope is adjusted as needed to meet the business needs of the value stream. There are no “project overruns” that must be justified with this model. Value stream budgets can be adjusted over time at PI boundaries, based on the relative value that each provides. This process is further described in chapter 14, “Lean-Agile Budgeting, Forecasting, and Contracting.”
Epic Funding and Governance
Allocating funds to the value streams (and as a result to the ARTs) is all well and good. But what happens when there are substantial financial decisions to make, such as portfolio, value stream, or program epics? Spending authority comes with the responsibility to communicate any investments that are not routine. This is the role of the kanban systems at the portfolio, value stream, and program levels. Each epic requires a lightweight business case and an explicit approval process, which is described further in chapter 13, “Portfolio Level Overview.”
Decentralized Economic Decision-Making
With these budget elements in place, the enterprise then empowers people to make content decisions at each level of the framework (for example, Solution Management for value streams, Product Management for ARTs, and Product Owners for teams). Of course, they don’t act alone. They work with their larger stakeholder community to determine the best course of action.
Job Sequencing Based on Cost of Delay
Every significant program has a backlog of new jobs—features and capabilities—waiting to be implemented to increase the value of the solution. In a flow-based system, optimizing the sequence of jobs based on CoD produces better economic outcomes than prioritizing work by theoretical Return on Investment (ROI) or “first-come, first-served” methods. Program and value stream kanban systems and backlog staging areas are the keys to success. When capacity exists, jobs are “pulled” for implementation based on WSJF, which is the CoD weighted by job size (a proxy for duration).
Capabilities and the Value Stream Backlog
Capabilities are larger work items that appear at this level to capture and define higher-level solution behaviors. These typically span multiple ARTs.
New capabilities may arise from a local context or occur as a result of splitting portfolio epics that may cut across multiple value streams. Another potential source of capabilities is the solution context, where an aspect of the solution environment may drive needed functionality.
Capabilities have attributes and practices similar to features. Here are some examples:
• They’re written using a phrase, statement of benefits, and acceptance criteria; they are structured to fit within a single PI.
• Associated enablers describe and bring visibility to all the technical work required to support effective development and delivery of business capabilities.
• They’re developed and approved using the value stream kanban.
• Capabilities approved for implementation are maintained in the value stream backlog and are prioritized using WSJF.
• Acceptance criteria are used to determine when the functionality has been properly implemented.
To be executed by ARTs, capabilities must be first split into features, which then are split into user stories that are implemented by teams within an iteration timebox.
The following list provides 10 patterns for “splitting work,” as described by Leffingwell in Agile Software Requirements:1
1. Dean Leffingwell, Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Addison-Wesley, 2011).
1. Workflow steps
2. Business rule
3. Major effort
4. Simple/complex
6. Data methods
7. Deferring Nonfunctional Requirements (NFRs)
8. Operations
9. Use-case scenarios
10. Breaking out a spike
Figure 10-3 illustrates an example of splitting a capability into features.
Value Stream Epics
Value stream epics are initiatives large enough in scope and cost to warrant analysis and a lightweight business case. Unlike capabilities that can be split to fit inside a single PI, value stream epics usually take several PIs to develop. They may arise as a result of portfolio epics, or they may occur locally as value streams plan larger initiatives.
Value stream epics are analyzed in the kanban system. Once approved, they’re split into capabilities and enablers. More details about epics (for example, lightweight business case or epic value statement) are covered in the discussion of portfolio epics in chapter 13, “Portfolio Level Overview.”
Defining and Building the Solution
Solution behavior and decisions are managed in solution intent, which serves both as a single source of truth and as a repository for requirements in their transition from variable to fixed intent. In addition to vision and roadmap, which also apply at this level, the development of solution intent in an adaptive manner is supported by these three additional practices:
• Model-based systems engineering. Describes how requirements and design elements can be developed, documented, and maintained in flexible and accessible models, as opposed to documents
• Set-based design. Practices that support preservation of options and the move from variable to fixed requirements over time, while deferring decisions to the last responsible moment
• Agile architecture. Supporting the balancing act between emergent design, which is built just in time by the Agile teams, and intentional architecture, which is created collaboratively with the senior technical leaders and the teams
A key element of the value stream level is the solution itself. Although the solution also appears at the program level in the three-level view, additional practices and details are described at the value stream level.
The behavior of a solution is governed by its solution context—the environment in which a deployed solution operates. Solutions are developed based on capabilities and enablers, which are used to satisfy the needs of customers and to realize the value stream vision and roadmap.
Capabilities are managed through the value stream kanban system to ensure they are evaluated and analyzed before they reach the value stream backlog. At that point, they’re sequenced for implementation. The kanban system limits Work in Process (WIP) and focuses trains on getting value stream backlog items fully done, before starting on a new work. This is essential for coordinating ARTs and suppliers to deliver capabilities together.
Larger initiatives are managed as value stream epics and are broken down into capabilities during analysis. In many cases, they require suppliers who develop components, subsystems, or capabilities for the value stream. These suppliers participate in value stream–level meetings.
Value Stream Flow
The value stream kanban is used to bring visibility and analyze upcoming work, as shown in Figure 10-4. It consists of two main elements: the value stream epic and the capability sections. Value Stream Management and Solution Architects/Engineers, who have responsibility over capabilities and enablers, manage this system.
Value stream epic section. This section is used for analyzing and approving value stream epics, as well as splitting them into capabilities to be further explored and implemented in the “downstream” capabilities portion of the value stream kanban (see Figure 10-4). Value stream or portfolio level stakeholders are generally involved in approving these epics. Depending on how frequently value stream epics occur in the local context of the value stream level, this section is not always present in the kanban. Its workflow follows the equivalent set of example steps in the portfolio kanban. See chapter 13, “Portfolio Level Overview.”
Capability section. This section is used for preparation, prioritization, and implementation of capabilities. Solution Management and Architects/Engineers have full content authority for this part of the kanban. The following are typical steps for the capability section of the kanban:
• Funnel. All new capabilities are captured here. They may require new or enhanced functionality, including capabilities to implement system qualities or support architecture or infrastructure.
• Analysis. Capabilities that best align with the value stream (or portfolio) vision and support current strategic themes are moved to analysis for further exploration. This step requires refinement of the key attributes of a capability: business benefit, acceptance criteria, and size in story points. Some capabilities under analysis may require prototyping or other forms of exploration that involve Agile teams.
• Backlog. When sufficiently elaborated, and approved by Solution Management, the highest-priority capabilities move to the value stream backlog, where they’re prioritized with WSJF.
• Implementing. At every PI boundary, the value stream pulls the top capabilities from its backlog and moves them to the implementing step. The transition is part of the pre-PI planning process, where selected capabilities are broken down into features and then are implemented by teams during the PI.
• Done. Capabilities accepted by Solution Management progress to this final step.
Summary
This chapter provided an overview of the value stream level, which is intended for builders of large and complex solutions. Such solutions typically require multiple ARTs, as well as the contribution of suppliers. The key takeaways of this chapter are as follows:
• Enterprises that build systems that are largely independent or that can be built with a few hundred practitioners may not need this level. Even then, however, those are far from trivial systems, and some elements of the value stream level may still be useful.
• The VSE is a servant leader who facilitates the work of multiple ARTs and suppliers.
• The Solution Management role represents the customer’s overall needs across trains, as well as the strategic themes of the portfolio vision.
• The Solution Architect/Engineering role collaboratively defines the architecture that connects the solution across trains.
• In addition to the triad of roles (VSE, Solution Management, and Solution Architect/Engineering), customers are the ultimate buyers of every solution and are integral to the value stream.
• The economic framework permits fast, effective decision-making, within the scope of the value stream budget. This requires three things: an understanding of the rules for decision-making; knowledge of the current local context, or domain; and delegating relevant decision-making authority.
• Capabilities are similar to features; however, they account for higher-level behaviors of the solution, which often span multiple ARTs.
• Value stream epics are initiatives large enough to warrant analysis and a lightweight business case but are constrained to a single value stream.
• The value stream kanban is used to manage the flow of value stream epics and the capabilities.