Besides the small introduction, subscribers and consulting clients within this management domain have access to:
This presentation documents the Info-Tech approach to defining your application release management framework.
The template gives the user a guide to the development of their application release management framework.
This workbook is designed to capture the results of your exercises from the Define a Release Management Process to Deliver Lasting Value blueprint.
Workshops offer an easy way to accelerate your project. If you are unable to do the project yourself, and a Guided Implementation isn't enough, we offer low-cost delivery of our project workshops. We take you through every phase of your project and ensure that you have a roadmap in place to complete your project successfully.
Document the existing release management process and current pain points and use this to define the future-state framework.
Gain an understanding of the current process to confirm potential areas of opportunity.
Understand current pain points so that we can build resolution into the new process.
1.1 Identify current pain points with your release management process. If appropriate, rank them in order of most to least disruptive.
1.2 Use the statement of quality and current pain points (in addition to other considerations) and outline the guiding principles for your application release management framework.
1.3 Brainstorm a set of metrics that will be used to assess the success of your aspired-to application release management framework.
Understanding of pain points, their root causes, and ranking.
Built guiding principles for application release management framework.
Created set of metrics to measure the effectiveness of the application release management framework.
Build sample release criteria, release contents, and standards for how it will be integrated in production.
Define a map to what success will look like once a new process is defined.
Develop standards that the new process must meet to ensure benefits are realized.
2.1 Using an example of a product known to the team, list its criteria for release.
2.2 Using an example of a product known to the team, develop a list of features and tasks that are directly and indirectly important for either a real or hypothetical upcoming release.
2.3 Using an example of product known to the team, map out the process for its integration into the release-approved code in production. For each step in the process, think about how it satisfies guiding principles, releasability and principles of continuous anything.
Completed Workbook example highlighting releasability.
Completed Workbook example defining and detailing feature and task selection.
Completed Workbook example defining and detailing the integration step.
Define criteria for the critical acceptance and deployment phases of the release.
Ensure that releases will meet or exceed expectations and meet user quality standards.
Ensure release standards for no / low risk deployments are recognized and implemented.
3.1 Using an example of product known to the team, map out the process for its acceptance. For each step in the process, think about how it satisfies guiding principles, releasability and principles of continuous anything.
3.2 Using an example of product known to the team, map out the process for its deployment. For each step in the process, think about how it satisfies guiding principles, releasability and principles of continuous anything.
Completed Workbook example defining and detailing the acceptance step.
Completed Workbook example defining and detailing the deployment step.
Define your future application release management process and the plan to make the required changes to implement.
Build a repeatable process that meets the standards defined in phases 2 and 3.
Ensure the pain points defined in Phase 1 are resolved.
Show how the new process will be implemented.
4.1 Develop a plan and roadmap to enhance the integration, acceptance, and deployment processes.
List of initiatives to reach the target state
Application release management implementation roadmap
As firms invest in modern delivery practices based around product ownership, Agile, and DevOps, organizations assume that’s all that is necessary to consistently deliver value. As organizations continue to release, they continue to see challenges delivering applications of sufficient and consistent quality.
Delivering value doesn’t only require good vision, requirements, and technology. It requires a consistent and reliable approach to releasing and delivering products and services to your customer. Reaching this goal requires the definition of standards and criteria to govern release readiness, testing, and deployment.
This will ensure that when you deploy a release it meets the high standards expected by your clients and delivers the value you have intended.
Dr. Suneel Ghei
Principal Research Director, Application Development
Info-Tech Research Group
Turn release-related activities into non-events.
Eliminate the need for dedicating time for off-hour or weekend release activities. Use a release management framework for optimizing release-related tasks, making them predictable and of high quality.
Release management is NOT a part of the software delivery life cycle.
The release cycle runs parallel to the software delivery life cycle but is not tightly coupled with it. The act of releasing begins at the point requirements are confirmed and ends when user satisfaction is measurable. In contrast, the software delivery life cycle is focused on activities such as building, architecting, and testing.
All releases are NOT created equal.
Barring standard guiding principles, each release may have specific nuances that need to be considered as part of release planning.
The business is constantly looking for innovative ways to do their jobs better and they need support from your technical teams.
The increased stress from the business is widening the inefficiencies that already exist in application release management, risking poor product quality and delayed releases.
Being detached from the release process, business stakeholders do not fully understand the complexities and challenges of completing a release, which complicates the team’s communication with them when issues occur.
IT Stakeholders Are Also Not Satisfied With Their Own Throughput
(Info-Tech’s Management and Governance Diagnostic, N=3,930)
COMMON RELEASE ISSUES
The bottom line: The business’ ability to operate is dictated by the software delivery team’s ability to successfully complete releases. If the team performs poorly, then the business will do poorly as well. Application release management is critical to ensure business expectations are within the team’s constraints.
“As software becomes more embedded in the business, firms are discovering that the velocity of business change is now limited by how quickly they can deploy.” – Five Ways To Streamline Release Management, J.S. Hammond
Research conducted on Info-Tech's members shows overwhelming evidence that application throughput is strongly tied to an effective application release management approach.
(Info-Tech Management & Governance Diagnostic, since 2019; N=684 organizations)
From | To |
---|---|
Short-lived projects | Ongoing enhancements supporting a product strategy |
Aiming for mandated targets | Flexible roadmaps |
Manual execution of release processes | Automating a release pipeline as much as possible and reasonable |
Manual quality assurance | Automated assessment of quality |
Centralized decision making | Small, independent release teams, orchestrated through an optimized value stream |
Info-Tech Insight: Your application release management framework should turn a system release into a non-event. This is only possible through the development of a holistic, low-risk and standardized approach to releasing software, irrespective of their size or complexity.
A continuous anything evaluation should not be a “one-and-done” event. As part of ongoing improvements, keep evolving it to make it a fundamental component of a strong operational strategy.
Continuous Anything
An application release management framework converts a set of features and make them ready for releasability in a low-risk, standardized, and high-quality process.
A continuous anything (integration, delivery, and deployment) mindset is based on a growth and improvement philosophy, where every event is considered a valid data point for investigation of process efficiency.
Diagram adapted from Continuous Delivery in the Wild, Pete Hodgson, Published by O'Reilly Media, Inc., 2020
There is no standard definition of a system’s releasability. However, there are common themes around completions or assessments that should be investigated as part of a release:
Governing principles are fundamental ways of doing something, which in this case is application release management, while releasability will generally have governing principles in addition to specific needs for a successful release.
Example of Governing Principles
Examples of Releasability Criteria
A pervasive myth in industry revolves around the misperception that continuous anything and nimble and non-event application release management is not possible in large bureaucratic and regulated organizations because they are risk-averse.
"We found that external approvals were negatively correlated with lead-time, deployment frequency and restore time, and had no correlation with change failure rate. In short, approval by an external body (such as a manager or Change Approval Board) simply doesn’t work to increase the stability of production systems…However, it certainly slows things down. It is in fact worse than having no change approval process at all." – Accelerate by Gene Kim, Jez Humble, and Nicole Forsgren
Many organizations reduce risk in their product release by adopting a paternalistic stance by:
Despite the prevalence of these types of responses to risk, the evidence is that they do not work and are in fact counter-productive because they:
At the enterprise level, continuous anything focuses on:
Focus of this blueprint
At the product level, continuous anything focuses on:
At the functional level, continuous anything focuses on*:
*Where necessary, practices at this level have been mentioned.
Pre-release practices such as requirements intake and product backlog management are important because: