Is release management part of your agile practice? Are you able to tell stakeholders target dates for your next application releases? Are you tracking how often your teams hit these targets and which releases hit the targeted scope and quality?

I’ve asked this question of many teams and hear various answers. Some are practicing continuous delivery, others attempt to formalize release plans at the start of a development cycle, and others only formalize releases when they are near ready to deploy to production. The teams that are in the most dire straits are in a constant churn of patch releases because of last minute requests from product owners or because they need to fix post-deployment defects.

The Importance of Release Management

When I speak to CIO and technology leaders, one of my key messages is that they need to take on practices that mimic software companies. You may not be selling software as part of your business, but the more customer facing application development you do, the more you need practices developed and matured at software companies.

So imagine if one of your software vendors did not communicate their roadmap and schedule of major and minor releases? What if they didn’t publish the schedule of general availability of these releases and the overall impact to users when upgrading to them? What if these releases have a history of disrupting or inconveniencing users because they have frequent defects or other unanticipated impacts? Software vendors that operate with these issues are branded as unreliable, unstable, or difficult to work with and are likely to lose customers over time.

Your customers and business leaders have similar expectations. They expect predictable, reliable releases where they can manage the changes and impacts to business operations or customer experiences.

What Delivery Plan Makes Sense for your Business and Technology?

Your release strategy has to align to how impactful changes are to end users and to the business model. It is strategic decision and companies should target a methodology based on the nature of the business and industry. For example, high profile B2C, SaaS, and enterprise software companies will employ different release strategies depending on how new functionality affects customer experience, functionality, workflow, APIs, and integration.

Your release strategy also depends on technical capability. How frequent you can reliably release code into production depends on the level of automation in your testing and deployment procedures and the overall complexity of your application and data architecture.

Does continuous delivery make sense for your business? If not, how can you get agile application development teams to go from adhoc releases to more reliable release management practices. I will explore answers to these questions in my next posts.