5 Agile Leadership Patterns

A epiphany came to Dan Greening in one of many conversations he had with Jeff Sutherland on the topic of why so many organizations claim to be Agile without actually being Agile. The epiphany was this: an Agile organization needs Agile leadership. It is common today for organizations to claim to have implemented Scrum and failed, then to move on to another framework like Kanban only to have that fail as well. These same organizations may then move on to Lean Startup. The trend lines in Dan’s research indicated peaks and valleys were huge as corporations hired on, and then fired off, mass quantities of coaches. Dan wanted to know why that was the case. After more research, he found corroborating evidence for his suspicions: businesses who retain their agility do so under the auspices of truly Agile leadership.


Brent Barton: Hi I’m Brent Barton and today I have Dan Greening. Hi Dan.

Dan Greening: Hey, man.

BB: You just finished an interesting talk on Agile leadership patterns.

DG: Yeah with Jeff Sutherland.

BB: That went well?

DG: Yeah, it went really well.

BB: I’m passionate about agile leadership, because as we get into bigger and more complex environments, it’s becoming more and more evident that they’re critical to our success.

DG: Right.

BB: Tell us more about your perspective on that.

DG: One of the things that I’ve discovered, and you’ve probably discovered this too, is that we think of Agile, at least initially, as an engineering problem. Okay, it takes a long time for us to do this, the projects sometimes fail, they’re overbudget and over-time. So we started out trying to fix engineering. And we did, largely. We have Scrum, Kanban, XP, all these other great things. But then, first of all, it’s hard to do, so we hire a bunch of coaches to do that and then it costs a lot of money. Then I started seeing large companies hiring massive numbers of coaches, an army of coaches, at millions of dollars per year in cost. They would hire them, they would convert the engineering department. Someone in the finance department would go, “Wow, this is really expensive. Do we have to keep these people around?” Someone says, “We’re Agile already — we don’t need them anymore, we’re converted.” The coaches go away and guess what? Agile would revert. We would get in the situation where the teams wouldn’t have this high level of Agile thinking anymore in the way that Agile would go. And then they would go, “Oh my god, our release times have gone from one month to six months, nine months, twelve months.” So, two years later, after they fired all the coaches, they go, “We better do something.” Someone says, “Well, that was Scum, now we ought to use Kanban.” So, they hire a bunch of Kanban people. Then I saw one recently where they go, “Yeah, that was Scrum and then we did Kanban, and now we should use something different called Lean Startup. That’s the thing!” And I’m going like, “That’s hilarious because Lean Startup is an Agile method but it’s not a replacement for Scrum or Kanban; it’s actually dealing with market-side stuff, product management. And so they can be used really effectively together. And then you see, you look at these peaks and valleys of hired coaches. What’s the issue here? So Jeff Sutherland and I have been hanging out and I’ve been complaining to Jeff for the last five years about this, and he said, “You know, I think one of the things is: who are the leaders?” And he and I started comparing notes, and we’re going, “Oh my god, is the leader Agile themselves? Do they run their company in an Agile way? Do they think about their work in an Agile way?” When we saw that, we saw that agility was retained. And often times they can create agility themselves and maintain it themselves. And then what we would also see is this pattern where a leader might get fired, or leave, or whatever, and then agility would disappear.


Learn more about how to lead effectively in today’s rapidly changing world in our upcoming webinar “Leadership Effectiveness: Guiding the Way to Business Agility” – the second installment in our Business Agility Webinar Series.

Register Now

BB: What does it mean to be an Agile leader in the context you just described?

DG: That was my first cut. I said, “Ok, I want to tackle that.” Because I’ve been dealing with big companies: I’ve been working with Skype, Citrix and other companies like that. So I said, “What is it about this?” And then I realized, I didn’t really have a good definition for agility. I can go to the Agile manifesto and it’s got some guidance for software developers. If you read it, it’s all about software. I think finance people, marketing people, everybody can be Agile if it suits their economics needs, and it usually does. So, I said, “Before I even tackle leaders and enterprises, I’ve got to figure out what agility is and what it’s defined by.”

So, I looked at all of our Agile practices and what purposes they serve. And what I think of as “chaotic economies.” Production is a chaotic economy, and Scrum works really well for that. Market product management is a chaotic economy, and Lean Startup works really well for that. So, what’s going on there? It’s all about sensing, adapting, and creating new things for an economy and doing it fast enough that you can adapt to the changes that might be occurring. So I came up with five patterns and they’re actually really simple. The first thing is you have to measure some leading indicator about your economy. In scrum, it’s about production. We have to produce something and the big indicators are cost. A leading indicator of cost is velocity. That’s a primary metric. If you just use velocity, though, it gets a little perverse. You start doing high velocity and then you produce crap. So we have to have something else to balance that off to make it not so perverse, so we use defect rate. Then you have both of those and and then we go, “We want our people to be happy, because when they’re happy, they produce more creative output.” We add happiness. So, they’re three metrics that lots of people like to use, Jeff and I especially; velocity, happiness, and defect rate. That pattern, measuring [a] leading indicator, is step number one. If you don’t know what your economy is, why you are doing it and what are some leading indicators that you’re making the right choices — you’re doomed for Agile. You can’t do it.

The second thing is you have to experiment, you have to adaptively experiment to improve. When you do that, you’re looking at your metrics and you’re trying new things. Like our retrospectives. We try new Definitions of Done, Definitions of Ready. We see: does it improve things or not improve things? Today most retrospectives are pretty lame, I have to admit. A lot of people phone it in. Yet that’s the center piece of Scrum really. If you’re really doing a good retrospective, you’ll see this acceleration of velocity. If you’re phoning in your retrospective, you might be better than waterfall, but not by much. So that’s the experimentation side.

The third thing — and these three things give you agility — the third thing is limiting work in process. You can measure stuff and experiment, but if the length time or amount of work to run those experiments is too big, you’re going to be a lot slower than the chaotic economy that you live in. So, if you limit the work in process, you’re going to be fast enough, then you’re doing all the right things. My assertion is, if you’re doing those three things, you are Agile. The problem is, doing those three things is really hard.

BB: That’s true.

DG: Like, you’re measuring stuff and guess what? You’re starting to tell the truth, and people are getting embarrassed, and guess what? They really wish you weren’t doing that. So then you’re experimenting and guess what? Sometimes you fail and sometimes people are uncomfortable about that. And that uncomfortableness is another pressure to stop doing Agile. You’re limiting work in process. And the people are saying around you, “Oh my god, my project is so important. Can’t you do a little on my project?”

BB: Just fit that in. It’s not that big!

DG: Yeah. So there’s pressure everywhere to be not Agile. So those three things are hard, and I’ve realized we do things in Agile to reinforce it a little bit. And one of those things is we embrace collective responsibility. Here’s what I mean by that. When you join a team, you can say, “I’m a developer.” And another person can join the team and say, “I’m a tester.” Then you start doing your thing and the developer gets done. The testing doesn’t get done. You get to the end of the sprint, it doesn’t ship. Someone says, “Here’s a failure. We couldn’t ship it.” You go to the developer and ask, “What went wrong?” The developer blames somebody else. The developer says, “Not my problem, I’m a developer. It’s the tester that did it. The problem, though, is as your project matures, testing becomes more and more of a dominant factor.

BB: Right.

DG: So, we didn’t shift, this developer didn’t shift their responsibility over to deal with that. They just said, “My job is this.” So collective responsibility says I join this team and I agree — I write a contract by joining this team — that I will be personally responsible for the collective output of the team. That puts enormous pressure on individuals to really make up for deficiencies in the team. But the result is higher agility. Now people are adapting with the flow of work that’s coming into the team to deliver value. So, that fourth thing provides enormous stability for Agile teams and we see that in training. XP, it’s all about together as a team, collective code ownership —  as another subpattern of that.

BB: For sure.

DG: And then the last pattern is, you’re often working in a system that is limiting your agility. So here I am on a team and I depend on stuff from other teams, let’s say. And they are slow. And I’m going, “Okay, I’m Agile, I can just ship, ship, ship. But I keep depending on this stuff from this other group that is doing two-month sprints.” It takes them two months to actually give me something releasable. So, that pattern solves systemic problems. So now what’s happening instead of looking at my little team, I start looking around my team and say, “What’s going on in the system around me that is limiting my agility?” And it turns out there’s all these teams I depend on. And so what happens is that encourages people to go out and reach out to those teams and help them. So, famously, Toyota did this, when it was doing just-in-time manufacturing. It’s trying to build these cars, someone makes an order, and then you start doing all the stuff to build the car. Well, they would get all the way down to the tires, and then they would go, “We don’t build tires; we buy those.” So, they went out to the tire manufacturer and said, “Hey, could you make some tires for me? I just got an order.” The tire manufacturer goes, “We do this on a quarterly cycle. We sent you the memo; you didn’t read it. You’re supposed to pre-order however many tires you need for the cars you’re going to build. Well, how many cars are you going to build?” And Toyota goes, “We’re just-in-time — we don’t know!” So they finally got frustrated and said, “Well, I guess we could be a tire manufacturer, but we’re not great at that. Here’s the next best thing: we’ll go out and teach the tire manufacturer how to do just-in-time.” And that’s exactly what they did. And by doing that they actually created kind of an infrastructure of just-in-time in Japan. And we started seeing Honda and other car manufacturers start to adopt this strategy because they could. Their tire manufacturers were Agile and they were sitting there like, sitting on their butts really, but they were like, “Oh, we can do that. We have all these great service providers…”

So, those five things: measuring economic progress, so, leading indicators. Adaptively experimenting for improvement. Limit work in process. And now you are Agile. You won’t be able to keep it unless you do a couple more things: Embracing collective responsibility, creating a culture where individual people feel responsible. And finally, solving systemic problems. And that gets us back to leadership. Right? So, now I’m going, “This is great! I’ve got a definition of agility, I’ve got these patterns, and guess what? They’re totally scalable.” I can go to an individual and I can say, “Hey, Brent I can tell whether you’re Agile by just interviewing you and asking some questions about how you run your life.”

BB: Right.


DG: Or I could go to you as a team or as an executive and say, “Hey, let’s find out if your organization is Agile or not. What are you measuring? What are you experimenting on? What’s your work in process limit?” And this is important. It’s important on so many scales. One is, as an executive, do you have a team of people dealing with strategic work? I call them strategic Scrum teams, where you got a bunch of VPs or directors in a room and you’ve got strategic work and a backlog and you’re plowing through it and solving major problems for companies. Another thing you can do is, you’re hiring someone for a position in a company that is Agile. And I’m going, “You know what? You shouldn’t be hiring someone who answers those five questions in a funny way.” That’s how you tell they’re Agile, not ‘that they wrote on their resume, “I know Agile” or “I know Scrum” or whatever it is. CSM! Or I was a CEO at such a thing… It means nothing. Let’s find out the reality behind the system.

BB: Sounds like these are a consumable set of patterns for leaders to really evaluate and participate in the agility in an organization.

DG: Absolutely.

BB: That’s great. I’d love to probe further about the finance groups and all of these these other things and see how those teams are. We must do this again.

DG: Great to talk to you, Brent.

BB: Thanks, Dan.