Agile Release Train: Develop Synchronously, Release Whenever.

The software development paradigm called the Agile Release Train (introduced in Scaling Software Agility and better elaborated in Agile Software Requirements) is being put to effective use in a number of larger agile, software enterprises. It is often put in place between six months and a year after the team-level agile transformation. (That’s when the entropy and local optimization of all that team-level empowerment can become an impediment of its own).

As I’ve described, the loftier goals of the ART are to “align teams to a common mission” and “institutionalize product development flow.” What that translates to is “get all the teams pulling in the same direction and keep them there” and “implement development practices based on synchronization and cadence (uber-sprinting) that bring the same agile content management and continuous system integration discipline to the program as you have done with the teams”.

While conceptually, it’s not that complex a process, there are a number of misconceptions about the train that require clarification.

The first is the behavior implied by the name Agile Release Train. As illustrated in the Scaled Agile Framework Big Picture graphic below, development occurs on a fixed cadence of about 8-12 weeks (often 4 dev sprints plus a hardening sprint if applicable).

Each larger interval results in a product or full system release, or Potentially Shippable Increment. (Note: of course, our goal is to have  PSI’s every darn day, but in the larger program, that’s not a practical reality). Though the PSI cadence is highlighted, the intent is that teams are free to release software at any time the market demands it, or whenever it benefits the enterprise to do so. However, since the name is “Release Train”, and the cadence and the Scaled Agile Framework Graphic are overloaded, some assume that you can and must release only on the fixed time boundaries. That can create some unwarranted resistance to adoption of the train. Comments like “we can’t adopt ART because our customers don’t want releases that often” or “we can’t adopt the train because we have to release more often than the train cadence” are not uncommon.

But you can and should synchronize development. Since this is a common misunderstanding about the train, I typically use the graphic below to illustrate the conceptual firewall between development cadence and release cycles.

To summarize from the graphic:

1)   Development occurs in constant length intervals, each characterized by a plan-commit-execute-demo-retrospect model with forced asset synchronization at the two-week sprint cadence synch points.


2)   Any team, or the entire program,is free to release any product, component, or system to anyone whenever they want, subject only to the program/enterprises release quality and governance criteria.

In other words, Develop Synchronously, Release Whenever!

Next post: The Agile Release Train as an agile practice fractal above the teams.


6 thoughts on “Agile Release Train: Develop Synchronously, Release Whenever.

  1. Hi Dean,
    The ART. your comment about “it’s often put in place between six months and a year after the team-level agile transformation.”
    Why not in the very beginning?

  2. Well it can be at the very beginning, and that’s the way I like to do it, but most enterprises start with team-level agile, and don’t address the enterprise issues until the next phase. That’s just the state of the industry at present, but that’s changing.

  3. Hi Dean,

    I liked your big picture but then could not quite get the idea of the “harden” iteration that is against Agile… So I spoke to an engineer who explained how it failed at a company that uses ART: engineers spent too much time planning and C.I. tools were very poor. So, maybe scrum masters should not be only a team activity but also a program and management activity where roadblocks touching the way an organisation works can be removed? In a nutshell, turn management into scrum masters at their own level to unblock teams and maintain Agile principles from top to bottom?

    • Christophe.,
      To be clear, if a program (fractal above the team) does not need a hardening iteration, then DON’T have one.

      But if a program is using a hardening (planned iteration without new user stories) to:
      1) provide estimating allowance for them to meet release objectives, which others are dependent on
      2) do final alpha or beta, user acceptance testing
      3) finalize documentation and release notes, localizations
      4) Final integration and system level regression testing
      5) any final P1, P2 defect resolution
      6) (in high assurance systems) finalize validation and release documentation

      after 3-4 successful sprints, I for one wouldn’t want to tell them that they were not agile, would you?

      If a program is using a hardening iteration to
      1) defer technical debt until then
      2) as an excuse for not driving continuous integration at the system level
      then they sure are not as agile as they could be.

      I have yet to see a single, truly large scale program (>50 devs and testers converted to agile sometime in the last year) that could integrate its assets and have potentially shippable software every day, though I fully expect to see some in the future. Maybe others have. If so, I’d love to hear the story, or read the case study and I’ll be sure to describe it here!

  4. Thanks Dean for your feedback,

    I would agree that some hardening might be required. My main point was the misuse of the hardening iterations by management: “we know we have one sprint to harden our features so let’s put some more features and raise bugs we will fix in the “harden” iteration”. And then “harden” phase starts being 2 iterations etc.

    My main question is: would you recommend to have scrum masters at the program and portfolio level that are able to remove roadblocks for the scrum teams. Such roadblocks could be: lack of quality focus at program level pushing teams in the wrong direction, change in the organisation to fix issues such as a poor C.I. system (which a normal scrum master cannot really do), limit lengthy “harden” iterations and deferring technical debt etc including talking to the CEO directly to make changes allowing engineers to spend time writing good software?

    So, in a nutshell, scrum master at scrum team level, scrum master at the program level and at the portfolio level? Does that make sense?


    • Well, I wouldn’t call them ScrumMasters, as they aren’t running a Scrum process and defining/building/testing software. So sending them to Scrummaster training won’t do much good. I would call them our “agile leaders”, and most every enterprise should be growing them as part of their agile transformation. And certainly, there are too few of them in most enterprises, but their were far too few agile developers in many of those same enterprises just a year or two back as well.

      Educate them. See my recent post on the topic.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s