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.
Details
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:
- Identify the Operational Value Streams
- Identify the Solutions the operational value streams use or provide to customers
- Identify the people who develop and support the solutions
- Identify the Development Value Streams that build the solutions
- Add the people needed to build the full business solution
- Realize development value streams into ARTs
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 [1].
- Value – The customer receives value when the value stream executes all of its steps.
- 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.
- 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 [1] as illustrated in Figure 2.
- 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 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 broader purpose and an explicit understanding of how specific elements of value flow to the customer.
Most generally, operational value streams fall into one of four types:
- Fulfillment value streams represent the steps necessary to process a customer request, deliver a digitally-enabled product or service, and receive remuneration. Examples include providing a consumer with an insurance product or fulfilling an eCommerce sales order.
- Manufacturing value streams convert raw materials into the products customers purchase. Examples include consumer products, medical devices, and complex cyber-physical systems.
- Software product value streams offer and support software products. Examples include ERP systems, SaaS, and desktop and mobile applications.
- Supporting value streams include end-to-end workflows for various supporting activities. Examples include the lifecycle for employee hiring and retention, supplier contracting, executing the annual budget process, and completing a full enterprise sales cycle.
And although companies need strong, functional departments to build and share knowledge, sales, marketing, purchasing, legal, finance, and manufacturing engineering are not themselves value streams. However, many of the people in these departments participate in one or more operational value streams.
It stands to reason that large enterprises typically offer a wide variety of products and services to their customers. That’s one of the ways they grow. As such, it follows that there are a substantial number of value streams within those enterprises. Figure 5 illustrates how the ‘consumer loan’ value stream is just one of the offerings and operational value streams of a large commercial bank [2].
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 6 provides an example.
Identify the Solutions the Operational Value Stream use, or Provide to Customers
Once the operational value stream steps are identified, the next activity is to identify the solutions that are developed to support it, or that it provides to its customers. It’s important to map the connections from the solutions to the various steps in the value stream as well as identifying the people who operate these solutions. This creates a deeper understanding of how it all works, as the consumer loan example illustrates in Figure 7.
(Note: The customer is also a direct participant in this value stream.)
Identify the People who Develop and Support the Solutions
Once the solutions 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 solutions, as Figure 8 illustrates.
Identify the Development Value Streams that Build the Solutions
The next step is to identify the development value streams, which represent the steps needed to develop those solutions 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 solutions support and enable better operation within the operational value streams and as such the value is new or amended features in the solutions. 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 solutions to enable the new functionality, there is likely only one development value stream. If, however, the solutions 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 9, 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.
While there is no obvious limit or constraint to ways an enterprise can configure development value streams, specific patterns have emerged. These are discussed in detail in the Development Value Streams article.
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 Agile 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 10, 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. Typically, larger enterprises are organized functionally. In addition, people are often distributed geographically. But value moves across these boundaries, as Figure 11 illustrates.
Realize Development Value Streams into 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 12 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, multiple ARTs will need to collaborate as part of a Solution Train. To support the overall goal of continuous value delivery to the customer, each ART within the Solution Train must be designed to maximize flow across the entire Solution Train.
As described in the Agile teams and Agile Release Train articles, SAFe recognizes fundamental team topologies [4] to help with the job of team and ART design, which are defined as follows:
- Stream-aligned team – organized around the flow of work and has the ability to deliver value directly to the customer or end user.
- Complicated subsystem team – organized around specific subsystems that require deep specialty skills and expertise.
- Platform team – organized around the development and support of platforms that provide services to other teams.
- Enabling team – organized to assist other teams with specialized capabilities and help them become proficient in new technologies.
These topologies can be readily extended to help make the right trade-offs in ART design as part of a Solution Train, (Figure 13).
(Note: A possible exception when applying these topologies to ARTs is the ‘enabling’ team type. Although it is common to have two or three enabling teams working across the portfolio—all aligned to the same objective—it is unlikely this would represent an entire ART on a Solution Train.)
Scaling these topologies to organize ARTs requires some additional considerations, as highlighted in the sections below.
Stream-aligned ARTs
A stream-aligned ART, just like a stream-aligned team, will have the necessary personnel, skills, and authority to deliver value, whether it’s a full product, service, subsystem, or whatever portion of the solution they have been tasked with.
The areas of responsibility for these stream-aligned ARTs are generally the same as they are for stream-aligned teams. And the same options for aligning them around a particular aspect, as covered earlier, apply here as well.
Complicated subsystem ART
Most large systems also include extensive subsystems. This means that complicated subsystem ARTs are common when building large-scale systems, again to reduce the cognitive load on the stream-aligned ARTs. For example, a guidance system for an autonomous vehicle could well require an entire complicated subsystem ART.
Platform ARTs
Similarly, it’s common for a Solution Train to have Platform ARTs providing services that the stream-aligned ARTs extend and build on. Continuing the example of the autonomous vehicle, a communication system that manages data transferred between the various subsystems would likely be represented as a platform ART, with clearly defined interfaces.
(Note: One additional benefit of the platform topology is that it also supports a single platform ART that is providing services across multiple development value streams within the organization.)
And of course, combinations of these types often appear in the larger value streams, as our final example in Figure 14 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.
Moving Forward
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.
NextLearn More
[1] Ward, Allen. Lean Product, and Process Development (video). Lean Enterprise Institute, 2004. [2] Contributed by Wilmshurst, Darren, Murray Ford, Per-Magnus Skoogh, Phillip Manketo, Sam Bunting, and Virpi Rowe. [3] Knaster, Richard, and Dean Leffingwell. SAFe 5.0 Distilled, Achieving Business Agility with the Scaled Agile Framework. Addison-Wesley, 2020. [4] Skelton, Matthew, and Manuel Pais. Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press, 2019.Additional Resources
Value Stream and ART Identification Workshop Toolkit for SPCs.
Last update: 10 February 2021
