Why Release Management Is Critical For Scaled Agile Framework (SAFe) Success

Agile and Waterfall software development methodologies operate at different speeds. But what happens at companies that rely on older software and systems? This post will explore how an enterprise relying on older software can deliver continued innovation by coping with .

Imagine working on a software development project in the days before Agile. Software took a long time to develop back then—months, maybe years, before it went into production. That was the Waterfall model.

Today, many companies are Agile. It’s a software development methodology that allows companies to deliver production software at unprecedented speed.

However, large enterprises do not enjoy the same advantages. They have many projects that involve legacy systems which tend to integrate at different speeds, leading to the problem of multi-speed IT.

What Is Multi-Speed IT and Why Does It Hurt?

When development teams create applications for the banking or telecom industry, they might find themselves interacting with systems of record. These systems, developed during the dawn of the information age, tend to be difficult to understand, and they don’t integrate well or predictably with modern programming languages.

This bodes ill for applications whose shiny frontends conceal a backend that resembles MS DOS. Agile teams working on the newer component will create at their usual breakneck speed, while the teams that are assigned to the older systems will plug away at Waterfall speed.

While Agile teams will be able to develop some features relatively fast, the time to production remains overlong, and the advantages of Agile—rapid iteration, lessened time to production—are lost.

The Scaled Agile Framework (SAFe) Can Solve Multi-Speed IT

The intention of the Scaled Agile Framework (SAFe) is to make up for the shortcomings of Agile that emerge when dealing with legacy software. Its key functional unit, the Agile Release Train (ART), enforces a holistic approach. Instead of isolated teams working on individual features, each train works together to create a working, integrated piece of software.

ARTs are typically made of up five to twelve Agile teams. Each ART knows the start date of their project, its release date, and how much work and which specific goals they need to hit in between those two dates. This is a ten-week increment by default. At the end, the train delivers production software with integrated features—a Potentially Shippable Increment (PSI).

Along the train’s journey, there are several different “stations,” representing, for example, system integration testing, user acceptance testing, and staging. If a team’s feature isn’t ready by the time they arrive at one of these stations, then they don’t get to stay on the train. Their feature will have to wait until the next increment is delivered.

This mechanism aligns with the Scaled Agile Framework’s overall “definition of done.” In SAFe, a feature is done when it is written, tested, and proven to work in production. By delaying features that don’t meet this definition, SAFe ensures that trains deliver PSIs with consistent levels of quality across the board.

SAFe thus includes baked-in quality control that is fundamental to solving the problem of multi-speed IT. This design philosophy helps to ensure that teams working with legacy software will deliver their features on time. It also allows Agile teams working with newer systems to create at their own pace, without getting too far ahead of the legacy teams.

Agile Release Trains Require Release Management Across Projects

Managing release trains is an art that requires extensive collaboration and coordination. Managing a single train may be relatively easy, but this single train may have dependencies which connect to other ongoing projects. In order to achieve even greater efficiencies, SAFe requires release management where multiple projects and multiple trains are involved.

Multiple ARTs are managed via vast Portfolio Epics: design documents that capture the entire scope and scale of a particular project. But customer expectations are a moving target, and the scope and scale of a Portfolio Epic may diverge from the finished production software.

Due to the sheer scale of an Epic, the designers of SAFe admit that “it may be difficult to assess how progress is being made on the development of its capabilities or features.” Thus, SAFe instructs Epic Owners to assess progress based on certain metrics, such as feature cycle time, team self- assessments, releases per year, and so on.

It is in the collection and interpretation of these metrics that Epic Owners might stumble. Attempts to coordinate the efforts of multiple ARTs and assess their progress usually take the form of a massive two-day meeting - a process that lacks visibility and is error-prone.

Negative outcomes include losing sight of quality, inconsistency with customer expectations. delays in the project overall, or a de-scoping of requirements.

How Plutora Release Helps

Plutora Release allows Release Train Engineers to sense problems within the release, and correct them before they become irreversible. Teams using Plutora Release will benefit from a real-time status and risk profile of the project. Live visibility drives collaboration and prevents problems from occurring, particularly when there are dependencies within the project.

Plutora Release provides several dashboards that display metrics from within trains, and across each train, allowing each stakeholder to have a detailed view of metrics from across the entire project. This results in a higher-quality PSI overall, which arrives with move of its features intact. As a result, the already substantial productivity gains from SAFe are further increased.

Plutora Release integrates with Plutora Environments to prevent environment conflicts and contention and ensure that releases pass through the correct quality processes with the highest level of quality.

Conclusion

SAFe represents an amazing way for enterprises to adopt the speed and high-quality output of Agile, even if they don’t happen to be dealing with green-field projects. Release management aligns with SAFe in a way that delivers improved visibility and improved governance.

This allows SAFe to fully live up to its potential as a design philosophy that solves multi-speed IT and helps deliver business-critical objectives.