Boosting the release pace
Obviously with even more visual management!
Obviously with even more visual management!
Cet article est également disponible en français.
From 1 release per quarter to 2+ releases per week
How we used visual management and gamification for our releasing processmedium.com
In the previous article I was bragging that we were to boost significantly our pace of release, now getting closer than ever from Continuous Delivery. Well, I haven’t told you the whole story!
There is more to it than the snakes and ladders game of the push to prod process. This first board works hand-in-hand with another one, the release planning board. Today we’ll talk about it!
Usage in Sprint Review
In: topics whose development is done
I already mentioned this board in a previous article about how we conduct our Sprint Reviews (article in French). In a nutshell, once a US is done, and if it requires to be pushed in production, then we add it to the release planning board.
The board makes clear to which team belongs each topic. Indeed this board will help synchronize several teams, and each team keeps responsibility to push to production its own topics. In our case, we use different post-it colors to identify the teams.
Out: topics in production
Conversely, topics which have been pushed to production are removed from the board.
We keep track of the number of sprints that the topic spent on the board. In other words, this is the number of sprints elapsed between the end of development and the actual releasing in production.
To that end, after removing the topics in production, we add a bar on the back of all post-its remaining on the board: the number of sprints spent on the board will be the number of bars.
Finally, we record this information in a spreadsheet for further analysis:
Number of releases per iteration
Time required to push to production a ‘done’ topic
Usage in Sprint Planning
Forecasting the releases of the sprint
This release planning board has a critical role to play during the sprint planning meeting.
The Sprint Planning starts with an additional step, shared between the various Scrum teams who shares the same resources required to push to production:
Adding urgent topics: some topics are not yet developed but are urgent and shall be released before the end of the sprint. Such topics are added in advance to the release planning board, so that they can be included into the sprint releases forecast.
Priorizing topics and forecasting the releases of the sprint: the order of the topics of the release planning board is updated and a tentative date is assigned topics that the teams will try to release during the sprint.
The releasing strategy is also refined through this sprint releases forecast. For instance we wish to use team downtimes (days off, Scrum meetings) to wait on external dependencies. Likewise, we want to maximize the number of releases with no external dependency on the days when the team is fully active.
We set up a strategy that will both maximize the number of releases and minimize risk.
Synchronizing with external dependencies
This release forecast will enable the teams and the external dependencies to synchronize with each other. The interactions with such entities being weaker and less casual, we must be more rigorous in the synchronization: by providing tentative dates.
An additional input for the development team defining the increment forecast
Once than this release forecast is done, each team can then proceed with the typical Scrum sprint planning… taking into account the load of the releases planned during this sprint!
Thus the team will adjust its increment forecast accordingly to the number and complexity of the releases planned during the sprint.
Copy-writing the release forecast on the Scrum boards
Finally the Scrum boards of the teams are filled up with the US of the sprint, the corresponding technical tasks… but also with the releases that the team took charge of!
Notice that the releases are always on the first lines of the board, before the sprint US: priority is always given to the releases.
Code has zero value until it gets released. That’s why pushing to production a ‘done’ topic is always more important than working on new topics.
The row will also be used to write down precious information:
We copy the tentative release date on the row
We’ll write the non-regression testing scenarios on technical task post-its
We’ll use a small card listing the set of devices/OS/browsers to check
The team will mark the releasing status : impediments, things to keep in mind, specific announcements…
Usage in daily stand-up
The various boards are checked and updated all the time during the sprint. A specific point is part of the daily stand-up.
The snakes and ladders game of release process: the status of the on-going releases are updated by moving the pieces of the releases on the snakes and ladders board, also checking that nothing is left
The Scrum board: non-regression testing progress, surfacing impediments, synchronizing the team…
The release planning board: if needed, updating tentative dates and synchronizing with the other teams; or adding hot-fixes
Now an irrelevant board
Much like the snakes and ladders game of release process, the release planning board is not used anymore. Moving to Kanban, these elements are directly integrated in the continuity of the teams’ Kanban boards.
For that matter pushing to production has become a second nature and the teams directly synchronize with each other, without any explicit board.
The teams have also reduced their dependencies with external entities, whom need for a planning.
The process is still alive but is now informal.
It’s very Scrum-y
And it’s logical to stop using these boards when switching to Kanban: these boards are in full alignment with the Scrum way.
Planning releases in Sprint Planning
Tentative dates everywhere
There is a strong focus on planning, which is a fundamental element of Scrum. I’m not going to spit at it: this focus on planning is exactly why Scrum has seen such a large adoption, providing for a familiar way of doing, compatible with existing constraints. Yet it’s also exactly this focus on planning that makes today’s Agile community move away from Scrum to find better ways of doing.
Long live the world of pull! (Kanban is king)
Scrum is good, Scrum is bad: planning
Both biggest strength and weakness of Scrummedium.com
Want more?
This article is part of a series about how we managed to get to release on a daily basis. Have a look at the other articles:
Our recipe for Daily Releases
It was upon a time a team that struggled to release…medium.com
Did you like this article?
Follow me to be notified of the other articles!
And don’t forget to click on the heart 💗 to support me, and to share the article: these like are what makes me putting my heart and soul into writing.
Thank you! 😄