Release Go/No-Go

70 deploy-release-go-no-go

The final step for the Release Management Team in the evaluation process for new functionality is to determine if the experience within the staging environment has met the needed criteria to be deployed to users in production.

Explore More.

Related Mindset:

Lean-Agile

Continuous Delivery

Segment:

Deploy

Inputs:

An experience within the staging environment which has been validated through automated testing and product management

Outputs:

A decision on whether the experience should be deployed to production, as well as a timeline for deployment, if the Release Management Team decides to deploy

The release management team owns the final decision on releasing functionality to end users.

The Release Management Team follows its own process for evaluating functionality in a staging environment. This concludes with a final go/no-go decision from the team for release to production. Since this team includes representatives from product management, DevOps, development, and marketing, this team should have all of the necessary individuals to identify not only a decision on a release, but also a schedule for making the solution available on production.

Common Pitfalls

Even organizations that have identified a Release Management Team with clear responsibilities, there can still be common pitfalls that occur:

  • Delayed decision-making on a release: Because of the multiple validations that occur throughout the process, decision-making at this level should be somewhat of a formality. The question should be more around when a release should occur rather than whether an aspect of a feature should be delivered to production. Once the validations have taken place, a decision should be made quickly.
  • Outside input required for decision making: The Release Management Team should have everyone needed within the team to make an efficient and well-informed decision on a release to production. If there is a need for outside input during this phase, the structure of the team may need to be adjusted.
  • Requirements changing in the release management process: In situations where members of the Release Management Team have not been fully invested in the process leading up to a release decision, changes to completed functionality may be proposed at this phase. If these changes are blockers for a release, the system has failed. The members of the Release Management Team should be fully invested in the process to surface any issues earlier in the process. It should be noted that ideas for new functionality can certainly be generated through this process, but those items should be injected back into the Portfolio or Program segments and not block the release of functionality, except in very rare cases.