Here is a brief excerpt from an article written by Hugo Sarrazin, Belkis Vasquez-McCall, and Simon London for the McKinsey Quarterly, published by McKinsey & Company. 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.

*     *     *

Understanding the true principles of agile can give companies the ability to work quickly, boosting efficiency and product success, and, ultimately, creating real, lasting value.

Agile isn’t just for software nerds anymore. In this episode of the McKinsey Podcast, senior partner Hugo Sarrazin and partner Belkis Vasquez-McCall speak with Simon London about how the agile way of working has gone way beyond the world of software. Agile has become more prevalent among companies wishing to make swift, iterative teamwork central to their change efforts because—if done correctly—it can help people work more efficiently, delivering successful products and creating much more value.

Simon London: Welcome to this edition of the McKinsey Podcast. I’m Simon London with McKinsey Publishing. Today we’re going to be talking about agile, with a capital “A,” which started as a set of principles and practices for developing software but is now being applied in many other areas of business. It’s a world of scrums, stories, epics, and timeboxed iterations (see sidebar, “Glossary of agile terminology”). These are concepts that are spreading well beyond the world of software. To help make sense of it all, we’re joined today by Hugo Sarrazin—Hugo is a McKinsey senior partner based here in Silicon Valley—and Belkis Vasquez-McCall, who is a partner based in New Jersey.

Hugo and Belkis, thanks very much for joining.

Hugo Sarrazin: It’s our pleasure.

Belkis Vasquez-McCall: My pleasure to be on.

London: If you don’t mind, let’s start with a little bit of history. I think that will help orient us. Hugo, just where and when did agile emerge?

Sarrazin: Software has been improving over many, many, many years. There are multiple versions, and agile is just the latest one. Before that, there was extreme programming, et cetera. There will be new versions that go beyond the current version of agile. It’s part of the normal evolution.

The current version of agile, most people would date it back to 2001, when the Agile Manifesto was put together by a group of experts and colleagues who were looking for better ways to deliver software—and were frustrated with the inability to do things on time, on budget, and to delight customers. They wanted to see if there was a different way to think about the overall process and to think of it in the system way. Then they built on the great stuff that was done before and came up with a couple of principles. We’ll cover some of them in a little while. These principles are helping us think very differently about how to deliver terrific products.

Vasquez-McCall: If you take the purest meaning of agile, which is how I always explain it to my children, agile is about being able to move quickly and easily. If you think about the fundamental principles of the Agile Manifesto, the core is that ability for speed and efficiency. When you think about when the Agile Manifesto was signed in 2001, it was a plea from the practitioners to shift how software development was built, to focus on the customers.

“Agile says, let’s break things into small little increments; let’s make sure we deliver value each time.”

London: Do you want to say a couple of words about waterfall? Because as I understand it, and for people who are not steeped in software-development methodology, part of what agile is reacting against is what was known as the waterfall—the classic waterfall methodology for developing big software products. Belkis, just say a couple of words about waterfall, and how it works, and what the problems were with it.

Vasquez-McCall: The whole reason I fell in love with agile was after I completed my first waterfall project, which was a disaster. I was in desperate need of finding a new way of working. When you think about waterfall, it’s based on a command and control approach, pretty much telling your team members what to do, how to do it, and when to do it. It is a very linear and sequential software-development approach.

Sarrazin: It’s not that waterfall is bad. Actually, waterfall is a perfectly fine way of doing things. There were good reasons why it emerged when the computer and mainframes and the cost of doing things were such that it required a lot of advanced planning, a lot of coordination, and a lot of rigidity to make sure that things were done in a way that dependencies were addressed properly up front.

The reality is, in today’s context, with technology being more flexible and cheaper, you have the ability to think very differently about how you bring technology to market. In the old paradigm, it was not uncommon [for projects to be lengthy]—we all have clients and colleagues who were part of large projects that took many, many, many months.

We’ve done lots of benchmarking over the years. The most recent one, I think we reviewed almost 6,000 IT projects. Thirty-three percent of them were not on time. Forty-six percent of them were over budget. Very few of them delivered the original benefit they were expecting to deliver. That’s not an indictment of the IT organization. It’s not an indictment of the people who deliver the software. It’s not an indictment of waterfall. It’s just that it takes a long time. To be rigid, you’re introducing risk by default.

Agile is the opposite. Agile says, let’s break things into small little increments; let’s make sure we deliver value each time, so that we don’t wait until the very end to have the big hoopla and the great unveiling, because at every step of the way, you’ve delivered value.

London: So that’s a great segue into the principles of agile. Maybe just step back: if I see an organization team on the ground operating in an agile way, what do I see happening in practice?

Sarrazin: I’ll highlight a few. I do think one of the beautiful things about these principles is you need to think of them in a holistic way. You can’t just cherry pick a few of them. We can get into why that can lead to bad outcomes—and some companies are doing that today, and they think they’re doing agile, but they get in trouble.

“It’s about making work fun again. Imagine that. Imagine getting your team members to enjoy what they’re doing and feel like they’re accomplishing their mission.”

At the core, you need to be putting the customer first. You need to be clear on who the customer is, what problem you’re trying to solve, what matters to the customer, and prioritize. Always come back to who the customer is. In some cases, the customer can be the internal customer. But often, you need to make sure that it’s the external customer.

In typical organizations, the distance between the customer and the people doing the coding is eight layers of translation. That can only lead to wrong prioritization, compromise, and, in the end, your likelihood of delighting the customer and doing something that’s “aha” is reduced. That’s principle number one and incredibly important.

Vasquez-McCall: The second principle that I would add is around how to focus on people interactions versus process. So, how do you make sure that your team members don’t just take a project plan on what we need to do and toss it over the wall to [another] team, but actually collaborate?

How do you come together to align on the objectives and mission that you have for your customers, and work to figure out the best solution to bring that to life? It’s about making work fun again. Imagine that. Imagine getting your team members to enjoy what they’re doing and feel like they’re accomplishing their mission.

As Hugo mentioned in the first principle, it’s about bringing the customer to the table. It’s part of the interaction of processes that takes away so much of the focus on just checking a box—to more of a focus on how to serve our customers and get to the right solutions for them.

Sarrazin: I think a third principle that is very important is welcoming change—so removing the barriers that if you change, [the idea that] if there’s failure, that something was wrong. Rather to turn it around and say, we’ve learned something. We’re going to integrate that learning into the next iteration. Because at the heart, and the way most organizations will implement these principles, is quick cycle times: two-, four-, six-week sprints, which is often the name that is used; and to deliver something at the end of the sprint, you have the ability to learn. If you do a quick sprint, you focus on delivering something. You bring the customer to give you feedback on what you’ve delivered. You have an inspired team. Now we’ve taken the three principles and we’ve gotten them to work together. That’s one way to implement the principles, although it’s not the only way.

“It’s scary for most organizations to let go. We have built organizations that are hierarchical, inspired from the military.… Now we’re saying, no, let’s flip it around.”

But you can begin to see how it’s self-reinforcing. The fourth principle, I’d say, is to empower the team. The team knows more about the customers, it knows more about what it can do. If you make it autonomous, within some boundaries, you can have something special. The team performs at a new level. The quality of the product goes up.

*     *     *

Here is a direct link to the complete article.

Hugo Sarrazin is a senior partner in McKinsey’s Silicon Valley office, and Belkis Vasquez-McCall is a partner in the New Jersey office. Simon London is a member of McKinsey Publishing and based in the Silicon Valley office.