A system must be managed. It will not manage itself. Left to themselves, components become selfish, competitive, independent profit centers, and thus destroy the system. . .  The secret is cooperation between components toward the aim of the organization.

—W. Edwards Deming

Program Level

The Program Level contains the roles and activities needed to continuously deliver solutions via an Agile Release Train (ART).

The Program Level contains the roles and activities needed to continuously deliver solutions via an Agile Release Train (ART).

The program level is where development teams, stakeholders and other resources are devoted to some important, ongoing Solution development mission. SAFe program-level teams, roles, and activities are organized around the Agile Release Train (ART) metaphor, a team of Agile Teams that delivers a continuous flow of incremental releases of value. ARTs are virtual organizations formed to span functional boundaries, eliminate unnecessary handoffs and steps, and accelerate value delivery by implementing SAFe Lean-Agile principles and practices.

Although it is called the program level, ARTs are generally very long-lived and, therefore, have a more persistent self-organization, structure, and mission than a traditional “program.” Typically, a program has a start and an end date, as well as temporarily assigned resources. The long-lived, flow-based, self-organizing nature of the ART is what powers SAFev.

Details

The Program Level (Figure 1.) is where value in SAFe is continuously delivered by ARTs, each of which realizes a portion of a Solution (or, in some cases, the entire solution). Many release trains are virtual, spanning organizational and geographic boundaries; others follow a line of business or product line management reporting structure.

Figure 1. Program Level
Figure 1. Program Level

Highlights

Below are the highlights of the program level:

  • Agile Teams– each ART is composed of 5 to 12 Agile Teams (50–125+ people) and includes the roles and infrastructure necessary to deliver fully working and tested software and systems.
  • Program Increments (PIs) – a timebox in which an ART delivers incremental value. PIs are typically eight to twelve weeks long, and the most common pattern for a PI is four development iterations, followed by one Innovation and Planning (IP)
  • Continuous Delivery Pipeline – represents the workflows, activities, and automation needed to provide a continuous release of value to the end user.
  • DevOps – a mindset, a culture, and a set of technical practices. It provides communication, integration, automation, and close cooperation among all the people needed to plan, develop, test, deploy, release, and maintain a Solution

Roles

Agile Release Trains are self-managing and self-organizing teams of Agile Teams that plan, commit, and execute together. However, a train does not create or steer itself. It needs guidance and direction. The program level roles help teams align to a common mission, coordinate the ARTs and provides the necessary governance:

  • System Architect/Engineer – is an individual or small cross-discipline team that truly applies systems thinking. They define the overall architecture for the system, help define nonfunctional requirements, determine the major elements and subsystems, and help define the interfaces and collaborations among them.
  • Product Management – is the internal voice of the Customer and works with Customers and Product Owners to understand and communicate their needs, define system features, and participate in validation. They are responsible for the program backlog.
  • Release Train Engineer (RTE) – is a servant leader and the chief Scrum Master for the train. The RTE facilitates optimizing the flow of value through the program using various mechanisms, such as the Program Kanban, Inspect & Adapt workshop, PI Planning, and more.
  • Business Owners – are a small group of stakeholders who have the primary business and technical responsibility for fitness for use, governance, and Return on Investment (ROI) for a Solution developed by an (ART). They are key stakeholders on the ART and actively participate in key ART events

Events

The program level uses three major activities to help coordinate the ART:

  • PI Planning – a cadence-based, face-to-face planning event that serves as the heartbeat of the Agile Release Train (ART), aligning all the teams on the ART to a common mission.
  • System Demo – provides an integrated view of new features for the most recent iteration delivered by all the teams in the Agile Release Train (ART). Each demo provides ART stakeholders with an objective measure of progress during a program increment.
  • Inspect & Adapt (I&A) – is a significant event where the current state of the Solution is demonstrated and evaluated. Teams then reflect and identify improvement backlog items via a structured problem-solving workshop.

Artifacts

The following program level artifacts help coordinate the ART:

  • Features – This is a system or service that fulfills a stakeholder need. Each feature includes a benefits hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a single Program Increment (PI).
  • Program Epics –These epics are specifically for one ART.
  • Program Backlog – This the holding area for upcoming features and enablers, each of which can span multiple ARTs, and are intended to advance the solution and build its architectural runway.
  • Program Kanban – It manages the flow of features and enablers through the ART.
  • PI Objectives – These are a summarized description of the specific business and technical goals that an ART intends to achieve in the upcoming Program Increment (PI).
  • Architectural Runway – The runway consists of the existing code, components and technical infrastructure necessary to support implementation of prioritized, near-term features, without excessive redesign and delay.

Managing the Flow of Value though the ART

A primary responsibility of the program level is the discovery, definition, and development of Features and Enablers that are required by the business to realize the Vision and Roadmap. To manage this flow of work, and to make sure it is visible to all stakeholders, SAFe provides a Program Kanban system. This Kanban is used to ensure that features are reasoned and analyzed prior to PI planning, then are prioritized appropriately, and that acceptance criteria have been established to guide a high-fidelity implementation.

Features are maintained and prioritized in the Program Backlog. Upon implementation, they are sized to fit in a program increment such that each PI delivers new functionality with conceptual integrity. Features, in turn, lie between Stories, which are handled by a single team within an iteration, and Capabilities, which are Large Solution Level services that can span ARTs.

Connection to the Portfolio and/or Value Stream

The program vision and roadmap provide a view of the solutions and capabilities to be developed, reflecting customer and stakeholder needs and the approaches that are proposed to address those needs. However, for Solutions Trains, the development of the program vision and roadmap are not created in isolation. They are created with the help of Product and Solution Management and must be synchronized with all ARTs that form the Solution Train. Lean Portfolio Management and Product and Solution Management also collaborate on the development of the respective roadmaps and visions.

Mixing Traditional Programs with ARTs

In enterprises transitioning to SAFe, and in cases where supplier development practices are outside the control of the enterprise, traditional (waterfall) programs may still exist. Therefore, SAFe LPM provides a governance model that can be applied to governing ARTs along with traditional, phase-gated programs. Guidance articles for this mixed mode of operation are provided in the Guidance section of this website. (See the Mixing Agile and Waterfall Development article.)

 


Learn More

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

Last update: 26 September, 2017