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 solution 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 a traditional program. Usually, a program has a definitive start and an end date, as well as temporarily assigned resources.


The program level (Figure 1) is where ARTs deliver a portion of a Solution 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
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 solution.


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:

  • 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.
  • 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 (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 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 and Value Stream

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, for Solutions Trains, the development of the program vision and roadmap are not created in isolation. They are developed with the help of Product and Solution Management and must be synchronized with all ARTs that form the Solution Train. Lean Portfolio Management (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: 13 November 2017