How NOT to fail your release management NY resolutions

[#1]

The beginning of the calendar year is often marked by a list of New Year resolutions that are enthusiastically drafted in late December and abandoned by the beginning of February. Even more so when your resolutions are dependent on other people, which is the case for Release Managers who are entrusted with the difficult task of carefully managing complex release processes which often involve coordinating the work of multiple cross-functional teams.

For the past few years our team has been carefully listening to all the challenges related to release management and multi-team scalability of Jira and working towards developing a viable, comprehensive solution that is flexible enough to meet the needs of every organization looking to scale their Agile practices and ensure coordination and visibility across multiple teams and sprints. We think we've nailed it with Cycle Control.

Want to end this year with successful resolutions regarding your release management process? Keep on reading!

New Year Resolution #1: Coordinating multiple teams? Loose few pounds off your backlog!

A typical release process involves the collaboration and coordination of multiple teams. Those teams are not 100% aligned in their processes - some may use Scrum boards, others would rather stick to Kanban - which further complicates the management of the release process. Having multiple teams with unsynchronised cadences makes it difficult to effectively keep track the status and progress of the work that's being done. This gap in Jira's off-the-shelf configuration leads managers to seek alternatives, most of which have proven to be ineffective:

• Consolidating the backlog of multiple teams: the most common approach to this problem is attempting to bring the work of each team into a common backlog in an attempt to be able to monitor the progress of the release. This leads to overcrowding the backlog view with multiple parallel sprints and requires all teams to standardize their workflows and fields.
• One team per project: another alternative approach is having one team per project, which requires maintaining parallel Fix Versions across all projects and still does not allow Release Managers to effectively roll-up the work of multiple teams into a single portfolio. Ultimately, managers will end up with a crowded list of Releases and Epics in their backlog view.
• Third party PPM solutions: the various Project Portfolio Management apps on the marketplace offer different solutions to this scalability problem, but one of their biggest pitfalls is that most of them focus on directly managing the teams, not the release process.

Our tip for keeping your resolution
Jira does not (yet) allow for a cross-team roll-up view of the work that's being done on an initiative/release, therefore a third party solution is a key to keeping your resolution for better coordination of multiple teams.

The tool gives you the ability to fill the gap between managing a single team and a portfolio. It allows for the roll-up of multiple teams and tracks their progress and status across multiple sprints. You can easily roll-up the deliverables of any team that manages their work in JIRA and give managers the ability to define the scope of the initiative by using Jira building blocks such as Projects, Boards, Epics, Sprints and Filters. No more backlog consolidation - coordinate multiple teams across multiple sprints in a single portfolio view!

New Year Resolution #2: Keep your initiatives healthy

At the beginning of each year, we promise ourselves that we will take better care of our health - eat better, workout more, sleep 8 hours and stay hydrated. Gyms around the globe are making a fortune each January due to the sheer number of people who sign up for a membership, only to be canceled a month later. This pattern can easily apply to Release Managers who start the year with the ambition to finally streamline the release management process and keep their initiatives healthy. Unfortunately, they are faced with the reality of the numerous complex challenges and roadblocks that ultimately defy their ambitions and before they know it - it is December all over again.

Jira was originally designed to improve the management of a single team, but its tremendous success throughout the years caught the eye of larger organizations who love the product but struggle with its capacity to scale effectively. Within the context of a typical release management process, that scalability is often associated with the inability to effectively track the health of one or more initiatives.

Our tip for keeping your resolution
We hear you - throughout the years we've encountered countless people in team management positions who were looking for a better way to keep tabs on the current health of their initiatives. The idea behind our solution was to provide managers with a single source of truth into the current and future health of their initiatives.

Preventive medicine is the best medicine! We have developed an entire medical kit to help you keep your initiatives healthy and running. Custom, JQL-driven metrics will allow you to continually tune your release management process, help monitor the development schedule and provide both managers and developers with the data needed to improve quality.

The release metrics are designed to measure any work that's been done in JIRA and can be adjusted to aggregate any numeric field. Release metrics give managers a macro-perspective on the current health and progress of an initiative and can be adjusted to track Total Scope, Burn down or any other KPI for all teams across sprints.

Additionally, you will be able to conduct an early diagnosis of a potential health hazard - a feature called metrics inspection will allow you to investigate the changes between two points in time for a specific metric and take preventive actions in advance.

New Year Resolution #3: Polish your macro-management skills

“What developers want from managers? To be left the f#ck alone!” - an actual quote from a developer who had just enough drinks at Atlassian's BASH event to tell it like it is. Teams require their autonomy, and having their work micro-managed is no recipe for success.

Unfortunately, managing multiple cross-functional teams for a single initiative often feels like building the tower of Babylon - each team is working on their own increment and speaking their own language, whilst Release Managers are responsible for coordinating deliverables, hand-offs and keeping track of activities. The lack of visibility and transparency across the work of all teams inevitably forces managers to micro-manage them in order to collect all the necessary information regarding the status and progress of their work. In reality, Release Managers hate micro-management even more than the teams subjected to it, but how else would you go about managing such processes in Jira?

Our tip for keeping your resolution
What if you could manage the release process and give teams their autonomy whilst ensuring full-visibility for managers and stakeholders? Managers will monitor and report on the work that's being done by the teams and not interfere with the actual work. This will ultimately declutter the calendar of everybody involved and eliminate regular sync meetings, where teams will have to report on their progress. You will be able to report the work progress of multiple teams with a click of a button and get early warnings for roadblocks via risk indicators.

Additionally, you will be able to easily manage any given release via intermediate checkpoints. These checkpoints are used as early indicators for the release progress or to coordinate deliverables which are due earlier than the delivery date. Here is a general break-down of these checkpoints:

• Gates: define certain set of conditions under which a release can move to the next stage (e.g. release quality gate that has a target value of 0 critical bugs, 0 major bugs and < 10 minor bugs)
• Milestones: target certain deliverables for a specific date (e.g. planning after sprint 2 in development stage)
• Checklists: reusable lists of tasks with different owners, due and activation dates.
• Approvals: a release object which requires manual involvement from the owner of the approval (e.g. Approve backlog)

New Year Resolution #4: Sprint to your completion date & stick to your resolutions!

A typical release process is a marathon run comprised of numerous sprints. The better you sprint, the more likely you are to complete the marathon (release) on time. One of the biggest mistakes in release management is the planning phase - you get all team leaders, managers and stakeholders to draw a plan with concrete due dates. In theory, it all sounds great - planning is essential! Let me ask you this - how many times have you been able to stick to your original plan? Software development is like the weather forecast - sure, you can estimate the temperatures for the next week, but accuracy is debatable and there's nothing worse than assuring customers, C-level executives and stakeholders that it will be sunny, only to be met with a hailstorm of bugs on the day of your release.

Our tip for keeping your resolution
One of the biggest issues with release management is meeting your completion date on time. Unfortunately when the actual work begins all kinds of unexpected challenges arise and all your initial planning goes out the window.

This application enables you to plan with agility by using the historical velocity of all teams delivering the Release and adjusting the date or scope based on your end goals. By using existing data based on the execution progress of your release, the application can forecast an accurate completion date, thus enabling you to take corrective actions in advance by redefining metric values for Burn-downs, Scope changes, Bugs and other KPIs.