ROADMAP-NAV-ICON-05-identify-VS

Break down barriers between departments.

—W. Edwards Deming


This article is part of the SAFe® Implementation Roadmap series which outlines and discusses the primary ‘critical moves’ that are common to successful SAFe transformations. To view the Roadmap and find links to the entire set of supporting articles, click here.


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:

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.

Details

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 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:

Figure 1. The anatomy of a Value Stream
Figure 1. The anatomy of a Value Stream
  • 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.
Figure 2. Steps in the value stream that created this article
Figure 2. Steps in the value stream that created this article
  • 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. In addition, 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 the value delivery 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 [1].

  • 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.

Figure 3. Questions to help identify operational value streams
Figure 3. Questions to help identify operational value streams

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.

Healthcare Provider Value Stream Example

Our first operational value stream example is a healthcare network provider, as illustrated in Figure 4 [2]:

Figure 4. A healthcare network provider’s operational value streams.
Figure 4. A healthcare network provider’s operational value streams.

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.

Figure 5. Steps in the patient billing value stream
Figure 5. Steps in the patient billing value stream

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.

Figure 6. A bank and its operational value streams
Figure 6. A bank and its operational value streams

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.)

Figure 7. The consumer loan value stream.
Figure 7. The consumer loan 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.

Figure 8. Identifying the systems that support the steps
Figure 8. Identifying the systems that support the steps

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.

Figure 9. Identifying the development value stream
Figure 9. Identifying the development value stream

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 10 illustrates.

Figure 10. Three possible scenarios for ART design
Figure 10. Three possible scenarios for ART design
  • 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. We’ll discuss that further below.

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 11 illustrates.

Figure 11. A common feature area ART and platform ART pattern
Figure 11. A common feature area ART and platform ART pattern

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 12 illustrates.

 

Figure 12. Combination of ART patterns in the bank loan example
Figure 12. Combination of ART patterns in the bank loan example

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

SPC_toolkit_thumbAs 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.

Moving Forward

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.

Learn More

[1] Allen Ward, Lean Product and Process Development. Lean Enterprise Institute, 2004
[2] Contributed by SPCT candidates Jane Tudor, Justine Johnston, Matt Aaron, Steve Mayner, and Thorsten Janning
[3] Contributed by SPCT candidates Darren Wilmshurst, Murray Ford, Per-Magnus Skoogh, Phillip Manketo, Sam Bunting, and Virpi Rowe

Additional Resources

Value Stream Toolkit for SPCs.

Last update: 14 February, 2017