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.
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.
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.
Leading Agile Teams 
Leave a comment