“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.
– Edwards Deming
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 need to 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 pull all the software assets together and test the end-to-end use cases (probably}
- A Release Management Team with the authority to define and evaluate quality and release criteria, and to coordinate the actual releases (probably}.
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 “PSIs”, Potentially Shippable Increments boundaries, which occur on a steady cadence at intervals of every 8-10 weeks or so. Releasing can happen on these boundaries as well. However, it is even more beneficial to release solutions whenever the market demands, so many programs use this longer timebox primarily for planning, higher level program assessment and Inspect and Adapt program improvement. And that leads us to the SAFe mantra Develop on Cadence. Deliver on Demand.
The Release Train Moves the Cargo
A Release/PSI is a multiple-iteration timebox during which valuable functionality is developed and delivered. The Release Train leverages the development capability of 5 to 15 Agile Teams (whatever the Value Stream requires), and includes the roles and infrastructure necessary to deliver value. Each PSI plan includes a commitment to a set of Program PSI Objectives, which represent the set of Features that have been prioritized using weighted shortest job first (WSJF), and which have been driven to the PSI boundary via the program Vision and Roadmap. Release Trains deliver fully tested, system-level solutions at least 8-12 weeks, but more frequently if the market so demands, and the DevOps infrastructure supports it.
Release Trains often require specialty skills to integrate, refine, and package delivered code from teams to the market. These abilities are found in the System Team and key specialists such as System Architects and User Experience designers. Content authority for what goes on the train rests with one or more Product Managers. A Release Train Engineer (often a project/program manager) serves as chief Scrum Master and helps keep the train on the tracks. Releases are committed externally only under the auspices of the Release Management Team, who have the relevant authorities for marketing, sales, development, quality, operations, infrastructure, and whoever else is necessary to assure the release is fit for its intended purpose and ready for customer deployment.
Roles in the Agile Program
The Product Manager is responsible for the feature content of a train. This content is driven from portfolio objectives, value stream business opportunities and customer feedback
Release Management Team
The Release Management Team has the authority necessary to determine that the solution is fit for release and appropriately timed to address business and customer needs.
The System Team serves as a system integrator and evaluator of working, tested code, as regularly delivered by the program’s Agile teams. Continuous integration, automated test suites, and end-to-end testing are primary tools by which the system team provides fast feedback to the Agile teams and the stakeholders during regular iteration demos.
Release Train Engineer
The Release Train Engineer’s primary responsibility is to keep the train on the tracks. This is no small feat, considering the myriad moving parts of the release train itself and the coordination needed to ensure that the release objectives are honored within the PSI time-box.
Real, tangible software development value occurs only when the end-users are successfully operating the software in their environment. This demands that the complex routine of deploying to operations receives early and meaningful attention during development. To ensure a faster flow of value to the end user, programs require mechanisms for tighter integration of development and operations. This is accomplished, in part, by integrating personnel from the operations team with the Agile teams in the Agile Release Train. We also provide specific suggestions for continuously maintaining deployment readiness throughout the feature development timeline. In turn, this gives the enterprise the ability to deploy to production more frequently, and thereby lead its industry with the sustainably shortest lead time.
The Program Backlog is the single, definitive repository for all the upcoming work anticipated by the program. The backlog is driven, in part, from Portfolio Backlog Business and Architectural Epics as well as feedback from the customers of the products and services the solution provides. Nonfunctional Requirements (NFRs) provide governance over the necessary system qualities of performance, security, reliability, availability, throughput, and others. In order to enable effective value delivery, Architectural Features provide the key mechanism of building the Architectural Runway.
Release Planning is to the PSI what iteration planning is to the iteration. Wherever practical, all participants are involved face-to-face in this process, (albeit typically at multiple, geographically distributed, locations). All members (from 50 to 150 persons, on average) participate (physically or virtually) over a 1-2 day period where they share in the vision, plan together, work out inter-dependencies, establish Team PSI Objectives and program level objectives for the upcoming period.
PSIs and Releases
PSIs represent the cadence-based, planning, build, program retrospective, evaluation and (often delivery) of value via a stack of new features and components. While there is no mandated PSI length, the Framework recommends a standard cadence of from 8 to 12 weeks. Planning, asset integration and system-level evaluation is done on the PSI cadence, but Releasing is a an activity that may be asynchronous with the planning cadence, as is is driven by internal business and external market needs.
Inspect and Adapt
Similar to a team Retrospective, a program conducts an Inspect and Adapt workshop at the end of each release/PSI. This typically requires the involvement of all program participants to discover and understand how the program can be improved. This workshop is a structured, problem-solving workshop that uses the lean/kaizen tools of fishbone diagrams, pareto charts and corrective action plans to create a set of improvement Stories that can be added to the backlog for the next PSI planning session. In this way, program-level continuous improvement is built into the release train and is fundamental to the way in which SAFe programs constantly improve their business delivery capabilities.
 Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Boston, MA: Addison-Wesley. 2011.
Last updated 28 July, 2013
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.