Enterprise Scrum Thinking: Part 3 of 3

Dan Greening explores the challenges of scaling Agile and Scrum concepts beyond the team level to project portfolios with executive involvement. Along the way, he discusses forecasting beyond sprints, commitments vs. lies, dashboard heresy, waterfall compatibility and failing safely, among other thought-provoking ideas. [Part 3: 26 min.]. Interview by Dave Prior at ProjectsAtWork.

Listen to the podcast at http://www.projectsatwork.com/content/PodCasts/275564.cfm.

Did you miss parts 1 and 2? Check out Enterprise Scrum Thinking: Part 1 of 3 and Enterprise Scrum Thinking: Part 2 of 3.

Transcript

Dave Prior: You’re about to listen to part 3 of my interview with Dan Greening on Enterprise Level Scrum.  If you check back on the ProjectsAtWork website, you’d be able to find the additional portions of this interview which were posted previously.

So I was going to ask you one of the question I always get asked is how big can it scale?  What’s the largest we can do without the enterprise collapsing around itself?

Dan Greening: Yeah.  This is in an exploratory topic for me, too. The way I looked at it, there’s a Scrum team, there’s up to seven people in a Scrum team, plus the ScrumMaster and the Product Owner, so that’s nine.  If you move up a level, I think we’re starting to talk about Scrum of Scrums. Lots of people have explored this idea of Scrum of Scrum teams, working together to produce a larger project. The largest Scrum of Scrums group I’ve seen effectively work is about four teams working together.  When you get to seven teams working together, it’s not really producing very well.  You might better have used those three extra teams for something else.

And that’s the same sort of property you see in Scrum teams themselves. The difference between the productivity of a four-person Scrum team and a seven-person Scrum team is not very high.  So adding those three people, it might have gotten you a little bit of speed to market, but not very much.

Similarly, at this Scrum of Scrums layer, you might have three teams working together. You have regular meetings with the Product Owners, the ScrumMasters, maybe a Chief Product Owner and maybe a Chief ScrumMaster, all those people working together to coordinate the interdependencies between those teams.  That can work until you get to about seven.  Seven, you know, it’s kind of stupid to go from six to seven, and maybe it makes sense to go from four to six, but I haven’t seen it work that well.  But, okay, so there you are. Now you have the Scrum of Scrums layer.

When I talk about Enterprise Scrum, we’re talking about portfolio management, now we’re talking about how do we prioritize these projects where each of them is organized in a Scrum of Scrums way.  So at that portfolio layer, now we’re talking about Enterprise Backlog Items that have quantified value and that have some likely finish-state within three to four months, and we’re prioritizing the funding of those things. I would say that you can have more than seven—I’ve certainly seen this.—I’ve had more than seven projects managed at that layer.  You can do maybe 10 -15 of them if every week you go through the whole list. The way we did this, we would have a weekly [Enterprise] Standup Meeting, where we would go through every active project and ask, “What did they do last week?  What are they going to do this week?  And what impediments are in their way of success?”  This was a big meeting where VPs would show up, and we would assess every item.

But then we realized that a lot of these teams were fine, but we wanted to focus executive attention on the projects that were faltering. So we created a scaling model at this level, where we could start to deal with 35 projects running simultaneously. We created a health indicator for every project, actually we had a set indicators. We called them Ready Criteria. That term might imply that we would use this criteria to determine whether to start a project, which is true. But these Ready Criteria were also applicable while the project was running.

I’ll give you an example. Here’s another area where some people will get appalled by what I’m about to say. [laughs] So you know, one of the dangers of Scrum is this attitude that we can’t forecast beyond a sprint.  Like we’ll make a commitment for what we’ll do in a particular sprint, but we won’t make a commitment beyond that.  And actually the problem with that is that isn’t exactly true.

We actually allow the Product Owner to do forecasting beyond the sprint.  In fact that is their responsibility.  And they need to do it to really effectively meet markets as they come up.  But one thing I’ve seen repeatedly in companies is this sort of attitude with the team. The developers are not committed beyond the sprint timeframe, but this has somehow extended to the realm of the Product Owner. It is not true for the Product Owner.  Product owner should forecast beyond the Sprint.

So, at this higher level, when we talk about Enterprise Backlog Items, we always had executives complain that Scrum and agile will not commit to dates. “[Scrum] teams will not commit to dates and that’s a big problem,” they would say.  Okay, so you and I know, if you’re in the agile field, that those commitments in the waterfall world were largely lies.

Dave Prior: I would say they were guesses.

Dan Greening: They were guesses, yeah.  But they were guesses that people knew were wrong.  So that’s why I call them lies, in a way, right?  Because they’re guesses and yet you make the guess, and then the person that hears your guess knows that the last time you gave a guess it was wrong.  And, it’s likely wrong by about 50% and so they sandbag further up the chain.  So if you have a senior manager who says, “Oh, yeah.  You know it’s going to be 12 months,” then the director hears this and says, “Oh, you know last time I heard this 12 month thing it was a lot longer than that.  So I’m going to add 50%.”  So when the director talks to the VP, they say, “Oh, that’s going to be 18 months.  We’re committed to 18 months.” Right?

Dave Prior: Yeah, everybody’s padding in all the way up and then nobody hits it anyway.

Dan Greening: Right.  That’s because none of this is based on any experimental evidence at all.

Dave Prior: Right.

Dan Greening: And that’s the thing that Scrum is supposed to fix.  Okay.  So sorry, back to our original topic, which is, What do we do at the enterprise level to create a health indicator for a project?  So we’ve started to do this: We said, “We want you to create a forecast, we want you first to create a target date.”  So we want the Product Owner to state explicitly, When did they want this project to ship?  And then we have the ScrumMaster on that team calculate a forecast for shipping.  So the only way they can legally create a forecast is if you have a fully populated product backlog for the project.  And so, you have to have a fully populated product backlog, you have to estimate everything in the backlog up through the release date, and then through that those estimates and historic velocity for the team you can forecast when the thing will ship.

Okay so, if the forecast date is past the date of the target articulated by the Product Owner, then we call that project [Enterprise Product Item] Red. It’s in trouble, right?  All indications from Scrum and the statistics indicate that this project will not ship on the date the Product Owner wants it to ship.

Then, at these weekly Enterprise Standup Meetings, we would talk only about the Red items—only the projects that were in trouble.

An interesting thing happened after we started to impose this rule.  The first Enterprise Standup that we had, after imposing this new health indicator, there were I think 35 active projects, and 25 of them were Red.  And why was that?  Well, it was because the Product Owner didn’t have a totally populated backlog, much less an estimated backlog.  They sometimes didn’t have estimates, there were problems because they were dependent on user experience diagrams or information architecture that wasn’t competed, they were dependent on something else and there were huge risks around that.  And so they were Red.

But then, that redness gave an indication to Product Owners that they needed to fix something.  So gradually the number of projects that were Red in any particular week dropped.  And eventually it got to four or five projects that would be Red.  And that was because all of these health rules started incentivizing Product Owners to really deal with the problems in their projects.

Ultimately, we got to a point where if people came up to us as ScrumMasters or me—I was Enterprise ScrumMaster in that case—and say, “Hey, you know, Scrum doesn’t give a date.”  I’m going, “What are you talking about?  Every single project we have has a target date, articulated by the Product Owner, and it also has a forecast date, which is the statistical prediction.  And so, you pick! Which one do you want to use? Do you want to use the date that the Product Owner hypothesizes or not even hypothesizes –wants? Or do you want the date that we are pretty certain we could to deliver to?”

So now, we’re having a very coherent discussion. You can have this discussion with partner companies that are waterfall. You start talking to waterfall companies with these kinds of forecasts and you say, “You know we have historical evidence that we can deliver on time”, because when you have this Scrum structure you really have a lot more experimental evidence behind you, the likelihood that you’re going to hit those dates is really high. And their historic record is horrible, right?

Dave Prior: Well yeah, because they’re just basing it on their guesses, but even though you’ve introduced the heresy of the dashboard, back into the mix [laughs], it’s based on reality so it actually has a positive value.

Dan Greening: Yeah, yeah, exactly. The reason that the people come back and complain about this process, sometimes is they think that when I said, you have to have a fully populated backlog that it means the Product Owner can’t change things after the Sprint that the team is currently working on. That’s not true, actually.

All we say is that you have to specify a target date, you can change the target date.  So if we forecast a date that’s a month after your current target date, you can make your project Green by just moving the target date.

Dave Prior: Yeah.

Dan Greening: All that’s doing is saying, “If you’re honest about the statistics in your target date, we’ll declare you Green, but if you’re hoping against hope that you’re going to deliver a month earlier than the statistics tells us, then you’re Red. That’s just the way it is.

Dave Prior: Cool.

Dan Greening:  And the other thing the Product Owner can do is, of course, is not only move the target date, they can also pull stuff out of the backlog. This is the classic thing that you do with the release burn down, right? You pull stuff out of the backlog, you bring the forecast date in. Now it’s within the target date. Now you’re Green, more power to you!  Or you can swap out features and swap in features.  When we did that, like if you affected the actual [goal] of the project, you would have to have a conversation with the Enterprise Scrum team, you know, these VPs, the Enterprise ScrumMaster, etc.  And the regular ScrumMasters would attend this meeting, so you would have this conversation ahead saying, “We thought we could put 3D into this thing, but it’s going to take longer than we thought, so we’re going to pull that out, I hope that’s okay?”  And people would say of course that’s okay.

Dave Prior: Cool.

Dan Greening: Yeah.  So anyway, that makes a well-operating company and it makes the company compatible with other organizations that do waterfall.  And this is essential, when you deal with mergers.

Dave Prior: Yeah.  Or within the single organization if you had part of it that was agile and part that wasn’t they’d be more compatible there, too.

Dan Greening: Yeah.  Although when I mentioned disturbances in the force, you know, that would cause agile to spin out of operation: a lot of the time, that is the result of mergers. So, when a company purchases another company, oftentimes the company it’s purchasing either doesn’t have agile and the purchasing company does, or vice versa.  And that’s when those surprise clashes happen.

One of the cool things is that startup companies that start agile, tend to stay agile, so that is a pattern that we’ve seen…unless they are acquired by a company that doesn’t have an agile mindset, then you can have this problem.

Dave Prior: Cool.  So I want to go back to the shu ha ri thing. [laughs] The reason I was curious about that is I have heard people use that phrase a lot, and I didn’t want to go around misusing it. I’m really sensitive to things like that. I talked to a friend of mine who is an Aikido instructor and he said, “Okay, go read these books.”  And I read the books, which didn’t really have a lot about shu ha ri in them, but one of the things that I thought was so interesting about Aikido in general was the whole idea of teaching people to fall down. That’s one of the first things you learn in Aikido is you’re going to get knocked on your ass, so let’s teach you how to do that safely.

And you know, it’s applied in other sports as well.  I was talking to Richard Lawrence a while back, and he was talking about how he does downhill mountain biking. One of the first things they teach you is when the bike is going at its own ridiculous speed and you’ve got to bail, how do you do that without dying?  So it’s interesting to me that in sports, we’ll teach people how to fall down and get back up, but in business nobody teaches you how to fail.

In agile, we always talk about fail-early-fail-often, and how important it is to create a culture where failure has value. Any giantly successful businessman is going to tell you how significant failure was to them becoming a success, but we’re all still terrified of it, and we don’t teach people how to navigate it. That’s one of the things that I’m just always really curious about, I mean, you talked about how in the enterprise adaption of agile being able to fail is a big deal.

Dan Greening: Yeah.  But you have to fail in a safe way like you said, right?

Dave Prior: Yeah.

Dan Greening: Initially you have to control that failure.  I like that idea, I’m going to start to incorporate that in my description of shu ha ri, I think.  So I agree you know, like at the beginning you have to be able to do this failure safely.

And of course the cool thing about one month sprints, if you’re really shipping to customers in that period, you can fail safely, right?

Dave Prior: Yeah.  Small pieces.

Dan Greening: Yeah.  You don’t want to risk your brand, that’s the one thing that you have to be careful about, but as long as you call it an alpha and you ship it, I mean, Google has made a whole organizational practice out of that.

Dave Prior: Yeah.  And taken over the world

Dan Greening: Yeah.  Gmail was in beta at least two years following the time I adopted it for my primary email system. [Laughter]

Dave Prior: Yeah.

Dan Greening: So I thought that was pretty hilarious.  Anyway, yeah, this failure is important, and everybody says how important it is and yet it is not culturally adopted by organizations.  And this is the big issue with innovation, actually.

You hear executives talk about how “innovation is really important to the success of our company,” and when they get particularly big, when you have 1,000-1500 people in your organization, yeah, innovation got them where they are, but the larger organizational scale [inhibits innovation and understanding of business drivers]. There’s an act of consciousness at the mid-level manager and above layers in terms of  “What are the metrics that really drive the organization’s success? How do we judge people’s behavior? And how do we fail safely at that level?  All those things, they’re kind of unconscious I would say.

Dave Prior: Yeah.

Dan Greening: Anyway, innovation requires failure. It requires failure.  You cannot really innovate successfully by planning everything upfront perfectly and executing to a plan.

Dave Prior: Right.

Dan Greening: You can’t. If you could, then your competitors would have done it long ago. The rest of the world would have said, “Oh yeah, I’m going to create an iPad and I know exactly what it’s going to look like.  And I’m going to do all these things and I’m not going to fail.”  Well, you know, that doesn’t happen.

Think about the success of the iPad, how it went from nothing to dominating the tablet space in such a short amount of time. Who invented that?  That was Apple.  And what failures did they have before that?  They had the Newton.  What a piece of crap that was, right? [Laughter]

Dave Prior: You know, I know a lot of people that would be willing to go to fist to debate that.

Dan Greening: Yeah.  I had one. [Laughter]

Dan Greening: I had one.  And I’m a fan of Apple, but it experimented, it failed.  And the other thing that you see with Apple is that the interface changes, when they ship new products. They deliberately discard former markets, they basically disrupt their own market.  These are techniques that you would see in an innovating company.

If you have a cautious failure-averse company, you see no innovation. Those companies are likely the ones that will acquire innovation.

Dave Prior: And then kill it off.

Dan Greening: [laughs] Yeah.  That’s true.  That’s true, sadly.

Dave Prior: Yeah.

Dan Greening: Yeah.  If you acquire companies and you don’t recognize that you have to have a failure tolerant culture in order to sustain these companies, then you’re right, they’ll acquire companies and they’ll fail.  So it’s an interesting challenge, but what’s interesting about this is that these agile principles really make it happen, right?

Dave Prior: Yeah.  Cool.  So if people want to learn more about the work that you do or more about your company, we haven’t said anything about your company. Where would they go?

Dan Greening: So, the company I work for is Evolve Beyond.  It’s a partnership between me and Gabrielle Benefield, one of the pioneers in Enterprise Level Agile Adoption. She was at Yahoo.  I think she was the person that really expanded agile throughout Yahoo, initially. Evolve Beyond currently operates in Europe and United States. We have a bunch of consultants and trainers that facilitate enterprise agility and lean product management.  Most all of us have been corporate vice presidents or startup CEOs in the past.  Actually I’ve been both. Anyway, you can go to evolvebeyond.com to find out more about us.

As for me personally I spend about 60% of my time working in United States and 40% of my time in Europe and Russia, mostly for Skype, one of our major clients.

I do enterprise focused Scrum training, helping folks really understand these concepts.  Also do long term consulting to help companies set up agile practices systemically.

To be honest, although I do perform typical agile coach functions, helping teams one on one, usually I move up the management hierarchy pretty fast, talking to mid-level managers and executives. For one thing, simple process and organizational changes at that level could drive you enormous improvements in a company.  And for a second thing, all the hard work coaching a team can go for naught if company policies fail to nurture agility.  I’m not really content anymore to train a team and then just leave it there like a sitting duck.

Anyway, it’s probably good that I’ve been in an executive role before, because I can speak their language and help them understand how they can use agile teams to drive profits higher. And of course, I love this type of work.

Recently I’ve been doing a lot of work with finance departments, and some semi-exotic stuff around how to properly capitalize engineering labor without requiring time tracking and other practices that dampen innovation.  We discovered that weekly time tracking is really accurate actually, and it raises all sorts of questions with auditors and we’ve managed to get around that and create some relatively bulletproof ways to capitalize.

Anyway, honestly, I can talk a lot about this stuff and so I should probably wrap it up.  You ask how people can contact me; just send an email to [email protected]. Since it’s hard to tell what time zone I’m in, that’s the best way to start a conversation.  Anyway, thanks a lot.