About this podcast episode

SCRUM is a recipe, not a guarantee of success. Today, Fred Fowler shares that the focus on accountability and value-driven assessments drives any successful SCRUM implementation. In Today’s podcast, Fred will focus on topics like:

✅ Individual accountability

✅ Value-driven investment decisions

✅ Iterative product design

✅ Product Ownership

Transcript

(transcripts are auto-generated, so please excuse the brevity) Fred Fowler: The worst thing in the world is for people to make decisions but not be accountable for the results. If you assign somebody to be a product owner and they want to do something and you overrule them, guess what? Now you are accountable for the results, not them.

Bill Raymond: Hi, this is Bill Raymond. If you are a regular listener of this podcast, you know we put all our energy into delivering content that you, our listeners want to hear.

Bill Raymond: One topic that comes up regularly in the Agile in Action podcast is a framework we call SCRUM. And you’ve asked to learn more about That is why over the coming fall, 2022 and winter 2023 months, I will be interviewing accomplished leaders in the SCRUM space to teach you about the framework. If you are new to the scrum framework or deeply familiar, I hope you will learn something important in your ever-changing journey towards organizational agility and value driven delivery.

Bill Raymond: So with that, let’s get started.

Introductions

Bill Raymond: Hi, and welcome to the podcast. Today, I’m joined by Fred Fowler, founder and CEO of Silicon Valley SCRUM, bestselling author on SCRUM, professional SCRUM master level three, which I’m interested in learning about, and a SCRUM advisor. Hi Fred, how are you today?

Fred Fowler: Hello. I’m great, how are you today?

Bill Raymond: I’m doing great as well. Thank you for joining today.

Today’s Topic

Bill Raymond: We’re going to talk about what makes SCRUM work when it’s done correctly, but before we do that, could you introduce yourself, share a little bit about yourself and also, I’d love it if you share what this professional SCRUM master level three is.

Fred Fowler: Okay. Alright. Well, I’ve been working in Silicon valley for forever. I wrote my first professional code in 1980, and so I followed the growth of Silicon Valley and also the growth of software development techniques and methods and frameworks ever since then. I first got introduced to SCRUM back in 2006. I should say I first got formally introduced, because when I discovered it, I realized I’d been using those methods and those ideas for a long time, because they kind of make sense.

Fred Fowler: So anyway, my first professional SCRUM work was way back then. Since then, I’ve progressed. I was the CIO of a distribution company in Silicon Valley with 21 locations around North America.

I introduced SCRUM there, it was very successful. I got more and more into it, and then finally, I decided to make SCRUM my career, my vocation. So I studied, got my level three certification early on, and I’ve been writing about it and teaching about it, instructing people ever since.

Certification based on merit

Fred Fowler: Now, by the way, I’ve got a certification through an organization called SCRUM.org. It was founded by Ken Schwaber, who was one of the co-creators of the SCRUM guide, along with Jeff Sutherland. And hedecided to certify people based on merit. In order to get a certification, you have pass some rigorous examinations.

SCRUM certification levels

Fred Fowler: The level one, PSM level one, is quite difficult, and it really is designed to indicate whether you know the SCRUM framework, whether you have read the SCRUM guide and understand it.

Fred Fowler: Now, PSM level two is a step above that, because level two tests to see whether you know how to put SCRUM into practice. Do you have the ability to take a situation, understand it vis-a-vis the SCRUM framework, and then figure out how to proceed along SCRUM lines.

Fred Fowler: Now, level three, which is the most difficult of all, basically, it’s a two-hour examination with nothing but essay questions.

Fred Fowler: And the purpose of level three is to determine whether you understand SCRUM well enough to be able to teach it to others. It’s very rigorous, it’s expensive to take the test, so only a handful of people worldwide have ever achieved professional SCRUM level three. And I’m proud to say that I’m one of them, and I’ve been one since, I think 2015 is when I passed. So a long time.

Bill Raymond: Well, congratulations. And I’m glad to have you on here to talk about SCRUM, because we’re going to get into this from a, if you will, maybe a bit more of an executive perspective.

Bill Raymond: Anytime someone says the word Agile, usually the word SCRUM or SAFe comes up. Where did SCRUM come from and what kind of problems is it trying to solve?

The old model of building software wasn’t working

Fred Fowler: Okay. Okay. Sure, sure.

Fred Fowler: Yeah, there was a great ferment, if you will, back in the early 1990s about software development basically saying, you know, what what’s going on here, this just isn’t working? The old model was kind of the same kind of model as an assembly line in a factory.

Fred Fowler: The idea was, well, you have different kind of tasks that have to be done to create some software products.

Fred Fowler: So you do the classic division of labor, you have some people do this task, which prepares the product for the next step, which some people do other tasks and the next step and the next step and the next step until finally, you get to the end. And it wasn’t working.

Fred Fowler: There’s a famous author, is named, oh my Roman Pilcher, Roman Pilcher. He wrote a book, "Agile Product Management with SCRUM." He talked about his experience as a project manager of a very ambitious project. Basically, it was a medical services company who wanted to replatform their entire product, bring it up to date. And it was a two-year project. There were nine different paths, which he managed very effectively, brought it in on time and on budget after two years, only to discover that they had created the perfect product for two years ago and the market had moved on and all of that time and effort was a complete write-off.

And that’s not an uncommon story. There are plenty of stories like that. And so the people who came up with SCRUM and also the people who came up with the Agile Manifesto were saying, you know, this stuff isn’t working. What would work? What are we trying to figure out?

Fred Fowler: And in 1995, a long time ago, Ken Schwaber and Jeff Sutherland presented the SCRUM framework in its initial form at a conference called OOPS, Object Oriented Program, forget what the other one was.

The Agile Manifesto

Fred Fowler: And then a few years later, six years later, in 2001, Schwaber and Sutherland, and a bunch of other people came back. Martin Fowler, a bunch of folks got together at a Snowbird ski resort for a long weekend. And said, what are we discovering here? What’s going on here, what’s really happening?

Fred Fowler: And they came up with the Agile Manifesto, which is a set of 4 values and 12 principles. And they were basically saying, well, we figured these out because we’ve been doing software and we’ve been helping others do it, and we find that these principles are kind of behind success. And then the SCRUM framework was kind of a recipe for implementing these values and principles and some other ideas.

Everybody’s Focused on the Recipe

Fred Fowler: Now unfortunately, everybody’s focused on the recipe. When you talk to SCRUM people, they talk, well, you have to have this 15-minute daily meeting. You have to have this, you have to have that, cause that’s what the SCRUM guide says. They’re missing the point. The recipe isn’t important. What’s behind the recipe is important. And there’s some very key insights behind all of that, which really make it work. And if you try to follow the recipe without understanding those insights, you’re probably going to fail, because you’re just going to be going through the motions without really understanding what makes it work. And the things that make it work, will make it work, whether you use the SCRUM framework strictly or not.

Fred Fowler: So ever since I wrote my first book, I kind of got on the idea that the world needed to know what makes it work, not how it works. And so, I’ve been talking about that ever since.

Bill Raymond: I really appreciate that overview and I think it’s interesting when we talk about project management, the way you were talking about it in the 1990s, I remembered, I mean, I was in the industry. I’m still in the project management industry for sure, and I’m still in this Agile space, but I remembered, when I was a consultant doing a lot of assessments.

Bill Raymond: You know, one of the biggest problems that we noticed that teams were having was that they didn’t do enough planning. And that’s what we put all of our effort into, was getting people to do more planning and write that scope statement upfront and create some sort of a detailed flow of work and assign the people.

Bill Raymond: And that’s that sort of two-year, but two-year lost effort that came in on time, on budget, but was, too little too late. And I think what the way SCRUM kind of turns us around, and agility in general turns us around, is to say, yes, there does need to be some sort of a plan. You do need to have some sort of a vision, but let’s also not wrap up everything into some perfect package that it will never be, and start delivering more frequently.

Adapting to an Ever-changing World

Fred Fowler: Yeah, absolutely. The world is full of examples of successful products that didn’t start out as what they ended up being. That’s kind of the essence of what those people at Snowbird were saying. They’re saying, we can make a perfect plan, but the world is always changing. And so what we need to do, is we need to watch that change happen and adapt to it, so we don’t end up creating the perfect product for some time in the past, rather than here and now.

What You Intend and What You Want

Fred Fowler: If I recall correctly, WebEx, very famous product for conferencing and stuff like that, didn’t start out as that. It started out as a way for tech support people to get into a customer’s PC and operate it, with the customer adding the password, so it was all safe and secure. So it was actually a support tool, which somebody said, Hey, well, wait a second, if we can do this, then we can let other people, and it turned into what WebEx is now.

Fred Fowler: So the realization there is that what you intend isn’t necessarily what you want, and you don’t really know what you want. You have to discover it as you go.

Bill Raymond: Yeah, customer expectations andnew markets can change the direction so quickly. And if everyone just has their heels dug into some sort of a far off plan, then you missed a huge opportunity.

Every Product is About Solving a Problem

Bill Raymond: Huh? Yeah. It’s all about problem-solving. Every product is a solution to some customer’s problems. And that’s one thing that the SCRUM framework and Agile, all that, are now focusing on. They’re focusing on the fact that this is all about solving problems. And the problems change, they mutate over time.

Fred Fowler: So you need an approach that will let you, in effect, do experiments. Try something, see what works, see what the customers are interested in. You might think that you’ve got three features, the customer really liked feature number one. And then the third feature is something you kind of threw in just because it was easy. And then it turns out the customer loves that third feature. They don’t care about the other two. So what you have to do is, you have to have a mechanism that will let you learn that as you go and adjust as you go.

Discovering the Product You Have to Create

Fred Fowler: So that’s why the SCRUM framework is all about iteration. You try something, you bounce it off the customer, see what the customer says, learn from that, adjust your plan, and then move forward on a step by step basis. In effect, you discover the product that you have to create rather than envision it and plan it.

Spoke and Wheel Advertisement

Sponsor: The future of work is, shall we say, stormy, and it looks like things are not changing anytime soon. So how do you weather these storms and stay competitive while continuing to innovate? Recent studies have shown that when you put psychological safety first, people will work at their highest IQ and be capable of analytical thinking and collaborative problem solving. Do you want to see these improvements in your organization? If so, I want to introduce you to Alla Weinberg, founder of Spoke and Wheel.

Alla and her talented team will perform a 90-day psychological safety sprint that will assess your culture against three critical areas.

Sponsor: I suggest you set up a free 20-minute call with Alla and the Spoke and Wheel team.

Sponsor: You can access this free call by visiting www.spokeandwheel.co/assess. That’s like the spokes on a bicycle wheel, www.spokeandwheel.co/assess. When you sign up for the free call, mention the Agile In Action Podcast to receive a 10% discount on your psychological safety assessment.

The different kinds of problems

Fred Fowler: By the way, you did mention something I forgot to talk about, and that is the different kinds of problems there are, and how each kind of problem has its own approach for addressing it. There’s some academic work that’s been done that basically divides the world of problems into four groups.

Fred Fowler: The first group, it’s a simple problem. It’s not very complicated, there’s not what you don’t know, and there’s a no brainer. So you don’t really need a structure to solve that.

Fred Fowler: The next kind of problem is a complicated problem. A complicated problem might have lots of moving parts, might be very intricate, but in the end, you know everything you need to know to solve it right upfront. And that kind of problem, if you know everything you need to know, well, then the PMI approach, the waterfall approach makes sense. If you know everything you need to know, you can make a rationalized plan that optimizes your resources, delivers on time. Since everything is known, you can optimize it that way.

Fred Fowler: And an example of that would be, I like to talk about the example of building houses. Let’s say that you’re a developer and you’ve bought a plot of land, you want to put a hundred houses on it. By the time you’ve built house number 99, there’s no mystery about building number 100. You know how much board-feet of lumber you need, you know how many carpenters, you know how many plumbers, you know everything because you’ve done it 99 times already. You have accumulated experience doing it. So it makes sense to plan it, you have everything you need to do to plan it.

Fred Fowler: Now contrast that with building house number 1. You don’t really know anything about it. You have some guesses, but when you build house number 1, then you find out, whoops, we made a mistake. Theupstairs toilet is right over the dining room. So when people are having their beautiful formal dinner, a toilet flushing above. Oh, we can’t do that. And oh, the span of that beam over the living room holding up the second floor is too big. We’re going to need a huge, big timber to hold that up. We have to change that.

Fred Fowler: So the first house is a problem-solving exercise. So as you can accumulate enough experience in order to create project plans, good old PMI project plans to build the rest of them, because all the mysteries have been uncovered.

Fred Fowler: And that’s what SCRUM is designed to do. SCRUM is an organized process of discovery. It allows you in effect, to build that first house and make mistakes, but learn from them and ultimately, find your way through. Discover how to build that first house, and then you know how to do it again. Now, software is a kind of interesting product because you never accumulate experience building the same software product over and over again. always building software for the first time. And if you try to build it based on a huge, big planning effort ahead of time, well, nobody’s perfect. And you’re going to find all the mistakes you made in that plan as you go.

Fred Fowler: And then the question is, well, what do you do about those mistakes? And in a typical waterfall environment, you have a rigid project plan with deadlines, deliverables, the plan can’t change because you’re just going to blast off by all kinds of people at all kinds of levels.

Fred Fowler: And there’s probably some changeacceptance board or change control board, where you have to go and petition them to allow you to make a change, if you discover you made a mistake.

Fred Fowler: And SCRUM is the opposite of that. Every time you do a sprint, which is a particular period of time, you have a chance to evaluate what happened, look at the marketplace and make adjustments. So you go in with the presumption that you don’t really know how to create what you want. You have some idea of what you want, but that can change. So you go through a step by step process where in effect you discover the product that the customer wants and you discover how to build it.

Fred Fowler: And by the way, that SCRUM type of problem is called a complex problem. A complex problem is one where you don’t know everything ahead of time, and you have to discover the way to do it.

Bill Raymond: You want to make sure that you are adjusting for the market. You’re making sure you’re validating your work against what the customer needs are. You can shift quickly, you can modify what you’re doing quickly in order to address those needs.

Bill Raymond: You’re focusing on the problem. So someone might say, we’ll put a button here, but the problem is that they need to be able to print something. And so you can resolve that a different way. But the idea here is that you’re constantlyiterating on these things.

Bill Raymond: And that makes sense the types of work that you talked about, where maybe if you will, if a more traditional project management kind of approach versus a more SCRUM-style approach makes sense.

And so I can definitely understand that. But one of the things that I think is a challenge sometimes to get over, and I’m interested in hearing your thoughts on this, especially for leaders that are now starting to think, this is something that everyone on my team is talking about and I want to make this work.

Implementing SCRUM in Your Organization

Bill Raymond: So what are some of the things that you need to think about if you want to implement SCRUM and make it work in your organization? I know that this is a fairly open-ended question, so maybe we can tackle a few of them,one at a time, like, for example, maybe you can talk a little bit about the roles first.

Fred Fowler: Okay. Yes. Yes. And actually, that’s exactly what I was going to talk about when you started your question, because what does a person in management need to understand in order for this to work? OK. And it turns out it’s kind of straightforward.

Two Kinds of Product Development Questions

Fred Fowler: There are always two kinds of questions to answer in any product development.

Fred Fowler: **The first question is, what should we develop? The other question is, how should we develop it? What do we do? How do we do it? **

Fred Fowler: And the SCRUM framework divides those questions into two groups and assigns people to answer them. One of the great powers of the SCRUM framework is that associates authority, capability, and accountability. Now the people who make decisions, who are authorized to make those decisions are first of all, they’re capable, and second of all, they’re accountable.

Fred Fowler: You know, you make a decision about what to create. Well, that is a business decision. It has to do with the customers that the company has, what they’re looking for. They’re all about decisions, about how to allocate our resources, to fill customer’s needs. In other words, these are investment decisions. The decisions about how to invest the time and effort of our developers in order to create value for the customers.

Fred Fowler: And those investment decisions are pretty significant. And if you make the wrong decision, well, that’s kind of really bad. So you want those decisions to be made by people who understand the business, understand the customers, and have the authority to invest tens or hundreds of thousands of dollars or more in creating valuable solutions.

The Product Owner

Fred Fowler: In the SCRUM framework,the name of the role that does that is somebody called the Product Owner.

Fred Fowler: And the product owner is a business person who is fully empowered to set the agenda that the developers work towards. They identify all the problems that need to be solved, and they prioritize those problems. These are the most important ones right now, these are less important, but basically these are the challenges the developers need to address.

Value-based Investment Decisions

Fred Fowler: And again, these are investment decisions. If you’re spending $50,000 on a two-week sprint, $50,000 worth of developer time, you better get more than $50,000 worth of value out of that effort. And so one of the most important things that management needs to understand is that it’s all about value, and their role is to make value-based investment decisions and measure the results. Measure the value that is produced.

Fred Fowler: If there was one thing I could wave a magic wand and make everybody do in the business world, is to learn how to measure the value of their efforts. Lots and lots and lots of people don’t measure value at all. They measure activity. How busy are you? How busy are your people?

Fred Fowler: ** It’s very easy to measure how active people are. It’s not easy to measure how valuable their work product is. But you have to measure how valuable work product is if you want to try to optimize it**.

Value Example

Bill Raymond: Can you just give a simple example as to what you mean by being able to measure the value, do you have like a real world example to tie that together?

Fred Fowler: Oh, sure. You have a team and they created an app called, Goofy Bird or something and put it on the app store, and it downloads a million times at $1.99 a piece. So what’s the value of that Goofy Bird app? 1.99 million dollars. Okay. So, okay, great. If you spent $500,000 creating that app and it’s worth 1.99 million, is that a good deal?

Fred Fowler: Absolutely. Yeah, it was great. You got four times a return on your investment. That’s wonderful. Anybody would be happy with that.

Fred Fowler: Now let’s say that you spent 3 million dollars producing that 1.9 million Goofy Bird app. Was that a investment? Hell no. That’s a good way to get fired.

Measuring Value

Fred Fowler: Well, let’s talk about measuring value. There are actually four ways to increase value. By the way, value always needs to be measured in dollars and cents. You say, well, why? This is because you’re spending dollars and cents to create it. The way you measure the effectiveness of a product owner is on the return on the investment the product owner earns.

Fred Fowler: Now there are four ways.

Increase Revenue

Fred Fowler: One is increasing revenue. That’s our Goofy Bird example. You start with nothing, you got 1.99 million. That’s an increase in revenue.

Decrease Cost

Fred Fowler: Another way to get value is to decrease cost. If you sell a million widgets per year and you can make an improvement that reduces the cost of those widgets by 50 cents each, well, that improvement is worth 500 k. Simple as that.

Decrease Risk

Fred Fowler: Now the third way you can get value is by decreasing risk. So let’s say you have a problem that hits you maybe once a year, and every time it does, it costs a million dollars. Well then, solving that problem is worth a million dollars a year. By the way, I actually had that very same situation when I was the CIO of that distribution company.

We had our data center a long way away from the main internet hub. And there was a single fiber optic cable that connected our data center to that hub and then out to the rest of the world. And once a year, some idiot with a backhoe would dig up the dumb fiber optic cable and cut us off for a day.

Fred Fowler: And every day that we were cut off cost us a million dollars in revenue. So I ended up spending about $50,000 moving the data center to a secure location outside of Sacramento, huge big complex, where the likes of Google and Facebook and all those folks have their computers. It was a co-location facility, and we never had a problem again. So, did it make sense to spend $50,000 to solve a million dollar year problem? Of course it did.

Increase the Probability of Success

Fred Fowler: Now the last way you can increase revenue is by increasing the probability of success. Let’s say you’re in a bidding situation and one time out of six, you win the bid. But you make some improvement that increases your odds to two times out of six. That’s very valuable and it’s quantifiably valuable.

Fred Fowler: So you can then compare that to the cost of making that improvement in order to figure out value. You know, the problem is that, so many companies really, at least in the world of IT and software development, they don’t even think about value. They think about how do we reduce the cost? How do we meet the deadlines? How do we come in under budget? All of those things, because they’re all easy to measure. But what they should be saying is how much value are we producing and how much are we realizing? And the only way to measure that is to work with a customer.

Fred Fowler: That’s why LEAN focuses on minimum viable products. They want to get something into the hands of the customer so they can get feedback about what’s valuable about it.

Fred Fowler: So to really go in the Agile direction, a company needs to stop focusing on cost and deadline stuff and start focusing on figuring out how to measure the value of the work they’re doing. That’s the number one recommendation I would always make to people.

Strategic Advantages of SCRUM

Bill Raymond: I think for the rest of the time on this podcast, what I’d like to skip to, if you’re okay with this, is that we start talking about what are some of the strategic advantages of using SCRUM in an organization? What makes this work and what are the strategic advantages of it?

Fred Fowler: Oh, the strategic advantages. It’s focusing on solving problems that are actually valuable to solve. By the way, the product owner is responsible for figuring out what problems to solve. The developers are responsible for figuring out how to solve them.

Characteristics of Developers

Fred Fowler: And so the developers, they need to have two important characteristics, and they’re kind of strange words, but they need to be cross-functional and need to be self-organized.

Fred Fowler: Now, what does cross-functional mean? Well, it means that they need to be able to create the product. They need to have all the talents and skills, cover all the technical bases that are necessary in order to deliver a working product to the customer. They must be able to do that without any outside help.

Fred Fowler: Now you should ask, well, why? Why do they have to do that? Can’t we divide them up into groups the way it’s traditional?

No Pointing Fingers

Fred Fowler: The answer is that if you divide people into traditional sequence groups, then they always have fingers that can point at somebody else. Oh, the coders did a bad job, and so that’s why the testers are not able to get the stuff done because we have all these blockers so we have to kick it back to the coders.

Fred Fowler: If the coders and the testers are all part of the same team, there is no way they can point any fingers at anybody else. It’s very important for the teams to be capable of creating the product so they can accept accountability for doing so.

Fred Fowler: Not only that, but they have to manage themselves, which means they have to make their own decisions about how to create the product. Why is that? Well, because if somebody else tells them what to do, then they could just point fingers at that person saying, well, we did what we were told, but it didn’t work. Well, that’s their fault, not my fault.

The Team Makes its Own Decisions

Fred Fowler: The team has to make its own decisions so that it has to accept responsibility for its results. So there’s a kind of a partnership. The product owner says, this is what’s really valuable. And I’m accountable for saying that this is the most important stuff to do. And the developers say, okay, well if that’s very valuable, then, yeah, we can do it, but we have to do it this way. And the product manager says, okay, fine. For the next two weeks, you guys do your work, and then at the end of that two weeks, we’ll see what you’re able to do. And then we will look again at what’s going on and then make plans for the next two weeks.

Fred Fowler: Nobody has some roadmap that says, the deadline for this is this. So you have to make it no matter what.

Fred Fowler: **The developers have to be able to say no, so that when they say yes, it actually means something. And as developers can make their own decisions and are capable of building the product, because they have the right people on the team, then when they say yes, they don’t have an excuse for not doing it. Not only that, but they are saying yes to something that they believe they can do. **

Allow Developers to Make Their Own Decisions

And by the way, the role of management is critical. They have to allow developers to make their own decisions. But then they have to hold the developers accountable for the decisions they make. And by the way, it’s very uncommon for developers to be in this situation, because most developers just learn, okay, just tell me what you want me to do and I’ll do my best. What’s the plan? What’s my objective? What am I assigned? And I’ll do the best I can.

Fred Fowler: The trouble is, if it’s somebody else’s plan well, if they gave it to you to do and you couldn’t do that, that’s not my fault, that’s their fault. They assigned me something I couldn’t do. They were the boss, they should have known that.

Fred Fowler: And second of all, when I say I’ll do my best, well, nobody can measure whether I’m doing my best or not. So what they’re basically saying is sure, I’ll give it a try, but I don’t guarantee success. I’ll figure out to blame somebody else if doesn’t work.

Fred Fowler: So that’s why, if the developers make their own commitments, then they basically don’t have any excuse. And management needs to allow developers to make their own commitments.

Fred Fowler: By the way, there’s a role in there called the "SCRUM master." The SCRUM Master’s job is to teach the developers how to organize themselves. And if the developers don’t know how to organize themselves, it’ll just all fall flat. That’s why SCRUM Masters are very important.

Product Owners and Resource Allocation

Fred Fowler: By the way,the role of product owner needs support from upper management, because the product owner usually is involved with just one product. And the product owner of course, wants all the resources in the world to be devoted to their product, but somebody with higher responsibility than the product owner needs to make resource allocation decisions amongst other products competing for resources.

Fred Fowler: So let’s say you have one product that’s part of a family of products, sometimes called "a program." There needs to be somebody at the program level who can make decisions, resource allocation decisions, in other words, investment decisions, as to which products to back more strongly or which to back less strongly.

Fred Fowler: And again, that person can be evaluated based on the return on those investments. Did they actually result in a program of products that made a good return on those investments? And then at even a higher level, portfolio level, it’s the same thing. Program people are competing for resources. There might need to be somebody at a portfolio level, very high level, making basic resource allocation decisions amongst these different programs, or in other words, investments.

Bill Raymond: I get a lot of messages from people that are listening to the podcast. And the question that I get a lot is, you said that the product owner is from the business or part of the business, understands the business really well.

Bill Raymond: Does that mean that there’s a separation of the Agile team, the SCRUM team, meaning like the developers and other folks that are on the team are not communicating with the customer?

Fred Fowler: Well, if you have a business person who understands the business and the business person is writing up details, specifications for the developers to follow, would you expect those specifications to be very good or very accurate?

Bill Raymond: No.

Fred Fowler: Yeah. They’re outside of the skillset of the business owner, business person. Right. By the way, I’ve seen lots and lots and lots of examples of business people who try to write detailed specifications for developers to follow, and end up creating very bad technological solutions, because they don’t understand the technology very well. You should let the developers, the people who understand the technology, make those decisions, because they’re the ones who got the skills and the talent to do it.

Fred Fowler: Now likewise, do you want the developers talking with the client and figuring out what the client wants? Well, the developers can probably come up with all kinds of solutions to whatever the client wants. The question is, is the client willing to pay the cost of doing that? The developers aren’t really business people. They’re not really equipped to make those decisions.

Fred Fowler: So it’s a good idea for the developers to understand what the client wants, but it’s very important for the product owner to say, yeah, that’s what the client wants, but we can’t afford to do that for them.

Bill Raymond: And you say that it’s the product owner who’s also there to help prioritize as well. So what you’re saying is the developers, the SCRUM team, the people that are working on the project, they absolutely will be communicating with the customer, but it’s the product owner who’s setting the priorities and defining the large problems that have been solved.

Fred Fowler: Yes. Yes. By the way, there is an event in the SCRUM framework called "the sprint review," which is all about putting customers and developers and the product owner in the same room, talking about the product. And so the sprint view is where the product owner demonstrates what the product does now, after the work or the prior sprint.

Fred Fowler: And the purpose of that is to stimulate ideas about what it could do next. I wrote a book about SCRUM framework and I described a sprint review for a, situation that I was involved in. I was teaching people at that time and putting my students through the practice of using SCRUM to develop software for not-for-profit organizations. And there was one foundation, I forgot the name of it, but basically they had a big estate near Silicon Valley. It was out in the woods, you know, bucolic, beautiful, andthey held summer camps for kids with cancer. That was their charity.

Fred Fowler: And there was a big garden because it was an old winery and the people who, you know, grew the grapes, they loved plants. And so they had a very extensive, exotic garden. And the software project had to do with the fact that when the kids were there, they loved, they ran around the guarden and looked at all this thing, and then they asked the counselors, Hey, what’s that? What’s that? What’s that? And of course, these camp counselors were just college kids, you know, during the summer, and they weren’t botanists, they didn’t know.

The foundation had been given a bunch of iPads as a donation. And so the project was to use the iPad to help the counselors answer the questions about what’s that, what’s that, what’s that. And so the plan was to label each of the plants with a barcode and then use the iPad camera to read the barcode and then have it display information about the plant.

Fred Fowler: And so after the first sprint, we had a review with the foundation people, the product manager and the developers, and the developers hadn’t been able to print the barcodes yet, but they were able to display a barcode projected on a wall and then they hit it with the iPad camera and lo and behold, up came a page of information about the plant, after just two weeks.

Fred Fowler: And the foundation people were just blown away. Wow. That’s so cool. That’s great, wow, look and there’s picture of the plant and um um, can we we have more than one picture? Uhhuh? Well, we want the kid to be able to look at the plant and look at the picture and say, yep, that’s the same thing, but plants look different in the spring than they do in the fall, and in the winter and the.

Fred Fowler: And then the developer says, oh, oh, oh, oh yeah. Yes, yes, yes. You want a carousel. And by the way, the iPad knows what the date is, so we can figure out whether it’s spring or summer, so we can show the spring picture in the springtime, the summer picture in the summertime. And the foundation people says, you can do that? Man, that’s so cool. Wow.

Fred Fowler: And then the product owner wrote down in his notes, carousel of pictures, date-sensitive. That became a feature to be developed later. And then one of the developers popped up, by the way, would you like this thing to talk? What? Well, we could put a button on this screen, you press the button, it says talk, and it will read the screen out loud. The foundation people says, it can do that? Sure. Easy. This is Apple. This is iOS, you can do that. Wow. You mean, we can give this to kids who are too young to read? We can give this to kids who can’t see? Yeah. Wow. And then the product owner wrote down, text-to-speech button.

Fred Fowler: So that’s the kind of interaction that should happen. The developers and the customer could talk about what’s possible, but then the product owner has the final say over whether it’s going to get done or not. So that’s one of the sprint events, the sprint review, which is all about bringing everybody together and getting ideas for the product owner to prioritize for the next time around. Did that make sense?

Developers Got Separated from the Customer

Bill Raymond: That’s a great example. During this whole period where we were doing this top-down project management, having subject matter experts, write up the scope of the project and other subject matter experts writing up the statement of work and the work that needed to be done and the functional specs and the technical specs, the developers kind of just got handed things and they never got a chance to see the customer and meet the customer and understand their needs.

Bill Raymond: And I think sometimes we think about developers as that person that sort of just sits there and writes code and doesn’t want to be interrupted, but they do want to be interrupted when they get to get customer feedback. And that is absolutely one of the things that I think has changed dramatically as people start implementing this.

Bill Raymond: I think that’s one of the greatest values that a framework like SCRUM, or just this concept of agility with small teams working with a portion of the business to get work done. I think there’s a lot of value coming out of that, and that’s why we’re starting to see so much more innovation right now than we ever have.

Fred Fowler: Yes, absolutely. Yeah. Developers want to use their talents to help people, to solve problems, to be the hero. And you can’t be a hero if you’re working on something that some subject matter expert handled to you saying, do this. All you can do is just either do it or not do it, and there’s no sense of accomplishment there.

Fred Fowler: So, again, SCRUM and Agile, all focus on problem-solving. And different people bring different points of view, different aspects to that problem solving. And in the end, the problem’s solved and everybody can be proud of that. Unfortunately, you don’t want business people making technical decisions. You don’t want technical people making business decisions, but there just seems to be a tendency to do that. And perhaps people aren’t realizing that’s what’s happening, but because if they realize that, they kind of say, this is terrible, this is crazy, it’s backwards. You want technical people to show what’s possible. You want business people to say what’s desirable, and together they figure out what to do.

For Leaders, Before SCRUM Implementation

Bill Raymond: We’re getting close to the end of the podcast here, but let’s say that I am a senior leader in an organization, director, and I’m thinking about implementing SCRUM. Maybe I and some of my colleagues are looking at it. Certainly you can go to SCRUM.org and see it. It all looks fairly easy actually. But you know, maybe they’re not organized in such a way where you could properly implement everything that we just talked about right now. And so there needs to be some sort of a way to think about getting there. What are some things that a leader needs to think about before they jump into an implementation process?

Fred Fowler: Okay, well, if you’re just going to take the SCRUM guide and tell people, use this, it will fail, because the SCRUM guide is a recipe, but the recipe only works under the right conditions. The conditions are what are important.

Fred Fowler: And so as a leader, what I would say, I need to identify somebody who can be accountable for the value of product, who has the capability of making the decisions, the authority to make the decisions, and is willing to be accountable for the results of those decisions. And then put them in charge of whatever product you’re working on, and then back them up so that nobody can second-guess them, protect them.

Fred Fowler: By the way, the best product manager I ever had was the COO of an organization. It was best because he understood the business, he knew what he wanted and nobody could second-guess him.

Fred Fowler: So that’s the kind of product owner you want to have. And then you get the product owner to talk about what is desirable, what the problems to solve are. And then attract a nucleus of technical people around that product owner who say, yeah, yeah, we can do that. We can do that this way. We can do that that way, and then say fine, figure it out, let’s set a goal for a couple weeks from now, show me what you can do.

Fred Fowler: That’s the way to do it, yeah. And any other way of doing it, say okay, we are going to hire a SCRUM master. We need to have a 15-minute meeting every day and we need to do this, we need to do that. That’s all missing the point. If you get those conditions right, then the SCRUM framework falls into place naturally, because it just makes sense.

Fred Fowler: Each of the different events have a purpose when you have people who are playing those roles, understand the roles and are accountable for them. The sprint planning meeting at the beginning is a negotiation between the developers and the product owner about what they can do. When the negotiation is finished, they shake hands, product owner lets them be, is there to answer questions, but then the developers have to figure out how to live up to the commitment they just made. And they need to keep track of what’s going on with each other. That’s why there’s a 15-minute meeting every day, just to make sure that everybody is on the same page about what’s going on. And if somebody’s in trouble, they can fix it.

Fred Fowler: At the end of the sprint, you had the review where in effect, you discuss the results of what you did, you look at the product again and figure out what you could do next. And then at the very end, you have a retrospective where the team gets together and talks about what just happened, is honest with each other, and builds a sense of team cohesion and teamwork. It all falls into place, if you have those initial conditions in place. And if you don’t, then it’s all a bunch of going through the motions, it’s form without any substance.

Meetings Don’t Have to Take Long

Bill Raymond: And someone might say, oh, more meetings, what’s your response to that?

Fred Fowler: My response is, the meetings don’t have to take very long. You still need to have an agreement between the product owner and the developers as to what the heck they’re going to try to do. And if they’ve done proper preparation, if they have discussed all these problems, then the sprint planning meeting can be all five minutes, and say, okay, well, this is what’s on the list and this is what we’re going to do, everybody clear? Okay, fine. Away you go.

Fred Fowler: I’m kind of an iconoclast a bit, because I say, you don’t have to have a 15-minute meeting every day face to face. What is imperative, is that the developers know what’s going on and can spot trouble and correct it. Now that very selfsame example I told you with the kids with cancer thing, those developers met online. And actually, they didn’t meet every day. But they were always on Slack all the time. And whenever they needed to talk, to discuss something, they popped into Zoom and had a video. So those developers were together. They understood what was going on, they knew what each other was doing, they were able to help. They didn’t have a 15-minute meeting every day. 15-minute meeting is not important. What’s important is that developers are working together.

SCRUM Can Start as a Rigid Thing

Bill Raymond: Yeah, what I’ve seen is, when an organization starts going down this path and they start adopting some of these ideas and these concepts, it starts as a very rigid thing. There will be a standup, they call them a standup or whatever you want to call it, the 15-minute, all the team gets together to kind of do the, what’s on my table today, what did I complete, and any kind of roadblocks or whatever. And that’s, I think a fairly common way to go about it. And all of the other meetings that you mentioned, the sprint review.

Bill Raymond: But I do see that they take up a lot of time initially, so everyone can feel like they’re in the cadence and they understand what it is that they’re supposed to be talking about and how. And I also do think it helps with team formation. It helps people get to know how to work together. And even if you did work with people all the time before, but now you’re doing it in a different way, following this framework, you know, there’s terms that might come up that you’re unfamiliar with. You might be consolidating your tools, so there aren’t 20 different ways to update your status of what you’re doing, there’s just one way. There might be different ways that you have to report on how you’re getting work done. All those things, they change. And so I see that at the beginning, everyone stays pretty rigid to the framework.

Bill Raymond: And then over time, they realize, here is how we’re going to do it now because this is what works for us. And I think it’s,I mean, I’m curious to hear what you have to say, but I think that’s okay.

Fred Fowler: Yeah, you know, I’ve had clients where the term "life-sucking meeting" came up a lot.

Fred Fowler: And I say to myself, well, what does all this mean? Well, having meetings, meetings, meetings, really is all about trying to get a handle on what’s actually going on. It’s about transparency, which is a big idea within the SCRUM framework. People are struggling to understand what’s going on, so they have meetings, meetings, meetings, really impeding the ability to get anything done. The SCRUM framework actually reduces meetings. There is no need for status meetings. There is no need for any kind of checkup or coordination meetings because the team is self-sufficient. It doesn’t need to coordinate with anybody else, so it doesn’t need to meet with anybody else.

Bill Raymond: Mm.

Fred Fowler: The product owner doesn’t need to know on a day to day basis about how the developers are doing. Actually, **nobody needs to know on a day to day basis about how the developers are doing, because if there was some implication that somebody had to do something about it, that the developers aren’t working hard enough, well, then that means the developers are not making their own decisions. That means that the developers have an excuse for not performing. **

Fred Fowler: The only status reporting that is necessary is at the end of the sprint, when the product owner says, okay, either you did what you said you were going to do, or you didn’t do what you said you were going to do, basically holding the team accountable for what it said it would do.

Fred Fowler: That’s the only status reporting that’s necessary. So actually, the SCRUM framework reduces a lot of those, forgive me, those BS meetings, because they’re not necessary. Actually, they’re counterproductive. By the way, everybody knows they’re counterproductive. They waste a lot of time, and all they’re trying to do is to give warm, fuzzy feelings to people about what’s going on. We don’t really know how to measure the value of what’s happening. I’m sorry if I have a kind of pet peeve about

Fred Fowler: that

Bill Raymond: No, I think it’s fair. I will be the first to admit that I used to hold meetings that even I thought were counterproductive. But I maybe I took them on from a previous person or maybe I set them up because it was a critical time in the company at that time, and then we just kept it going forward because it was a recurring thing on the calendar. And finally, someone just says, I’m fed up, and then we all say, yeah, maybe we don’t need that meeting. And it just gets canceled and no one cares and nothing breaks and everything’s fine.

Bill Raymond: So one of the things that you might do as you’re starting to think about implementing something like this, is to take a look at your existing meeting cadences and see what you could just X off the calendars for people, so that you can free up to do these other smaller, lightweight things that SCRUM provides.

Bill Raymond: Are there any other takeaways that someone could use after they listen to this podcast?

It’s About Accountability

Fred Fowler: Yeah, yeah. Again, it’s all about accountability.

Fred Fowler: If you’re a director or a VP or somebody like that, and you assign somebody to be the product owner, that person needs to be accountable, needs to make decisions and be accountable. The worst thing in the world is for people to make decisions but not be accountable for the results. And so if you assign somebody to be a product owner and they want to do something and you overrule them, guess what? Now you are accountable for the results, not them. And so when you overrule somebody, you’re really taking away their accountability, and you don’t want to do that. You want people to be empowered to make decisions, sometimes make bad ones, but learn from them, but ultimately be focused in and make decisions and be answerable for the results, good or bad.

Fred Fowler: If somebody makes a killer decision that makes a lot of money, they need to get all the credit for that. They’re accountable. They’re accountable for their success as well as their failure. And sometimes stuff happens and things fail, but c’est la vie.

Bill Raymond: Fred Fowler, this has been a fantastic conversation, and I really appreciate your time today. Is there some way that others might contact you if they want to reach out and further this conversation?

Fred Fowler: Oh, sure, sure. I’ve got a website, www.siliconvalleyscrum.com. I’m also on LinkedIn, although I’ve got 10,000 contacts. So if you want to contact me send me a message and say, hey, you heard me on the podcast and I’ll be happy to reply.

Bill Raymond: That’s great, thank you. And of course, these contact links will be available in the show notes on our website, the agileinaction.com website, and also, if you are listening to this on a podcast player app right now, just go into the show notes for the details and you’ll see those links there.

Bill Raymond: Fred Fowler, thank you once again for this great conversation. I really appreciate it.

Fred Fowler: My pleasure, I really enjoyed it. Thank you very much for inviting me.