As I’ve described at length in Agile Software Requirements, Scaling Software Agility and this blog, the Agile Release Train can provide tremendous benefits to the larger agile software enterprise. I, and many others, routinely apply it to: 1) Align agile teams to a common mission 2) Institutionalize program-level, product development flow.
However, being a man of oft-too-many-words, I struggle sometimes to describe the Agile Release Train in the simplest possible terms. A while back, I mentioned the release train as a fractal above the sprint/iteration. (A fractal is a geometric shape that can be split into parts, each a reduced size copy of the whole). Maybe that’s the best way to think about the release train. Let’s try it.
There is no debate that an agile iteration/sprint has a common and simple pattern: 1. Plan. 2. Commit. 3. Execute. 4. Demo. 5. Adapt (retrospect). It looks like this: The release train has more teams and longer iterations (uber sprints, composed of multiple, aligned team sprints) but the pattern is exactly the same, it’s just that it is at the next level of program scale. It looks like this: