Release Entry and Exit criteria's - Gates and Approvals

Release Entry and Exit criteria's - The Missing Piece in the Release Gates and Approvals Process.

A brief description of the importance of release gates. Releases which are made up of Project and non-project work potentially all perfomring functional changes to common systems need a minimum level of governance to ensure code changes don't create regression issues. A common practise is to setup release phases such as Dev, SIT ,SVT and UAT which act as boundaries for release stakeholders to work within aka "Release Runway".  In order to ensure the Release Runway is achievable (i.e. the release won't over run and crash before evening making it to production) Release Managers need to ensure activities such as dependency management, scope and impacts assessments, full regression testing etc are completed as per the Release Schedule. To track these types of activities gates are applied to the Release Runway. These Release Gates act as checkpoints which allow Release Managers and Senior Management to ascertain the health of the Release while allowing Projects who are part of the release to gauge what dates they need to track too.

A common problem many release management frameworks have is the lack of emphasis's on Release Gates and the associated approval process. I stress emphasis because most frameworks we have seen implemented in large organizations do have gates and approvals but there is no military style execution on the enforcement of the objectives (entry and exit criteria) for each gate. It's a classic case of release stakeholders flagging the gates as approved because the process says so but really not diligently performing the checks and balances to ensure each gate objective/s are satisfied.

The release quality and schedule slippages begin to surface when gates are setup but not actively manage. Gates need to be setup with entry and exit criteria's and socialised with all release parties. Without entry and exit criteria's everyone is flying blind in respect to what is expected of them to achieve gate approval.

Common reasons why release gates often bypassed:

• Release managers feel overwhelmed by the amount of project management type activities that gates become an un-necessary evil and get bypassed.

• No proper documentation on the entry and exit criteria for each gate (I will elaborate on this one further in the next paragraph)

• No senior management buy-in which means enforcing the gates with peers across various development, testing and IT operations teams becomes extremely difficult

Entry and Exit criteria is a must for establishing, tracking and delivering large scale monolithic releases. Release Managers need to setup the Release Gates and the theory behind this is that each gate will have a set of approvers who need to provide their approval for the release to progress to the next set of phases/activities. Approvers need to understand what the entry and exit criteria is and if each one has been diligently completed in order for them to hit the approve button. Without each Gate entry and exit criteria clearly articulated and the accompanying results how can an approver really make that call.

The task of documenting the entry and exit criteria per gate is also one of many discussions. It's not good enough to have the entry and exit criteria buried in some word document which nobody will read. The entry and exit criteria per gate needs to be available front and center for all stakeholders.