Release Management

Disciplined Agile Release Management

The release management process blade encompasses planning, coordinating, and verifying the deployment of IT solutions into production.  Release management requires collaboration by the IT delivery team(s) producing the solutions and the people responsible for your organization’s operational IT infrastructure.  In the case of organizations with a “you build it, you run it” DevOps mindset these people may be one in the same, although even in these situations you will often find a group of people responsible for governing the overall release management effort.

This article is organized into the following topics:


Why Release Management?

There are several reasons why enterprises adopt release management strategies:

  1. They have a complex operational infrastructure.  The greater the complexity of your operational infrastructure the greater the risk that the release of new functionality into production will break something, hence the greater need for release management.  Operational infrastructures become complex when there are many technologies in place, when there are different versions or configurations of those technologies, and when solutions are highly coupled to one another.  Ideally you should strive to pay down this technical debt.
  2. There are many delivery teams working in parallel.  Your operational infrastructure is a shared environment, or more accurately a collection of shared environments, that your IT delivery teams deploy into.  As the number of delivery teams rises, the greater the chance that their release efforts will conflict with one another.
  3. IT delivery teams need help to release their solutions into production.  Your IT delivery teams, particularly new ones, may not have much experience deploying solutions into your operational environment.  Your release management team can coach your IT delivery teams in effective release strategies, can guide them in ensuring that their solutions are production ready, and can help in the planning and coordination of their release efforts.


The Release Management Process

The following process goal diagram overviews the potential activities associated with disciplined agile release management.

Release Management Goal Diagram

The process factors that you need to consider for release management are:

  1. Plan IT release schedule.  Your organization’s overall release schedule needs to be planned and communicated.  Many organizations have blackout periods where teams are not allowed to deploy into production (for example, many retail organizations will not allow non-critical production releases near the Christmas holidays).  There are many strategies that organizations may choose to adopt when it comes to scheduling releases, including release trains, release streams, ad-hoc releases, and release windows.
  2. Schedule solution release.  The release of an individual delivery team’s work needs to be scheduled so that it does not conflict with the releases of other teams who want to deploy into the same operational environment.
  3. Manage infrastructure configuration.  The release management team will work closely with your operations team, in fact they are often members of your operations team, to perform configuration management of your operational environment.  To safely deploy into production you must know what is currently in production and how those hardware and software elements depend on each other.  The more complex your operational infrastructure, and the more IT delivery teams you have, the more important this process factor becomes.
  4. Determine production readiness.  Part of the release process is to verify that the solution is ready to be deployed and that the stakeholders are ready to have it deployed to them.  The bigger and more infrequent your releases, the more this becomes an issue.
  5. Support delivery teams.  The release management team, when a separate one exists, will work closely with the IT delivery teams to help them deploy successfully.  This help may take the form of coaching the team on deployment techniques, on planning, and even working with them to automate their deployments.  The release management team will often help with deployment testing, the verification after the fact that a deployment was in fact successful.
  6. Govern releases.  Your organization’s overall release efforts should be governed, ideally with the aim to streamline those efforts as much as possible.  This governance will include the development of policies and guidelines pertaining to the release process as well as the identification and collection of pertinent metrics.  This is part of your overall IT governance efforts.


Workflow With Other IT Teams

The following diagram overviews the major workflows that people performing the Release Management activity will have with others.  One interesting aspect of this diagram is that it shows that many IT delivery teams, which may be following different lifecycles or even tailored versions of one of the disciplined agile lifecycles, potentially feed production ready releases into the release management process.  In some organizations you may have a separate release management team doing this work.  Other organizations, particularly those that are well on the way to adopting a disciplined DevOps strategy, will often choose to have the delivery teams themselves do the release management work via a “you build it, you release it, you run it” mindset.  For now our focus is on the activities surrounding release management, not on the potential organizational structures to support it.

Disciplined Agile Release Management Workflow

The following table summarizes the workflows depicted in the diagram.

Process Blade Process Blade Overview Workflow with Release Management
Continuous Improvement Addresses how to support process and organizational structure improvement across teams in a lightweight, collaborative manner; how to support improvement experiments within teams; and how to govern process improvement with your IT department. Your continuous improvement efforts should result in improvement suggestions gleaned from other teams that whoever is doing release management can learn from.
Enterprise architecture Addresses strategies for collaborative and evolutionary exploration, potential modelling, and support of an organization’s architectural ecosystem in a context-sensitive manner. The enterprise architects will produce a technology roadmap that will reflect the current operational environment as well as the expected direction that it will head in. This information will be used as input into decisions regarding any technology strategies to support release management activities. Release intelligence, measures surrounding your release management activities (such the number of releases put into production, the time/cost of each release, results from deployment testing, and so on) are made available to enterprise architects to be used as input into their decision making processes.
IT Delivery Addresses how to develop solutions in a disciplined agile manner. This includes the four lifecycles – basis/agile, advanced/lean, continuous delivery, and exploratory – supported but DAD plus the program management blade (effectively a large team following one or more of the lifecycles). Your release management strategy will need to be able to support the range of development/delivery teams within your organization. Because each team is potentially working in their own, unique manner, it implies that release management professionals (if any) will need to be sufficiently flexible to work with these teams in manners that reflect their chosen strategies.
IT Governance Addresses strategies for consolidating various governance views, defining metrics, taking measurements, monitoring and reporting on measurements, developing and capturing guidance, defining roles and responsibilities, sharing knowledge within your organization, managing IT risk, and coordinating the various governance efforts (including EA governance). The IT governance team will provide guidance to all IT teams, including anyone performing release management activities. Release intelligence will be provided to the IT governance team so as to provide insight into the effectiveness of the release management effort.
Operations Addresses how to run systems, evolve the IT infrastructure, manage change within the operational ecosystem, mitigate disasters, and govern IT operations. Your operations group will provide operations intelligence (a range of measures, including current system statuses) that will be used to guide release management decisions. For example, if a platform is currently down (perhaps it is being upgraded), then you would likely be blocked from deploying into that environment until it is available. The release management activities will produce release intelligence measures that operations staff will use in their decision making around the consumability of aspects of the operational infrastructure. For example, they may be interested in knowing the level of effort required to deploy into various platforms.
Portfolio Management Addresses how to identify potential business value that could be supported by IT endeavors, explore those potential endeavors to understand them in greater detail, prioritize those potential endeavours, initiate the endeavours, manage vendors, and govern the IT portfolio. Your organization’s portfolio management monitoring activities will take advantage of any release intelligence made available to it.


Release Management and DevOps

Release management is an important part of your Disciplined DevOps strategy. Having said that, many IT departments are still in their early days of adopting a DevOps approach yet still effective release management.  The implication is that the way that you approach release management will vary depending on how far down the DevOps adoption path you are.  For example, with no DevOps in place at all your release management activities are likely to be performed by a team that is completely separate from your IT delivery teams.  When you are in the process of adopting a DevOps mindset release management is likely to be a collaborative effort between the IT delivery teams and the release management team.  When you have fully adopted DevOps strategies release management is mostly performed by the delivery teams themselves.


Have any Question or Comment?

14 comments on “Release Management


Interesting article, Thank you. I am also looking for release management team strategy, techniques, tips, tools and process:) let me know if anything which will help me.


Thang Phan

Good article. Do you have any recommendation on Agile Release Management book? Need much more details to define a process.


Thang, good question. I really like the book Release It! from a few years back but don’t have a specific recommendation for an agile-specific book. Would be interested in hearing about one though.

Thang Phan

Yes. Our client is doing greenfield development with 400+ team members and immediate plan for full automated CICD. No release (whatsoever) process in place yet. Love to hear your recommendations.


Thang, it’s one thing to have plans and another thing to execute them. Here is the typical learning/process improvement lifecycle in this case:
regression testing ==> continuous integration (CI) ==> continuous deployment (CD)

The hard part is the first step, getting your act together on regression testing. This can often require a large investment in time and money to get an appropriate number of regression tests in place. This in turn often requires the organization to invest in their people to pick up testing thinking and test automation skills.

Adopting CI and then CD, which often occur at pretty much the same time, tend to be much easier efforts than addressing the dearth of regression tests and regression testing skills.


If DevOps has not been fully adopted, then who(Prod Mgmt, PMO, Dev, QA) owns this release management process?


This would depend on your organization. Typically it’s the operations department but I’ve also seen it as a responsibility of development.

Bharat Patil

I would suggest someone who understands the whole end to end process including operations. The person in this role should not have a conflict of interest between projects and operations/service as they need to take decisions which is right for the whole platform/systems.

The person should be empowered to gate projects as well as push for operational improvements by as outlined above providing ‘release intelligence’. The person should be reminding everyone of the technical debt, again as outlined above.

Maran Santhalingam

I have been working as release Manager as many years. I seen in the industries , Release Managers manage releases from DEV, UAT , Stage, and Production.
But some places they have mind set of deploying to Production is Release Management. Your thoughts on this??


This depends on the organization. I would hope that release management is there to help throughout the entire deployment process.

Bharat Patil

If there is an intention to improve life cycle end to end and move towards more releases and DevOps then Release Management should ideally be end to end.

If it is just deploying to production then it is more of a gating role rather than providing some of the things mentioned above like coaching, governance, reduction of technical debt, etc.

Ras Bokhari

What kind of Release Management Metrics would you recommend for Governance. This is something I’m constantly working on finding good quality metrics of release management. There are plenty of metrics for infra, devops, networking, for RM, you have to rely on some of these metrics, but mainly look at QA metrics.



The quick answer is it depends on what you’re trying to improve. Is it time to market? Is it to reduce the number of release collisions? Is it to increase the frequency of releases into production? Your improvement goals will drive the metrics you collect.

Bharat Patil

While I have not seen any industry wide standard metrics, one thing that comes to mind out of my own experience is time spent in each phase: Dev & Test, Integration Testing, Operational Readiness Testing. Even Demand time can be included.

Defects that have “escaped” is a metric to measure as well. We used this to identify left shifting testing, especially UAT testing. Move towards defect prevention than detection.

Release management done properly in my opinion should look at the whole development life cycle not just the cut-over or transition into production.


Leave a Reply to Scott Ambler Cancel reply

Your email address will not be published. Required fields are marked *