5 benefits of the Agile Release Train for a single team

To some the Scaled Agile Framework seems like agile with it’s heart removed and the process turned up to 11; a set of guidelines and practices designed by consultancies to sell “Agile” to organisations undertaking large software development programmes. They believe it’s promises to synchronise, homogenise and constrain a legion of development teams are irresistible to companies that want to partake of the Agile Kool-Aid but don’t want to embrace its spirit. Despite all that bad press, our single, small development team has found one of the tools the framework advocates incredibly useful – The Agile Release Train.

As I detailed in my last post, my team use a train visualisation to help plan and deliver Redgate’s latest product, SQL Lighthouse. We don’t work in a multiple team programme that would require the Scaled Agile Framework (and if we did, we’d probably shy away from its prescriptive nature), but we’ve found that the train metaphor it prescribes unlocks the potential of our existing regular, frequent release cadence.

Release Train visualisation

Release Train visualisation

Aside from the obvious product planning benefit of the visualisation, we’ve found that there are significant other advantages of using an Agile Release Train. Here are my top five side-benefits:

1.  Small, independent user stories

To be able ship a valuable piece of functionality every week (or two) and assemble a train which makes use of each available release, you need to break the functionality to be delivered down into the smallest units possible. Although this has always been a characteristic of good backlog management, regular weekly releases makes this mandatory. Additionally, to be able to make the most of the opportunity to reprioritise and shuffle a release train plan based on new information (user feedback or slower/quicker progress), making these stories independent is also very useful. Without having to be particularly deliberate about this, our user stories have ended up valuable, small and discrete.

2.  #NoEstimates

As a consequence of the Release Train encouraging teams to break functionality down into the smallest possible valuable blocks, these blocks tend to be a similar size. Over time, the team has developed a good sense for how long one of these blocks will take to complete and this is surfaced by the team predicting which release a piece of functionality will be ready by (“yeah, we can do that for next week”, “nope, we’ll miss the next release with that one”). Although the granularity of these hunches is simply the length of time between releases, we’ve found these to be accurate enough to allow us to plan, track and respond according, which (in a sane world) is the point of estimates. We’ve found no need to break out the Planning Poker cards, Ideal day estimates, t-shirt sizes or a ouija board so far.

3.  Team-driven scope management

As the team was central to the assembly of the release train, predicting when functionality will be delivered and building up a chain of releases to meet a goal, they can easily appreciate the knock-on effects of an overrunning story or blocked release. With the wrong team, this could be a problem – encouraging people to relax their quality principles in order to expedite some work and keep the train on schedule. With the right team – one that understands that the release train is not a formal schedule to be obeyed but a prediction that helps us make decisions –  this foresight encourages the team to ask the right questions to control scope throughout the project.

My team are aware of the effect decisions in the present will have on our future success and as a result are very sensitive to scope-creep, gold-plating and ‘lone wolf’ developers. This doesn’t stop us from going the extra mile to make a piece of work awesome, but when we do we are aware of the consequences and make those decisions prudently.

4.  Clear planning horizons

Many agile teams I’ve worked with in the past have struggled with the question of how much preparation to do ‘up-front’ for each piece of work. Ideally, user stories at the top of a backlog (earmarked to be worked on soon) should be well understood (with acceptance criteria, notes on what is out of scope and even a story points size). Stories halfway down the backlog might be represented by a single sentence – “As a user, I want … so that I can …”.  Pieces of work at the bottom of the backlog are epics – mega user stories that cover a large undertaking and will eventually break down in many individual stories.

This is great, but this can sometime leave the medium-term plan for a project somewhat opaque or unfocussed – with only a hazy idea of what work ‘may’ be tackled in the future. Also, because agile teams can change direction quickly, Product Owners have been known to pull work into the next sprint from the middle or end of the backlog in response to customer feedback. As a result, teams can find that a poorly understood user story is suddenly something they need to start ‘right now’.

Applying the Release Train has encouraged us to think about the wider objective we want to achieve with a chain of releases – for instance, to improve user retention or support a new use case. Our 2015 planning activities have involved queuing-up a number of release trains each with a distinct objective. When we near the time earmarked for a new train to start, we go about assigning the chunks of work we feel are necessary to achieve the train’s objective. As I mentioned above, those chunks are broken down into the smallest, valuable pieces we can envisage. The acceptance criteria that help judge whether a piece of work is complete, tend to be established as a side effect of the process.

What we’ve ended up with is a string of well understood, fully-planned pieces of work that are very likely to be undertaken soon. Future Release Trains are not broken down into stories until we near the end of the previous train. This approach has given us clear, sustainable planning horizons and ensured we only spend time discussing the minutiae of work that will be started imminently.

5.  Intrinsic release cadence

Delivering a product using a Release Train has meant that our weekly release cadence is now metronomic and fundamental to our approach to software development. The dream of agile development – getting valuable functionality into users’ hands as often as possible and receiving feedback that helps modify our plans, hopefully delivering a better end-result – is now second nature. It would be almost impossible to stop doing “Continuous Delivery”.

Our development practices are tuned to be able to release at the drop of a hat, our automated tests are reliable (if it’s red, it’s broke), we split our work into week-sized chunks and we plan in the knowledge that we’ll be incrementally delivering features to our users. There’s none of this ‘potentially shippable product’ rubbish at the end of a sprint, just shipped product.

The end of the line

So, even if the thought of applying the Scaled Agile Framework makes you burn with agile indignation, consider giving the Release Train metaphor a go with your team to unlock the potential of your frequent releases.

Laying the track as we go: New product development and the Agile Release Train

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.

Laying the track as you go

Laying the track as you go

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 SQL Lighthouse Beta Release Train

The SQL Lighthouse Beta Release Train

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).

The SQL Lighthouse Beta Release Train

“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.

The next Release Train: Get 250 users onto the Beta

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.