Break down barriers between departments.
—W. Edwards Deming
This is article five in the SAFe® Implementation Roadmap series. Click here to view the entire roadmap.
Identify Value Streams and ARTs
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 effectively implement SAFe. These steps were described in the previous articles:
- 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 take steps to actually implement SAFe. In this article, we describe the next critical move: Identify Value Streams and Agile Release Trains (ARTs). If you think of value streams and ARTs as the organizational backbone of a SAFe initiative, you will understand their importance to this journey. Attempting to shortcut or breeze through this step would be the same as putting your foot on the brake at the same time you are trying to accelerate. But get this one right, and you’ll be well on your way to a successful transformation.
Identifying enterprise Value Streams and Agile Release Trains requires a fundamental understanding of a new organizational model, one that is optimized to facilitate the flow of value across functional silos, activities, and boundaries. This is not a trivial process, and it includes a number of key activities:
- Identifying operational value streams
- Identifying the systems that support the operational value stream
- Identifying the people in the development value stream
- Identifying ARTs
Each of these activities are described in the sections below.
A Value Stream Refresher
Before we begin, a brief refresher is in order. 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. The flow of value is triggered by some important event, perhaps a customer purchase order or new feature request. It ends when some value has been delivered—a shipment, customer purchase, or solution deployment.
- Steps. The part in the middle are the steps the enterprise uses to accomplish this feat [see Ref 1]. For example, Figure 2 describes the steps needed to publish the article you’re reading now on the this website.
- Value – Value is created when the value stream executes all of its steps and delivers value to the customer. In Figure 2, value is delivered when the user can read the finished article and increase their knowledge if 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 website functional, and Amazon’s Web Service hosting systems are all part of the value stream.
- Lead Time – The time from the trigger to delivery of value is the lead time. Shortening the lead time shortens the time to market. That’s the primary focus of Lean thinking.
Types of Value Streams
Before we risk oversimplifying, note that there are two types of value streams .
- Operational value streams – These are the people and steps used to provide goods or services to a customer. Examples might include manufacturing a medical instrument, or ordering and receiving a part from a supplier.
- Development value streams – These are the people and steps used to develop new products, systems, solutions, and services sold by the enterprise, or that support internal operational value streams. These are the value streams that constitute a SAFe portfolio.
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 value streams help us understand how to get there. However, understanding both types of value streams is important, as teams must understand the enterprise’s operational value streams in order to build the development value streams that support them.
Identify Operational Value Streams
For some organizations, identifying operational value streams is easy. Many are simply the products, services, or solutions that the company develops and 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 important analytical activity. Figure 3 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 larger purpose, and an explicit understanding of how specific elements of value flow to the customer. To assist you, we’ve illustrated two examples in the sections below—one from healthcare, and one from financial services.
Value Stream Definition Template
Once identified, each value stream can be further characterized for more complete understanding. Table 2 provides a template, along with an operational value stream example.
|Description||Provides Customers with a fast, consistent ordering experience from mobile or web|
|Customer(s)||Small- to medium-size business|
|Triggers||New customer order or order update|
|Inputs||New order detail (with Customer information)|
|Outputs||Shipment request to shipping, billing information to finance|
|Includes||Internal customer-order work flows and personnel, SAP order management, help desk, mobile and web order entry applications|
Table 2. Value stream definition template with an operational value stream example
Healthcare Provider Value Stream Example
Our first operational value stream example is a healthcare network provider, as illustrated in Figure 4 :
For further analysis, the teams decided to focus 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 value stream is the arrival of a patient at the hospital. Full value is realized when the patient is treated and payments are received for the services provided, as illustrated in Figure 5.
The people indicated at the top are the people who execute the various steps in the value stream.
Financial Services Value Stream Example
The second operational value stream example, and one we will develop further, is a banking institution. Upon initial analysis, the teams determined that there are a number of primary value streams as indicated in Figure 6.
For additional analysis, the team selected the “consumer banking loan” value stream. This flow is triggered by the granting of a loan (origination) and is fulfilled when the loan is repaid with interest. They identified the steps and the people who perform them, as highlighted in Figure 7. (Note that the customer is also a direct participant in this value stream.)
Identify the Systems that Support the Value Stream
Once the steps in the operational value stream 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 our consumer loan example illustrates in Figure 8.
Identify the People in the Development Value Stream
Once the systems that support the operational value stream have been identified, the next activity is to estimate the number and locations and number of the people that build and maintain those systems. This defines the development value stream that supports the operational value stream, as Figure 9 illustrates.
Development Value Streams Cross Boundaries
Once the value streams are identified, the next step is to start to understand how to form Agile Release Trains 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, efficiency of centralization, acquisitions, geography, and more. As a result, it’s quite possible that no one really understands the complete series of events necessary to continually develop and enhance the systems that help deliver the value. Further, attempts to improve tend to focus on functional, local improvements, the result of which may be 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 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 distributed across multiple geographies and multiple countries. But value moves across these boundaries, as Figure 10 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 system, or related set of products or services
- Long-lived, stable teams that consistently deliver value
- Minimize dependencies with other ARTs
- Can Release value independent of other ARTs
Depending on how many people do the work, there are three possible ART scenarios that can arise, as Figure 11 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. In this case, ‘ART design’ is largely . Everyone is on that ART!
- A single development value stream can fit within an ART – Often, a Value Stream can be realized with 100 or less practitioners. Many development groups are already organized into units of about that size, so it’s a common case. Again, everyone is on the ART.
- Multiple ARTs are required for large development value streams – When a lot of people are involved, the development value must be split into multiple ARTs, as described in the next section.
Splitting large value streams into multiple ARTS
The last case is very common in large enterprises, and some additional analysis is required. When possible, trains should be focused on a single, primary system, 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 system, it works best when teams developing features and components that have high degrees of interdependency work together. This leads us to the fairly 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 small team) is dedicated to maintaining platform 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 12 illustrates.
There’s 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 13 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 generally far less desirable.
The SAFe Value Stream and Implementation Workshop
As you can see, there’s critical thinking and analysis involved in this process. To help you identify value streams, Scaled Agile, Inc. provides a Value Stream 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 provides a proven, systematic approach to optimize design by considering the dependencies, coordination, and constraints.
The Value Stream 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.
In this article, we’ve 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 we’re ready for the next step, Create the Implementation Plan, which is the subject of the next article in the SAFe Implementation Roadmap.Next
Learn More Allen Ward, Lean Product and Process Development. Lean Enterprise Institute, 2004
 Contributed by SPCT candidates Jane Tudor, Justine Johnston, Matt Aaron, Steve Mayner, and Thorsten Janning
 Contributed by SPCT candidates 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.
Value Stream Toolkit for SPCs.
Last update: 26 May, 2017