If you've been a release manager you'll understand that you sit between two groups:

An operations group tasked with accepting and supporting a software release. This group wants a predictable process, they view releases as incidents to be managed, and they answer to a business that wants predictability and accountability.

One or more development groups tasked with creating software to be released. These groups tend to be more diverse. You might have one development group that is using bleeding-edge technology to create a next-generation website that is more research than development, and another group developing applications against Oracle that is more predictable.

What you understand is that you have to bridge these two groups - groups that use different terminology:

• When operations talks about a customer for IT Service Management they might be talking about development.

• When development groups talk about a customer they are likely referring to a real customer of a large website or a system.

Development and Operations use very different tools:

• When an operations group such as a help desk needs to keep track of changes to production they might use a change management database or an incident response system like ServiceNow or BMC's Remedy. Most of these tools have standard, predictable forms that feed into a well-defined process.

• When a development team needs to track down changes in a release they might refer to a source repository in Perforce or Github. These teams will discuss architecture and other issues in free-form discussion threads in Atlasssian's JIRA.

These teams use different language, they operate with different tools, and it is your job to coordinate with both of them. So what do you do? Well, you have a choice. Here are your options:

1. You can side with operations and model your releases as a strict ITSM-focused process. If you choose this path you'll likely have to educate some of the senior members of your development teams on ITIL and what it means to approach IT from a service management perspective. Following a strict ITSM-focused process will absolutely reduce risk, but at the cost of agility. The amount of up-front planning and design required by heavy IT process can suck the air out of the creative, collaborative process that has come to characterize most product development groups.
2. You can side with development and ask your operations to embrace a more agile, DevOps-focused view of software delivery. In this approach software isn't a service to be managed for an internal customer, it's a shared responsibility of both operations and development to work together to create systems to support software that can be deployed continuously. While this is a popular trend, the largest organizations supporting the most critical systems can't afford to expose the business to the unpredictability and risk that often accompanies a transition to DevOps. Most mission-critical organizations that have adopted a more agile approach to development require a "firewall" around such groups and software releases, transforming DevOps to groups that speak ITIL and ITSM.
3. You can use a tool like Plutora which provides hooks for both of these views. With Plutora you can integrate systems that track project status in development-focused tools like Atlassian and then turn around and create a CRQ in BMC Remedy - all without asking either group to adapt to the other's process. It is this third way of operating that has come to characterize effective release management.

Release management is the bridge between operations and development. You can think of it as a heat shield protecting a release during the reentry process from a DevOps orbit to a more manageable IT service management approach that the largest companies have come to expect.

If you don't want to bother your development groups with talk of BMC Remedy and IT portfolio management, and if you want to isolate your IT service management teams from the free-form creativity of agile development process, Plutora is the purpose-built tool designed to act as an organizational adaptor.

Plutora facilitates communication and collaboration between different groups involved in the release management process because it was designed by people who have experienced both sides of this equation. Plutora captures the decades of experience our release managers have had delivering agile software to the largest, most risk-averse companies in the world.

Our recommendation is to take the third option. Provide the necessary tools that can facilitate communication across this divide without requiring either side to adopt the tools or terminology of the other.