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:
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.