Agility is about adjusting a company’s operating model and culture, meaning it should be something any organization could undertake successfully with the right tools and plan. In this episode of the McKinsey Podcast, McKinsey partner Santiago Comella-Dorda and master expert Gerard Speksnijder speak with Roberta Fusaro of McKinsey Publishing about how IT functions in large, complex companies can work to become more agile by better mimicking the actions taken by start-ups and digital-native organizations.
Podcast transcript
Roberta Fusaro: Welcome to this installment of the McKinsey Podcast. I’m Roberta Fusaro, editor of McKinsey on Business Technology, and today we’re talking about agility. Specifically, why is it that established companies have such a hard time moving fast? Every company wants to be like Amazon, Uber, and other online companies that develop products and services quickly, test them, tweak them, and satisfy customers’ needs on the go. Traditional companies, by contrast, have had less luck in doing the same.
Want to subscribe to The McKinsey Podcast?
What’s keeping them from mirroring the successes of their digital counterparts? McKinsey’s Santiago Comella-Dorda and Gerard Speksnijder and their colleagues have been studying just this question, and their research points to a critical message for traditional IT organizations. Update your operating model, otherwise even small-scale experiments with agility will fail to have the desired impact.
Santiago and Gerard are the authors of “An operating model for company-wide agile development,” and they’re here to speak with us about their findings. Santiago and Gerard, thanks for joining us.
Gerard Speksnijder: Good morning, Roberta, thank you very much.
Santiago Comella-Dorda: Thanks so much, Roberta.
Roberta Fusaro: A lot of people use the word agile in different contexts to mean a lot of different things. Can you define the term as you’re using it in your article and generally in the world of IT?
Santiago Comella-Dorda: Fundamentally, the idea around agile is to create small, cross-functional, self-contained teams that deliver technology in quick increments. And because they’re self-contained, they feel accountable, and that’s truly the magic of agile, a team that really feels accountable for the outcomes they’re producing—so it’s a very simple concept. Obviously, deploying that principle, in the context of a complex organization, is not easy, but the concept itself is quite simple.
Gerard Speksnijder: It’s a straightforward idea that basically builds on principles that feel very intuitive and effective. I’ve got a persistent team, folks who work together for a longer period of time, not just the IT folks, but they work together with the business, and they get to know each other, they know how each other’s organizations work. They know what individuals’ strengths are, what their weaknesses are. The fact that such a team becomes more productive feels very intuitive.
Roberta Fusaro: It seems as though when people think about agile, they think about Internet companies. I’m wondering why it is so easy, or why it seems to be so easy, for Internet companies to be all agile, all the time, and so hard for brick-and-mortar companies or traditional businesses to do the same. What are impediments to agile that some of these traditional organizations face?
Gerard Speksnijder: My take on this is that a lot of these Internet companies or digital-native organizations that grew up in this digital day and age basically have a big advantage in not having the legacy along a couple different dimensions. First of all, they don’t have the application-architecture legacy. There are no monolith applications. Everything typically is being defined in a pretty modular fashion, with lots of microservices, APIs, which allows you to make changes to the specific component of the application architecture. You can test it and release those features quite fast and without having lots of dependencies on other parts of your application landscape.
This setup is typically what you won’t find in large companies, brick-and-mortar companies that have been around, sometimes, for decades. They’ve grown much more organically and have a lot more spaghetti-like architecture. Legacy also pops up in the mind-set of the individuals themselves and in the processes that they use. If you look at some of the system-development life-cycle artifacts that need to be created for you to move on to the next phase of your project, very much typical in a waterfall sense, it becomes hard to break through because people would expect a solid business case: business requirements, documents, with everything laid out. That doesn’t work that well in an agile delivery mode.
Santiago Comella-Dorda: Adding to that, large organizations have tried to create these scale economies by specializing resources over the past few decades. As a result, if you look at the large organization, delivery resources in general are tremendously specialized. You have folks that know how to do XML, but on this domain, and then folks that know how to modify databases, but for this particular database.
So the concept of creating an end-to-end, self-contained team is tremendously difficult in a large organization. In many cases, it requires involving tens of people, which makes things quite complicated. That’s not the case for start-ups. In start-ups, you have resources that tend to be a little bit more flexible, which makes it easier to adopt agile.
Roberta Fusaro: You and your colleagues did some research that would point to the need for an operating-model makeover, so to speak. What sorts of changes are traditional companies making to be more agile on a broader scale?
Would you like to learn more about Digital McKinsey?
Santiago Comella-Dorda: Many organizations have been trying to just change teams and processes. That’s insufficient to really become agile more holistically. What we see organizations doing these days is to reorganize themselves to move away from the silos that were effectively governing their organizational structures in the past.
They are also modifying quite a few enterprise processes. For example, the way you source work to vendors, the way you staff teams, the way you do budgeting and planning—those kind of enterprise-wide processes are being modified to really accommodate agile. Finally, the way you think about the technical architecture is we are seeing quite a few modifications from that, as well. To give you an example, the concept of having more decoupled systems is extremely important as you move to agile.
Gerard Speksnijder: It’s interesting to see how pretty much every organization, certainly every Fortune 500 organization, has been making strides and moving on the agile journey. What we’ve seen happening is that many of these professional IT shops know how to do an agile project. They know how to take a team and have a small set of folks, basically, operate in agile mode. At a team level, we’ve seen quite a few organizations be successful. When you lift it up a level, and you think about agile at a program level, and certainly when you look at agile at an enterprise level, that’s where some of these components that Santiago talked about are becoming really quite complicated.
That gets to the concept of organizational structures or processes that involve non-IT parts of the organization, for instance, around funding or how to onboard and resource individuals to do vendor management. When it gets outside of the realm of IT and you really have to take the whole enterprise and become an agile organization as a whole, we find that the biggest barriers to success are around organizational structure, around how to resource. If you solve for that, then you’re really able to get to agile at scale.
Roberta Fusaro: In the article, you talk a lot about these four success factors—we’ll call them that, potential success factors. One of the most interesting to me is this idea of improving interactions between business and IT. It’s a perennial issue, one that a lot of people face in a lot of different contexts. But in creating agile at scale, how important is it to get that business–IT interaction stronger or to improve it to a larger degree than perhaps it already is?
Gerard Speksnijder: You’re absolutely right. This is a perennial issue, and it’s top of mind for many CEOs, as well as business leaders. What this agile philosophy really allows you to do is to create a much more intimate relation between the business and IT by aligning your development teams, by aligning your cross-functional teams—not just development but including operations, including testing, including, perhaps, even designers—bringing those teams very close to the business. Having a product owner be the representative of the business lined up against that team creates a real intimate environment where you can make good prioritization of features, where you can align effectively on the type of requirements that you really need.
That’s where, in many ways, co-ownership starts to happen and people have a joint responsibility and a joint accountability to make it happen. As opposed to the old-fashioned model where a lot of the requirements almost get thrown over the fence, and IT is trying to read between the lines on what the business really wants to make happen.
Santiago Comella-Dorda: Software is eating the world, and the business is becoming technology. So getting the business to really interact more closely with tech is highly beneficial. It makes the business savvier about what can be done and what’s not doable from a technology point of view. That kind of expertise, that cross-pollination between the business and technology, is tremendously beneficial in the way you structure your operations and organize your business strategy.
Roberta Fusaro: Again, looking at the article, one of the other success factors you talk about is this notion of orienting teams around products versus projects, allowing for a broader, at scale, deployment of agile. It sounds like a simple concept, but how simple is it actually to achieve?
Santiago Comella-Dorda: In certain areas, for a product—whether that product is a customer journey or a commercial product or whatnot—it is relatively simple to create this cross-functional, self-contained team that owns the product end to end.
As you get closer to the core of technology and as you get closer to the systems of record, it becomes more difficult. In many cases, you need to actually define products that are technology products, and that are systems that provide services to the rest of the organization. That balance between business-aligned products versus technology-aligned products is one of the key success factors and one of the most difficult decisions that you need to make as you move to agile.
Gerard Speksnijder: The challenge that you find is in a lot of these shared capabilities, a lot of different business users leverage them. If you have multiple business units that all use a payment system, how do you find a payment platform, using those feature teams or those agile teams supporting multiple business units? That’s where things become a little more complicated because then you don’t necessarily have one product owner; you might have multiple product owners who represent multiple businesses and help understand what your payment features are that they really need. So you’re thinking through what the business-line products and the feature teams are around it. But what also are the shared or more platform capabilities that you have supporting multiple business units is not straightforward.
Roberta Fusaro: Can you share some examples of the positive outcomes that some of the companies you looked at in your research are achieving through deploying agile at scale or changing up their operating models to some degree?
Santiago Comella-Dorda: It falls out in at least three different categories. The first one is around those feature teams becoming more productive; they’re becoming more efficient. This is measured in a 2x to 3x increase. It feels very intuitive. If I’ve got a team that’s working together from release to release, from sprint to sprint, it’s almost like I have a sport team. Here are folks playing basketball, and they show up for training every weekend, they show up for matches every weekend, they get better all along, as opposed to the old model, where you basically put folks together, let’s say for one game, and then you switch out a team for the next game.
It’s very intuitive that these folks will become more productive. The second dimension is all around throughput. If you look at the deployment frequency, and if you look at the lead time from code commit to code deploy, the improvements along those two dimensions are dramatic. Deployment frequency could go up hundreds of times, and the lead time from code commit to code deploy could really go down by a factor of 1,000, almost. You’re talking about minutes as opposed to weeks or months.
Then, finally, it’s around resilience. We’ve seen resilience go up dramatically, where the mean time to resolve is going down and the change fail rate is drastically improving, as well. This is one of those situations where you can have your cake and eat it, too. Productivity goes up, but quality goes up, and your throughput goes up, as well.
Santiago Comella-Dorda: If I may, I’ll illustrate it with an example of a client of mine. With this client, technology was seen as the long pole. The business had all these visions of what it wanted to do, and the challenge was technology delivery.
I’ve seen two fundamental changes in that organization. Number one, there is no more business versus tech. It’s all business, truly. There are technology elements, there are nontechnology elements, but it’s on the business. Furthermore, the kind of technology know-how that it has added into cross-functional teams is such that right now, the technology is seen as driving the transformation and driving the organization and as an enabler of change, rather than the way they were seen for years back when they were the bottleneck.
Roberta Fusaro: That’s a great point. It sort of echoes other McKinsey research that’s come out recently on this notion of IT becoming more of a business partner. If we’re looking at the four pillars that you identify in the article, are there particular challenges and pieces of advice that you would give to traditional organizations that are looking to deploy agile at scale?
Santiago Comella-Dorda: The one advice I’ll give is don’t fix problems for the sake of fixing problems. Get in the agile journey; as you go deeper, you’ll identify the roadblocks that prevent you from being more successful, from innovating more, and then address those problems. Always think through your operating model and what the next biggest challenge is that’s preventing you from going faster. Fix it and then go for the next one, rather than trying to create a master design and change everything at the same time.
Gerard Speksnijder: One example comes to mind. I’m working with a client now where we are making changes to the funding model. We find it to be particularly challenging. It used to be this situation where this large-scale organization would essentially figure out once a year what are the priorities to build, what are the priorities to change, and, essentially, agree on a number of projects and a portfolio of projects that need to be executed for that year. Changing this into much more of an agile funding model, where funding would happen—cost envelopes would be dedicated to agile teams and agile teams could then draw from that cost envelope for a period of time and, basically, do this specific prior authorization of initiatives or features to be released with the business, much closer to the business and much more real time.
It has turned out to be quite a daunting task, where lots of other people in the organization are looking at this—for instance, group finance—is looking at this going, “Listen, how do we control the costs? How do we make sure that we follow the overall strategy of the company?” This has been quite a difficult and hard change, and it also involves for each of these individual platforms or capabilities to basically set out a three-year business plan, to say, “Here is what we are planning on doing, and here is how it lines up with the overall IT and business strategy.”
It was a large-scale change and moving in that direction has proved to be difficult in the sense that it really requires business and IT, and supporting organizations like finance and risk and strategy, to join the party and collectively move in that direction.
Roberta Fusaro: It would seem that part of the transformation to agile at scale would involve a number of roles being redefined and reassessed.
Santiago Comella-Dorda: Most roles are modified in a number of ways, but there are a few roles that are entirely redefined. To give you a few examples, agile has this concept of a product owner, which is fundamentally someone who decides on behalf of the users and on behalf of the entire corporation what gets built and in what sequence.
Easy to explain, but the reality is that organizations don’t have a role like that. They have many stakeholders, all with a voice, all providing input to the team on what needs to get built. The concept of empowering a single individual to make those decisions is entirely new for organizations.
The role of a scrum master is new. The role of frontline managers changes because IT frontline managers were responsible for delivery. As such, they would effectively tell people what to do to produce a piece of software and release it into production. If you want to create empowered teams and self-managed teams, that role obviously needs to change.
An operating model for company-wide agile development
Gerard Speksnijder: What I find fascinating is the seed of change happening even on the core development side of the house, where people used to be a developer and a developer in a very specific technology. You are a .NET developer, a Java developer, or a COBOL developer, and that’s what you would do; you wouldn’t touch the other systems.
We have seen that concept of being a very deep technology expert on that specific language and that specific application change, where folks become more of a software engineer. The concept of engineering would include a real need to understand testing really well and a real need to understand operations really well.
Frankly, also, to be much more versatile in understanding the traditional business-analyst role so that you can translate the business requirements into what is needed from a technical perspective. What you see happening is that the profile of traditional developers that have a strong vertical lag, they become more T shaped in the sense that you would expect in an agile setup, a more pronounced horizontal expertise, as well, where you start combining depth operations, testing type capabilities in the single engineering role.
Roberta Fusaro: That’s a really interesting piece of the article and of the whole discussion. Thanks so much for talking with us today.
Santiago Comella-Dorda: Thanks so much, Roberta, my pleasure.
Gerard Speksnijder: Thanks so much, Roberta.
Roberta Fusaro: To read the article, “An operating model for company-wide agile development,” please visit McKinsey.com.
