Changing Your Release Process: That’s the Real Revolution

Years and years, decades: that’s how long some of the release processes we support have been running. In a sector that is so focused on the newest technologies it can be challenging to design systems that last more than a few years, but when you support software development at the largest scale you notice something: software changes, teams change, management changes, but one thing almost always remains constant – your release process.

Your release process is the governance structure that the organization has set up to organize and collaborate together. And, once you establish these patterns they are difficult to change.

Release Processes are Governance

A release process is half technology and half governance, and the mechanism that teams use to validate, promote, and deploy systems to production – this is the pulse of the organization.   The contracts different teams develop over the years, and the processes designed to preserve uptime and reduce conflict all of that is governance, and when you decide to make a change to these processes it’s almost like you have to convince a department to start a revolution.

When you stand up in a meeting an announce that you are shuffling off the reins of an oppressive release process there will be a few people in the room who will secretly want to preserve this system.  You’ll need to have a tool at the ready to help identify inefficiency and support the transformation to a leaner, more efficient software organization, and you'll need allies along the way.

Don’t Blunder into a Revolution: Conspire

When it comes to planning a revolution, there’s only one verb to use: “conspire.” What’s the definition?

“make secret plans jointly to commit an unlawful act”

Don’t worry.  When you change your release process and make it more efficient and when you start granting exceptions for more Agile projects no one will be “harmed,” but many will see this change as “unlawful” and somewhat dangerous.  You’ll be met with responses like, “We can’t let that team release whenever they want to.” But, in some organizations there's no way to move forward unless some of the unnecessary checkpoints and meetings are cancelled.

Across all industries we've been running heavy, process-oriented releases in an effort to mitigate release risk, and we're still operating some of the largest releases with processes developed in the 90s.   Plutora was created because there has to be a better way.  Instead of assembling release status from spreadsheets a release manager should be able to mine the several systems the organization has stood up to track software progress. Teams should be enabled and empowered to move faster without having to sit through mindless process meetings that were created before tools like BMC and Jira had APIs or even existed.  It's time to upgrade our approach to release processes and Plutora is that upgrade.

To change a release process the first step is to identify who in your organization is thinking the same thing.  Which projects will gladly serve as internal champions and how do you make progress visible to management (Hint: Use Plutora to track releases.)