Understanding Agile Management

Welcome to the HBR IdeaCast from Harvard Business Review. I’m Sarah Green Carmichael. Today I’m talking with Darrell Rigby and Jeff Sutherland. Darrell is a partner at Bain & Company and head of the firm’s Global Innovation and Retail Practices, and he’s joining me here in the studio today. Darrell, thank you so much for coming in.

DARRELL RIGBY: Thank you, Sarah. It’s great to be with you.

SARAH GREEN CARMICHAEL: And Jeff Sutherland is co-creator of the Scrum form of agile innovation and the CEO of Scrum, Inc., which is a consulting and training firm. Jeff, thank you so much for talking with us today.

JEFF SUTHERLAND: Thanks for inviting me. I look forward to the conversation.

SARAH GREEN CARMICHAEL: Daryl and Jeff are the co-authors, with Hirotaka Takeuchi of Harvard Business School, of the new article, “Embracing Agile: How to Master the Process” that’s transforming management.

So without further ado, let’s talk a little bit about agile and what it is. In the article you write, “Some executives seem to associate agile with anarchy, everybody doing what he or she wants to do, whereas others seem to take it to mean doing what I say, only faster.” But in fact, as you write, agile is neither.

So just to start with, what is agile? And Jeff, let’s start with you. What are we talking about here?

JEFF SUTHERLAND: Well, agile is a word that comes from a meeting where we wrote the Agile Manifesto, which was at the time directed to our software development, but basically had four values.

And without going into more detail, I want to just say that the word agile came from a book about 100 lean hardware companies who said that they were, number one, first lean, but they had become agile by involving the customer directly in product creation. So that would be my definition of actual. Lean plus getting the customer directly in the middle of innovation.

SARAH GREEN CARMICHAEL: And I think you have a sidebar in the article that goes into some of those principles, things like people over processes and tools, prototypes over documentation, responding to change over following a plan, and then customer collaboration over rigid contracts.

JEFF SUTHERLAND: Exactly. Those are the four agile values in the manifesto, yes.

DARRELL RIGBY: I might just add, I think of two words, agile innovation. And I think we define innovation as the profitable application of creativity. So it’s not just a bright idea. It has to be both creative and commercial.

And when we talk about agile, we’re really contrasting it with predictive innovation that tries to guess at the beginning all of the requirements that are going to be necessary in the end. We think of agile as being more adaptive. That is, you cannot forecast everything that is going to be required. So you should start with a vision of where you want to go. But be prepared to shift the path along the way and how to get there.

SARAH GREEN CARMICHAEL: So as we’re talking about this, other words may be coming up in people’s minds. They may be thinking, OK, so agile. We’ve talked about lean. Maybe they’ve heard of Scrum and Kanban. And that can be– to a newbie, that might be a lot of vocabulary to get your head around.

So I’m just wondering, as we’re getting into this, how much do people need to know the specific words, specific terminologies, or can they move ahead without knowing quite all of this? Jeff, I hear you about to jump in there.

JEFF SUTHERLAND: Yeah. They certainly can move ahead without knowing all of it. But because there is some confusion, if Professor Takeuchi was on the line, he would say the first paper that was written on Scrum in HBR in 1986 was written after viewing lean companies doing hardware development, new product development. And they were working so closely together that they reminded Professor Takeuchi of rugby teams. And so he and his colleague Professor Nonaka decided to call this Scrum project management.

So that’s where we got the name Scrum. But when we implemented Scrum, we did involve the customer directly in product creation. So when it came to the Agile Manifesto meeting, Scrum was one of the key methods discussed. And so there’s a linkage between all three things, and they are all related.

SARAH GREEN CARMICHAEL: So we’re sort of moving a little bit backwards and forwards here through the history of this idea, which is fine. But I do want to just pause here for a moment and clarify. We’ve talked a little bit about software and hardware and a little bit about innovation more broadly. Am I right in this, Darrell, that this is something where some companies are using it really only in their IT departments. Other companies are using it in much more advanced ways sort of throughout the whole company.

DARRELL RIGBY: Yeah, it’s pretty funny, actually, that a lot of people wonder whether agile innovation can work outside of IT because over the last 25 to 30 years, that’s probably where it has been practiced most frequently. But I think the irony is that initially it was developed outside of IT.

So again, if Hirotaka Takeuchi were here, he would be talking about how he originally identified this process in hardware companies that were developing products with much faster cycle times that were far more successful. And so he started trying to understand how did they do that, and he found this process of working together as a team, getting out of functional silos but working together and in collaboration with customers to do this iterative and incremental development as a team.

And when he wrote the article in 1986, it was all about hardware companies and manufacturing companies. And then Jeff could tell you the story better than I could, back in the early 1990s, was searching for a better way to do software development. And he was collecting best practices from a lot of different industries and a lot of different methodologies. And when he saw Hirotaka’s article, it became the capstone for his approach, kind of the eureka moment that said ah, now I get how to put all of these elements together.

And from there it took off in the software industry, and then turned out to be so successful there that other parts of the organization, particularly as IT started spreading to more and more parts of not just a company but individual products, that they started watching how this process was working in the IT department and saying, hm, I wonder if this couldn’t work in marketing or in any kind of innovation. And therefore it has already started to spread.

SARAH GREEN CARMICHAEL: Well, and that was interesting to me in the article. One of the things that you write is that if you’re trying to implement this throughout your company, don’t force everyone to use it. Kind of have it being piloted in a few places where people are excited about it, and then let the enthusiasm spread when people see how well it works.

JEFF SUTHERLAND: Yeah, well, this is one of the challenges, because Scrum was named after rugby and rugby is a sport. And you can’t just put people out on the field and ask them to play football unless they want to do it. And so it works best if people volunteer. The beauty of it is, it’s a lot more fun, it’s more active and more interesting than the old way of big upfront planning and then long development without anything visible. So people enjoy it more when they participate in it. But people really need to want to do it.

And if you look at some of the brightest minds coming out of universities these days, they are eager to assume positions of responsibility and do things that are going to matter. That’s the kind of company they want to go in. They don’t want to be 10 layers below a CEO just executing what some middle manager is telling them they should be doing. They want to be involved in important projects, feeling like a team, and feeling like they’re making important contributions.

So I think sometimes people underplay the importance that bringing out the talents and the enthusiasm and the engagement of employees plays in this agile innovation process because the assumption really is, if you create a great team, they are capable of doing far more than most management teams think they are capable of doing today.

JEFF SUTHERLAND: In addition, it’s not just tapping the talent that people have. But certainly in many years that we worked in the gaming industry and places like that, the best people will not work in an environment that’s not agile. So a lot of CEOs that come and talk to me, they say, how are we going to get that talent? Our competition is Google and Apple and all these other companies that are stealing all our best people. We need an environment that developers really like, that’s engaging, that’s fun, that’s radically innovative.

SARAH GREEN CARMICHAEL: You mentioned that you’ve worked a lot with the gaming industry. So I don’t know if there’s an example from that world or maybe from any example that you particularly like, but just a story that will kind of help us understand what this really looks like in action. I think most of us at this point have probably had some experience with agile. But how’s it supposed to work? What should it look like?

JEFF SUTHERLAND: Well, you have to start– in Scrum we have a product owner. That’s a person that has a vision for what needs to be built. And he creates a backlog, a list of features that need to appear in the order of business value. And he engages a team and a Scrum master to work with him to figure out how to implement that.

And once they agree or are clearly understanding what the product owner feels that customers need, they enter into what we call a sprint, where they work in short cycles building, essentially, production prototypes. So they may go into a one- or two-week iteration. At the end they have something working that they can show to a customer, and then get feedback whether they like it or not. And based on that feedback, they can change the way they’re working and iterate again and keep coming back to the customer with something that’s better and better every time.

And so this mode of working is it is what enables you to get– as we say in my recent book, “Scrum is the art of doing twice the work in half the time.” And it’s better work because it taps directly into the customer’s wants, desires, feelings about what they actually see working. And

SARAH GREEN CARMICHAEL: Darrell, maybe I’ll throw this back to you. This way of working, what kind of companies and industries does it work well for? Are there others that it doesn’t work quite as well for? I mean, every system has pros and cons. What do you think?

DARRELL RIGBY: It does, and it’s not a magic solution. But I think it is very effective, particularly if you are looking for breakthrough innovations. When I first talked to Jeff about where he had come up with this idea for Scrum, he said, what I was really trying to do was to create a skunkworks inside corporate headquarters. And so most people realize that if you’re going to have a radical breakthrough, you have to separate the people into sort of a self-contained autonomous unit. But when you do that, you lose a little bit of the advantage of being able to reintegrate those insights back into the business. And I think the beauty of Scrum is that it is that integrated skunkworks.

And so when you talk to people about what do you have to do to have an affective skunkworks, it goes back to the Lockheed innovative update of the P-38* back in the 1940s. But Kelly Johnson listed 14 rules of what you need. And he talked about things like you’ve got to delegate control, and you’ve got to have a small but powerful and autonomous team. And you’ve got to restrict the overseer’s access to the team. And you’ve got to have simple, flexible iterations.

And a lot of those are the exact same elements that are required to have an effective Scrum team. The difference is that engaged in that Scrum team are all the individual functions that are going to be required to make it successful when it gets into the market. So while they are protected from the corporate bureaucracy, they also have team members that are experts in that integration process so that when it goes into manufacturing, and when it goes into sales, and when it goes into marketing, those people are engaged from the beginning, as are the customers.

So as Jeff was saying, we’re going to take a piece of the solution, we’re going to test it with a part of the customers for a short period of time, we’re going to make sure it works, and then we’re going to go on to the next piece and the next piece and the next.

SARAH GREEN CARMICHAEL: So when we get really into the weeds here– I think I’m guilty of this– I can sort of make it sound more complicated than it is. I want to emphasize that we’ve had HBR editors successfully implement this with their children, helping them do their homework.

JEFF SUTHERLAND: Yeah. One of the most interesting areas of education–and I was in the Netherlands recently, where they had implemented it in the school, in high schools, and getting really great results. And the kids said to me, we can’t believe you invented this for adults. It works perfect for teenagers.

SARAH GREEN CARMICHAEL: Well, because they like to see making progress, and they like to be able to say, this is what’s blocking me, which is a big part of it, is sort of surfacing the blockers, right? As a teenager, that’s really empowering.

DARRELL RIGBY: You know, it’s fascinating to me to watch when people have no experience with agile at all. But when you break them into these teams, at first they’re a little skeptical, and I don’t know how this is going to work. Often the comment we get is, good luck getting our management team on board with this.

But once you get them formed and get the management team to treat them the way they should be treated, within two or three months most of them are saying to me, we’d never go back to the old way of doing business. This is just so much more fun, so much more fulfilling. And we feel like we’re turning out such better work. Couldn’t go back any more.

SARAH GREEN CARMICHAEL: You do spend a good part of the article, though, talking about obstacles and how to overcome them. So maybe here we could get into some of that as well. What are some of the mistakes people make, and how can we correct for those? Jeff, maybe let’s start with you for this one.

JEFF SUTHERLAND: Well, the biggest challenge for traditional management– who wants to have a command control, hierarchical mode of working with linear timelines and dates and arbitrary commitments that are forced on the workers– this is like a total shift, because coming out of the lean context, lean is a pull system.

So for example, the Prius team at Toyota is a good example that Professor Takeuchi had written about. The managers set really aggressive goals. We want twice the gas mileage and we want the car driven in half the time. And the developer said, well, that’s impossible by doing anything we’ve ever done at Toyota. And the management said, well, do something different.

And then they backed off and told the developers, if you need anything, call us. So it pushes the work onto the team, and they have to figure it out and engage themselves. And when they come back, they came back to the management, they said, we need all kinds of electoral technology we don’t have, the management immediately went out and acquired that technology and gave it to the team so that it was fully integrated within a car in 15 months.

So that’s agile management that works in a very different style. So this is the first big blocker, is trying to get the management to flip the way they work.

SARAH GREEN CARMICHAEL: Darrell, anything to add on to that? Any other sort of key issues you want to highlight?

DARRELL RIGBY: Well, I agree with Jeff that probably the hardest thing for management teams to learn is, it’s OK to delegate. I think a lot of them have grown up believing that 2% of their time is more valuable than 100% of somebody who is perhaps more junior but closer to the customer than they are.

And that’s hard to realize, that I could actually put my time to a higher and better use if I can learn how to delegate the things that other people can actually do as well or better than I do to them, and let them enjoy, let them learn, let them develop into general managers by doing those kinds of things. And I can focus on the more bigger, visionary kinds of things that only I am capable of doing.

I also think it is difficult to implement these agile systems. It’s not easy. And in some places it is not necessary. So there are places where predictive innovation works just fine. If you’re in a very stable, predictive environment where customer requirements are not going to change– you can forecast the requirements that are going to be necessary 18 to 24 months from now, the detailed specifications that you write out up front are going to stay intact over that two-year period of time– you may as well go ahead and use traditional innovation methods.

I think those kinds of conditions are a little less common than they used to be. But where those exist and where classic operations management is in place and working just fine, there’s no need to interrupt it with this. But I think this is a far better way to do important, breakthrough kinds of innovations in unpredictable environments. And we’re just seeing those in a lot of places these days.

But it means that a senior executive has to stop giving command and control orders to what a team should be doing. And they’ve got to stop fragmenting their best workers over so many projects. It is not uncommon for me to run into very capable senior executives who have no more than 5% or 10% of their time allocated to myriad projects, and that’s just catastrophic.

If you understand the dangers of multitasking, what that does to the quality of the products, to the morale of the workers, to the productivity of the teams, multi-tasking is a killer. So we have to teach executives that it is not a good thing to fragment the workers. It’s not a good thing to overturn their decisions. It’s not a good thing to put 50 people on a team as opposed to nine people on a team.

With the best of intentions, I think executives treat the organization in a way that kills agile and keeps it from ever being able to work because they’ve never seen the right way to make this work. They just don’t understand it.

SARAH GREEN CARMICHAEL: I’m curious to know if there’s any kind of organizational cultural issues to be aware of, you know, if people aren’t comfortable with some of the transparency agile requires, should you be cautious about implementing this throughout your business? Or if you work in a culture where people really seem to like hierarchy, are you going to struggle with this?

JEFF SUTHERLAND: This is, again, one of the big obstacles, maybe the biggest one that comes after management flipping its mindset. That is, Scrum works fundamentally on transparency. It’s built on making work transparent. Why? Because then teams can organize around doing something in a way that is impossible otherwise. They can see the results of their work quickly, and they can resolve problems also very quickly. And without transparency, it won’t work.

Now if you’re a person who is afraid of having real data about your operations exposed, if you’re a person that is building an empire that, in reality, is sub-optimizing the revenue of the larger company but maximizing your bonus, you don’t want that transparency, and that’s a problem.

SARAH GREEN CARMICHAEL: It’s the kind of thing where it seems like we pay lip service to the idea that transparency is always a good thing. But then in practice, sometimes we behave in different ways. Hopefully we’ve now done a good job of kind of laying out what agile is, how people can use it to innovate better, how to overcome some of the obstacles. I know there’s a lot more in the article.

But if people are now at this point ready to try– and for some people, they may be trying again. They may have tried this once before and it didn’t quite go the way they wanted it to. What are some good ways for people to get started maybe introducing the concept to their team or to their business unit? Jeff, let’s start with you.

JEFF SUTHERLAND: My latest book, Scrum: The Art of Doing Twice the Work in Half the Time was written for general management in any domain to really understand the basics and be able to have a conversation with a team and start to introduce some of the basic principles, you know, short iterations, getting people involved and that sort of thing.

And then we do training and consulting all over the world with companies, helping them move in this direction. And agile is a journey. It’s not a destination. In fact, it’s really more like a martial art. I you get a brown belt, are you done with your martial arts training? No, there’s a black belt. If you get your black belt, are you done? No, there’s 10 different degrees of black belt. And very few ever make the top.

So we know companies that have implemented Scrum, then come back and re-implement again. And then Cisco is on its third major transformation over the last 10 years, re-implementing a third time. And I’m sure they’re thinking this is going to go on for as long as the company is successful.

SARAH GREEN CARMICHAEL: Well, and that’s part of the idea, right? It’s like continuous improvement. So just because you’ve done it once or done it a little, there’s no reason not to keep refining it and going further.

DARRELL RIGBY: And I might add to that, I prefer to start small and create passionate ambassadors that have such a great experience with this that they can’t wait to tell other parts of the organization how it works. And from there I would say, pick the right problem to attack. Pick something that really needs a creative breakthrough, and where you believe that if you assemble a team of highly engaged, passionate team members, they will do better by working as an autonomous, cross-functional, multi-disciplinary team than a command and control team would.

And then I would say, give the senior executives enough of an education that they don’t unintentionally kill the effort, that they don’t overturn their decisions, that they don’t interfere, that they don’t pull team members off partway through the project. So let them know how this is going to work so that when we come back to them and say, ah hah, you remember we told you not to do this, OK?

So get the senior executives to agree to the rules of the game. And then give the team responsibility for doing this. Trust that by testing a part of the solution with a part of the customers for a short period of time, how far astray could we go in a three- to four-week increment? We’re going to run it by the market and see if it works. And if it works, great, we’ll do more of it. If not, we’ve only wasted three or four weeks. So how much downside is there really?

And then after you run this for three or four months, and word starts spreading, you won’t be able to stop it, and you won’t have to force. It won’t be a push on the organization. It’ll be a pull from the organization of, can we try this? Sure, let us help you do that. But remove the barriers that get in their way don’t try to force them to do this.

SARAH GREEN CARMICHAEL: Well, and it sounds like also very important to manage by asking questions rather than trying to jump in and fix things if things do go a bit wrong.

DARRELL RIGBY: That’s exactly right. And in my opinion– and I’m a fairly senior executive at Bain– so it always feels good when a team member comes to you and says, gee, I’m stuck. What do you think the answer is? And you say, well, having done this for 40 years, let me tell you what the answer is.

But I have learned over time that it’s a lot better to say, what do you recommend? What do you think the answer is? And then when they come back, say, how could we test that? How would you recommend that we design a test and learn environment to figure out if that’s right or not?

So it’s different for me as well. But it’s much more fun and much more productive when I stick to it.

JEFF SUTHERLAND: Right. It’s facilitative leadership and servant leadership. And it’s the way the best companies work, where they have leadership that brings people up and coaches them to become great, rather than being the great leader telling everybody what to do.

SARAH GREEN CARMICHAEL: I think that’s a great note to end on. Jeff and Darrell, thank you both for taking the time today.

DARRELL RIGBY: Thank you.

JEFF SUTHERLAND: Thank you.

SARAH GREEN CARMICHAEL: That was Darrell Rigby and Jeff Sutherland. They are the co-authors, with Hirotaka Takaeuchi, of the new article “Embracing Agile.” For that article and more, go to hbr.org.

*The speaker has asked us to update the transcript to reflect that he meant to reference an update to the P-38, not the creation of it.