Aligning product owners and business stakeholders to a release management strategy

I have found that the hardest part of getting a release management practice instituted is in getting the business alignment. Development teams often recognize the need to develop a release management strategy. If they are strong technically, they may look to mature their DevOps practices to support continuous deployment if it makes sense for their business. If not, they may build continuous integration and delivery capabilities, then look to implement a more traditional release and deployment strategy.

Even when product owners and stakeholders are involved in formulating the strategy, they often struggle adhering to this in practice.

It's not always their fault. Product owners have their customers to satisfy. Some customers can be very demanding, or the product owner may just be feeling the pressure for high customer satisfaction. So for the purpose of this post, I'm going to assume that there are rational business reasons for a product owner's need for flexibility in the release practice and this isn't just a product owner behaving badly. If it is, here are my suggestions on handling difficult product owners.

Release Management Anti-Patterns

What are some of the issues that misalign business need with a development team's release management practices?

• There's a problem and I need a hotfix
• Users are complaining and we need an improvement fast
• There's a new marketing event scheduled and the app needs
• We're driving a price increase and need a big feature release 
• How can we make a big workflow change easier for users 

Let's look at these one by one and consider mitigation strategies

There's a problem and I need a hotfix

The technical solution is to make sure your branching and testing strategy supports hotfix branches. See one example. But the bigger problem is the cost to implement the hotfix especially if the product owner is prone to request many of them. First, it disrupts the development team to branch, fix, and deploy the hotfix. Second, it requires at least two rounds of testing; one when the hotfix is deployed and a second it is merged into the main development branch. Here's what I suggest

• Make sure the product owner understands the tradeoff by reducing the commit in the current sprint to support the hotfix.
• Illustrate and build awareness around the added testing costs
• Measure and benchmark the behavior (# hotfixes / time-period), communicate the impact to the roadmap, and single out product owners that have higher hotfix requests.

Users are complaining. We need an improvement fast

This is more likely to happen with internal applications deployed rapidly and where users may have different workflow needs. It may also happen if release cycles are too long and users prefer seeing more incremental changes. Suggestions

• Make sure to capture and reflect if the needs of a specific user group were missed.
• If this happens infrequently, consider scheduling minor releases before going onto your next major release. See more specifics on major/minor releases.
• If this happens frequently, consider shortening your release cycle.

There's a new marketing event and the app needs

This is more specific to products or customer facing applications. Ideally, marketing events should be considered when developing the overall product and release roadmap. That being said, it's fairly common for an agile marketing team to find new opportunities requiring changes to the release schedule and feature prioritization. Suggestions:

• Make sure the marketing team is engaged when developing roadmaps and release schedules.
• Develop a communication/collaboration process so that you are informed as early as possible when a new marketing opportunity may impact the roadmap.
• Make it easy for product owners to update priorities in the agile backlog.
• Develop a branching strategy that can accommodate these opportunities.

We need a big feature release

This shouldn't really be an ad hoc business decision and this business strategy needs to be reflected in the product roadmap and the release strategy. If it comes out of nowhere, it probably means that there is a shift in business strategy, or this may be a onetime event. Suggestions:

• Make sure the team understands whether this a shift in business strategy that should require a review of the roadmap and the release strategy, or if this is a onetime event.
• Consider having shorter and incremental "alpha" releases for internal users and longer "go-to-market" releases that are customer facing.

Can we make a big workflow change easier for users

This suggests that you have the capability to roll out incremental improvements to a subset of the user community, or, have the ability to do A/B tests when rolling out new capabilities. Suggestions:

• If you need to roll out changes to different customers or user communities incrementally, then this capabilities has to be developed within the application. Add it to the backlog and develop a rollout strategy based on the application's authentication groups and roles.
• There are many third party tools to support A/B testing or you could build the capability in house. If A/B testing is needed, just make sure it's developed as a horizontal capability so that it can be leveraged across multiple applications.

If you send me any other anti-patterns, I'll look to update in a future post.