Define a Release Management Process for Your Applications to Deliver Lasting Value

Use your releases to drive business value and enhance the benefits delivered by your move to Agile.

Analyst Perspective

Improving your release management strategy and practices is a key step to fully unlock the value of your portfolio.

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

Executive Summary

Your Challenge

• Your software platforms are a key enabler of your brand. When there are issues releasing, the brand suffers. Client confidence and satisfaction erode.
• Your organization has invested significant capital in creating a culture of product ownership, Agile, and DevOps. Yet the benefits from these investments are not yet fully realized.
• Customers have more choices than ever when it comes to products and services. They require features and capabilities delivered quickly, consistently, and of sufficient quality, otherwise they will look elsewhere.

Common Obstacles

• Development teams are moving faster but then face delays waiting for testing and deployment due to a lack of defined release cycle and process.
• Individual stages in your software development life cycle (SDLC), such as code collaboration, testing, and deployment, have become leaner, but the overall complexity has increased since many products and services are composed of many applications, platforms, and processes.
• The specifics of releasing products is (wrongly) classified as a technical concern and not a business concern, hindering the ability to prioritize improved release practices.

Info-Tech's Approach

• Develop a release management framework that efficiently and effectively orchestrates the different functions supporting a software’s release.
• Use the release management framework and turn release-related activities into non-events.
• Use principles of continuous delivery for converting your release processes from an overarching concern to a feature of a high-performing software practice.

Executive Summary

Info-Tech Insights

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.

Your release management journey

1. Optimize Applications Release Management - Set a baseline release management process and organization.
2. Modernize Your SDLC - Move your organization to Agile and increase throughput to feed releases.
3. Deliver on Your Digital Product Vision - Understand the practices that go into delivering products, including articulating your release plans.
4. Automate Testing to Get More Done - Create the ability to do more testing quickly and ensure test coverage.
5. Implement DevOps Practices That Work - Build in tools and techniques necessary for release deployment automation.
6. Define a Release Management Process to Deliver Lasting Value (We Are Here)

Define a Release Management Process for Your Applications to Deliver Lasting Value

Use your releases to drive business value and enhance the benefits delivered by your move to Agile.

Executive Brief

Your software delivery teams are expected to deliver value to stakeholders in a timely manner and with high quality

Software delivery teams must enable the organization to react to market needs and competitive changes to improve the business’ bottom line. Otherwise, the business will question the team’s competencies.

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

• Only 29% of IT employees find application development throughput highly effective.
• Only 9% of organizations were classified as having highly effective application development throughput.
• Application development throughput ranked 37th out of 45 core IT processes in terms of effectiveness.

(Info-Tech’s Management and Governance Diagnostic, N=3,930)

Your teams, however, struggle with core release issues, resulting in delayed delivery (and disappointed stakeholders)

Implementing tools on top of an inefficient pipeline can significantly magnify the existing release issues. This can lead to missed deadlines, poor product quality, and business distrust with software delivery teams.

COMMON RELEASE ISSUES

1. Local Thinking: Release decisions and changes are made and approved without consideration of the holistic system, process, and organization.
2. No Release Cadence: Lack of process governance and oversight generates unpredictable bottlenecks and load and ill-prepared downstream teams.
3. Mismanagement of Releases: Program management does not accommodate the various integrated releases completed by multiple delivery teams.
4. Poor Scope Management: Teams are struggling to effectively accommodate changes during the project.

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

Historically, managing releases has been difficult and complicated…

Typically, application release management has been hard to coordinate because…

• Software has multiple dependencies and coordinating their inclusion into a deployable whole was not planned.
• Teams many be spending too much time on features that are not needed any longer.
• Software development functions (such as application architecture, test-first or test-driven design, source code integration, and functional testing) are not optimized.
• There are no agreed upon service-level contracts (e.g. expected details in requirements, adequate testing, source control strategy) between development functions.
• The different development functions are not integrated in a holistic style.
• The different deployment environments have variability in their configuration, reducing the reliability of testing done in different environments.
• Minimum thresholds for acceptable quality of development functions are either too low (leading to adverse outcomes down stream) or too high (leading to unnecessary delays).

…but research shows being effective at application release management increases your throughput

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)

An application release management framework is critical for effective and timely delivery of software

A well-developed application release management framework is transformative and changes...

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.

Robust continuous “anything” requires proficiency in five core practices

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

• Automate where appropriate
  • Automation is not a silver bullet. All processes are not created equal; and therefore, some are not worthy of being automated.
• Control system variables
  • Deploying and testing in environments that are apple to apple in comparison reduces the risk of unintended outcomes from production release.
• Measure process outcomes
  • A process not open to being measured is a process bound to fail. If it can be measured, it should be, and insights found should be used for improving the system.
• Select smaller features batches
  • Smaller release packages reduce the chances of cognitive load associated with finding root causes for defects and issues that may result as post-production incidents.
• Reduction of cycle time
  • Identification of waste in each stage of the continuous anything process helps in lowering cost of operations and results in quicker generation of value for stakeholders.

Invest time in developing an application release management framework for your development team(s) with a continuous anything mindset

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

Related Info-Tech Research

Streamline Application Maintenance

• Justify the necessity of streamlined maintenance. Gain a grounded understanding of stakeholder objectives and concerns and validate their achievability against the current state of the people, process, and technologies involved in application maintenance.
• Strengthen triaging and prioritization practices. Obtain a holistic picture of the business and technical impacts, risks, and urgencies of each accepted maintenance request to justify its prioritization and relevance within your backlog. Identify opportunities to bundle requests together or integrate them within project commitments to ensure completion.
• Establish and govern a repeatable process. Develop a maintenance process with well-defined stage gates, quality controls, and roles and responsibilities, and instill development best practices to improve the success of delivery.

“Releasability” (or release criteria) of a system depends upon the inclusion of necessary building blocks and proof that they were worked on

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:

• The range of performance, technical, or compliance standards that need to be assessed.
• The full range of test types required for business approval: unit tests, acceptance tests, security test, data migration tests, etc.
• The volume-criticality mix of defects the organization is willing to accept as a risk.
• The best source and version control strategy for the development team. This is mostly a function of the team's skill with using release branches and coordinating their work artifacts.
• The addition of monitoring points and measures required for evaluations and impact analysis.
• The documentation required for audit and compliance.
• External and internal dependencies and integrations.
• Validations, approvals, and sign-offs required as part of the business’ operating procedure.
• Processes that are currently carried out outside and should be moved into the pipeline.
• Manual processes that may be automated.
• Any waste activities that do not directly contribute to releasability that can be eliminated from the development process.
• Knowledge the team has regarding challenges and successes with similar software releases in the past.

Releasability of a system is different than governing principles for application release management

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

• Approval from Senior Director is necessary before releasing to production
• Production deployments can only be done in off-hours
• We will try to automate processes whenever it is possible for us to do so
• We will use a collaborative set of metrics to measure our processes

Examples of Releasability Criteria

• For the upcoming release, add performance testing for Finance and Budget Teams’ APIs
• Audit and compliance documentation is required for this release
• Automation of manual deployment
• Use trunk-based source code management instead of feature-based

Regulated industries are not more stable despite being less nimble

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:

• Requiring manual sign-offs from senior personnel who are external to the organization.
• Increasing the number and level of authorization gates.
• Staying away from change and preferring to stick with what has worked in the past.

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:

• Create blocks to frequent releases.
• Introduce procedural complexity to each release and in effect make them “bigger.”
• Prefer process over people (and trusting them). Increase non-value-add scrutiny and reporting.

There is a persistent misunderstanding about continuous anything being only an IT engineering practice

01

At the enterprise level, continuous anything focuses on:

• Visibility of final value being provided in a high-quality and expedited manner
• Ensuring efficiency in the organization’s delivery framework
• Ensuring adherence to established governance and risk mitigation strategy

02

Focus of this blueprint

At the product level, continuous anything focuses on:

• Reliability of the product delivery system
• Use of scientific evidence for continuous improvement of the product’s delivery system
• Orchestration of different artifacts into a single whole

03

At the functional level, continuous anything focuses on*:

• Local functional optimization (functions = software engineering, testing, application design)
• Automation of local functions
• Use of patterns for standardizing inputs and functional areas

*Where necessary, practices at this level have been mentioned.

Related Info-Tech Research

Implement DevOps Practices That Work

• Be DevOps, rather than do DevOps. DevOps is a philosophy, not an industry framework. Your organization’s culture must shift toward system-wide thinking, cross-function collaboration, and empathy.
• Culture, learning, automation, integrated teams, and metrics and governance (CLAIM) are all critical components of effective DevOps.

Automate Testing to Get More Done

• Optimize and automate SDLC stages to recover team capacity. Recognize that automation without optimization is a recipe for long-term pain. Do it right the first time.
• Optimization and automation are not one-hit wonders. Technical debt is a part of software systems and never goes away. The only remedy is constant vigilance and enhancements to the processes.

The seeds of a good release are sown even before work on it begins

Pre-release practices such as requirements intake and product backlog management are important because:

• A standard process for documentation of features and requirements helps reduce “cognitive dissonance” between business and technology teams. Clearly articulated and well-understood business needs are fundamental ingredients of a high-quality product.
• Product backlog management done right ensures the prioritized delivery of value to stakeholders. Features can become stale or get a bump in importance, depending upon evolving circumstances. Prioritizing the backlog is, therefore, critical for ensuring time, effort, and budget are spent on things that matter.