The End of Two-Speed IT

Back in 2012, as established companies began to make a serious push into digital, BCG advocated a concept known as “two speed IT.” It was something of a compromise—a very necessary one. If IT organizations were going to support digital initiatives, they needed to work in faster, more flexible, more collaborative ways. Yet management often viewed these methods—based on principles set out in 2001 in the Agile Manifesto—as untested and maybe even a bit wonky. Two-speed IT was a way of saying, Don’t worry: you can use the new techniques for new areas like digital, and the traditional approach for mission-critical core functions.

It was a good idea at the time, but times have changed. Today, two-speed IT is a compromise that companies can no longer afford to make. The future of IT is one speed: all-agile. That’s not just because agile has proved itself at countless startups and major technology companies—and for all types of software development, digital and nondigital alike. It’s not just because agile’s footprint is expanding to industries like banking and insurance. (See “Ensuring Digital Readiness in Financial Services,” BCG article, April 2016.) And it’s not just because today’s companies can draw on fleshed-out playbooks when implementing agile. (See “Five Secrets to Scaling Up Agile,” BCG article, February 2016.) More than anything, it’s because two-speed IT creates—or will create—significant challenges for companies that continue to employ it.

Two-speed IT was a great intermediate stage, but it is not a long-term solution. And its term is up.

The Problems with Two-Speed IT

With its iterative development cycles, multidisciplinary teams, and continuous testing, agile represents a sea change from the traditional “waterfall” approach, where development flows sequentially from conception to testing and where separate teams take over at each phase. The differences between the models—and the processes, culture, and even mindset they require—make the appeal of two-speed IT easy to understand. But operating at two speeds, we have observed, creates three problems.

It’s harder to attract and retain talent. Recruiting and developing top-tier talent are perhaps the most important challenges  that CIOs face today. You can’t do great things without great people. But two-speed IT puts companies at a significant disadvantage in the war for talent. The organization is effectively split into two parts—each with its distinct, and inevitable, culture. There is the “fast” group, which is seen as doing all the exciting, cutting-edge work. And there is the “slow” group, which is viewed as doing the staid and traditional work. The dinosaur projects. The dull stuff.

It’s not hard to guess which group everyone wants to join. This causes a problem because having top talent in the slower group is particularly important. Here is where the hard challenges of transforming legacy systems are tackled—and where the larger part of IT spending still goes. But when people see themselves as stuck in the slow group with no chance to switch sides, they’ll look for opportunities elsewhere.

Two-speed IT, we are seeing, leads to talent drain. It also makes it harder to hire talent. Today’s digital generation looks for—and expects—a workplace that emphasizes the flexibility, cooperation, and adaptability that are hallmarks of agile.

It leads to “hurry up and wait.” In today’s IT environment, fast-moving agile initiatives increasingly rely on core and legacy systems. Consider, for example, a digital front end that links to a back-end platform. In such a case, two-speed IT means slamming on the brakes. Fast-moving projects will often run up against—and be delayed by—slow traditional test-and-release cycles. What could have been running tomorrow is now set to run after the summer—maybe. This “slowest common denominator” issue is becoming increasingly problematic as digital applications become more central to business and must interact closely with core systems.

It keeps the larger organization from realizing the benefits of agile. Within many two-speed companies, there is a well-entrenched notion that, changed world or not, the more methodical waterfall approach is still better suited for legacy and very large projects. But it’s not. Large projects are particularly susceptible to delays and rising costs, and tend to have very low success rates. Part of the problem is that testing comes only at the end of the process, so errors are found late in the game, when fixes become time-consuming, difficult, and expensive. Agile, with its iterative cycles and continuous testing, finds and corrects errors as development progresses. There is no last-minute—and nightmarish—back-to-the-drawing-board scenario.

The waterfall approach works well when the goal is fixed—if you know, for instance, that you need to build a bridge across a river. But in today’s IT realm, fixed goals are the exception. Whether it is a digital front end or a core business system, requirements change frequently because of customer feedback, competitors’ moves, evolving regulatory environments, and alterations made to associated systems.

Agile-related processes incorporate change better than waterfall methods do because they were designed to incorporate change. This adaptability is something the entire IT organization—not just part of it—needs to benefit from.

In a world where customers have more choices than ever before, the ability to develop core systems faster and more flexibly is crucial. To quote Peter Jacobs, the CIO of ING Bank Netherlands: “I would rather work agile at my core bank system than at the channels.”

Making All-Agile Work

While a single speed can “spread the wealth” of agile throughout the IT organization—and beat back the challenges that two speeds create—the model won’t work without the support and commitment of senior leaders. They can mobilize the troops and help steer—and, when necessary, push—the initiatives and changes that will ease the move to all-agile. A number of steps, we’ve found, are particularly crucial.

Identify and empower agile champions. Two-speed IT has helped companies get agile up and running in part of their organization. The experience and talent already developed can be harnessed to spread agile concepts—and knowledge—throughout IT. The most enthusiastic and communicative agile team members can serve as mentors to those just getting started—providing insights on what works, what doesn’t work, and how to do things better.

Create the right technical environment. Legacy systems are not a deal breaker for agile. Indeed, agile’s main principles can be translated to work on any project, and industries that still rely heavily on legacy applications and infrastructure—such as banking, insurance, and aerospace—have already started to embrace, and benefit from, agile.

But there are modern technologies and practices that can make the agile approach more effective. A decoupled architecture—in which applications, infrastructure, and data interact with one another through standardized interfaces like APIs and microservices—allows teams to work more independently of one another. Now they’re in control of their own development speed (and if one service breaks, just that service is down—not the whole system). Companies can also increase speed and efficiency—often dramatically—by combining agile with techniques like continuous delivery and continuous deployment of applications. This reduces the manual tasks—and the resources—required. Companies should be taking these steps anyway to improve their responsiveness and accelerate their digital transformation.

Implement agile in an agile way. A large established company is likely to implement agile very differently than a startup will. After all, bigger, older organizations must account for the layers of processes and hierarchy developed over the years. Similarly, agile will take different forms even within a single organization. Whereas one team may find two-week sprints optimal, another may determine that four or six weeks work better. Agile on a legacy mainframe, meanwhile, won’t look the same as agile on a mobile shopping app. And because some projects, like a major enterprise-resource-planning transformation, won’t lend themselves to going live in little pieces, agile may mean releasing code to the testing environment—but not the production environment—every day. Agile is a flexible set of principles, not a rigid doctrine. It should be implemented in that spirit.

Offer incentives to middle management. Agile changes the role of middle managers. Eventually, many of the coordinating tasks that have historically fallen to them will disappear. In agile, managers are much closer to the content and the technologies. While they still have some traditional managerial responsibilities, like recruiting and evaluations, they now work in the teams themselves. And on these teams, they are equal to every other member—serving, for example, as a fellow developer. Instead of instructing others, they work as coaches and advisors.

Given these shifts, it’s easy to understand why middle managers would resist the migration to agile: they can see themselves losing control and power. How to avoid this perception? One way is to start getting these managers closer to the front—in both body and mindset—through education, training, and participation in agile conferences and the agile community. KPIs used in measuring a manager’s performance should be tweaked as well. They should encourage the quick development and deployment of features but also tolerate some failures as long as the overall system stays stable. This is much more in line with how agile works.

Develop a digital culture. Migrations from two-speed to all-agile IT won’t happen overnight. And with the war for talent continuing, it’s important to send a message—to current and prospective employees—that agile and the workplace it creates are the company’s future. Hackathons—marathon sessions where teams compete to develop software and even hardware—have been used to foster a fast-moving “think outside the box” culture. (In fact, Facebook’s ubiquitous “like” button traces back to a company hackathon.) The idea is to take steps that let technology experts know that they can stay—and succeed—as technology experts; that, contrary to the old days and the old ways, they don’t need to take a managerial position to make a career at the company.

Establish joint business and IT teams. One of the hallmarks of agile is the cross-functional team, in which members representing the business and IT work together. Migrating to agile means breaking down organizational barriers and fostering communication and collaboration across once-isolated domains. (See The Power of People in Digital Banking Transformation, BCG Focus, November 2015.) Flexibility is crucial here, too. A key tenet of agile is that someone from the business side serve as the “product owner.” But for IT4IT products and tools, such as telepresence, it will make more sense for this owner to come from IT. Once again, the experience and practices already developed on the agile side of two-speed IT can prove invaluable.

Taking Agile Even Further

Unlike two-speed IT, the all-agile model is a long-term solution—and not only for the IT organization. Think about the main principles of agile: short iterations that enable teams to quickly spot errors and react to changes; collaboration in multidisciplinary teams; and progress that remains visible—and tested—as work continues. These are principles that can be utilized to great effect throughout a company, increasing its responsiveness to customers and competitors alike.

Already, we are seeing agile move beyond IT into areas such as product management and marketing, and functions that include human resources and risk management. (See The Agile Marketing Organization, BCG Focus, October 2015.) Spotify and ING are notable examples of companies that are bringing an agile style of working to IT and the business alike. (See “Building a Cutting-Edge Banking IT Function,” BCG article, December 2015.)

Today’s businesses are under mounting pressure to get products to market and systems deployed while minimizing risk and delay. Two-speed IT was an important step in gaining experience in new and better ways to do this. Now it’s time to take the next step. A return to a single speed—one based on agile principles—will improve efficiency and outcomes across all technology delivery and, ultimately, across the company. The result: better experiences for customers—and a competitive edge for the business.