Release Management: 4 steps to scale

Intro

In this article I want to share a practical case from my current project I found might be handy for the community. In common words, in this article I'd like to share a practical experience on how we managed to scale Release Management (RM) for the comprehensive and branched program using SAFe (Scaled Agile Framework).

So during the last half-year, our project team significantly increased, apparently more than 100 FTE's involved in the delivery. The whole account is divided into multiple workstreams, which are also divided into functional teams.

Despite the scale, we wanted to keep agility in place, including Release Management flexibility. Historically on the project agile methodologies were proven as fittable, most closer we were to Scrum. To keep growing further as I mentioned above SAFe was chosen as a superstructure over the already implemented Scrum-like framework.

I give these initial details to bring the reader the source of reference we were looking at when applied the change in the RM approach. These are the two ideas that were chosen as the basic ground:

1. “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” - 3d Agile Principle
2. "Deliver on Cadence, Release on Demand." - SAFe mantra

So all in all let me highlight 4 steps we applied to re-arrange our RM flow. Find it necessary to caution the reader that despite now proposed flow would seem structured, but in fact, it was rather an empirical way of doing things, nor pre-defined. So common sense and a portion of sane criticism are inevitable before application.

Step 1: Synchronized iterations

As I mentioned above a number of functional teams working in value-delivery in parallel. Each team has a different backlog of features with different timelines for delivery. Some features are long-runs, some are smaller change requests which should see the light ASAP.

So to make their progress coming to a single point regularly we made all iterations starting/ending at the same time, this's also one of SAFe's recommendations.

It allowed us to implement a System Demo thing. Progress of multiple teams merged to a single validation point - sprint demo. Of course, it adds an additional layer of synchronization - e.g. code freeze of one team has to be aligned with another so by demo time their features are merged and nothing's broken right before the demo. So after demo passed we can plan the release.

Step 2: Matched cadence of releases and iterations

Once we had iterations and demos aligned to the same cadence over the program another privilege opened. When all teams iteratively deliver value at a single point on the timeline you can easily merge those shipments and plan a release. That's what we did. Basically, we agreed that releases happening on a bi-weekly cadence regularly, and it's on the team to decide whether they want to fit some Work Package (WP) in the already planned shipment or not. On the image below is an abstract visualization of the agreed flow.?

The small red box on the image above stands for hotfixes. Devil always in details, as much engineering wants ahead planned releases business though often need urgent things to be launched. So in this case expedite work package delivered right to master, bypassing pending package planned for release.

Should also mention sudden positive side effect appeared on the way. It quite often happens that certain features need to go live synchronously on both front-end and back-end sides. As you can see in this flow this option is embedded out of the box. If such a need appears we don't need additional planning.

Step 3: Decentralised content management of releases

The problem that came up next was in following the agreed approach. Multiple teams were often confused with managing a variety of Work Packages that should go for a certain release or should not for another. We definitely needed some visualization tool to track the scope of releases on a daily basis.

"Decentralize decision-making" - 9th SAFe Principle

Teams needed tools to work according to the newly settled approach. Solution came from automation plugins built for Jira, particularly we adopted plugin Release Management and Roadmap. It was a perfect match for our need that allowed tracking of releases, dates, and scope. Below how the tracking board looks like.

In a sense, it's an enlarged version of the common Agile board with all know attributes: statuses, swimlanes, tags, etc. It pulls fix versions from different projects, if needed able to merge multiple versions into global packages. By clicking on any of the packages/versions a detailed breakdown of the scope appears.

Should also mention great and simple decision team worked out in the process. To decentralize the process of filling up fix versions during the development process. In Git they have added a check "fix version is added" so while merging pool request if related Jira ticket lack fix version value PR won't be approved until the value is added.

Step 4: Weekly release syncs

Although how seamless and simple approach is a certain grade of control was needed to synchronize visions and resolve dependencies.

"People don't do what you expect but what you inspect" - Louis V. Gerstner

On a weekly basis, we've scheduled Release Sync. It is 20-30 mins appointment to go through the tracking board. Agenda usually looks this way:

1. Sync on planned releases: dates, statuses, blockers (10-15 mins);
2. Check that each release has an owner on QA and Eng sides - those owners then give a final sign-off for the launch, share release notes with business (5-10 mins);
3. Project upcoming releases and create related fix versions - so that team can fill them up on the way (5-10 mins).

Summary

In such a storytelling manner I've disclosed how we approach our RM at scale. It's definitely not ideal. but serve well enough. I believe the best summary for it would be a list of brief pros and cons. So the reader can think through acknowledged from both sides.

Pros:

• Structure: provides a known level of transparency for all stakeholders;
• Accountability: team can reflect on what and when was released, who was responsible for launch;
• Predictability: focusing on release by cadence makes planning easier;

Cons:

• Overhead: it needs some effort to keep the approach working from both engineering and management sides;
• Expectations management: businesses need to be properly educated on why bi-weekly cadence is better than on-demand launches. Some shipments might be delayed upon cadence rhythm;

Hope this insight will be helpful in your practice. Feel free to comment and share your cases.

Cheers!