Why CIOs should go all in on Agile to avoid chaos

Almost daily, I’m asked a now-familiar question: “My organization isn’t ready to go fully Agile – how can we go ‘multi-speed’?” Certainly, it’s unreasonable to expect a whole organization to travel to the hallowed land of agility all at once. Inevitably, there might be those who don’t want to, or can’t, make the journey thinking that the fable of “The Tortoise and the Hare” often rings true or even that “tortoise” and “hare” could harmonically co-exist in an enterprise. A mix of approaches is the pragmatic reality of every organization. But is it possible to get the best of both worlds, without making the full commitment that agile evangelists claim is essential?

We know that Agile—a mindset which enshrines an iterative approach to development, yielding greater speed and efficiency—is a proven path to transformation, and doubles the chance of success in delivery. But being widespread and acknowledged doesn’t mean that it’s easy to embrace agility, and it definitely doesn’t guarantee success. Like with any new process, teams are having to make compromises and find ways to move toward an Agile approach despite inevitable barriers or limitations. Leaders often ask how long it takes to reap significant benefits from a business agility transformation—the answer can be off-putting, with data pointing to the first big step change happens in two years, and again after eight years. It’s clear, then, that doing the right thing doesn’t mean a quick fix or sticking plaster.

Can “multi-speed” be done right?

Historically, the aim of multi-speed IT has been to recognize that different teams will work at different speeds, and to accommodate these differences through purposeful selection of a particular model per team. Different speeds can be defined based on the ease of changing particular parts of the overall system architecture, the governance needed to balance particular risks based on regulation for parts of it, or what we focus on here: the delivery methodology selected. Typically, the speeds based on the delivery methodology fall into two camps—teams doing some form of “Agile,” and those doing “Waterfall.” The latter is often an overly vague term and might more accurately be described as chaos with gates.

As humans, when we attempt to fully adopt a new way of doing something, we naturally find intermediate states or hybrid solutions that borrow from what we are already comfortable with. But settling for a hybrid approach as an intentional target state presents a problem—not least because organizations are usually unwilling to compromise on expected benefits. Using the term multi-speed to describe the end state or goal of an Agile transition may indicate an organization is not working through the challenges involved in fully embracing an Agile approach and will ultimately prevent them from realizing the associated benefits. Once mature and in continuous delivery, agile teams will naturally find different cadences that work for them – this doesn’t need a brand applied to it to enable it to happen.

Many hybrid solutions are not multi-speed in any sense. Rather, they could cause the opposite effect of Agile, and slow your team down. In many scenarios, they just lead to a mess.

What is a hybrid Agile solution and what are its downfalls?

A “hybrid” Agile approach has become the catch-all term for organizations attempting to mix Agile approaches and more conventional methodologies (often and sometimes questionably identified as waterfall). Some teams may be working in an Agile way, in iterations, with practices and tools that strengthen collaboration and allow the team to innovate more quickly. Other teams may be following a more waterfall-like approach with a structured sequence of gates and stages through which work passes and handovers happen.

These distinctly different frameworks and processes, operating simultaneously in the same organization, inevitably limit these teams in collaborating, tracking dependencies and handling lead times.

Following a hybrid solution can come at a real cost. Truly Agile organizations have on average 16% earnings before interest, taxes, depreciation and amortization (EBITDA) growth, compared to only 6.5% for those with inconsistent Agile practices.

So how do you distinguish hybrid from well-managed multi-speed? Shared agility should lead to fewer dependencies or incongruences between the different models selected so that teams don’t block each other. It simplifies the complexity when an organization is in flux. It is not a stop on the path to being truly Agile, like many hybrid solutions, but rather a state in itself. Even if an organization can eventually claim to be ‘fully Agile’, this shouldn’t mean a one-size-fits-all way of working is forced top-down on all teams.

The biggest risks if you don’t go fully Agile

Multi-speed IT might be attractive to sell as a new ideal end state, and even as a way to justify an existing hybrid model. But first, let’s consider why organizations struggle to go fully Agile and therefore reap the many benefits of the approach. These fall under the broad banner of “cultural change is difficult.”

First, there may be fear of the scale of change. Most organizational change faces some degree of resistance, usually because teams fear they won’t be able to deliver as expected. Second, the organization might not have invested enough resources and time into establishing the cultural shift required for teams to be able to work with agility regardless of which framework or methods they choose.

To avoid falling into the murky middle ground on your Agile journey, look out for these two most common hybrids that center on the relationship between different teams and functions in your organization.

1. Upstream governance still thinks and functions in a Waterfall way. The result is big chunks of requirements, even for the teams that have allegedly transitioned to Agile. Product management wanting to shape new items to go into their teams are beset with heavy governance processes that require them to define large amounts of detail up front, ironically hampering any actual agility.
2. One or more downstream test or deploy/operation phases driven by your Agile teams is handed over to another team. In this hybrid, large quantities of work are combined into huge releases (and therefore inevitably delayed). Poor quality resulting from this, ends up requiring more time from the teams to address bug fixes and late surprises.

So, before using the term multi-speed IT to justify sustaining an organization’s compromised state, explore more deeply why being fully Agile remains elusive, and what the costs of that might be. Often hybrid translates to one speed, and that speed is slow.

Thanks to my colleague, Yiannos Theodoridis, for his contributions to this blog.