Break down barriers between departments.

—W. Edwards Deming

バリューを中心にオーガナイズする

This is article six in the SAFe^® Implementation Roadmap series. Click here to view the entire roadmap.

The first five ‘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 of empowered change agents in place, it’s now time to implement SAFe. This article describes the next critical move—Organize Around Value. 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 while simultaneously trying to accelerate. But get this one right, and the organization will be well on its way to a successful transformation.

詳細

Organizing around value 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 make the whole 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:

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 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 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 value delivery is the total lead time (or Flow 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.

Figure 2. Operational and development value streams

Operational Value Streams – Contain 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 in a SAFe portfolio.)

Development value streams are SAFe’s primary concerns. 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 steps to produce 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 internal and external customers.

Identifying operational value streams in a 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. The below questions can help stakeholders through that identification process.

Who are your users and customers? Are they internal, external, or both?
What products and services do you market, sell, and support?
What solutions do you provide for internal users?
What triggers the flow of value?
What value do your customers perceive you deliver?

Most generally, operational value streams fall into one of four types shown in Figure 3:

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 employee hiring and retention lifecycle, supplier contracting, executing the annual budget process, and completing an entire enterprise sales cycle.

Figure 3. Examples of the four types of operational value streams

And although companies need strong, functional departments to build and share knowledge, sales, marketing, purchasing, legal, finance, and manufacturing engineering are not 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 their customers a wide variety of products and services. That’s one of the ways they grow. As such, it follows that there are substantial value streams within those enterprises. Figure 4 illustrates how the ‘consumer loan’ value stream is just one of a large commercial bank’s offerings and operational value streams [2].

Figure 4. Operational value streams in a commercial bank

Value Stream Definition Template

The value stream definition template in Figure 5 can be used as an aid to elaborate and understand the characteristics of the identified operational value stream.

Figure 5. Value stream definition template with an operational value stream 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 identifying the solutions needed to support it. It’s essential to map the connections from the solutions to the various steps in the value stream and identify the people who operate these solutions. The map creates a deeper understanding of how it all works, as the consumer loan example illustrates in Figure 6.

Figure 6. Identifying the systems that support the steps

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

Figure 7. Identifying the people who develop the systems

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 and the people who create them. The solutions support and enable better operational value streams; as such, the value is new or amended features for the solutions. The triggers for the development value streams are the needs and ideas that drive these features.

Figure 8. Defining the development value streams

These triggers are also used to identify the development value streams. If most requirements necessitate touching all solutions to enable the new functionality, there is likely only one development value stream. If 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 8, most requirements touch the first three systems or the last one, but rarely all four, so there are two development value streams, each capable of developing, integrating, deploying, and releasing independently of the other.

While there is no apparent 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 development — including representatives of IT operations, legal, marketing, finance, support, compliance, security, and others — is 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.

Figure 9. Add the People Needed to Build the Full Business Solution

In the example in Figure 9, 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 offered. The second development value stream, which develops the Core Banking system that manages the 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 and 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 understanding 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 value is created in the organization because that is where the people, processes, and systems are. It becomes evident that development value streams cross many boundaries when doing so. Enterprises are organized the way they are for many reasons: history, functional convenience, the efficiency of centralization, acquisitions, geography, and more. As a result, no one may understand the complete series of events necessary to develop and enhance the systems that help deliver value continually. Furthermore, improvement attempts often 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.

The long-lived nature of value streams 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 10 illustrates.

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

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

Figure 11. 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.
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 typical 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 many 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 ubiquitous in large enterprises, and additional analysis is often required. Trains should focus on a single primary solution or a set of closely related products or services. In smaller value streams, the result is a relatively simple design—one ART delivering a well-defined set of solutions.

However, when 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, 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 specialist 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 help make the right trade-offs in ART design in the context of a Solution Train (Figure 12).

Larger Value Streams require multiple ARTs in a Solution Train

Figure 12. A mixture of topologies applied to ARTs within a Solution Train

(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 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 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 complete 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 for stream-aligned teams. And the same options for aligning them around a particular aspect, as covered earlier, apply here as well.

Complicated subsystem ARTs

Most large systems also include extensive subsystems. This means complicated subsystem ARTs are expected when building large-scale systems 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 autonomous vehicle example, a communication system that manages data transferred between the various subsystems would likely be represented as a platform ART with clearly defined interfaces.

Enabling ARTs

While not pictured in Figure 12 and less common than the other ART topologies, enabling ARTs provide specialty tools, services, or expertise to other ARTs and teams. Some enabling ARTs may operate as part of a solution Solution Train, internally enable the other ARTs delivery or externally enabling consumers of the Solution Train’s large solution.

(Note: One additional benefit of the platform topology is that it also supports a single platform ART that provides services across multiple development value streams within the organization.)

And, of course, combinations of these types often appear in larger value streams, as our final example in Figure 13 illustrates.

Figure 13. Combinations of ART topologies in the consumer bank loan example

Finally, other ART designs and optimization factors are based on concerns such as geography, spoken language, and cost centers, 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 Practice Consultants (SPCs) can use to guide stakeholders. The workshop provides a structured approach to identifying value streams and defining ARTs, which can realize the flow of value in the enterprise. This toolkit offers a proven, systematic approach to optimizing 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 critical stakeholders. The objective is to take them through 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 organize around value and design the ARTs that form the basic organizational structure for the transformation.

Some change leaders may find identifying their portfolios and beginning the initial steps of organizing the Portfolio related to the initial ARTs identified assists in this acceleration. In this case, activities described within Enhance the Portfolio may be begun here, with the knowledge that these critical moves are not dependent on each other but have the potential of accelerating each other early on.

Now it’s time for the next step, Create the Implementation Plan, which is the next article in the SAFe Implementation Roadmap.

詳しく学ぶ

[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

SPCs have access to a Value Stream and ART Identification Workshop explicitly designed to help identify value streams, initially define ARTs, and create the implementation plan. Learn more about the toolkit.

Last update: 19 January 2023