The Principal of Alignment: There is more value created with overall alignment than with local excellence.

– Don Reinertsen: The Principles of Product Development Flow

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. Descriptions needed 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 – We need more and different teams, too.

a Product Management Team 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}
Release Management Team with the authority to define and evaluate quality and release criteria, and to coordinate the actual releases (probably}.

Timebox – The handy two-week iteration that serves us so well at the team level is too short a period for program level planning and solution delivery. Rather, we’ll find it convenient to align iterations and aggregate teams outputs to deliver solution value in Release increments (or “PSIs”, Potentially Shippable Increments), which occur on a steady cadence at intervals of every 8-10 weeks or so.

These constructs must be applied systemically to assure that the programs are always aimed at the right target and are largely self-organizing and self-managing, so as to routinely provide a continuous flow of value without unnecessary oversight and management.

Details

The Release Train Moves the Cargo

A Release/PSI is a multiple-iteration timebox during which valuable Features and Components are 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 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 every 8-12 weeks.

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, Shared Resources, 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 uber-scrummaster 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

Product Manager

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.

System Team

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.

Shared Resources

Modern software is complex and multifaceted. Specialists are often needed to regularly address issues such as data engineering, security, data warehousing, IT/infrastructure, deployment, etc. The Shared Resources team has the specialty skills needed to help the team deliver the goods, while typically leveraging their capabilities across this train and others.

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.

Additional Constructs

Program Backlog

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.

Release Planning

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 interdependencies, and establish team and program level objectives for the upcoming period.

PSIs and Releases

PSIs represent the frequent, cadence-based build, evaluation and 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 and assets integration is always done on the PSI cadence, but Releasing is a an activity that may be asynchronous with the planning cadence. Releasing is driven by internal business and external market needs. In other words, plan and integrate on a cadence, but release on demand!

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.

Learn More

Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Boston, MA: Addison-Wesley. 2011.

Last updated 15 January, 2013