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!
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:
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!
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.
“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:
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.
Teodora V _Fun Inc_
Putting Pieces Together @ Fun Inc
Fun Inc
Sofia, Bulgaria
46 accepted answers
0 comments