Release wednesdays and the agile release train upload
•Download as PPTX, PDF•
1 like•2,536 views
The document discusses the benefits of using an "Agile Release Train" approach for software development. Some key points: - An Agile Release Train plans work in train-like themes that are delivered on a regular cadence, such as every 2 weeks. This provides a predictable release rhythm. - Work is broken into small, independently releasable increments called user stories. If a story is not ready for the current release, it waits for the next one. - Planning occurs through story mapping epics and stories to future releases. The plan is updated each sprint to reflect progress and priority changes. - Benefits include clear focus on current work, visibility of priorities and timelines, and
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (16)
Similar to Release wednesdays and the agile release train upload
Similar to Release wednesdays and the agile release train upload (20)
More from Chris Smith
More from Chris Smith (8)
Recently uploaded
Recently uploaded (20)
Release wednesdays and the agile release train upload
- 1. Release Wednesdays and the Agile Release Train
- 2. Why talk about this? •Successful approach on current projects •Putting releases at the heart of how we develop and deliver software •Allowing us to plan better and make better decisions •Encourage other teams to try this approach
- 5. Because… •Give users valuable stuff quickly •Get timely feedback •Reduce risk by reducing delta between releases •Get better at releasing •Get a kick out of it
- 6. ‘Deliberate’ or ‘Opportunist’ cadence
- 7. Why releases at a ‘deliberate’ cadence? •Gives us a regular, sustainable rhythm •Keeps us honest; we need to keep build continually ready •Don’t have to think about it •Don’t overdo it
- 9. The benefits we have seen •Users get functionality and bug-fixes quickly •No release ‘crunch’ •We don’t worry about ‘when’ •We are better at releasing •Work in progress is small •Our processes are healthy •The team are motivated by it
- 10. How we release every Wednesday •Streamlined, automated releases •Small, incrementally valuable user stories •‘Master’ branch is continually releasable •Team focusses on the release cadence •Team owns release process
- 11. Dude, where’s my track?
- 12. Choo-choose the ‘Agile Release Train’
- 13. The what? •Trains (releases) go out on fixed timetable •The train delivers cargo to customers •The train will not wait for you •If cargo (work) is not ready the train goes without it •Cargo waits for the next train
- 14. The Release Train to synchronize work streams
- 15. The Release Train to help plan… for the short term
- 16. The Release Train to help plan… for the longer term
- 17. Why is this better than a Gantt Chart? “Plans are useless, but planning is indispensable” Dwight D. Eisenhower
- 18. Why is this better than a Gantt Chart? The Release Train is not a formal schedule to be obeyed, but a prediction that helps us make decisions. It encourages the team to ask the right questions in order to control scope and understand timescales throughout the project
- 19. The benefits we have seen Team-driven planning: •Clear planning horizon •Clear current focus •Clear immediate plan •Important marketing activities/deadlines are visible •Changes to plan are explicitly discussed •Team-driven scope management •Understand real progress towards goals
- 20. The benefits we have seen Embeds good practice: •Keeps weekly releases •Keeps us to small user stories •#NoEstimates
- 21. It can be hard For example: •Breaking work up into small, valuable stories is hard (but not impossible) •Watching cargo fall off the end of a train can be painful •*Just* missing a release with some cargo is frustrating •Releasing is REALLY motivational (we need to watch for burnout)
- 22. When it worked: SQL Lighthouse Beta in six weeks
- 23. When this worked: DLM Dashboard ‘Retention’ theme Timeboxing work on retention features
- 24. How to plan with the Agile Release Train
- 25. Plan in (kinda) timeboxed themes Jan Feb Mar Apr May Jun Theme 3 Theme 2 Theme 1 ~8 weeks Get 800 users Invest 6-8 weeks
- 26. Break into epics and stories Theme 1 Story A1 Epic/Featu re A Story A2 Story A3 Story B1 Epic/Featu re B Story B2 Story C1 Epic/Featu re C Story C2 Story C3 Story C4
- 27. Utilize weekly release cadence Jan Feb Release 7-Jan-15 Release 14-Jan-15 Release 21-Jan-15 Release 28-Jan-15 Release 4-Feb-15 Release 11-Feb-15 Release 18-Feb-15
- 28. Throw stories at the plan Jan Feb Release 7-Jan-15 Release 14-Jan-15 Release 21-Jan-15 Release 28-Jan-15 Release 4-Feb-15 Release 11-Feb-15 Release 18-Feb-15 Story A1 Story A2 Story A3 Story B1 Story B2 Story C1 Story C2 Story C3 Story C4 Story B3 Story B4 Story C5 Story C6
- 30. Update the plan every sprint Jan Feb Release 7-Jan-15 Release 14-Jan-15 Release 21-Jan-15 Release 28-Jan-15 Release 4-Feb-15 Release 11-Feb-15 Release 18-Feb-15 Story A1 Story A2 Story B1 Story C1 Story B2 Story B3 Story B4 Story C3 Story C4 Story C2 Story A3 Released Released
- 31. Update the plan every sprint Jan Feb Release 7-Jan-15 Release 14-Jan-15 Release 21-Jan-15 Release 28-Jan-15 Release 4-Feb-15 Release 11-Feb-15 Release 18-Feb-15 Story A1 Story A2 Story B1 Story C1 Story B3 Story B4 Story C3 Story C4 Story C2 Story A3 Released Released Story B2 Released ReleasedReleased
- 32. Think about the end of the train Jan Feb Release 7-Jan-15 Release 14-Jan-15 Release 21-Jan-15 Release 28-Jan-15 Release 4-Feb-15 Release 11-Feb-15 Release 18-Feb-15 Story A1 Story A2 Story B1 Story C1 Story C2 Story C3 Story B3 Story B4 Released Released Story B2 Released ReleasedReleased Release 25-Feb-15 Story C4 ReleasedReleased ReleasedReleased Released
- 33. Next theme… Jan Feb Mar Apr May Jun Theme 3 Theme 2 Theme 1 ✓ Done
- 34. Questions?
Editor's Notes
- As a result of putting Release Wednesdays at the heart of how we develop and deliver software, we’ve optimised our processes and practices so that we can to release frequently and deliver new features incrementally. Interestingly, in addition to increased pace of delivery and user feedback the weekly cadence gives us, we’ve found many of these optimizations to be beneficial in their own right.
- I want to talk about this because it is the foundations of the release train – this is central to how we are building software
- In my opinion, ‘potentially shippable’ product is a cop-out
- We want to give our users valuable enhancements as quickly as possible and get timely feedback on the direction we are taking the product. We believe in keeping the delta between releases small and the risk associated with an individual release low. We think practice makes perfect and that the more often you release the less frightening it is to do so. 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.
- I’d argue in favour of a want ‘deliberate’ release process, not an ‘opportunist’ one. An opportunist release process results in an irregular release rhythm; sometimes there might be three releases in a week, sometimes one a month. You release when you can. A deliberate approach to frequent releases means a regular, sustainable rhythm. Dashboard have released every Wednesday this year. 12 releases and no more. I’ll talk about why and the benefits in the rest of the presentation…
- It keeps us honest. In order to achieve our goal, we need to be able to keep our build ready for release continually. We don’t have to think about when to release. Not continually agonising over whether ‘now’ is a good time to do a release or not. That decision can take time, effort and (possibly) a great deal of thought. We don’t want to drown our users in updates. We think that one release a week is frequent enough for users to get their hands on the latest work we’ve done and give us timely feedback, without the update notification becoming irritating.
- This lead us to Release Wednesdays on our products Renamed “Welease Wednesdays” almost immediately. Giving it a name, helped it stick! 2015: 12 releases in 12 weeks
- Users get valuable new functionality sooner – if we feel that users will get value from a partially complete feature (where the ‘complete’ part has been fully tested), a bug fix or a usability enhancement, then we ship it on the following Wednesday. No crunch We are better at releasing – we’ve practiced, we trust our automated tests and we’ve streamlined our process. We don’t ship broken releases – even though we release much more often than we used to, we have not shipped a release we have had to recall since we started Release Wednesdays. That’s because we’ve kept the delta between releases small and the risk associated with an individual release low. We don’t spend time worrying about when we should release – if it is not a Wednesday, we don’t start the release process. We are always releasable – we’ve had to organise our development environment so that we are always ready to release. That means using the likes of feature branches, tiered automated tests and continuous deployment into a test environment. The team love it – there’s something intrinsically motivational about delivering something you have made to people who will find it useful. Whenever we ask the team what they like about the project, they always mention “Release Wednesdays”
- We’ve streamlining our release process – automating everything we can and simplifying everything else. For example, we rely on automated testing to prove builds and, thanks to an internal tool, we can deploy to Production with the click of a button. See my post from 2013 about the benefits of automated deployments. We break our work up into small, incrementally valuable user stories. This is so that they can be integrated into our weekly cadence – each story should be around a week to two week’s work for the team. This is obviously a bit of a black art, so we’ve had to think a lot more deeply about the scope of our user stories and their relative value. We have found that we have a much more ‘agile’ backlog and a good feel for what we can achieve in a week. We keep the product code in a continually releasable state. This is a working agreement and has pushed us to use separate branches for each feature, user story or bug fix, so that the root of our source control repository only has work that is fit for immediate release. An additional benefit of this is that any parallel streams of work (e.g. a new feature and a big fix) are isolated from one another and so can be shipped independently. I’ve encouraged team to buy into a weekly release cadence and do my best to coach them when they discover obstacles to delivering stories. Without the team being behind this initiative, it was not going to work. Once the team had tried it and liked the momentum we achieved, the approach was here to stay. Now, getting then current story done in time for next Wednesday is hugely motivation for the group. The team are responsible for the releases – they decide when things are shipped.
- Although we released every week. We had this problem – not a clear path ahead… we sometimes felt like we were going to run out well understood work just around the corner
- 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. We apply the Agile Release Train technique, which has brought it’s own benefits – #NoEstimates, Team-driven scope management and clear planning horizons. See my recent post on the Release Train for more details.
- From the Scaled Agile Framework Synchronization points Planning mechanism
- From the Scaled Agile Framework Planning mechanism
- If we know we are able to release every week, to a schedule, we can start to use that as a part of a planning cadence We can judge how much cargo we *might* ship We can measure real progress We can timebox effort
- If we know we are able to release every week, to a schedule, we can start to use that as a part of a planning cadence We can judge how much cargo we *might* ship We can measure real progress We can timebox effort
- 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.
- The Release Train is not a formal schedule to be obeyed, but a prediction that helps us make decisions. It encourages the team to ask the right questions in order to control scope and understand timescales throughout the project
- Clear visualization of progress to stakeholders (and effect of changes in direction)
- From the Scaled Agile Framework Planning mechanism
- From the Scaled Agile Framework Planning mechanism
- Plan new work in themes – groups of stories and epics initiated to advance ‘something’ E.g. Improve retention Improve getting started Further improve retention Differentiation Obviously me
- Break into epics and stories
- Assemble a train on the cadence
- Assemble a train on the cadence (more or less in order) A1 A2 A3 B1 B2 The rest
- Think about which individual stories are the more important Don’t care about A3 very much – certainly we care about other things more There is a RG update – we want to be able to talk about feature C We’d rather have C2 earlier – users want it more We think doing 4 stories on the last train is mad, so we are dropping C5 and C6
- We release A1 We release A2, but we can’t finish B1 (we were mad to think that)
- We release A1 We release A2, but we can’t finish B1 (we were mad to think that) We release B1 and C1/B2 But we realise C2 will take two weeks (this is ok) This means some valuable work falls off the back of the train
- We might decide to add another release to this schedule – the stories are too valuable to not realease (but we do want to get on to our next theme)
- Plan new work in themes – groups of stories and epics initiated to advance ‘something’ E.g. Improve retention Improve getting started Further improve retention Differentiation Obviously me