Skip to content
Scaled Agile Framework - SAFe 5

icon picker
Value Stream Coordination

Content Page. Value Stream Coordination defines how to manage dependencies and exploit the opportunities that exist only in the interconnections between value streams.
All it takes to play baseball is a strong arm, good speed and the coordination to hit the ball. That’s it.
—Ryne Sandberg

Value Stream Coordination

Although many value streams operate independently, cooperation among a set of can provide some portfolio level capabilities and benefits that competitors can’t match To this end, understand the challenge and opportunity their value streams provide. They make them as independent as possible, while simultaneously interconnecting and coordinating them with the enterprise’s larger purpose.


By their very nature, value streams are long-lived and generally independent of each other. For example, a systems or software company may sell many products and services, largely decoupled from each other in technology. More likely, however, is that they have dependencies between them. Although we typically think of dependencies in a negative sense, Principle #2 – Systems Thinking informs us that value flows through these dependencies. Yes, there are challenges to be addressed, but there are also valuable opportunities to exploit.
Most importantly, this additional value is often unique and differentiated. Indeed, an enterprise may offer a set of solutions via those very dependencies that cannot be matched by competitors. Or perhaps the competitor has not developed mastery in surfacing the unique and emerging capabilities that these coordinated value streams can provide.

Coordinating Value Streams

Exploiting opportunities from the interconnections between value streams requires the ability to coordinate value streams within a portfolio, as illustrated in Figure 1 and described in the sections below.
Figure 1. Cross-Value Stream coordination

1. Coordination Roles and Responsibilities

Keen observers of SAFe are probably aware that the Framework includes a repeating pattern of three primary roles, each with a consistent set of responsibilities:
What gets built Product Owner > Product Management > Solution Management
How it gets builtAgile Team > System Architect/Engineering > Solution Architect/Engineering
Servant leadership-based operation and executionScrum Master > Release Train Engineer (RTE) > Solution Train Engineer (STE)

So, whenever a significant degree of coordination is required, it isn’t surprising to see the similar roles and responsibilities appear in large portfolios. As seen in Figure 2, these roles are filled by:
Solution Portfolio Management – Has the overall responsibility for guiding a portfolio to a set of integrated solutions
Enterprise Architect – Provides technical guidance for the long-term evolution of the technologies and platforms and the larger (e.g. security, Compliance, performance, and more) for the portfolio solution set
Agile Program Management Office (APMO) – The Agile Program Management Office (APMO), along with RTEs and STEs, is typically responsible for supporting decentralized, but efficient, program execution

Figure 2. Cross-value Stream coordination roles

2. Apply Cadence and Synchronization

Figure 3 illustrates how Principle #7- Apply cadence and synchronization is as relevant to the , as it applies to Agile Release Trains (ARTs) and Solutions Trains. The benefits of this principle are the same:
Making routine things happen regularly, thus lowering the transaction costs associated with change
Synchronizing the various aspects of multiple value stream solution development

Figure 3. Apply cadence and synchronization across dependent value streams (whenever possible)
Shared cadence also provides the opportunity and the mandate for the portfolio level solution (via ) to move forward in sync with defined planning and integration points. Each creates the occasion to evaluate the solution set under development objectively and supports large-scale continuous integration with internal and external suppliers.

3. Introducing New Portfolio Level Work

Figure 4 illustrates another vital concept: the portfolio cadence determines the rate and timing at which new portfolio level work can be added into the system.
During each Program Increment (PI), the Agile Release Trains (ARTs) and Solution Trains are focused on the committed PI Objectives. Any new work added to the system in the interim causes substantial interruptions, task switching, realignment, and movement of people to new objectives. The portfolio cadence provides a reliable rhythm for introducing new portfolio work since teams often cannot meet prior commitments and mix in significant unplanned work. It helps the programs achieve the predictability the enterprise depends on.
Figure 4. Introducing new portfolio level work
Through the system, this cadence also establishes conventional mechanisms for , , and others managing epics. Any epic that’s not ready for PI Planning must wait for the next PI, even though capacity may have been available. Timeboxing the cadence also limits Work in Process (WIP) for the new and substantial work that will be introduced into the system.

4. Ensured Integration Points

When integrating solutions across value streams it may not be possible to do full integration across them, every iteration (Figure 5.) Therefore, it’s imperative to do partial integration throughout the Program Increment (PI) when full integration is not yet possible. These cadence-based integration points are the only true measure of portfolio velocity. The more frequently we integrate, the faster we learn.
Figure 5. Ensured integration points
It’s important to consider the following economic trade-offs when determining the cadence of integration:
Benefits of faster learning, which often translates into higher quality and better products
Cost of deferred learning and possible rework
Cost and benefits of DevOps automation
Depth of integration required
Fidelity of feedback needed
The level of customer satisfaction needed (from satisfy to delight)

Moreover, do not let small changes sit idle; this adds to the ‘holding’ cost, which is a form of waste. Instead, find a way to integrate them with other changes. DevOps practices, automation, and models support end-to-end integration to demonstrate complete or partial system-level functionality.

5. Portfolio Roadmap

As Figure 6 illustrates, the portfolio is both derived from and contributes to Solution roadmaps. This higher-level view provides the opportunity to integrate relevant aspects of the Solution roadmaps, and their associated , into a more comprehensive view, which communicates the larger picture to the enterprise and portfolio stakeholders.
Figure 6. Portfolio Roadmap

6. Deploying and Releasing New Work

Due to the nature of the value streams and dependencies, deploying and releasing integrated value depends on effective DevOps capabilities. In some cases, ARTs provide all the DevOps capability that’s needed. In others, there are additional considerations (Figure 7). These may even require dedicated or Shared Services and System Teams for individual ARTs and across value streams that help integrate the solution into a portfolio level release.
Figure 7. Deploying and release work across value streams

Navigation Bar

© Scaled Agile, Inc.
Include this copyright notice with the copied content.
Read the FAQs on how to use SAFe content and trademarks here:
Explore Training at:
This link can't be embedded.
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
) instead.