2020-05-28 00:11 — By Erik van Eykelen
If you're new to release management you can be overwhelmed by the amount of jargon, complex processes, and information overload. This article helps you focus on ten things to know that matter most. Let's kick off with a definition of release management:
Release management is a relatively new but rapidly growing discipline within software engineering. As software systems, software development processes, and resources become more distributed, they invariably become more specialized and complex. Furthermore, software products (especially web applications) are typically in an ongoing cycle of development, testing, and release, often running on evolving platforms with growing complexity. Such systems require dedicated resources to oversee the integration and flow of development, testing, deployment, and support.
Establishing the definition of ready is one of your most important tasks. You must ensure that the development team, product manager, and your customer are all on the same page. You base the definition of ready on specifications, proposals, roadmap, or any other written documents that define what a specific release must do.
Make sure you update and communicate the definition of ready throughout the development phase, certainly when the definition is undergoing changes. By resending/reposting the definition of ready often you prevent the dreaded "this is not what we thought we would get" discussion with customers.
A product can be marked ready only when it passes all tests. Ensure you collaborate with your test manager on the testing specifications and include them in your definition of ready. If you don't have a test manager then this responsibility lies with you, your development team, and your product owner.
Chances are your product is being designed, developed, tested, and deployed by different people, possibly working from different locations. Your first order of business when you start out as a release manager is to have one on one conversations with (preferably) everyone. Meet them in person, or schedule a video call, to establish a relationship. Try to cover mutual responsibilities, experience, and project details that are of interest to you.
Once you've done your round of introductions, pick a couple of co-workers who you think are best suited to become your status providers. Usually these are experienced folks with an ability to separate details from the big picture, with an eye for detail, and clear sense of responsibility. Ask them whether it's OK to set up a weekly call/meeting/report to assess (their part of) the project status.
Try to avoid busying yourself predominantly with processing, and relaying, information from others to others without establishing whether what you're being told is factually correct. You can easily spend your entire working week inquiring about the status of hundreds of backlog items, calling up people, or sitting in meetings without actually ever seeing or touching the product.
Instead, compile a list of 10 or 20 essential aspects of the release you're working on and personally assess the status and quality. How does it look? Is the wording clear? Is design/UX/UI following the style guide? Does it work properly? Is it clear enough to be documented? Is it a joy to use? By taking the responsibility to personally verify important elements of this release you'll create a repeatable litmus test for your team's ability to ship a solid product.
Release management often has its own set of internal key performance indicators, which differ from the company's broader set of KPIs. Examples of release management KPIs are decreasing the number of regressions or bugs introduced by new releases, or fewer post-release support issues, down to very detailed indicators such as a change in the number of spelling mistakes or translation errors.
Over time you will know which internal KPIs matter most to the project you are responsible for. Obsess over those details by personally verifying that none of the indicators are showing a trend in the wrong direction. Address the problems with the product owner, tech lead, or (if you're in small team) directly with the responsible engineer, designer, or other role.
As a release manager you will write a lot. Besides the definition of ready, you will work on a planning document, release notes, testing reports, weekly status reports (team, customer, management), best practices, and internal KPIs as discussed in the previous point.
Don't wait until the last day to start working on these release artifacts. Start a release cycle by writing down what you expect from your team, update the necessary documents throughout the project, and write a post-release memo in which you collect the conclusions from the retrospective meeting you should conduct with the team.
Make sure you include budgetary details into your reports: still within budget? Unexpected costs? Who pays for them? Don't wait until it's too late to discuss financial issues.
People are busy, wear different hats, have to switch "context" between various projects, and have lives outside work. Do not expect that your team members, or even your customers, hold all essential dates in their heads. It is your responsibility to communicate crucial dates early and often. By doing this you avoid the "but I assumed ..." and "if I would have known ..." discussions that so often sour the conversations about planning and deadlines.
The customer is going to use (and rely on!) the product you are about to release. They will use every nook and cranny of the product. Click every button, enter any kind of data they deem necessary to get their work done. Do you know your product as good as the customer knows it?
Take the time (a whole day if necessary!) to walk through every screen, every dialog, and every form in your product. Make notes or take screenshots. Start with a pristine account, then use a fully loaded account with actual data. Read the handbook or documentation if available. Then read the release planning to check what's about to change. By doing this you ensure you know as much about your product as the customer.
After a release has been shipped the next release will be coming up. It's easy to fall into the trap of considering past releases as done and dusted. You're missing out on essential information though by ignoring what can be learned from the post-release phase.
Start by contacting the customer. Does the release work well? Were the release notes adequate? Which issues did they run into? Corroborate their feedback with data from your own support department. How would they score this release? (using a simple 1-10 score, NPS, or whatever your company uses).
Write down essential findings and feedback per release. Plot the findings in a table to chart indicators such as regressions, bugs, missing features, delays, or complaints in general. Share this info with your team to improve quality.
The role of release manager is essential, whether you're a startup or an enterprise. Every company wins by releasing better software by dedicating a human being who ensures that details that matter are tested, and built according written specifications. There are however a few differences.
Larger companies who release software to customers running complex infrastructures have extra release management requirements in terms of co-ordinating releases with other vendors, DevOps, or security operations. Include these additional aspects in your definition of ready.
Startups on the other hand have different challenges: trust between the start-up and customer is still fragile, the software is relatively immature, and resources in terms of development and QA/QC are limited. There is a direct correlation between the quality of your work as release manager and churn rate. Since churn can kill your company it's essential to ship solid stuff.
By understanding the needs of the customer you know what matters most to them. You've been hired to ship a better product, make sure you determine what exactly "better" means for your company and its customers.
Calls, meetings, writing, testing the product's release-worthiness, and dealing with hundreds or thousands of items on your list make the job of a release manager a demanding one.
With today's tools like IFTTT, Standard Library, and Zapier even non-technical people can glue together disparate services and platforms. There are countless examples where a tiny bit of automation can decrease the workload. If you find yourself having to do the same chore multiple times per day or per week it's time to take a step back and think "can I automate this?".
