Release Readiness: Being Prepared for Change

Cloud products change frequently. New features, new frameworks, new user interfaces, bug fixes… change is constant. It takes a lot of planning, cross-team communication, and testing to prepare for a software release. Simply “test then deploy” isn’t enough. Release readiness is the practice of preparing the entire team and your customers for changes. In this blog, we’re going to discuss some of things you can do to prepare for a software release.

The Importance of Release Readiness

Release readiness gets everyone on the same page and aims to make each software release smooth and painless. Release readiness should be baked into the overall process of developing and deploying software – it’s effectively an extension of the software development process. The absence of a release readiness plan can lead to frustrated customers, an ill-prepared customer-facing team, and possibly even major incidents that can have a negative impact on the business.

If you’re not already practicing release readiness, start now by holding a “hand off” meeting where the development team gets other team members up to speed on what’s changing. By involving customers-facing roles and marketing early on, potential issues and questions can be raised about the upcoming release that may not have been thought through yet. It’s this cross-team collaboration that makes for a smooth and painless release.

Here are some of the things to keep in mind as you plan for a release…

Test, Test, Test

This should go without saying, but you need to make sure testing is complete before you release something. How big is the change? Does it touch a lot of other parts of the application? Depending on the nature of the change, different types of testing will be needed. A release shouldn’t happen until you’ve satisfied your Definition Of Done. If you don’t already have a definition of done, start there and then come back to this article.

Document The Changes

Create a release readiness handover template that you can use for every software release. This template should include details on what exactly is being released, why it’s being released, who is impacted, who worked on the project/feature, how it works, and how to troubleshoot it.

Communicate Across Teams

Customer support, sales, and marketing all need to be educated on releases. Support needs to be able to support the change and part of that means updating existing documentation or creating new documentation. Sales need to have a strong understanding of the change so that they can speak authoritatively around the product. And marketing needs to be able to write blogs, update the website, and host webinars. Don’t leave your team in the dark on a release – give them a seat at the table before the release happens. This brings me to the next point…

Educate Your Team Early – But Not Too Early

Be timely with your release readiness efforts. Bringing in other teams too late can result in missed opportunities for a successful release. If you’ve already released something to customers without preparing the rest of your team, things are bound to go wrong. Your marketing team will be scrambling to produce content, and your support and sales teams are going to get blind-sided with questions they don’t have answers to. But bringing in these teams too early can be unproductive, cause confusion, and raise pre-mature questions that slow down the development process. With release readiness, it’s better to loop in the rest of the team earlier rather than later, but you’ll want to find a good balance.

Rollout In Phases

So long are the days where software teams would work tirelessly – often for years – on a project, package it up on a CD-ROM, and distribute to stores all around the world. The cloud allows us to release more often, faster, and to certain segments. Phased rollouts allow you to test the waters and make sure the release is on track for success. Start with a small percentage of users for a day, or a week. Keep in sync with your support team – if something is going wrong, they’re going to know about it. Increase the percentage over time as you feel comfortable. Check out LaunchDarkly or CloudBees to help with phased rollouts to your customer base.

Publish Release notes

What good is releasing a new feature if no body knows about it? You’re doing your customers a disservice if you’re not publishing release notes. Keep a change log, whether in a blog, in your app, or in your help site to communicate with your customers about changes to your software. Consider giving your customers a heads-up if you have a big change you’re about to release. Setting expectations with customers can go a long ways, especially if you’re changing a major part of the application. Headway, Beamer, and Releasenotes.io are all tools that help you publish and share your release notes.

Closing Thoughts

A good release readiness plan is part of a quality-driven and customer-centric culture. Take it slow, don’t get wrapped up in the excitement of the release at the expense of your customers and your team. Bring in other roles as you prepare for the release and revisit your release readiness plan from time to time. Finally, celebrate! Building software is a lot of work, acknowledge that and celebrate your successes.