ROADMAP-NAV-ICON-05-identify-VS

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:

With a sense of urgency and a powerful coalition in place, it’s now time to 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 (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 it includes the following steps to identify:

  • Operational value streams
  • The systems that support the operational value stream
  • The people in the development value stream
  • The structure of the ARTs

The sections below describe each of these activiies

A Value Stream Refresher

Before we begin, a brief refresher is in order. A value stream is a 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
  • 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 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 this website.

Figure 2. Steps in the Value Stream that created this article

  • 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 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 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. 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] as can be seen in Figure 3.

Figure 3. Operational and development 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, the enterprise’s operational value streams must be identified 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 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 essential analytical activity. Figure 4 provides a set of questions that help stakeholders through that process of identification.

Figure 4. 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 broader 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

The value stream definition template can be used to further elaborate and understand the characteristics of the identified value stream. Table 1. provides an example.

Table 1. Value stream definition template with an operational value stream example

Healthcare Provider Operational Value Stream Example

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

Figure 5. 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. The Hosptial receives the full value after the patient is treated and payments are made for the services provided, as shown in Figure 6.

Figure 6. 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 some primary value streams as indicated in Figure 7.

Figure 7. 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 fulfilled when the customer repays the loan with interest. The team identified the steps and the people who perform them, as highlighted in Figure 8. (Note that the customer is also a direct participant in this value stream.)

Figure 8. The consumer loan value stream

(Note that the customer is also a direct participant in this value stream.)

Identify the Systems that Support the Value Stream

Once the operational value stream step 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 9.

Figure 9. Identifying the systems that support the steps

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

Figure 10. Identifying the people who develop the systems

Define the Development Value Streams

Next, we move 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 we need to consider what the trigger and value are. The systems support and enable better operation through 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.

Figure 11. Defining the development value streams

 

We can use these triggers to identify how many development value streams we have. If most requirements necessitate touching all systems to enable the new functionality, we probably have one development value stream. If however the systems are decoupled, we might have 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 11, most requirements touch the first three systems or the last two, but rarely all, and so we have two development value streams, each capable of developing, integrating, deploying, and releasing independently of the other.

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, 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. Further, attempts to improve 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 12 illustrates

Figure 12. Value flows across functional, organizational, and geographic boundaries
Figure 12. Value flows across functional, organizational, and geographic boundaries

 

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

Figure 13. 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, the ART’s is roughly the same as the value stream . 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 fewer 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, and form a Solution Train.

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

Figure 14. 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 15 illustrates.

Figure 15. ARTs 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 the 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.

Because no design is perfect, enterprises sometimes run this workshop again after learning more, as part of the Sustain and Improve part. This allows them to refine their understanding of value streams and ARTs and incorporate new learnings into the organizational design

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 next article in the SAFe Implementation Roadmap.

Next

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

[4] Knaster, Richard and Leffingwell, Dean. SAFe Distilled, Applying the Scaled Agile Framework for Lean Software and Systems Engineering. Addison-Wesley, 2017.

Additional Resources

Value Stream Toolkit for SPCs.

Last update: 31 October 2017