Achieving the Big Picture Business Results You Expect from Scrum

Kevin: Yes. We’re really excited to have you here, actually, Kenny. You know, as you know, OpenView is an organization that’s very committed to Scrum. It something that we practice here, internally, and that certainly we encourage our portfolio companies to do, as well. So, you know, I’m really anxious to get some perspective from you about Scrum and sort of some of the details around it, today. So, you know, to kind of start that off, I was wondering, with a real softball question, but, can you kind of explain to our listeners what Scrum actually is, in a nutshell?

Kenny: Sure. I’d be happy to. The best way to think about Scrum is it’s a framework. It’s a framework for developing products and for managing work, and it’s based on a set of very simple principles that, when applied appropriately, help an organization, really maximize their investment in that kind of development effort. So, the simple part of it is, you know, the team works off a prioritized backlog. I think of that as a list of the work that needs to be done. It’s put into a particular order that the product owner, the person who is responsible for, overall, what we should build and the order in which we should build it, puts that list in the appropriate order, and, then, the team works in these short-duration iterations, which we’ll call “sprints,” typically a few weeks, up to about a month in duration. During each Sprint, you know, the team decides on a subset of the high-priority work to pull into that sprint, to work on. Then, they move in and actually do the work, and, at the end, they’re supposed to have something that is done, what often is referred to as “potentially shippable” or “potentially releasable,” and, at that point, the business can either take what they just built and put it into the marketplace, or, perhaps they don’t have enough of it yet. So, they do another sprint and eventually they do, and then they release. At the end of every Sprint, the team does two inspect and adapt events. The first is the inspect and adapt on the product that’s being built, called the “sprint review,” and the second is the inspect and adapt on the process called “the sprint retrospective.” And, then, in essence, you rinse and repeat, repeat the process, and, after doing it a sufficient number of times, they have completed the work there intending to complete.

Kevin: So, you know, as I mentioned earlier, we use Scrum here at OpenView and I think being a, you know, a venture capital firm, our application is perhaps a little bit different from the traditional one of software [inaudible 03: 06], and we primarily use it as a tool to help us, you know, be really organized, get focused on what our top priorities are and to have, you know, sort of transparency and visibility in what each person on the team is doing. You know, those are sort of the immediate benefits that come to mind, for me, of Scrum, but, you know, in your experience, what are sort of the more holistic benefits of Scrum?

Kenny: It’s a really good question. You know, first I’d like to think that we’re going to have delighted customers. The idea that a
customer somehow, on the first day, when they have the worst possible knowledge they’ll ever have about what they want, can
definitively describe what it is we should build for them and, really, get that right. It’s probably not very practical. So, the idea behind Scrum is that we build things more iteratively and incrementally, the goal being that we actually get people what they really need, not what they asked for on the first day when they didn’t really know very well. So, in addition to that, we are able to get multiple points of feedback. Right? Rather than writing a requirements document on the first day and then coming back at the end of the project to see what was delivered, where the surprise, disappointment, frustration might set in, in Scrum, we get feedback every two weeks or every three weeks or whatever the sprint length might be. It’s a lot easier for customers or stakeholders to stay involved. So, I do think the overall effectiveness and the happiness of the customers can go up. To me, that’s a large benefit. Second, I would like to think that the economics of the situation are improved, meaning a better return on investment, meaning, in scrum, we deliver features at a time, not phases at a time. A typical waterfall style development is phased-based, sequential, plan-driven, and, in that model, you really don’t give value until the very end. In Scrum, where we build every couple weeks, all right, we have the ability to get features done every couple weeks, and the ability to, then, deliver those features. The ability to deliver features today is more valuable than delivering them in the
future, because features, today, generate revenue today, and money today is worth more than money tomorrow because money has
a time value.

So, we have every opportunity to improve the overall ROI. Part of that would be reducing costs. All right, by the way we focus 0n the work, right, and the speed at which we do things and the waste elimination that we’re able to bring to bear, meaning not doing things that don’t have to be done, don’t do the work any sooner than you actually have to do it, makes things more cost- effective, which, again, reinforces the return on investment, and, you know, in the spirit of . . . that we work in a very complex world. I mean, you think about, you know, OpenView Partners and, you know, companies in general, you work in a very complex world. It’s a world that you, yourselves cannot control, meaning that the environment, itself, can change on you and you have no control over those changes, but, yet, you have to adapt to them. I think Scrum, one of the core benefits of Scrum, is giving us confidence to succeed in a complex world, where other approaches that assume more stability in the environment won’t be as well-attuned to our needs. And, then, I guess, the last one, I like to refer to as “generally more joy,” the idea that, you know, people who work on Scrum projects tend to be happy. Why? Because they get to build things quickly that people get to use, and, being a technical person, you know, by origin, what gets technical people excited is the ability to build real things, get them in the hands of customers and have them use them. There’s no technical person I’ve ever met who would like to build something that will never see the light of day.

Kevin: Sure.

Kenny: And you put people on a waterfall-style project, something that, you know, it’s a year worth of development, but, before you deliver anything, by the end of that effort, the joy of the people is diminished and you have people at that point to would willingly pay you money if you would assign them to a different project. Right? On Scrum, we build something every few weeks, and we get to re-energize the team every few weeks. So, the list of benefits goes on, but those would be kind of my top contenders.

Kevin: So, with so many different benefits available from scrum, you know, it would seem like a no-brainer for companies to adopt it, yet, you know, my assumption is that it’s not always quite that simple. You know, what are some of the things that you need to do at the, you know, decision-making, executive level to really assure that Scrum gets adopted?

Kenny: Now, another excellent question. All right. In my experience … I’m a trainer and a coach. I fly around the world and, typically, every week I’m with one or two different companies, somewhere around the world, getting to see what they do, and I will frequently go into an organization and see their teams that have adopted Scrum, actually doing fairly good Scrum, meaning the basic blocking and tackling of they do look good. And, then, you have to ask the obvious question, “If the teams adopt Scrum, and they’re executing in a manner in which you would expect a Scrum team to execute, can the business naturally assumed they will get the benefits that we’ve been talking about?” and, really, the sad part of that, the answer there is, “Not necessarily.” Right? There are some real inhibitors to using Scrum successfully that occur at a level beyond the single team. For example, in my experience, I’ve seen three categories of issues. The first I would call, I guess, “the ignorance or misapplication of core agile principles during development,” just a failure to understand, and I’ll happily give some examples.

Kevin: Yes. That would be great.

Kenny: Now, list all . . . I’ll give you three inhibitors. The second, I would call “the failure to apply agile principles through the value chain,” and the third I would say would be “the failure to structure teams in an economically-sensible way.” So, let me tell you what I mean by that. First, I talk about principles. You know, Scrum is a particular realization of agile. Agile has a core set of principles, you know, some things that most people are familiar with: keep your options open; favor and adaptive over an exploratory approach; you know, embrace change in an economically-sensible way; try to validate your important assumptions fast; you know, organize your work for fast feedback; you know, recognize you, you do have inventory and product development and you need to manage it for good flow; you know, don’t worry about idle workers; worry about idle work, things like that. So, when I talk about, you know, people . . . organizations that have an ignorance or misapplication of core agile principles, it’s failing to understand those principles, and making decisions in what otherwise would seem like an economically-sensible way. I’ll give you an example. Question for you: have you ever gone into a restaurant where they have available tables and yet they won’t seat your party?

Kevin: I have.

Kenny: You know, good. Right? I think we all have had that happen, and the question is, “Why?” You know, a good entrepreneur, or a good restauranteur knows that if three of their servers didn’t show up for work that day, you know, they have pretty good idea what’s going to happen if they seat my party at that table. All right, I mean, I’m sure you’ve had this happen. Right? It takes 40 minutes for them to come by and bring you water.

Kevin: Exactly.

Kenny: I’m sorry. Nobody’s that patient. Actually, the scenario is much, much worse. Right? I mean, what if they’re actually foolish enough to seek my party at that table? Then you have asked the question, “What happens to the service of all of the tables in that restaurant?” and we know. We’ve all been there. Right? Everybody’s service goes down. The reason I use that as an example is, on Easter Sunday this past year, I took my family to a local burger and fries place and we had that happen, but the difference was, rather than tell us at the door, “Sir, you know, we’re a little lightly staffed, given its Easter Sunday. It’s going to be 45 minutes, really, before we can seat you.” They actually sat us and we got horrible service.

Kevin: Right.

Kenny: Now, I’m not inclined to want to go back to the restaurant. So, my point is, the restaurant or the manager of that restaurant made a choice. That choice was to seat people at the table, which, in a myopic sense, economically looked good. I’ll bet his revenue, his profit for that evening was pretty good. He had a small number of servers working and he over-sat the restaurant. So, he probably generated a lot of revenue, relative to the number of servers, but he didn’t consider the economic framework in which that decision was being made, meaning, the long-term delight . . . how delighted his customers would be in coming back, and, you know, we’re simply not motivated to want to go back to that restaurant, again, after the bad experience. Now, translate that. I see a lot of companies where the way they approach Scrum is to make decisions just like that restauranteur. They don’t understand the core principles, so they make what looks like a reasonable decision: seat the party at the table, but, in reality, it’s not. It has grander, longer-term consequences, and, since they don’t apply those principles in an economically-sensible way, that’s why a lot of these organizations are not going to see the value they expect. Right? And I can give other examples here, as well.

Kevin: Sure. Yes. This is great.

Kenny: All right. So, I often get asked this question, “What you mean when you say ‘economically-sensible Scrum’?” Well, I’ve described what Scrum is, you know, through the first discussion we had. Now, imagine that framework has to reside on top of the core economic framework for decision-making. The core framework, itself, is based on agile principles, you know, the ones like I mentioned earlier, you know, don’t worry about idle workers; worry about idle work, things like that. So, economically-sensible Scrum is running your scrum in the context of that framework, which implies that you have to have an economic framework. Where this becomes important is you have to have some way of comparing the different trade-offs, the different decisions within an organization. All right. And most organizations try to compare these decisions in variables that are in different units. You know, somebody says, “We should make the following change because it will reduce waste.” Someone else might say, “We should make the following change because it
increases customer satisfaction by five percentage points.” Which is the better thing to do? The one that reduces, you know, $50,000 of waste, or $500,000 of waste or the one that increases customer satisfaction by 5%? The problem, of course, is there and totally non-comparable units. I have no way of saying whether the $500,000 in waste is better or worse than a 5% increase in customer sat.

Kevin: Right.

Kenny: So, you have to translate all the variables into a single variable that I’ll call “life cycle profits,” and I’m borrowing this idea from Don Reinertsen [SP] out of his book Flow, the idea being simple, you make all of your decisions in an economic framework, where the goal is to maximize life cycle profits, because most companies are in the business of generating profit, and, even if you’re a nonprofit, if you fail to generate ongoing revenue, you won’t be a nonprofit for very long. Right? You won’t be able to sustain your operation. So, life cycle profits provides sort of that foundation for doing it. Then, once you have that framework in place, you can do . . . Let me use that
waste example. So, I’ll give you one deeper example. In product development, we actually have inventory, and I said one of the core principles of agile is “Recognize you have the inventory and manage it for good flow.” Well, the problem with our inventory . . . When I talk about inventory, I mean like a requirements document that might get written or a project plan that goes up on the wall or a design, and architecture the gets put together up front. I call those “an inventory” because, until you actually build those things and put them into a system than the inventory that sits on a manufacturing floor.

I mean, think about it for a minute and think about the waste. Now, use the manufacturing example for moment. Let’s say that we design a product to manufacture. We order a truckload of parts. The truck shows up at the manufacturing plant. It deposits the parts on the floor, and the truck then leaves. Let’s say that after that happens, where we now own the parts, we change the design of our product. Well, question what do we do with the parts? You know, and as you start to think about this, you realize, “Well, I don’t know. I guess I could scrap them, or maybe I sell them on eBay for pennies on the dollar, or maybe I can rework them to fit in the new design, or, worse yet, maybe I compromise the new design to use the parts I already bought,” but, in any way you think about it, we’ve now incurred one or more forms of waste, potentially, to the tune of 100%, and, so, our inventory and product development has the same characteristics. You produce a lot of inventory, create a lot of items in your batch. If something changes once you do that, you may have to, then, rework or throw it out, and it becomes very, very expensive. So, I watch organizations do this all the time. The problem is that, in our world, unlike manufacturing, where inventory is both physically visible . . . You can touch it. It sits on the floor. And, financially visible. In our world, product development, inventory is both physically invisible and financially invisible. I mean, most of our inventory and product development fits on a disc. It’s hard to see that. How you manage what you can’t see? It’s also financially invisible. See,
if I ask the CFO of a manufacturing company, “How much inventory is in your factory?” this guy’s going to give me an immediate answer. “No. We have a half-million dollars of inventory in the factory.” I asked that same question to the CFO of a product
development company, “If I go to one of your, you know, one of your partner companies, a company that [inaudible 17:08] invest, and I go ‘How much inventory do you have in product development?’ I might hear back ‘None.’ Right? Look. Look here at the balance sheet. There’s no line item for inventory on the balance sheet.” The problem is, we do have inventory, but it’s invisible. Therefore, it’s hard to see and how do you measure and track something you can’t see?

So, when we make decisions on how to do our work, how to organize it, one of our core goals is to make the inventory visible, and, now, I can give you an example of where I see companies messing up all the time. I said one of the principles was “focus on idle work, not idle workers.” Here’s what I mean. Let’s have hire you into my company to do testing and I pay you 100% salary to do testing. I have an expectation that you should probably test about 100% of the time, since I paying you full salary. I don’t think that’s unreasonable. The problem is, what if I hire you and then I assign you to one project and that project requires you only 60% of your time? It will give the
appearance that your underutilized by 40%. Well, in a lot of organizations . . . I’m talking about . . . Remember, where I was saying, sometimes the organization isn’t economically embracing these principles and, therefore, their teams to have very hard time acting in a Scrum-like way. I assigned you to one project and someone goes, “Well, that’s a 40% under utilization waste of the tester. That’s not good,” and I’ll do what most companies do, I assign you to a second project. They need to 30%. Okay, now I got you 90% utilization. It worked so well the second time, I’ll do it a third time. Now you’re at 100%. Clever me, I have eliminated idle tester waste, but at what cost? Let me give you an analogy to tie this all together, now. If I apply that same strategy to the 4 x 100 m relay race at the Olympics, the “let’s keep them 100% busy” strategy, then, the first observation of that race would be, “That is a very inefficient race.” It is, right? I pay those runners 100% salary. I expect them to run 100% of the time.

Kevin: Right.

Kenny: And, of course, the runners are going to look at me and go, “Oh, well, I don’t understand. What do you want me to do when I’m carrying the baton, when I’m not carrying the baton?” “I don’t know. Why don’t you, like, run up and down the stands, or something?” Remember, I’m trying to keep him 100% busy. “Or, better yet, there’s another racetrack right over there. Why don’t you run another race over there while you’re waiting for the baton over here?” Congratulations. I have now figured out how to eliminate I don’t run a waste, completely missing the point you don’t win that race by keeping the runners busy; you win the race by getting the baton across the finish line first, leading to the observation: “We’re watching the wrong thing.” In that race, you don’t watch the runners; you watch the baton, and if the baton ends up on the ground, you have a problem. You won’t win the gold medal. Now, let’s translate it back. The
baton, that’s our work. That’s the work that we, as a company, need to get done and deliver to our customers, and our goal is to flow that work across the system in a fast, flexible and economically-sensible way. The problem is, the way most organizations have set themselves up, they are going to drop the batons over 90% of the time, which means, if you were to click a stopwatch when someone asks for a feature, and you didn’t click that stopwatch again until the feature was delivered . . . What I’m saying is, in a lot of the organizations I visit, 90% of the time, the work isn’t flowing. It’s blocked. My team is waiting on that team over there to get some work done. Until they do their piece, we can’t move forward. The end result, we’re not doing economically-sensible Scrum.

So, this is a detailed example that I see in pretty much every company I visit of how I can make the conclusion, even if the Scrum teams are operating in an excellent way, great Scrum blocking and tackling, decisions being made at the organization level. Let’s assign people to all these different teams at the same time, will interfere with the fast and flexible flow of the work, which goes against the whole economics of what we’re trying to do. You want to solve these problems you will not solve them at a team level. All right? You only solve them at an organizational level, because the teams didn’t make that decision; management made that decision. All right, and the list goes on. I mean, you look at companies that failed to adopt agile through the value chain, right, meaning, they bring in agile, they bring in Scrum into the development organization and they don’t worry about, you know, what happens all around them, downstream in operations, upstream in sales and marketing. What about management and legal, HR, finance? One of the things I like about what you guys do at OpenView is you look at bringing Scrum in across the entire value chain, from the Board of Directors all the way down to the development team. That’s the way you want to be successful. Long-term, if you only do Scrum at the development-team level and fail to adopt it through the value chain, you won’t get the long-term benefits of Scrum.  You’ll get blocked, either upstream or downstream.

Kevin: Well, why don’t we dig into that a little bit more. You know, Scrum was something that was initially designed for software development and the development team. So, you know, can you expand on some of your ideas and best practices for how to apply Scrum more broadly, through the entire value chain, across your management, etc.?

Kenny: Sure. It’s actually a really great question. Right? First, if you think about internal management, here’s the classic disconnect that I hear when I go visit companies: “Oh. Yes. Yes. You guys downstream, you get to develop in and agile-like way but you still have to provide me with all those same plan- driven artifacts that you’re used to giving me, you know, the upfront requirements, the full budgets, the precise schedule, all that stuff, before I’ll even improve your work.” Okay. Obviously, this is a very big disconnect. Essentially, it’s like “You guys downstream, be agile; we won’t, over here.” Well, the problem, of course, is that disrupts the behavior of the team, because, in an agile environment, using Scrum, we wouldn’t do many of the things I just said. We wouldn’t put the full requirements document together. We wouldn’t produce, you know, an entire project plan, put an 18 month Gantt chart on the wall. So, the first thing we have to do is get management into the room and help them understand that if they start the process off, you know, disconnecting everything, then, downstream, they shouldn’t expect their teams to be wildly-successful with Scrum, because they’ve already put them behind the eight ball. So, the first thing you have to do is get management into the room and do executive-level training with them, if nothing else, to help them understand the economic framework in which these decisions have to be made.

I mean, goes even further. Like, think about sales. You know, in many organizations I’ll visit, sales will go out and sell customers on an idea, come back in with the proverbial “napkin.” On the napkin, it’s listed what they just sold and the date in which it has to be delivered. Right, so . . . Oh. And maybe they’ve agreed to do it at a fixed price. They’ve got a fixed- price contract as well. Now, they’ve constrained all the variables, date, scope and budget. The team has no flexibility to maneuver when trying to build this system. So, what you have to do? You have to tell sales, “You need to engage our customers in and agile-like way. You can’t just run out there and do things like you’re used to doing, because that will disconnect us downstream, and it will be very hard for us to run engineering in and agile-like way, when you’ve over constrained the problem, you know, on the first day.” Oh, and the biggest, to me, and I do like a 90 minute presentation just on this: portfolio-level planning. It’s rare that I’ll go into a company and their portfolio-level planning has any resemblance, at all, to and agile-like approach. They use traditional portfolio-level [patent] management techniques. The end result of that is a total disconnect downstream. Things like they pull . . .

Think about this. I’ll summarize it in one statement. This is just one out of 11 topics in this area. I have yet to meet an organization, in recent memory, that isn’t suffering from this problem. They are working on too many projects at the same time. You going to any company and asked that question, “You guys think you . . . ” You know, ask the people doing the work, “Do you think there’s too many projects being worked on at the same time, here?” It will be a chorus of “Yes.” Right? And the problem is, you have to address that at a management level. The teams didn’t decide how many projects the company was going to work on at one time. That was the executive team. Right? Then, you have the downstream misalignment. What happens if you’re over two weeks, you doing fantastic Scrum? I mean, you are cranking out high-value features, and the downstream team, for you, is the one [that] has put everything into production, and they march to the beat of their own drum, meaning, they’ll go to production when they deem it’s important for them to go to production. If you have potentially shippable work every two weeks and have absolutely no ability to get it into production to be of value to a customer, you have to ask the obvious question “Are you really delivering on the proclaimed benefits of Scrum?” Right? If you can’t get that into customer hands. So, management has to be very concerned about how they align agile through the value chain, if they want to have a top-to-bottom functioning. As I said, that’s why I like what you guys do at
OpenView Partners.

Kevin: Well, that’s been very, very helpful. I really appreciate, Ken . . . We’re actually just about out of time, but come before we go, I just wanted to ask you if you could let our listeners know where they can get in touch with you if they want to.

Kenny: Oh. Thank you. I appreciate that. So, I host the website called Innolution.com. And my email address is [email protected]. I’m happy to entertain emails. You can follow me on Twitter @KRubinagile, and I’d love to hear from the listeners.

Kevin: Great. Well, thank you so much. Really appreciate your time, today.

Kenny: Thank you, Kevin. I appreciate it.