All it takes to play baseball is a strong arm, good speed and the coordination to hit the ball. That’s it.
Value Stream Coordination
Value Stream Coordination defines how to manage dependencies and exploit the opportunities that exist only in the interconnections between value streams.
Although many value streams operate independently, cooperation among a set of Solutions can provide some portfolio level capabilities and benefits that competitors can’t match To this end, Lean-Agile Leaders 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 companies that do not provide an equivalent set. 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 valuable 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 built – Agile Team > System Architect/Engineering > Solution Architect/Engineering
- Servant leadership-based operation and execution – Scrum 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 Nonfunctional Requirements (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. The APMO provides support for standard reporting patterns, shared best practices, and growth and dissemination of institutional knowledge.
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 Portfolio Level, 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 Epics) 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. If new work is added to the system in the interim, it 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 Portfolio Kanban system, this cadence also establishes conventional mechanisms for Epic Owners, Enterprise Architects, and others managing epics. Any epic that’s not ready for PI Planning must wait for the next PI, even though resources 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
Clearly, at this level of the portfolio, a plan of intent must be evident. As Figure 6 illustrates, a portfolio Roadmap is a useful artifact that highlights how new content, primarily in the form of epics, contributes to the plan of intent.
This higher-level view also provides the opportunity to integrate aspects of the lower-level roadmaps, and their associated Milestones, 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
Last update: 6 September 2019