Here’s a simple idea: update your operating model to be able to build small, self-contained teams that create change quickly and efficiently.

I urge you to check out brief excerpt from a podcast transcript created for the McKinsey Quarterly, published by McKinsey & Company. It is based on a conversation involving McKinsey’s Santiago Comella-Dorda and Gerard Speksnijder and their colleagues. They discuss “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.” To read the complete article, check out other resources, learn more about the firm, obtain subscription information, and register to receive email alerts, please click here.

To learn more about the McKinsey Quarterly, please click here.

* * *

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.

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.

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.

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?

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.

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.

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?

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.

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.

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?

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.

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.

* * *

Here is a direct link to the complete article.

Santiago Comella-Dorda is a partner in McKinsey’s Boston office, Gerard Speksnijder is a master expert in the San Francisco office, and Roberta Fusaro is with McKinsey Publishing in the North American Knowledge Center.