This post could have also been titled “Questions Release Managers should be Prepared to Answer.” Imagine you report to a VP who is asking you questions about how prepared you are for releases and how you are addressing a set of emerging issues. Everyone who has participated in release management understands that software change is risk and you’ll never be working under ideal conditions, but the difference between a good release manager and a great release manager is how that manager mitigates risk and manages unpredictability.
If you are a release manager, the key to success is knowing how to respond to emails like these from your manager. Release management has grown more challenging: the average size of IT portfolios increases every year and the frequency of releases mean that release managers find themselves the center of attention. Executives are starting to notice that release management can make the difference between success and failure and they are starting to ask difficult questions like these:
Do we have a plan for a rollback? and, have you rehearsed this plan on a staging environment? Before we suffer through another debacle like the last release I want to know if you’ve anticipated failure scenarios. The fact that it took us so long to recover during last week’s outage was a “black eye” for the whole department, and the executives I answer to were surprised that we didn’t have a rollback plan. Can you show me what our plans are for rollback?
Can you show me a report of success rates for releases broken down by application team? I know that application teams bear some responsibility for failed releases. I want to know which teams have the most problematic history with releases and I want to follow up with each Director on the root cause for these problems. If there’s a team causing problems because they are using production as a testing environment then I expect you to keep track of that for me. It’s no longer acceptable for the site to just “stop working” every time we run a release.
How much downtime can be attributed to the release process? Management understands that upgrades and maintenance can cause some downtime, but we’re seeing consistent problems every time even a minor fix is deployed to production. Again, I understand that you are responsible for the release process and not the quality of the software (that’s QA’s job and I have another email to the QA Director similar to this), but if it’s release-related than I want a plan from you detailing what is being done to ensure that we’re not introducing avoidable downtime.
How much time is our department spending on the change control process? I’m not going to be able to do away with the change control process and the CAB meetings, but if you can give me a detailed report of how much time we’re dedicating to it then I will have an argument to stand on the next time I’m asked to defend you for taking the necessary shortcuts. CAB meetings are a real hassle, especially as we move to daily minor releases. I’m talking to the CEO next week about simplifying this process, and it would help to have these numbers assembled.
How much of our release is automated? and how much requires manual effort? Our QA director is complaining about how late the QA team has to stay up to support post-release verification, and the engineers we’ve recently hired have all identified our release process as being surprisingly manual when compared to our competition. If we’re going to be performing more frequent releases you need to provide me with a plan that targets 90-100% automation. I understand that there are parts of the process that might not lend themselves to automation, but I need your team to focus on more critical items not this robotic, release work that keeps our people up until 4 AM. What I want to see is a system that is fully automated across the board.
Is your team looking into how we handle configuration management? From my perspective our process focuses on copying the right software to the right systems at the right time, but our configuration story still feels very manual. Individual teams are making configuration changes in production without oversight. I’d like our release management effort to have end-to-end control over production state because I’m not comfortable with the current set of unknowns. Research the latest best-practices for configuration management and write a report about the current best practices and how we align with emerging standards.
Common themes in these emails are transparency, tracking, and automation. VPs and senior IT managers are looking to release management to address waste and inefficiency and to solve some of the most difficult problems they face. If you find yourself facing similar questions Plutora’s Release Manager is a perfect tool to help answer them. With Plutora you can send your management a clear message that you are working toward a solution and measuring the appropriate metrics. If management is going to be paying closer attention to release management plan to provide them with solid answers backed by Plutora Release Manager.
The post VPs to Release Managers: “Do We Have a Plan?” appeared first on Plutora.