Making release management feel valued again

From the cold of winter to a warmer climate – making release management feel valued again

The typical journey from one software development model to another always requires a shift in perspective, with one or more members of the businesses delegating out different roles to other employees to suit where their strengths lie.

This approach is beneficial regardless of what the move from a legacy waterfall is going to. However, when a business chooses to move into scrum/agile, the job roles that are needed can be very different.

Teams often function in isolation to focus all of their attention on their own individual tasks, helping to ensure that the results are delivered as quickly and efficiently as possible.

How release management gets left in the cold

However, this isn’t an easy road to navigate – communication lines that were once so well-defined can become blurred. The typical management tie to the team is suddenly gone and the role of updating the product owner with the status of a project now lies with the scrum master – a technical role.

Agile teams are autonomous silos; that’s the benefit and the downfall, simultaneously. Each team works independently on purpose, but this makes it challenging to truly know where things are until they get to production – and these teams are still expected to deliver against one another. The question here is: where does management fit into all of this?

This problem becomes even more complex when scaled in a large enterprise. Going agile means compiling a bunch of fixed iterations into the schedule, but they still have an overall delivery schedule for the whole set of functionalities that has to be adhered to. Just because the methodology has changed, that doesn’t mean the mainframe by which the whole project is dependent upon has too.

There are still legacy components and traditional teams that the new system has to be coordinated around, and even once that has been achieved, the new system needs to successfully integrate with testing activities. For example, every release has compliance issues; enterprises need to do a security audit and approval process with operations and management before any new code is issued to end-users.

Taking all of this one step further, after agile comes continuous delivery and DevOps: essentially the ‘wild west’ of cultural change when compared to traditional models. Teams are given complete control over their direction; they deliver on demand, there are no more iterations, and the wider business is even further removed from tracking activity. In effect, management is left out in the cold.

The ice-breaker of a ‘bottoms up’ approach

So, how does an organisation overcome this management problem? The answer is to switch thinking from a ‘top down’ to ‘bottoms up’ approach. A change in leadership style that moves the focus away from commanding and directing the team to empowering them to work autonomously – but also in connection with wider business goals – is key. Management plays an integral role in making sure teams are talking to each other and collaborating effectively.

Bringing management back into managing development is achieved through the coordination of multiple delivery pipelines, and this is no easy feat. Coordinating when the release goes live against the release schedule as well as other factors such as change advisory boards and governance, compliance and testing issues means that management still has a lot of work on its hands.

Essentially, the release manager sits between the executive side and the individual teams and looks at ways to instil continuous improvement; in order to go faster, however, these pieces still all need to be put together.

Creating a warmer climate for all

In order for management to be successful, the manager needs to be looking at all the metrics of all the tools and aggregate them together. To do this manually would be painstaking, therefore tools that allow the consolidation of all features in the system – in real time – is the true enabler of continuous improvement.

What changes, then, is that the role of release management becomes more of a ‘management by exception’, whereby managers act like investigative reporters – looking for problems and areas that can be optimised in order to move the whole system forward. These tools can help organisations decide which team structures work best within the company and provide a historic look at metrics over time to see where improvements are being made – in turn, management as well as the quality of the delivery process improves.

Release managers therefore play a key role in the process of transitioning from legacy to a new software development model, as the ones who oversee the entire range of delivery pipelines. Part of making this as efficient as possible is having release managers lean upon the test environment managers for the support that the autonomous teams need, and thereby providing a suitable environment to manage the entire delivery lifecycle.

With these vital team members in place, the overall application delivery will be smoother and faster than ever before.

Jeff Keyes, is a director at Plutora