Do you wonder if your release process is running as smoothly as it could? Many organizations ponder this question, and few are happy with the answers they discover.
That’s because release management is an evolving process that needs continuous improvement, and there’s no such thing as a “perfect” release process. The best you can do is find one that works for your organization, which takes time, effort, and a willingness to evolve.
However, teams can adopt a strategy that accelerates this trial-and-error period and helps deliver organizational consistency around a common goal: stability.
Why Is Release Management Challenging?
The release process is challenging due to the need to align multiple teams that are all working toward different key performance indicators (KPIs) and goals. For example, product teams are tasked with delivering new features with speed, while engineers often want to produce bug-free code and address technical debt. Building consensus is an ongoing struggle.
The numerous handoff points between teams are also an open invitation for challenges and risks to arise. Typically, new product requirements start with product and design teams, move to engineering teams for scoping, architectural planning, and building, and end up with QA for code review before the release team takes over with staging and monitoring. Without a well-honed coordination and communication process, organizations are bound to encounter problems.
And then there’s the X factor: executives. Unfortunately, even the best-planned releases find themselves on the back burner when executives meddle. It’s not uncommon for an exec to apply pressure for a rushed release when a VIP customer demands a new feature or needs a specific bug fixed. Similarly, when a critical demo to key investors is on the horizon, everything else may get derailed until a must-have feature is designed, built, and released.
Needless to say, release managers have their work cut out for them. Their responsibilities reflect this unpredictable environment:
- Adjusting when non-scoped and last-minute features are added to a release
- Ensuring additional functionality doesn’t impact the stability of each release iteration
- Recognizing and addressing any potential problems immediately
- Providing real-time information to teams on release health
- Knowing when to move to the next phase of the release process
Build a Repeatable Release Process
Despite a natural proclivity for hiccups, release management can operate smoothly when a repeatable release process is adopted. The key is to provide teams with a means to share, evaluate, and work toward a single goal. I propose stability as that goal.
Stability is a measurable indication of how healthy each release is, based on how many errors are occurring. Stability provides an instant answer to questions like, “Is the application working?” and “Are customers experiencing crashes and bugs?”
There are three factors necessary for a successful release:
- A means to quickly identify where major issues exist in order for developers to know exactly where to fix them
- The ability for teams to remain agile and focused solely on the major bugs
- A singular focus across teams on the stability of a release and the capability to constantly monitor it
Stability management and error-monitoring tools serve as an important line of defense because they enable organizations to metricize and analyze stability during every step of testing and deployment. These tools build a common understanding around what new bugs have been introduced, how many users are experiencing them, and how critical the bugs are, as well as a clear comparison between the errors in previous builds to those in the latest release.
Stability in Practice
Organizations that measure stability can set targets for what level of stability they want to accomplish and thus determine how many bugs is too many bugs. This service-level agreement (SLA) equivalent for stability makes it easy to gain solidarity around one question: Should we fix bugs or build new features?
Stability targets are the critical missing piece for teams that lack alignment. By establishing what the target stability should be for each release, everyone knows exactly what action is needed when errors start to pop up. Simply put, stability targets consolidate business decisions across all teams.
Of course, teams may disagree on what the stability target should be, which is why it’s important to have an open dialogue and set realistic stability targets. Targets also can (and should) be updated over time as teams develop a better understanding of their own capabilities and customer resilience when encountering bugs.
Beyond stability targets, release managers who adopt practices like partial and phased rollouts are able to minimize the impact of new software on the entire customer base while enabling engineers to hit target stability numbers through testing with a smaller group of users. Ongoing stability management is also important for release managers, especially in the 24 hours after a launch, because it will provide quick insights into the end-user experience.
Metricize for Success
Without a smooth and understandable process that the entire company can track, release managers may face a lot of confusion and frustration from their fellow employees. To send out healthy releases and deliver the best customer experience possible, release teams must gain control over the quality and reliability of the software.
By measuring and monitoring stability in real time, release managers inject accountability, predictability, and complete peace of mind into the organization. And if they happen to make their own jobs easier in the meantime, then release managers will know for certain that they are being effective.
