Making Multi-Speed IT Work for You

Every organization strives to be high-performing, and in today’s business landscape, it’s a goal that depends on digital transformation. The reality of the matter is that various parts of businesses grow and adapt their IT savviness at different times and at varying speeds. But in the quest to move faster, adapt more quickly and embrace being software-defined for success, what does digital transformation actually look like when IT is pulled in multiple directions?

In an ideal world, innovation calls for agility and speed; however, most enterprise organizations are cursed – or blessed – with legacy systems that still have a shelf life and need to operate alongside the introduction of other more modern components. Developers working in established sectors like banking or telecoms, for example, understand this situation well, being in industries that are embracing mobile banking and connected cars, yet are also still dealing with legacy systems of record. These systems have little interoperability, can be written in what’s tantamount to a foreign language for developers today and can be unpredictable due to their age.

This is particularly troublesome for applications with newer front ends that hide a backend built on legacy infrastructure and programming. Agile teams working on the newer component will operate at their usual rapid speed, while the other teams work through the older systems at a slower pace.

Getting the Multi-Speed Trains Running

The resulting discord can cause multi-speed IT, giving rise to the type of scenario in which a business may be embracing DevOps, but because it’s slowed down by legacy systems, isn’t able to yield quick production outputs. It’s an unfortunate conflict that highlights how embracing a DevOps methodology isn’t just about looking forward, but also about incorporating the legacy within the business. So how do companies looking to embrace the future and remain competitive do this without leaving systems of record behind?

The answer may well be the Scaled Agile Framework (SAFe). The intention of this framework is to bridge the gap between old and new, making up for the shortcomings of Agile that emerge when dealing with legacy software.

The key functional unit, the Agile Release Train (ART), enforces this holistic approach and is the primary value delivery construct in SAFe. Each ART is a long-lived, self-organizing group of Agile Teams — a virtual organization that plans, commits, and executes together. ARTs are organized around the enterprise’s most significant value streams and are responsible for delivering the promise of that value by building solutions that benefit the end user.

This means that each train works together to create a working, integrated piece of software, rather than isolated teams working on individual features.

Teams, Stations, and Management

ARTs are typically made up of five to 12 Agile teams. Each ART knows the start date of their project, the release date and how much work and which specific goals they need to meet within the timeframe. Ultimately, the train delivers production software with integrated features. 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 be included in the PSI and will have to wait until the next increment is delivered. This mechanism is in alignment with the SAFe’s overall “Definition of Done.” In vanilla Agile, a feature is complete 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 automatic 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. Managing release trains is an art that requires extensive collaboration and coordination to connect one train with all of the dependencies that it has. Without this management layer, no matter the understanding or oversight of multi-speed IT, the trains will crash before results are reached.

Therefore, the release manager can be thought of as the conductor: the person who knows the status of every train, coordinates between and within trains and looks ahead for any obstacles that may be approaching. Despite the importance of every team member, the release manager may be the most crucial person on the train, ultimately making sure the train arrives on time and on budget. With a good release manager staying in sync with the whole team, the issues associated with multi-speed IT can easily become a forgotten hitch in the tracks.

Nearly all organizations will find themselves in a multi-speed IT situation at some point, and if they are prepared with the right structure in place and good management this can be seen as taking the best of both old and new to remain competitive.