Release when ready

Most agile teams build their processes around a single release per sprint, with one release every two weeks being most common.  This typically backs into a certain number of days of development (ex. 7) and the remainder of the sprint is a code freeze on new functionality so that manual testing and bug fixing can occur.  This culminates in a release of everything done in that time frame, and then the process repeats for the next sprint.

It doesn’t sound too bad on paper, but this framework leads to a lot of bad behaviors, such as:

  • Development teams will cut corners to meet the two week deadline to avoid having their feature delayed an additional two weeks
  • If developers are given a little bit longer to wrap up, it compresses the testing time and introduces more risk
  • QA has to test all features together and could potentially miss issues or find issues and not know which new feature was the root cause
  • Bug fixes have to be turned around very quickly and are often hacky solutions that add tech debt
  • The larger and more complex a release is, the harder it is to perform the release, leading to longer release times and more firefighting in production, which forces releases to occur after hours or on weekends with all hands on deck
  • All this together makes each sprint feel like a death march to close out a sprint and start a new one fresh

The release when ready model I use for my teams turns all of this on its head.  What this means is that each feature is developed, tested, and released independently from each other.  There are several requirements to put in place before you can do this:

  • Stories must consist of small, iterative features that continually improve the platform with clear acceptance criteria.  The bigger the stories, the harder it is to meet the rest of these prerequisites.
  • Each QA Engineer must have the ability to test a specific branch of changes instead of using a shared environment.  This generally requires a more technical QA team that can build, maintain, and switch branches on their own environments (usually locally).
  • QA Engineers need to be empowered to merge the branches they are testing after verifying the functionality (in lieu of PMs having a separate review/verification step, except on larger or riskier features)
  • Switch to using trunk-based development so that the main default branch is always releasable
  • Build Continuous Delivery processes to automatically push any new changes in main to a pre-production/staging environment and fully automate the production release at the push of a button

Once you’re ready, you get to reap the benefits:

  • If Software Engineers OR QA Engineers need additional time to wrap up a feature, they can take an extra hour, day, or week without impacting other features being released.  This is especially important for larger or more impactful features where more attention is needed to reduce risk and/or increase quality.
  • Whenever dev and testing are done throughout the sprint, the functionality can release immediately instead of waiting until end of the sprint
  • QA Engineers are more able to review a specific story’s code changes and adjust their testing plans accordingly (often finding additional areas to test that they wouldn’t realize they had to do otherwise)
  • Since QA is testing changes right after development is done, engineers don’t have to context-switch back to something they finished several days to a week or more earlier.  Any new bugs found are easier to triage and resolve.
  • The pre-production/staging environment contains new changes that have already been tested and approved, allowing PMs or other stakeholders to take a final look as needed
  • Releases can occur at any point, multiple times a day, which will allow us to iterate faster
  • Releases during business hours allow us to see immediate usage with actual users
  • Smaller changes enable us to “fail fast”, gain quick learnings and evolve instead of having “big bang” releases, and are also easier to rollback if critical issues are found after deployment
  • Releases become “disposable” and don’t need the full attention (or any attention!) of devs or QA when they occur.  Ideally the push-button process is driven by the PMs that are shepherding their stories throughout the entire development lifecycle.
  • Engineers can continually focus on new feature development and QA can continually focus on testing new features as they are completed

When I explain this release when ready model to potential candidates in interviews, the biggest misconception is that it’s very difficult and more stressful than two week releases.  This is often because people are imagining the painful release process and overhead they are used to and thinking they will feel those same emotions daily.  In reality, this model de-stresses the entire team by allowing people to focus on what’s important instead of focusing on the process itself.