Enterprise Scrum Thinking: Part 1 of 3

In the first of 3 podcasts, I discuss how to spread agile approaches beyond individual teams to the enterprise level, where potential benefits and challenges multiply. In the realm of project portfolio management, decision-making roles can include a Chief Product Owner and Enterprise ScrumMaster.

Listen in at http://www.projectsatwork.com/content/PodCasts/275359.cfm [Part 1: 23 min.]

Transcript

The written transcript (with some minor clarifying edits) follows:

Dave Prior: Hi.  This is Dave Prior with ProjectsAtWork and I’m here today with Dan Greening.  And Dan, you’re here to talk about a very specific topic.  But before we get started, could you give the folks a little bit of background about yourself, just in case they’re not familiar with your work?

Dan Greening:  Sure. I’m kind of a jack-of-all-trades sort of guy.  I started out as a research scientist at IBM and then became a start-up guy.  I’ve had a few start-ups behind me. Most recently, I’ve been working with companies that are on a moderate to large size using agile methods initially within teams and then spreading them throughout the enterprise.  And so, recently, that’s my background: How do you deal with enterprises and how do you manage them in a way that helps them make a lot more money with the same amount of staff?

Dave Prior:  Cool.  Okay, great!  When I’m teaching, that’s always one of the biggest topics and I was really glad when I took the CSPO class that you and Jeff [Sutherland] did together that there was a good a bit of time allocated to that topic, because I know it’s sort of a tough spot for a lot of folks.  But when we talk about enterprise level adoption of Agile, how do you differentiate between a company that is trying to spread it and a company that is trying to spread it in an enterprise way?  I mean, is there like a dividing line or criteria where you say “This thing is [sustainable and effective, but that thing] is just you trying to make Agile appear all over the place”?

Dan Greening:  [laughter] All right.  So, you know, most people, when they deploy Agile in a company—and in fact I would recommend this to any company—they start out with a single team, see how it goes, and then it typically goes well, and then that idea spreads through the engineering organization.  It especially works well if you have a senior level executive that is sponsoring this idea. When you have executives that are not necessarily supportive of agile methods, it can take a while for these ideas to spread and certainly, it makes it very difficult to create an enterprise-wide deployment of Agile.

Ultimately, myself and colleagues in the industry have noticed that Agile can take hold in an organization and then it can actually regress.  You can have Agile take hold on a few teams and then it gradually expands.  And then if you get into a situation where executives don’t understand the principles behind the Agile, you can see it disappear, particularly if key people leave the organization who understand those principles, and then there’s a vacuum of understanding at that level.

So, my interest now is, How do you change enterprises so that they are not only supportive of Agile principles at the team level, but also use some of the principles of Agile in their own activities?  A lot of people think that executives and middle level managers have no real use for agile methods and, as a result, they’re sort of ignored.  But the problem with ignoring those levels, the middle level management and the upper level executive layers, is that only by using [agile] techniques do you really start to understand why they are valuable and how they produce value for the company.  So, that’s where I’m spending a lot of my time lately.

Dave Prior: I just want to make sure that I’m straight on it.  What you’re saying is that for it to really survive, the folks that are maybe accustomed to trying to become agile when they have to interact with the IT side of the house, you’re advocating that they begin to use the practices in the rest of their business as well.

Dan Greening:  Yeah.  Ultimately, that’s true.  Although even just within a sphere of a large engineering department, what I’ve often seen is that engineering teams themselves use Agile and then you remove even just one layer up where you’re talking about, you know, managers and senior level managers and directors, those people do not necessarily use Agile methods to guide their activities.

So, middle level managers are really looking at systemic impediments to the organizations productivity.  For example, if you have multiple teams in an organization, they’re all using a single infrastructure for, let’s say, continuous deployment or, how do we educate people about database management principles across the company, and other stuff like that.  Those big topic areas are things that managers really need to attend to.  And if they do a good job, they create a very resilient organization, but the benefits are spread among multiple teams.

So, within a single team, you might do one thing for continuous deployment for your particular team.  But if you’re thinking about the enterprise as a whole, you want to have a uniform mechanism for continuous deployment, because you want all these teams to be producing software that interacts very well in the continuous deployment infrastructure, and you want the continuous deployment infrastructure to actually integrate the work of multiple teams.

So, that requires you to have cross-team interaction and you have to think about impediments over the entire organization rather than a particular team’s experience.  And so, those mid-level managers, they have strategic activities that they do, and those strategic activities can be organized with Scrum.  You can create a backlog of impediments that we’re going to address and you can have Scrum teams of managers who start plowing through these impediments to get incremental work done that removes at least some aspect of the impediment to team success.

If they do a really good job at that level, every time they get one of these, I guess, “managerial backlog items” done, they can actually improve the productivity of multiple teams and they then are using this iterative approach to actually make the whole organization better.  So, that’s one aspect of Enterprise Scrum thinking.

Another form of Enterprise Scrum thinking is a topic that I wrote about which is “How Do You Do Portfolio Management.”  In other words, how do you organize a huge number of engineering projects in a way that prioritizes them for the company’s success and also makes it reduces that risk that you’ll start working on a project that never ends, for example, or a project that is destined to failure.  All these other problems that have occurred in the small for individual teams, they also occur in the large for enterprises. So, whereas with the small team, when you’re dealing with a project that is supposed to go for a year and then takes a year and a half or two years, the cost difference between one year and two years it’s “only about $1,000,000” worth of salary down the tube.

When you’re dealing with enterprises where you have hundreds of engineers making a mistake in terms of prioritization or having some risk in the projects you develop, it can be multiplied by multiple teams, right?  So, instead of $1,000,000 of waste, you might have $10,000,000 of waste at the enterprise level.  That’s why I pay a lot of attention to this enterprise level.  I just think that there’s a lot of opportunity to help improve things at that level.

Dave Prior: It almost sounds like you’re talking about a different role.  Maybe because it’s just looking at things at a higher level, but in the first part of your answer I was thinking, “So there’s almost like a portfolio level ScrumMaster.”

Dan Greening:  Yes.

Dave Prior:  But do you think that that’s going to emerge as a separate role within Scrum for enterprise-level adoption or is that something that you would advocate as being distinct from a traditional ScrumMaster within enterprise adoption?

Dan Greening: I call that person the Enterprise ScrumMaster. So, the first thing I talked about was, how do you organize engineering managers or managers in general to resolve impediments for the organizations?  That’s one thing.  And those teams, they look a lot like just regular Scrum teams because you’re organizing maybe seven people, you might have a Product Owner who would likely be their boss, and then you might have a ScrumMaster who helps them get their stuff done.  So, that looks like a team.  It’s just that instead of doing development, those guys are doing sort of managerial tasks.  So, let’s put that aside for a second.  That is a valuable thing to do in an organization and if you do that, of course, the engineering managers start to really understand the purpose of Scrum and how it benefits them.

Now let’s talk about portfolio management in large organizations.  So, in portfolio management, let’s say, you have an engineering department with 400 engineers.  So, you’re likely dealing with maybe 25, 30 projects that are going on simultaneously.  In a normal organization, in a waterfall organization I would say, the projects that you’re pursuing have enormous timeframes associated with them.  You assign teams to them and the teams are assigned for, let’s say a year and a half, and you sort of commit as an organization to pursuing all those projects simultaneously.  You staff them, largely just due to who demands the most staff, and then you go forward.

If you look at this task of portfolio management in an agile sense, what you start to [see] is that these projects are really like giant backlog items.  Some people call them epics.  Epic is so poorly defined that I don’t really like to use that term.  I use the term Enterprise Backlog Item for those projects that you might pursue in an agile way at this portfolio level.  And these Enterprise Backlog Items have to be time-limited or have to be reasonably sized, so that you could actually complete them and assess, How’s it going? And then decide whether you—the company—should further invest in the project.  It wouldn’t be a 12-month or 18-month project that might go into one of these Enterprise Backlog Items, because then the company incurs a tremendous amount of risk in terms of the amount of spend that it might make to complete a project like that.

So, you can think of a team as really about $1.5 million per year, if you add up the cost of the salaries plus all of the administrative cost around the team.  So, if one team is $1.5 million a year, you’re risking a couple of million dollars … on a project if you never test it with the market, you know, during the timeframe of let’s say 18 months.  Instead, what I think you should do is try to figure out how to create customer value in three months or less.  That’s how I like to define Enterprise Backlog Items. You give them enough time that they can actually produce something of value that they can release, but you don’t give them so much time that they incur enormous risk in the company.

So, now you have an Enterprise Backlog Item and I say it should last no more than three months.  It can have multiple teams working on it just as you can have multiple people working on a regular Product Backlog Item.  Now, we’re moving up in scale, right?  Now, we’re deploying teams rather than people at this level.  And now, decisions about whether to pursue an Enterprise Backlog Item or not … are roughly million dollars decisions.  You can think of them that way.

So, you’re right, there is a role for an Enterprise ScrumMaster.  And there is a role for a Chief Product Owner.  So, sometimes in companies, you have a Chief Product Owner who is the CEO.  Sometimes the Chief Product Owner is a VP of Product Management.  But regardless, you need one person to make judgment calls about roughly what prioritization to put on major projects that the company pursues.  And that Chief Product Owner role turns out to be an extremely important role.  …  They are sort of like the King Solomon of your company.  They are the person that says “Hey, you know what? You know, one person wants the funding, another person wants the funding.  I guess I could split the funding in two and give each of you half of the funding.  But each of your projects will go half as fast.”

And the problem with that judgment, just like King Solomon’s judgment, that you know, splitting the baby is not necessarily the most appropriate way to deal with a problem [laughter].  Similarly, splitting the funding is not necessarily a good way to deal with a confusing problem about which project to fund.  Instead, you should look at this project and say, “Okay, which project is either going to earn us the most money or save us the most money in the long run?”  And whatever that amount of money, you know, whatever that profitability is, we should fund the one that’s going to bring the most to us.  Because if we get more profit from that top priority project, that profit could be used to fund this other project later. The end result is that the company makes a lot more money overall, if it does prioritize these projects where the most profitable project is first, and gets the lion’s share or all of the funding while the other one maybe doesn’t get any funding, doesn’t get started.

So, that Chief Product Owner has a difficult job.  Because usually, you have regular product owners underneath that person who are all, you know, really invested personally and emotionally in their particular project.  But when push comes to shove, somebody has to make a decision.  You know, in a good company, someone will make a decision about what is the most important thing to fund.

So, now, I’ve talked about a Chief Product Owner and I’ve talked about an Enterprise ScrumMaster, and then, for them, the enterprise team, is a collection of scrum teams, right?  That basically, they fund the project by staffing it with a bunch of scrum teams, saying “Hey, you know, let’s put this other teams on this particular project and let’s let it go.”  And so, I – you know, there’s a lot of nuances around that and a lot of political issues around that, but when you get it right, you actually make a lot more money.  So, I’ve seen this now in a couple of companies. These ideas are starting to spread among more companies than just those few that were the initial starting point.

Dave Prior:  So, the Chief Product Owner, it sounded like you had sort of specific guidelines around how they prioritize [the Enterprise Backlog] as opposed to saying “Here’s nine different techniques. Use whichever one fits best for you.” When you’re coaching people into that role, is it really more of a financial “What’s going to bring in the most cash the quickest?” or are there other techniques that you advocate they use, also?

Dan Greening:  Well, you know, there are other techniques of course.  So, you can use any of the ranking techniques—you know, Innovation Games [a training company] focuses on different prioritization techniques for backlogs, product backlog items for example.  They focus on How can you incorporate the needs of multiple stakeholders in your prioritization process, so that your outcome satisfies the most stakeholders you can?  Those are extremely suitable for product backlog items because at the product backlog item level, you don’t really want to do a financial analysis for every single product backlog item.  You want to have some intuition involved and you want to have some simple strategies for roughly approximating value.  Because if you actually go down to calculate the profitability of different decisions at that level, it will just take way too long and your product owners will be overwhelmed.  So, that just doesn’t work at that level.

At the Enterprise Scrum level, it can work. You have to be really careful about it because a lot of bean counters will go in and say “Hey, you know, I’m looking for a spreadsheet on every one of these Enterprise Backlog Items that tells me where you’re going to earn the money, or where you’re going to get the cost savings, and exactly how much, and I’m going to use that in my financial forecast and blah, blah, blah.”  I’m not necessarily into that level of detail at that Enterprise Backlog Item level, but I would look for some financial maturity at that level.  Because to make decisions on any other basis—you can make decisions on other bases, but you should make it explicit. For example, “We are not making our prioritization decisions entirely based on finance. They’re also based on the moral values of the company, and here’s our mission.” In this example, some things will satisfy finance.  Other things will satisfy our
mission.  But there’s a lot of clarity around how you prioritize backlog items.  As long as that clarity is there, I’m a happy camper.

Dave Prior:  Okay.

Dan Greening:  In most cases, though, I would say that even enterprises do not make decisions based on criteria other than squeaky wheel.

Dave Prior:  Yeah.  [laughter]

Dan Greening:  So, squeaky wheel, you know, it—I guess it’s better than nothing.  But in many cases, squeaky wheel means that a particular person always gets their prioritization accepted and other people who are quieter may not.  And that may be to the detriment of the company overall.

Dave Prior:  Yeah.  Okay.

Thanks for listening to Part One of my interview with Dan Greening.  Make sure to check back on the ProjectsAtWork website for the 2 following segments from this interview.

Dan can be reached sending him an email at [email protected].