Visibility is one of the key requisites to speedy, quality deliveries; without end-to-end visibility of the release process, work can get significantly stalled. Which is why organisations try hard to find ways to improve real-time visibility so they can better their release quality and success rate, as well as productivity, coordination and communication.
That being said, let’s take a look at four ways to improve visibility of your releases, and some of the practices that can help get you there.
1. TRACK DELIVERY TIME
Is everyone along the release chain well-informed of the timing of a release? Do they know if and when it slips?
Most if not all releases are time-sensitive and goals without deadlines are - let’s face it - bound to fail. And though deadlines motivate us to deliver releases on time, they don’t tell us much about anything, let alone how the release is happening or why it slipped.
Know your time
What would be helpful is if we could manage to access the records of the time spent on every issue, task and release, so that we can evaluate and distribute release tasks according to our reports. We can also get better estimates of our future deadlines given our collected set of data from previous releases, and represent that data visually.
Bottom line is, when you gain awareness of the time spent on every single task, you get a real chance at understanding the requirements of that one task and every other, so you can better estimate your release's delivery date.
Issues need to be recorded when they happen, so when you create an issues log, you need to make sure to report and communicate what’s happening with your release. Without a defined process, you risk ignoring issues until it’s too late to deal with them properly. There are many tools that allow you to display issues and events for all to access.
Use a timeline backdrop
While spreadsheets might work, they can quickly become hard to maintain i.e. you’ll have trouble communicating with the relevant stakeholders. But with a roadmap software tool, you can get a portfolio-level view of releases across the entire organization, and lay out stakeholders against a timeline backdrop, to make it easy to view the planned order of release.
Track your slippage
In order to overcome schedule slippage, you can use tools that have a visual slippage trail as a feature. This allows release managers to forecast impact, conflicts and mediate instantly; it shows up when your release’s length goes beyond your initial expectation.
2. UNDERSTAND THE SCOPE
Is your team aware of what is being delivered in the releases? How good is your response to incidents?
Having visibility across the lifecycle of your release isn’t just about saving time, it also creates the space for effective feedback to make sure you can detect issues with code for example and prevent them early on.
Say, developers are creating code for an application that the testing team is going to test; the release manager on the other hand is going to oversee the integration and deployment of this new application. If somewhere along the development phase, the operations team has spotted a problem, they shouldn’t have to explain it to the development team; instead, the latter should automatically be notified and know exactly what’s required of them; right?
There are ways to do that, here are a couple:
Tag your tasks
Tags are a great way to group release tasks together; they allow you easy access to what’s happening in your release pipeline, across all tools. They’re user-defined so you can name them based on what makes sense to your team. By tagging your releases, you get to control release workflows and phases based on the type of deliverable; that would include tagging hotfixes, features and so on.
Navigate with filters
It is useful to filter releases based on attributes such as projects, status and type of release so that you can keep a clean visual that only shows relevant information when navigating extensive records. By filtering issues and merging requests by release, you get a better overview of the items associated to a release.
To make sure your team is swift when acting upon incoming issues/requests from other teams, you should have an overview of all issues across multiple releases. By linking those issues, you can add structure to your work and get better visibility of what your team is up to. You can also select a handful of related issues to surface correlated trouble spots.
3. LOOK AT THE BIGGER PICTURE
Visibility at the release level should extend further towards visibility of all releases across multiple teams; especially important when we’re dealing with one codebase. Otherwise we get to enjoy a whole lot more regression bugs, risk conflicts and release slips.
Create a holistic system
For the most part, release lifecycle management starts when a release is initially given a name and runs until the name is no more. Whatever the case may be, your team’s infrastructure should be designed in such a way as to support the release management lifecycle from start to end.
Why is this important? Imagine an organization that develops software systems. Many groups end up working on different components within these systems, which makes sense. Developers, for example, get to specialize and build piece by piece; but ultimately, the pieces should converge into a single, seamlessly-integrated, holistic system.
View at the portfolio-level, again.
A portfolio plan is essentially a roadmap of all the work you’re involved in, from the issues your teams are tackling to the releases your teams are committed to delivering. This portfolio-level view of releases across your organization can solve the cohesiveness factor and help teams organize their releases, share activities and understand cross-team, cross-department dependencies.
4. IMPROVE YOUR STRUCTURE
Finally, let’s tackle the foundation by going back to basics and solving the visibility dilemma at the level of your organization’s structure. So we can avoid the lack-of-communication trap, the confusion as to everyone’s responsibilities, and the not-so-useful, quite unconstructive, lack of involvement within the team.
Release management calls for cross-departmental synchronicity - from R&D, systems engineering and operations, to sales, marketing and customer support. So how to ensure proper structure when communication is poor?
Incorporate a culture of visibility
A tool you can use to incorporate a culture of visibility into your processes is the Release Governance Framework, which can help you build, review and adapt your release processes. It includes simple templates that help you test what works for you and your team, so that you can iterate and improve the way your team delivers. We’ve taken a good look at this toolkit in a previous article - if interested, you can access it here.
Create cross-project releases
As the name suggests, cross-project releases are used when managing joint releases, dates and milestones across multiple projects, by associating releases to more than one project. When turning project-specific releases into cross-project releases, release managers can access a higher level view, meaning they can now orchestrate and synchronize activities across multiple individual projects.
Categorize by status and date
Release phases can have associated statuses and dates; every team member gets to update their status and stage dates in order to communicate progress. Status is pretty much an ‘are we ok?’ nudge to everyone, and it plays a key role in mitigating release management risks. Feature status workflows on the other hand enable granular visibility into the readiness of the feature and its current status with respect to development, staging, or QA environments.
Hopefully we’ve managed to shed some light on some of the practices that can help you succeed in one of the top challenges release managers face: visibility. But don’t take too long, the lack of visibility has its toll.