Release slack
This post is part of 101 ideas for agile teams.
Context
Your team releases software on a pre-defined schedule (e.g. quarterly) with whatever features could be developed in this time-box. The context of your product does not allow a continuous delivery workflow (e.g. your devices need manual intervention to be updated, the devices are not online, …).
Although there is no fixed scope, your team struggles in the last Sprint(s) before the release:
- show-stoppers are found
- stakeholders change their opinions
- the testing environment with all the simulators of the external services makes trouble
- additional work due to late insights (we thought it was done, but found out it wasn’t, and we really should change this before the release, or our users will be confused)
Action
Introduce some slack time between the external release date and the internal done for the release date (e.g. 2 Sprints).
If everything goes well, use the slack time to start working on the next release. If there are problems, you have the slack time to solve them — without overtime, without disappointed stakeholders.
What you gain
Less stress before releases, resulting in better quality of the product.
No hard switch from release n to release n+1. If needed you can smoothly transition to the next release.
How to strengthen
Defect fixes, very urgent features should be implemented and deployed as soon as possible — without fixed release dates or slack time. This strengthens acceptance from your stakeholders regarding the slack time.
Risks
The release you introduce slack time will be shorter (normal time minus slack time) and will, therefore, contain less scope/features. If this is not acceptable, you can introduce the slack time in several steps. On every release, you add one week to the slack time.
The slack time results in a longer cycle time. Make your trade-off between the continuous pace of the development team and cycle time. Find a way to release more frequently and with feature flags.
Please help me improve this idea by providing feedback.
More ideas at 101 ideas for agile teams
Many thanks to bbv Software Services for making this blog post possible.
