The concept of Agile Release Train (ART) is central to understanding the constructs of SAFe® and to implement them. So, what is an ART? Is it a set of teams working in tandem with each other following a common release calendar and Sprint timeline? Or is it a set of features scheduled for release at regular durations to continuously deliver the anticipated business value? Is there any role that is central to the running of an ART? We will try to answer these questions and have a closer look at ART in this blog.
What is an ART?
The Agile Release Train (ART) is the primary value delivery construct in SAFe®. The Agile Release Train is a long lived, self-organizing team of Agile Teams, a virtual organization (5 to 12 teams) that plans, commits, and executes together. ARTs are organized around the enterprise’s significant Value Streams and live solely to realize the promise of that value by building solutions that deliver benefit to the end user.
Hence, an ART is basically a team of Teams responsible for the regular release of Features and business benefits. All the teams of an ART are bound by a common Vision, Program Backlog, and a Roadmap. An Agile Release Train typically consist of 50-125 people. (How many ARTs are associated with a “Vision” or a “Program”? Basically, is there 1 ART per Program or can there be multiple ARTs per program?)
How is Program Increment (PI) related to ART?
Program Increments (PIs) provide a development timebox (default 10 weeks) that uses cadence and synchronization to facilitate planning, limiting WIP, provide for aggregation of value and assure consistent retrospectives. In other words, PI timeboxes are the duration over which the ART (team of Teams) has to deliver a piece of work. (In the case of IT and software domain, that would mean working- software). Each train has dedicated people and resources necessary to continuously define, build and test capabilities in every iteration.
Principles governing the Agile Release Train
The Agile Release Train provides alignment and helps manage risk by providing program level cadence and synchronization. It is based on agreement and adoption of a set of common operating principles and rules which are followed by all teams who are part of the train. The rules are agreed and shared with the entire ART over a 2-day PI Planning event. To read up more on PI Planning, you can access my last blog here (Unravelling PI Planning). These rules are as follows:
- Frequent, periodic planning and release – the ART must ensure a regular value delivery model is followed and adhered to. The system demo typically should happen every 10 weeks.
- Teams apply common iteration lengths – within a PI there are 5 Sprints of 2 weeks each and each team adheres to the iteration length.
- Clearly defined, objective milestones are established. The milestones for each 10-week cycle are decided over the 2 day PI Planning event by the entire ART.
- Continuous system integration is implemented at the top, system level, as well as at the feature and component level. The work accomplished by multiple teams over the Sprint must be integrated to keep the software in a releasable state.
- Release increments are available at regular (typically 60-120 day) intervals for customer preview, internal review, and system-level QA. This is a high-level System Demo (also called the PI Demo) event that showcases the ART team’s achievement over the entire PI timeline of 10 weeks and senior stakeholders attend this event.
Release Train Engineer
The Release Train Engineer is a servant leader and operates as a full-time ‘Chief Scrum Master’ of the train. The Release Train Engineer (RTE) tracks the Features and Capabilities release dates. The RTE conducts the PI planning events for each ART. The RTE is responsible for ensuring the required stakeholders attend the two-day event and that all the logistics for the successful completion of the event are in place. The RTE needs to have the PI Planning, Iterations and System Demo dates defined so that a holistic picture of the work being executed by an ART can be made available to the stakeholders. It is worth noting that more than 1 ART can make up a Value Stream. Also, Capabilities are broken down into Features that are linked to an ART. ARTs derive their score from the features that have been allocated to the PI. The score refers to the Business Value that an ART is supposed to deliver during the PI.
ART Milestones
The milestones listed below are adhered to by an ART and are tracked regularly.
- PI Planned Start Date (derived from the PI)
- PI Planned End Date (derived from the PI)
- Sprint Planned Start Date (derived from the Sprints inside a PI)
- Sprint Planned End Date (derived from the Sprints inside a PI)
- PI/Sprint Planning Dates (Entered at the PI/Sprint level; derived at the ART level)
- PI System Demo (defined during the PI Planning meeting)
An Example
To recap the concepts covered in the blog – take a look at the image below. The image depicts a Sales Value Stream that comprises of 5 ARTs. Out of these, an elaboration of ART1 is presented. ART1 delivers releases over multiple PI timeboxes. Each of the PI timeboxes comprises of multiple Sprints. In other words, PI timebox is to a Sprint what an ART is to an Agile team. Also the backlog of the PI comprises of the Features that need to be delivered in the timeboxe by the ART.
The PI level Features are broken into User Stories that form the Sprint level backlog of various teams. Each of the PI are also accompanied with a list of identified risks that were uncovered by the ART team during PI Planning meeting.
This covers the most important concepts surrounding an ART and if there are any questions please put them in the Comments section below and I will be happy to answer them.
