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.
0 Comments
HI this text in article does not make sense? ” In the image below there are 3 Features that will be delivered by ART1 in its second PI (PI2).” There are alot more features shown across all of the sprints for PI2 than 3?
Hi Cliff – Thank you very much for reading the blog and pointing out the gaffe. We will correct this. Best wishes and happy holidays.
Thanks for the article on SAFe. I got some good concepts from this without the site trying to sell me some bootcamp or some other nonsense. Thanks much for the information Anshuman!
Hi,
Thanks for sharing the valuable info. Based on my current organization setup i have a question: what is mapping between ART and Program i.e. is it 1:1 OR 1:N OR N:N
Let’s say i have an ART with 5 Agile teams in it. At any given point of time i have say 6 programs for which these agile teams will be working (all or some teams).
How do we do the PI planning, do we have one PI planning for the ART OR do we do multiple PI planning (1 for each program) ? If later then agile teams may be participating in multiple PI planning.
Please help.
Hi Amit,
Thanks for visiting our blog and thanks for the question. You’ve asked a great question – something that I’d also asked during my SPC class 🙂
So, conceptually, an ART handles one Program, and so one Program Increment (PI) at a time, but over a period of time handles multiple PIs. So, at an instant of time, it is a 1:1 mapping, but over time, of course, it is a 1:N (1 ART: N PIs) mapping.
Now, there is nothing stopping you from having your ART members multiplexing their time over multiple Programs/ PIs at a time. However, it is a rare occurrence. You would typically combine multiple Programs under a single Solution Train – where again, each individual Program is being handled by an ART.
By definition, you are doing PI planning for one Program – which is why it is called a “Program Increment”. At a time, you are doing ONE PI planning – even tho’ at a higher level, you might be doing Portfolio-level planning where you are building the high-level PI Roadmap (a high-level plan for which Epics/ Features will be taken up in which PI) – but the detailed PI/ Sprint planning for a PI is being done for one PI by the ART responsible for the Program.
Hope this helps!
Hello, Anshuman. I’m sorry if I missed something, but I actually have the question “Basically, is there 1 ART per Program or can there be multiple ARTs per program?” and I’m not really sure if I understood the information correctly. What I got is that is no correct answer. There cam be several ARTs per program if that’s what fits better. Is that it?
Hi Raphael,
The usual organization we have seen with our customers is along the lines of what you have mentioned. You have one ART at Program level, and possibly multiple ARTs at the portfolio level, if one portfolio is feeding multiple programs. Of course, depending on the size of the organization and the overall product portfolio, you might also have solution trains above the ART level. However, as you said, there’s no right answer. Depending on how and where you start, you can scale up appropriately. Typically, most companies start with one ART and then expand into multiple ARTs and each new ART manages or works on its own Program.
Hope that helps.