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 — luxury customers with low-cost and low-quality suppliers, for example.
—Alan C. Ward
Value Stream Level Abstract
The Value Stream Level is intended for builders of large and complex solutions, solutions that typically require multiple ARTs as well as the contribution of Suppliers. The level provides a number of constructs that are new in SAFe 4.0. It was designed in large part based on the input of Enterprises that face the largest systems challenges, building multidisciplinary and cyber-physical systems that contain software, hardware, electrical and electronic, optics, mechanics, fluidics, and more. Building these systems often takes hundreds, even thousands, of practitioners, as well as internal and external Suppliers. These systems are mission crucial. Failure of the Solution, or even a subsystem, has unacceptable economic and societal consequences.
This is serious business, and yet traditional, stage-gated approaches do not always scale well to the challenge. A leaner and more Agile approach is required to deliver the right economics, as well as solution efficacy and safety. SAFe addresses this in general, but now with a particular focus on the largest systems at the value stream level, intended to help those defining, building, and deploying these, the world’s most important systems.
The Value Stream Level is optional in SAFe. Enterprises that build systems that are largely independent, or that can be built with a few hundred practitioners, may not need the constructs of this level, in which case they can operate from the “collapsed view,” which is called 3-level SAFe. Even then, however, those are far from trivial systems, and the constructs at the value stream level can be used in 3-level SAFe. It’s a framework, after all.
But the primary purpose of this level is to describe Lean-Agile approaches to systems development that scale to the challenge of defining, building, and deploying large, mission-critical Solutions.
Building such solutions in a Lean-Agile manner requires additional constructs, artifacts, and coordination. Therefore, this level contains an Economic Framework to provide financial 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 deployment environment; and Capabilities, describing the larger behaviors of the solution.
Similarly to the Program Level, the value stream level is organized around Program Increments, which are synchronized across all the Agile Release Trains in the value stream. It provides for cadence and synchronization of multiple ARTs and Suppliers, including Pre-and Post-PI Planning meetings and the Solution Demo.
Much like the “troika” of the program level, the value stream level has its own troika of three critical roles necessary to coordinate and advance the value stream, as Figure 1 shows.
Execution and improvement – The Value Stream Engineer is the servant leader of the value stream. He is responsible for seeing that the value stream is running smoothly and that bottlenecks are identified and resolved across the entire value stream. He facilitates the value stream level meetings and monitors the Value Stream Kanban and the value stream health via its Metrics.
Content management – Solution Management represents Customers’ needs as well as the Strategic Themes of the portfolio Vision. They work with the ARTs’ Product Management to define capabilities and decompose them into Features. They are responsible for the Value Stream Backlog and its prioritization via WSJF, as well as for the creation of an economic framework to govern the decision-making process for ARTs and Agile Teams.
Technical excellence – Solution Architect/Engineering is a team in charge of defining the overarching architecture that connects the solution across ARTs. They also work with the System Architect/Engineering team to help guide the architecture developed by the trains.
Defining the Solution
Solution behavior and decisions are managed in solution intent, which serves both as a single source of truth and as a container for requirements in their transition from variable to fixed. In addition to vision and Roadmap, which also occur at this level via the spanning palette, the development of solution intent in an adaptive manner is supported by three additional practices:
- Model-Based Systems Engineering (MBSE) – Describes how emergent requirements and design can be developed, documented, and maintained in more flexible and more accessible models
- 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
Building the Solution
The main construct of the value stream level is the solution, which is the subject of the value stream. While the solution also appears at the program level in 3-level SAFe, additional practices and details are described at this level.
Solutions behave as described in solution intent, but they also live in the larger part of a solution context, which characterizes the environment in which a deployed solution operates. Solutions are built to satisfy needs of Customers and are built up of capabilities and Enablers, which are needed to realize the value stream vision and roadmap.
Capabilities are managed through the value stream Kanban system, which is used to verify that capabilities are evaluated and analyzed before they reach the value stream backlog, where they are queued for implementation. It also serves as a focusing mechanism and limits WIP to ensure that all the ARTs are synchronized and have the capacity to deliver capabilities together. Larger initiatives are managed as solution Epics and are broken down into capabilities during analysis.
Large solutions, in many cases, require Suppliers who develop components, subsystems, or capabilities for the value stream. These Suppliers participate in value stream level meetings.
Another function of the value stream level is to handle the coordination of multiple ARTs that deliver a solution together. To support this, all ARTs in the value stream are synchronized around a single PI cadence, with synchronized Iterations to facilitate collaboration across ARTs and even Suppliers.
At the start of each PI, planning takes place for all ARTs at the same time. The planning is done by the ARTs themselves in PI Planning meetings, but in order to align and create a single plan across all trains, as well as manage dependencies between the trains, pre- and post-PI planning meetings are also held, which results in aggregated Value Stream PI Objectives that can be communicated to stakeholders.
At the end of each PI (usually a bit into the next PI), a solution demo is held. This is an important event where the value stream shows Customers and stakeholders from the portfolio and from other value streams an integrated solution across all ARTs and Suppliers. After this demo, an Inspect and Adapt workshop is held to improve the process of the entire value stream.
Using Constructs of the Value Stream Level in 3-Level SAFe
As described, some of the constructs of the value stream level are primarily relevant for large value streams that have to be realized by multiple ARTs, but some may well be relevant to ARTs in a 3-level SAFe environment. These constructs include solution intent and related practices, which are particularly necessary in building high-assurance systems. The solution context, the economic framework, and guidance for working with Suppliers may also be relevant. While they do not “descend” to the program level in a 3-level SAFe “collapsed view” (the way Customer and solution do), they are still relevant, and many programs can and should use them as needed.
Last update: 31 March 2016