Last updated on
Plutora Blog - Agile Release Management, Release Management

What is Multi-Speed IT and Why Does it Hurt?

Reading time 4 minutes

When development teams create applications for the banking industry, they might find themselves interacting with systems of record. If they develop for telecom, they might end up learning about the SS7 Protocol. 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.

Creating features for systems of record will take a long time, and integrating those features will take longer still. In the meantime, the Agile teams who’ve already finished their portion of the work will be left sitting on their hands.

Supercharge your SAFe implementation with Plutora

Value stream management improves Agile Release Train (ART) performance by bringing visibility and insight to the development pipeline.

Learn More

That’s Multi-Speed IT in a nutshell. 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

Multi-Speed IT - System of Record - System of Innovation

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

The intention of 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.

The Agile Release Train (ART) is the primary value delivery construct in SAFe. Each ART is a long-lived, self-organizing team of Agile Teams, a virtual organization (5 – 12 teams) that plans, commits, and executes together. ARTs are organized around the Enterprise’s significant Value Streams and live solely to realize the promise of that value by building Solutions that deliver benefit to the end user.

That is to say, 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. They know the release date, and they know how much work and which specific goals they need to hit in between those two dates.

This is a ten-week increment by default. In 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.

These stations are the same for every team aboard the train. 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 not get included in the PSI and will have to wait until the next increment is delivered. This mechanism is in alignment with the Scaled Agile Framework overall “definition of done.” In vanilla Agile, a feature is done when the code for it is written and tested. 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 a 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.

In order to achieve greater efficiencies, SAFe requires release management where multiple projects and multiple trains are involved.

Multi-Speed IT and Agile Release Trains Require Release Management Across Projects

Managing agile 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. That’s why, in order to achieve even greater efficiencies, SAFe requires release management where multiple projects and multiple trains are involved.

Learn how to implement Multi-Speed-it with Release Management and Safe framework. Download our free white paper: An Introduction to Release Management and SAFe