Last updated on
Plutora Blog - Release Management

What is an Agile Release Train? (Safe ART)

Reading time 3 minutes

Over many client engagements, we have come across a few companies who aren’t familiar with this term. While we recognize the term “agile release train” is not an official IT delivery term, it is a term often used and referenced in large enterprises who manage tightly integrated releases across complex interdependent systems.

Definition of Release Train (ART)

An agile release train is a pre-planned release cycle which has been stringently planned into phases of which individual Projects and/or BAU release teams must align to in order to deliver their release.

The key reason release teams need to align to these trains is because they have changes which impact other parts of the organization outside of their own system changes, which may require the use of shared SIT test environments. In most cases, agile release trains are set up as a quarterly delivery window but span up to 10 months due to planning and integration dependencies.

Quality software releases at scale with Plutora

Plutora provides a complete toolkit for application delivery. Schedule releases , track dependencies and maintain compliance while accelerating change.

Learn More
Agile Release Train -  Continuous Delivery Model

Agile Release Train on a Continuous Delivery Model

When release or delivery teams setup these trains they usually communicate to various system teams in advance (sometimes several months in advance) and publish them on a Release Schedule.  The reason why release trains are published months in advance is purely to allow various business and technology units to plan and book in their releases and changes so that dependency and impact assessments activities take place.

The structure of an Agile Release Train (ART)

A release train is a very formal and structured process and requires meaningful data to ensure teams who join the agile release train can make a judgment around there suitability in formally joining. When the train is setup there is almost always some foundation data required. This include:

  1. Release details (rel id, name, deployment date, risk level, release type –  Enterprise, Program or Portfolio etc)
  2. Release phases and scheduled dates per phase
  3. Activities and tasks to be completed for each phases
  4. Milestones and stage gates
  5. Key stakeholders responsible for managing the enterprise agile release train.

Common practice is to set up an agile release train with a phase called “Release Submission”, which is the cut-off for when individual system teams can submit their release information (changes/systems) to be considered for inclusion based on the dependencies and system impacts against other potential agile release train candidates. This process is very important in making sure that the agile release train can both be delivered on time and with minimal/zero regression risks.

We often get asked about agile release trains and how Plutora handles agile release trains. The common questions are:

  • Do you have an enterprise agile release train process we can adopt?
  • Can I see what systems are impacted by an agile release train?

The answer to those questions is Yes.

Plutora manages agile release trains using the release management function. It allows users to setup releases, define the dates and define phases, add in activities per phase and assign stakeholders. Individual system teams who want to join the release then elect to join the agile release train by adding the dependency association to the agile release train.