Agile release train

An Agile Release Train (ART) is a team of agile teams that plan, commit, and execute together. Typically consisting of 50-125 people, an ART is a long-lived organizational structure that delivers value in a continuous flow. The concept comes from SAFe (Scaled Agile Framework) and addresses the challenge of coordinating multiple teams working on related products or systems.

Why it matters

Single agile teams work well for contained projects. But when products grow complex enough to require multiple teams, coordination becomes challenging. Without structure, teams optimize locally while the overall product suffers from integration problems, dependency conflicts, and misaligned priorities.

The ART provides that structure. It creates a container for multiple teams to work together with aligned objectives, synchronized cadence, and shared accountability. The "train" metaphor reflects that the ART operates on a schedule-if you're not ready when the train departs, you catch the next one.

How it works

An ART includes several agile teams, each following their own process (typically Scrum or Kanban). These teams work on related parts of a larger system or product. The ART adds coordination mechanisms while trying to preserve team-level agility.

The ART operates on a fixed cadence called a Program Increment (PI), typically 8-12 weeks comprising 4-6 sprints. At the start of each PI, all teams come together for PI Planning-a 2-day event where they align on objectives, identify dependencies, and commit to delivery.

Throughout the PI, teams execute their sprints with integration points for coordination. At the end, the ART demonstrates integrated work and reflects on what to improve.

Key roles

Beyond the roles in individual teams, ARTs have additional coordination roles:

Release Train Engineer (RTE) facilitates the ART, similar to how a Scrum Master facilitates a team. They coordinate PI Planning, remove cross-team obstacles, and track ART-level progress.

Product Management owns the program backlog and sets priorities at the ART level. They work with Product Owners on individual teams to ensure alignment.

System Architect provides technical guidance across teams, ensuring architectural coherence and addressing cross-cutting concerns.

Business Owners are stakeholders who evaluate the value delivered by the ART and participate in PI Planning and reviews.

Pi planning

The PI Planning event is the heartbeat of the ART. Over two days, all ART members come together (physically or virtually) to:

Align on vision and context. Business Owners and Product Management present the upcoming priorities and explain why they matter.

Plan as teams. Each team drafts their plans for the PI, identifying what they'll deliver and what dependencies they have on other teams.

Integrate plans. Teams identify and resolve dependencies, negotiate trade-offs, and create a coordinated plan for the whole ART.

Commit. Teams commit to PI objectives-not detailed scope, but outcomes they'll work toward.

PI Planning requires significant investment-bringing 100+ people together for two days isn't cheap. But it creates alignment that's difficult to achieve otherwise. Many teams report that PI Planning is when real clarity emerges about what they're building and why.

Benefits and criticisms

ARTs provide genuine benefits for large-scale development:

Coordination happens through structure rather than constant ad-hoc negotiation. Dependencies are visible and managed.

Alignment comes from shared planning and objectives. Teams work toward common goals rather than optimizing separately.

Predictability emerges from the regular cadence. Stakeholders know when they'll see integrated results.

Critics argue that ARTs add overhead that undermines agility. The additional roles, ceremonies, and planning can feel bureaucratic. Some argue that the need for ARTs indicates architectural problems that would be better solved by restructuring to reduce dependencies.

Both perspectives have merit. ARTs work well for genuinely complex systems where coordination is unavoidable. They're overkill for simpler situations or can mask structural problems that should be addressed differently.

Implementing an art

Before launching an ART, assess whether you actually need one. Multiple teams with significant dependencies benefit from ART structure. Teams that could work independently might be better served by looser coordination.

If an ART makes sense, start with training. People need to understand the concepts, roles, and ceremonies. SAFe provides extensive training and certification, though some teams adapt the concepts without full SAFe adoption.

The first PI Planning is typically rough. Teams are learning the process while trying to plan. Accept imperfection and use retrospectives to improve.

Success depends on leadership commitment. ARTs require investment in coordination overhead. If leadership doesn't value the coordination benefits, the ART will be seen as waste.

Arts and organizational structure

ARTs often don't match traditional organizational structures. An ART might span multiple departments or include only part of a department. This creates tension between ART structure (optimized for delivery) and reporting structure (optimized for functional expertise and career development).

The best implementations align organizational structure with ART structure where possible. Where alignment isn't possible, clear expectations about dual membership help people navigate.

ARTs work best when they have enough autonomy to truly own their value stream. ARTs that must constantly negotiate with outside the train for resources or decisions struggle to achieve the coordination benefits.