Break down barriers between departments.
—W. Edwards Deming
Identify Value Streams and ARTs
This is article five in the SAFe® Implementation Roadmap series. Click here to view the entire roadmap.
The first four ‘critical moves’ of the Implementation Roadmap establish the urgency for change, and the critical mass of informed and dedicated people needed to implement SAFe effectively:
- Reaching the Tipping Point
- Train Lean-Agile Change Agents
- Train Executives, Managers, and Leaders
- Create a Lean-Agile Center of Excellence (LACE)
With a sense of urgency and a powerful coalition in place, it’s now time to implement SAFe. This article describes the next critical move—Identify Value Streams and Agile Release Trains (ARTs). Value streams and ARTs are the organizational backbone of a SAFe implementation and are critically important to the success of this journey. Attempting to shortcut or breeze through this step would be like putting your foot on the brake at the same time you are trying to accelerate. But get this one right, and the organization will be well on its way to a successful transformation.
Identifying Value Streams and Agile Release Trains (ARTs) requires an understanding of a new organizational model, one that is optimized to facilitate the flow of value across functional silos, activities, and boundaries, and includes the following steps:
- Identifying the operational value streams
- Identifying the systems that support the operational value stream
- Identifying the people who develop and maintain those systems
- Defining the development value streams that contain the systems and people
- Adding the people needed to build the full business solution
- Identifying the ARTs that realize the development value streams
The sections below describe each of these activities.
A Value Stream Refresher
A value stream is the primary construct for understanding, organizing, and delivering value in SAFe. As illustrated in Figure 1, each value stream is a long-lived series of steps used to create value—from concept to the delivery of a tangible result for the customer. Like any well-constructed narrative, the value stream identifies a chronological flow of activities:
- Trigger – Some important event triggers the flow of value, perhaps a customer purchase order or new feature request. It ends when some value—a shipment, customer purchase, or solution deployment—has been delivered.
- Steps – The chevrons in the middle are the steps the enterprise uses to accomplish this feat . For example, Figure 2 describes the steps needed to publish the article you’re reading now on this website.
- Value – The customer receives value when the value stream executes all of its steps. In Figure 2, the user gets value when she can read the article and increase her knowledge of SAFe.
- People and systems – A value stream also contains the people who do the work, the systems they operate, and the flow of information and materials. For example, in Figure 2, the people who write the articles, those who maintain the website, the WordPress application that makes the site functional, and Amazon’s Web Service hosting systems are all part of the value stream.
- Lead time – The time from the trigger to the delivery of value is the lead time. Shortening the lead time reduces the time to market. The easiest way to shorten lead time is to identify and reduce (or remove) non-value added activities and wasteful delays. That’s the primary focus of Lean thinking.
Types of Value Streams
Note that there are two types of value streams  as illustrated in Figure 3.
- Operational value streams – Contains the steps and the people who deliver end-user value using the business solutions created by the development value streams.
- Development value streams – Contains the steps and the people who develop the business solutions used by operational value streams. (These are the value streams that a SAFe portfolio manages.)
SAFe concerns itself primarily with development value streams. After all, delivering new solutions in the shortest sustainable lead time is the focus of SAFe, and development value streams help organizations understand how to get there. However, the enterprise’s operational value streams must be identified first to determine the development value streams that support them.
Identify Operational Value Streams
For some organizations, identifying operational value streams is easy. Many are just the products, services, or solutions that the company sells. In the larger enterprise, however, the task is more complicated. Value flows through various applications, systems, and services—across many parts of the distributed organization—to both internal and external customers.
In these cases, identifying operational value streams is an essential analytical activity. Figure 4 provides a set of questions that help stakeholders through that process of identification.
Identifying operational value streams in the large enterprise is not a trivial undertaking. It requires an awareness of the organization’s broader purpose and an explicit understanding of how specific elements of value flow to the customer. To assist you, two examples are provided in the sections below—one from healthcare, and one from financial services.
Healthcare Provider Operational Value Stream Example
The first operational value stream example is a healthcare network provider, as illustrated in Figure 5 :
For illustration, this example focuses on the hospital, specifically the value stream that represents the processes and information systems that support patient treatment—from intake through treatment and billing.
The trigger for this operational value stream is the arrival of a patient at the hospital. The hospital receives the full value after the patient is treated and payments are made for the services provided, as shown in Figure 6.
The people indicated above the chevrons (major activities of value delivery) are the people who execute the various steps in the operational value stream.
Financial Services Operational Value Stream Example
The second operational value stream example is a banking institution . Figure 7 illustrates the variety of value streams that might exist in such an organization.
The red rectangle highlights the ‘consumer banking loan’ value stream used for further illustration below. The flow of value is triggered by the customer searching for and finding the bank’s loan offerings and rates, and is fulfilled when the customer repays the loan with interest. The steps and the people who perform them are highlighted in Figure 8.
(Note: The customer is also a direct participant in this value stream.)
Value Stream Definition Template
The value stream definition template can be used to further elaborate and understand the characteristics of the identified operational value stream. Figure 9 provides an example.
Identify the Systems that Support the Operational Value Stream
Once the operational value stream steps are identified, the next activity is to identify the systems that are developed to support it. For larger value streams it’s important to map the connections from the systems to the various steps in the value stream. This creates a deeper understanding of how it all works, as the consumer loan example illustrates in Figure 10.
Identify the People Who Develop the Systems
Once the systems that support the operational value stream have been identified, the next activity is to estimate the number and locations of the people that build and maintain those systems, as Figure 11 illustrates.
Define the Development Value Streams
The next step is to identify the development value streams, which represent the steps needed to develop those systems as well as the people who develop them. Since these are different value streams from the operational ones, organizations need to consider what the trigger and value are. The systems support and enable better operation within the operational value streams and as such the value is new or amended features in the systems. The triggers, then, are the requirements and ideas which drive these features.
These triggers can be used to identify the number of development value streams. If most requirements necessitate touching all systems to enable the new functionality, there is likely only one development value stream. If, however, the systems are decoupled, there might be a few of them. In any case, development value streams should be mostly or wholly independent, and able to develop and release by themselves, without too many intra-value stream dependencies. In the example in Figure 12, most requirements touch the first three systems or the last one, but rarely all four, and so there are two development value streams, each capable of developing, integrating, deploying, and releasing independently of the other.
Add the People Needed to Build the Full Business Solution
Development value streams strive to deliver innovative business solutions and as such require the contributions of more than just development teams. Everyone involved in business solution delivery — IT operations, legal, marketing, finance, support, compliance, security, and others — are considered part of the development value stream. With this in mind the next step is to identify these additional individuals and teams who are part of the development value streams identified in the previous step.
In the example in Figure 13, the first development value stream, focused on the loan application process, includes marketing to develop promotional materials and campaigns for attracting customers. Legal team members are also included to define the relevant terms and conditions of the loans being offered. The second development value stream, which develops the Core Banking system that manages repayment of loans, also includes marketing for managing ongoing communications with the existing customer base. Both development value streams include support teams, to respond to any customer issues that might arise, as well as operations teams, that manage the stability of these systems in production.
Development Value Streams Cross Boundaries
Once the development value streams are identified, the next step is to start to understand how to form Agile Release Trains(ARTs) to realize them. The ARTs contain all the people and other assets needed to enhance the flow of value. The first step is to understand where in the organization that value is created because that is where the people, processes, and systems are. When doing so, it becomes obvious that development value streams cross many boundaries. Enterprises are organized the way they are for many reasons: history, functional convenience, the efficiency of centralization, acquisitions, geography, and more. As a result, it’s entirely possible that no one understands the complete series of events necessary to continually develop and enhance the systems that help deliver the value. Furthermore, attempts to improve tend to focus on functional, local improvements, which may result in the optimization of one function or step but sub-optimization of the end-to-end flow.
It is the long-lived nature of value streams that triggers different thinking in the Lean organization. To address this, enterprises apply systems thinking (Principle #2, Apply systems thinking) and come to understand how various parts of the system need to work together to accomplish improved flow. Typically, larger enterprises are organized functionally. In addition, people are often distributed geographically. But value moves across these boundaries, as Figure 14 illustrates.
Identify the ARTs
The final activity is to define the ARTs that realize the value. Experience has shown that the most effective ARTs have the following attributes:
- 50 – 125 people
- Focused on a holistic solution or related set of products or services
- Long-lived, stable teams that consistently deliver value
- Minimize dependencies with other ARTs
- Can release independent of other ARTs
Depending on how many people do the work, there are three possible scenarios for the ART design, as Figure 15 illustrates.
- Multiple development value streams can fit within a single ART – When several related products or solutions can be produced with a relatively small number of people, a single ART may deliver multiple value streams.
- A single development value stream can fit within an ART – Often, a Value Stream can be realized with 100 or fewer practitioners. Many development groups are already organized into units of about that size, so this is a common case. In this case, the ART is roughly the same as the value stream. Everyone is in that ART!
- Multiple ARTs are required for large development value streams – When a lot of people are involved, the development value stream must be split into multiple ARTs, as described in the next section, and form a Solution Train.
Splitting Large Value Streams into Multiple ARTs
Large development value streams are very common in large enterprises and often some additional analysis is required. When possible, trains should be focused on a single, primary solution, or a set of closely related products or services in that value stream. This is a fairly simple design—one ART delivering a well-defined set of valuable things.
However, in the case where many people are needed to deliver a single solution, it works best when teams work together while developing features and components that have high degrees of interdependence. This leads to the relatively common pattern of organizing ARTs around ‘feature areas’ or subsystems.
- Feature area ARTs are optimized for flow and speed. In this case, individual teams on the train, and the entire train itself can deliver end-to-end features. The benefit is obvious, and that’s why they’re preferred. But pay attention to subsystem governance, or else the system architecture will decay, ultimately reducing velocity. Often, a system architect (one or more individuals, or even a small team) is dedicated to maintaining architectural integrity.
- Subsystem ARTs applications, components, platforms, and so on, are optimized for architectural robustness and reuse of subsystems and services. Again, the benefit is obvious, as this can increase development and reuse efficiencies. (Service-oriented architectures leverage this.) However, depending on the separation of concerns in the system architecture, the flow of value in this scenario can create more dependencies, and require coordination among the ARTs.
There’s no one right solution, and large systems typically require both types of ARTs. A typical example is when multiple ARTs provide services or solutions based on a common platform. In that case, there may be one or more platform ARTs supporting the feature ARTs, as Figure 16 illustrates.
There is another common pattern, where ARTs realize specific segments in a larger Value Stream. That may not seem fully end-to-end, but in reality, the ‘beginning and end’ of a value stream are relative notions. The types of input, value, and systems may be very different in these segments, creating a logical dividing line.
And of course, combinations of these models often appear in the larger value streams, as our final example in Figure 17 illustrates.
Finally, there are other ART design and optimization factors based on concerns such as geography, spoken language, and cost centers—all of which may influence the ART design. But these are far less desirable.
The SAFe Value Stream and ART identification Workshop
As demonstrated, there’s critical thinking and analysis involved in this process. To help identify value streams, Scaled Agile, Inc. provides a Value Stream and ART identification workshop toolkit, consisting of a workshop and other artifacts that SAFe Program Consultants (SPCs) can use to guide stakeholders. The workshop provides a structured approach to identifying value streams and to defining ARTs, which can realize the flow of value in the enterprise. This toolkit offers a proven, systematic approach to optimize ART design by considering the dependencies, coordination, and constraints.
The Value Stream and ART identification workshop is often run directly following a Leading SAFe class with key stakeholders. The objective is to take them through the process of identifying the value streams, designing the ARTs, and perhaps even picking the date for the first ART launch after they have a fundamental understanding of Lean-Agile development enabled by SAFe.
Because no design is perfect, enterprises sometimes repeat this workshop after learning more, as part of the Accelerate roadmap step. Doing this allows enterprises to refine their understanding of value streams and ARTs and incorporate new learnings into the organizational design.
This article described how teams do the work to identify the value streams and design the ARTs that form the basic organizational structure for the transformation.
Now it’s time for the next step, Create the Implementation Plan, which is the next article in the SAFe Implementation Roadmap.Next
Learn More Allen Ward, Lean Product, and Process Development. (video) Lean Enterprise Institute, 2004  Contributed by Jane Tudor, Justine Johnston, Matt Aaron, Steve Mayner, and Thorsten Janning.  Contributed by Darren Wilmshurst, Murray Ford, Per-Magnus Skoogh, Phillip Manketo, Sam Bunting, and Virpi Rowe.  Knaster, Richard and Leffingwell, Dean. SAFe Distilled, Applying the Scaled Agile Framework for Lean Software and Systems Engineering. Addison-Wesley, 2017.
Last update: 28 September 2019