A system must be managed. It will not manage itself. Left to themselves, components become selfish, competitive, independent profit centres, and thus destroy the system … The secret is cooperation between components toward the aim of the organization.
Develop on Cadence. Deliver on Demand.
—A SAFe tenet
Program Level Abstract
At the Program Level of the Framework, the efforts of some number of Agile teams are aligned and integrated to create larger value to serve the needs of the enterprise and its stakeholders. To scale Agile at this level, we’ll scale the three prime constructs: value, teams, and timebox.
Value – Additional constructs are needed to describe system behavior at the higher levels of abstraction necessitated by larger system complexity. These are:
- the features of a system in the program backlog
- the vision for where the program is headed
- a roadmap that describes how the solutions will evolve over time
Teams – Our systems thinking approach requires more and different people and skills, too:
- Product Management to establish the larger vision and maintain contact with the marketplace
- A System Team to help pull the software assets together and (perhaps) test the end-to-end use cases and other requisite system qualities (NFRs)
- A Release Management Team with the authority to define and evaluate quality and release criteria, and to coordinate the actual releases
Timebox – This handy two-week iteration serves us well at the team level, but is too short a period for meaningful system, program, customer and business-level feedback. Rather, we’ll find it convenient to align planning on “PIs”, Program Increment boundaries, which occur on a steady cadence at intervals of every 8-10 weeks or so. Releasing can happen on these boundaries as well, or whenever the market demands, so this longer timebox primarily for planning, higher-level program assessment and Inspect and Adapt program improvement.
The Agile Release Train Delivers the Cargo
Value Streams are realized by one or more Agile Release Trains according to a fixed cadence called a Program Increment. Each Program Increment, typically 8–12 weeks, is a multiple-iteration timebox during which a significant, valuable increment of the system is developed. Each Agile Release Train is composed of 5 to 15 Agile Teams, and includes the roles and infrastructure necessary to deliver fully tested, working, system-level software.
Agile Teams meet with key program stakeholders on the PI cadence and plan the next increment during a Release Planning session, which is typically facilitated by a Release Train Engineer who serves as chief Scrum Master and also helps “keep the train on the tracks.” All members participate (physically or virtually) over a 1–2 day period where they share in the vision, plan together, work out inter-dependencies, establish Team PI Objectives and Program PI Objectives for the upcoming period.
Plans include a commitment to deliver a set of Features that have been prioritized by the Product Managers using Weighted Shortest job (WSJF) economic prioritization. Features appear at the boundary, driven by the Vision, Roadmap, and Program Epics. Features come from the Program Backlog, the single, definitive repository for all the anticipated upcoming work. Nonfunctional Requirements (NFRs) provide governance over the necessary system qualities of performance, security, reliability, availability, throughput, and others. Plans are made by the teams, and presented to the Business Owners for approval. Business Owners are integral to the train, and have specific responsibilities to assure that the train gets the fast market feedback it needs.
Thereafter, Release Trains produce fully tested, system-level solutions increments on the PI cadence cadence. Releasing is a separate concern and is done in accordance with market demands: Develop on Cadence, Release on Demand. In order to enable ongoing high-velocity value delivery, Architectural Features provide the key mechanism for building the Architectural Runway. Trains use a selected set of ART Metrics to help guide and improve performance.
Release Trains require specialty skills to integrate, refine, and validate system code. These abilities are found in the System Team and key specialists such as System Architects and User Experience designers and Shared Resources. A Releases are committed externally under the auspices of the Release Management Team, who have the relevant authorities for marketing, sales, development, quality, operations, and infrastructure.
 Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Boston, MA: Addison-Wesley. 2011.
Last updated 28 June, 2014 (WIP)
This information on this page is © 2010-2014 Leffingwell, LLC. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact permissions@ScaledAgile.com.