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.
Program Level Abstract
The Program Level is where funding for personnel and other resources are applied to some important, long-lived, enterprise mission. In the SAFe enterprise, most programs are a one for one relationship with an Agile Release Train, each following the funding, governance and incremental development patterns of the ART to deliver their portion of a Value Stream. In this case, ARTs are generally very long-lived, and therefore have a more persistent structure and mission than a traditional “program”, which more classically has a start and end date.
In enterprises transitioning to SAFe, and in the case where supplier development practices are outside the control of the enterprise, such traditional programs may still exist, so SAFe Program and Portfolio Management provides a governance model that can be applied to governing ARTs along with traditional, stage-gated programs. Guidance articles for this mixed mode of operation are provided in the Guidance section. (See mixing Agile and waterfall articles.)
The Agile Release Train Delivers the Cargo
Programs in SAFe are delivered by long-lived Agile Release Trains, which deliver a portion (in some cases, all) of a value Value Stream. They accomplish this by delivering incrementally in Program Increments, 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 update: 11 August, 2014
Leffingwell et al. © 2011-2014 Scaled Agile, Inc.
Information on this page 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, visit the Permissions FAQ and Form.