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 is where development teams, stakeholders, and other resources are devoted to some important, ongoing system development mission. The ART metaphor describes the program level teams, roles, and activities that incrementally deliver a continuous flow 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 long-lived and, therefore, have a more persistent self-organization, structure, and mission than traditional programs which usually have definitive start and end dates, as well as temporarily assigned resources.

The ARTs operating at the Program Level are ultimately responsible for creating and releasing value in flow at the frequency needed by the enterprise to meet market and customer demand. The mindsets and practices in this level contribute to the enterprise competency of DevOps and Release on Demand that makes this flow of value possible.


The program level (Figure 1) is where ARTs deliver one or more systems or in some cases, the entire Solution.  The long-lived, flow-based, self-organizing nature of the ART is what powers SAFe.

Figure 1. Program Level

Many trains are virtual, spanning organizational and geographic boundaries; others follow a line of business or product line management reporting structure.


The highlights of the program level include:

  • Agile Teams – Each ART is composed of 5 – 12 Agile teams (50 – 125+ people) and includes the roles and infrastructure necessary to deliver fully working and tested software and systems.
  • Program Increment (PI) – A timebox in which an ART delivers incremental value. PIs are typically 8 – 12 weeks long, and the most common pattern for a PI is four development Iterations, followed by one Innovation and Planning (IP) iteration.
  • Continuous Delivery Pipeline – Represents the workflows, activities, and automation needed to provide a constant release of value to the end user.
  • DevOps – A mindset, 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 system.


ARTs are self-managing and self-organizing teams of Agile teams that plan, commit, and execute together. However, a train needs guidance and direction. The program level roles help align people to a shared mission, coordinate the ARTs, and provide the necessary Lean governance:

  • 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.
  • System Architect/Engineer – Is an individual or small cross-discipline team that truly applies Principle #2, Apply Systems Thinking. They define the overall architecture for the system, help define Nonfunctional Requirements (NFRs), determine the major elements and subsystems, and help design the interfaces and collaborations among them.
  • 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 (I&A) workshop, and PI Planning.
  • Business Owners – Are a small group of stakeholders who have the business and technical responsibility for fitness for use, governance, and return on investment (ROI) for a Solution developed by an ART. They are primary stakeholders in the ART and actively participate in ART events.


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

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

The program level stakeholders meet periodically to ensure the ART is advancing toward the committed PI Objectives, and to manage risks and dependencies.  These synchronization meetings include Scrum-of-Scrums (RTE and Scrum Masters), PO Sync (Product Management and Product Owners), and ART Sync (Scrum-of-Scrums and PO Sync together). For more discussion on these activities read the Program Increment article.


The following program-level items help coordinate the ART:

  • Features – This is a system or service that fulfills a stakeholder need. Each includes a name, benefits hypothesis and acceptance criteria. They are sized to fit within in a PI.
  • Program Epics – These epics are for a single ART.
  • Program Backlog – This the holding area for upcoming Features, which are intended to address user needs and deliver business benefits for a single Agile Release Train (ART). It also contains the enabler features necessary to build the Architectural Runway.
  • Program Kanban – It manages the flow of features and enablers through the Continuous Delivery Pipeline.
  • PI Objectives – These are a summarized description of the specific business and technical goals that an ART intends to achieve in the next PI.
  • Architectural Runway – The runway consists of the existing code, components, and technical infrastructure necessary to support the implementation of prioritized, near-term features, without excessive redesign and delay.

Managing the Flow of Value through the ART

The program Kanban system is a method to visualize and facilitate the flow of features from ideation to analysis, implementation, and release through the continuous delivery pipeline. Once approved they are maintained and prioritized in the program backlog. Upon implementation, they are sized to fit in a PI such that each delivers new functionality with conceptual integrity. Features are realized by Stories, which are handled by a single team within an iteration.

Connection to the Portfolio, Value Stream, and Large Solution

The program vision and roadmap provide a view of the features to be developed, reflecting customer and stakeholder needs and the approaches that are proposed to address those needs. However, they are not developed in isolation. The work of the ART is informed by the Strategic Themes, the Portfolio Canvas, Lean Budgets, and Guardrails for their corresponding Value Stream as articulated by Lean Portfolio Management (LPM). ARTs also build the component features of Portfolio Epics. For Solution Trains, the solution vision and roadmap are developed with the help of Product and Solution Management and must be synchronized with all ARTs that form the Solution Train. LPM and Product and Solution Management also collaborate on the development of the respective roadmaps and visions.


Learn More

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

Last update: 2 October 2018