Add to Google
Agile Iteration. Agile Release Train. Agile Fractal.
Posted on September 27, 2011 by Dean Leffingwell in Agile Release TrainAs 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:
Does that simplify things a bit?
Very nice, thanks Dean! The same patterns seem to go both up and down another level as well. Down to individuals and small groups within a team doing their daily work within a sprint (perhaps not timeboxed to days, but scope-boxed to stories), and up to the road map and perhaps even portfolio levels.
I’ve also found a lot of useful practices by looking at something solving a goal at the release level and figuring out if it has an analogue at another level. It’s been a great lens to help get away from mechanics and more focused on goals and principles.
Hello Dean,
Very nice post! I’ve translated it into french :
https://agilarium.wikispaces.com/It%C3%A9ration+Agile.+Train+de+Release+Agile.+Fractale+Agile.
Thank you,
Fabrice
Sorry, there is a point at the end of the url :
https://agilarium.wikispaces.com/It%C3%A9ration+Agile.+Train+de+Release+Agile.+Fractale+Agile.
Dean,
nice post, just one question:
When a sprint runs for two weeks, and a PSI for 10 weeks, and you have 5 sprints („execute“) in one PSI in fig. 2, how much time is for plan, commit, demo and adapt?
There is often a 1/2 day demo and retro/workshop the day prior to release planning (usually 2 days). To keep the cadence, this is one of the uses of the hardening sprint. Many teams don’t need all that hardening anyway, and those that do, shouldn’t, so even then it’s appropriate to stop and figure out why they do.
Hi Dean,
Enjoyed your talk at Agile 2011 and read your book afterwards; insightful and informative, very good topics.
As enterprise transitioning to agile, what’s a reasonable size of an agile train? Is there ever a Too Large a train?
Thanks
Trains tend to naturally be formed around significant value streams, and even in the larger enterprises, it often takes (only?) around 50-100 people to “build a really big thing of interest”. The largest train I’m currently involved in is 150 people, 75 in the US and 75 in India. We plan together, and via video, but not in person. That’s about as big as is reasonable. After that, you need more than one train because there is a social networking and logistics problem beyond 100 or so (people just can’t care as much about people they can’t really know). So after 100, it’s more trains. The largest agile enterprise I’m familiar with has 18 trains about that size; another has 10. Coordinating the activities of the train is the next agile fractal above the train. Fun stuff, though.