Bringing Management in from the Release Pipeline Cold
Transitioning an enterprise to a different software development model is always a cultural journey, whether that is from a legacy waterfall to an agile, lean, CI/CD or even DevOps approach.
In a legacy model, a visionary in the business sees the need for change and passes this on to other members of the business who begin the journey under defined timelines such as “plan,” “estimate,” “schedule,” “test” and “deliver.” Within these, team members hold defined roles such as business owner, functional owner, test and so on. In transitioning to the Scrum/Agile world, however, the roles change dramatically; the work becomes more isolated, the timeline becomes shorter and each team works independently in order to go and deliver as fast as possible.
The Big Chill
This isn’t a bump-free road — communication lines that were once so defined now become blurred. The typical management tie to the team is suddenly gone and the role of updating the product owner with that 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 a challenge 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 is made 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, 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 this one step further, after Agile comes continuous delivery and DevOps: effectively 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.
Breaking the Ice
So, how does an organization 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 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 here 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 instill continuous improvement; in order to go faster, however, these pieces still all need to be put together.
Navigating the Blizzard
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 optimized in order to move the whole system forward. These tools can help organizations decide which team structures work best within the company, provide a historic look at metrics over time to see where improvements are being made – and in turn, management gets better as well as the quality of the delivery process.
In essence, the release manager acts as the “scrum master of product owners”, navigating technical and business issues that span all delivery pipelines. They take over the role of aligning the business, product owners and scrum masters. To help with this process, enterprise release managers should also look to test environment managers to help support autonomous teams. They provide a self-service environment to manage both internal and cloud-based preproduction environments as well as demand and supply, quality of environments and supply, therefore helping along the way to bring about overall application delivery enhancement.
Feature image via Pixabay.