The ‘Agile Release Train’ has been popularised as part of the Scaled Agile Framework – a set of guidelines aimed to bring agile software development to the enterprise and programme delivery. In the framework, the train metaphor is used to describe a series of iterative releases set to a strict schedule that multiple teams must abide by in order to synchronise and ship their work.
We use the “train” metaphor to communicate a few key concepts.
- The train departs the station and arrives at the next destination on a reliable schedule (fixed cadence; standard velocity, predictable releases)
- It delivers its cargo to customers (Release) or is used for internal evaluation and proof of incremental system robustness and quality (PSI/Release).
- If an Agile Team wants its “cargo” (code, documentation, etc.) to go, it has to put it there on time. The train will not come to them nor wait to get their content.
From http://scaledagileframework.com/agile-release-train/
I’m fortunate enough to work at Redgate – a software house based in Cambridge, UK. At the moment we don’t have a need for the Scaled Agile Framework and all it’s rigourous, and potentially overbearing, process and procedure. I predominantly work with a small software development team (5 to 10 people) focused on a single product, with relatively little need to share work across multiple teams (certainly when compared to a large enterprise-y development programme). This could well change in the future, as we’ll be pushing to synchronise efforts across teams much more regularly. But at the moment, scaling agile is not something on our todo list.
Release Wednesdays
In the last few years, the teams I’ve lead have decided they like to to release their products every week. Every Wednesday, to be precise. Why? Well, I’m a bit torn on how to answer that. The project manager part of me says it’s because we believe in releasing frequently to give our users valuable enhancements as quickly as possible and to get timely feedback on the direction we are taking the product. The developer part of me says its because we get a kick out of putting the stuff we’ve created into the hands of people who’ll enjoy using it as soon and as often as we can.
In any case, by releasing every Wednesday we’ve proved that releasing frequently is best practice, as we extoll the virtues of keeping the delta between releases small and the risk associated with an individual release low. We’ve also found that practice makes (almost) perfect and that the more often we release the easier and less distressing it has become.
We choo-choose the Release Train
Although, I’d used the term ‘Release Train’ with the team for most of the time Release Wednesdays has been a thing, it’s only in the last few months that I have explicitly used the concept to help the team plan, visualise and track their work. I don’t think it’s an exaggeration to say that doing this has been transformational.
The catalyst for a more formal adoption of a Release Train was a realisation that my current project, SQL Lighthouse, had a significant deadline looming that we had no clear plan for how to meet. To be more specific – the team, as a group, realised that for SQL Lighthouse to be a success this year, it was paramount that we had a public beta of the tool ready for a Redgate’s annual London conference.
Once the target was agreed, the team set about deciding what needed to be delivered in order for this to be achieved. We decided on a single, valuable use case we would support with the Beta release and broke the required functionality down into the smallest possible chunks (we used User Stories for this). We then looked to our weekly release cadence to help us decide if this was, in fact, an impossible task.
We wrote up the dates of the 6 weekly releases that would happen before the deadline and placed cards detailing each chunk of functionality under those dates. We were then able to quickly arrange, prioritise, and re-arrange the chunks into a reasonable plan. The entire team gathered around the wall discussing, pontificating and worrying about the plan for the upcoming work – it was the most engaging planning activity I’ve experienced.
Although we’d managed to get each chunk of work down to a small, reasonably independent unit, it was clear that they wouldn’t all take a week or less to complete. We didn’t spend too much time worrying about an exact (or even relative) size, as a group we took a guess at when it could be shipped and moved on. So, if the team believed it would probably take two weeks to complete a particular chunk, it was quickly assigned to the subsequent release. A key point here is that the team realised they were making a informal guess and trusted ‘management’ not to hold them to their hunches.
In the end, we fashioned a release plan made up of 6 weekly, iterative releases. Vital functionality was front-loaded into the early releases and nice-to-haves had settled at the end. As each release was scheduled for a Wednesday, and any functionality that was not ready for that day would have to wait for the following Wednesday – we had an Agile Release Train (see below, cut-out train and carriage wheels were an optional but metaphor anchoring extra).
“Plans are useless, but planning is indispensable”, Dwight D. Eisenhower
Of course, as soon as we’d drawn up the plan it was out of date. If Agile has taught us nothing else, it’s taught us to expect change. So, during the next six weeks we kept the Release Train up-to-date and relevant. It reflected functionality we had shipped, the proposed contents of the next release and any realisations that we just couldn’t get something done for when we’d hoped we would.
Importantly, the whole team took part in analysing the knock-on effects when a piece of functionality (or cargo, to keep with the analogy) missed a release we had earmarked it for. This prompted releases (carriages) to be re-arranged, functionality (cargo) to be juggled and scope-creep (baggage) to be jettisoned. We were all engaged in the process of project planning.
As I detailed in a previous post, the plan and the planning worked – the team met their goal of releasing by the important trade show and in the process transformed the product from a proof-of-concept alpha into a genuinely useful tool. As a direct result of that success, the Release Train was here to stay; we’ve applied the metaphor to every step we’ve taken with SQL Lighthouse since.
More than just a release plan
As I reflect on how we do software development on the SQL Lighthouse team now, it’s interesting to note the side-benefits that the Release Train has brought; including small user stories, #NoEstimates, collaborative planning and implicit scope management. This has turned into a long post, so I’ll cover those in my next one – 5 benefits of the Agile Release Train for a single team.
Leading Agile Teams 
Leave a Reply