Measuring Busyness Vs Measuring Results

Read The Transcript:

We’re trying out transcribing our podcasts using a software program. Please forgive any typos as the bot isn’t correct 100% of the time.

Galen Low: Pop quiz: you're halfway through your project, and all your metrics look great. Your vendor spent the agreed number of hours and your team's velocity and utilization are exactly where you planned for them to be. 

But in spite of your project having a clean bill of health, the product continues to miss the mark in focus groups and user testing. The technology your executive sponsor was adamant about is quickly becoming outmoded, making it difficult to make changes. And your team's morale is low: when you ask them for solutions, they shrug their shoulders and say they did what they were asked to do within the allotted amount of time. 

So how can your project be healthy even if the output isn't producing its intended value? 

If you've been finding that your project metrics are measuring busyness more than value, keep listening. We're gonna be diving into the practical mechanics of how project teams can measure value and exploring ideas for shifting the incentive from hours spent to value created.

Hey folks, thanks for tuning in. My name is Galen Low with the Digital Project Manager. We are a community of digital professionals on a mission to help each other get skilled, get confident, and get connected so that we can amplify the value of project management in a digital world. If you want to hear more about that, head over to thedigitalprojectmanager.com.

All right. Today, we are talking about the difference between measuring project health and project progress versus measuring project success. So is it enough to track team velocity and cost performance? Or is it our responsibility as project leaders to measure project outcomes and impact as well? 

With me today is Fred Fowler—a Level 3 certified scrum master who has published multiple books on the Scrum methodology, is the organizer of the Silicon Valley Professional Scrum meetup group of about 2,000 members, leads a similar scrum community-based in Shanghai, China, and organized the first Silicon Valley Scrummit conference. So in other words, someone who knows a thing or two about Scrum.

Welcome Fred!

Fred Fowler: Hello! Thanks for having me on the show with you. 

Galen Low: Great to have you here. 

Fred Fowler: I introduce myself as a scrummy guy. So, although some people would say I'm scrumcious.

Galen Low: Well that's better than me saying Fred scrum-of-the-earth.

Fred Fowler: There are all kinds of ways you can play with the word scrum. You can scrumbag and whatever. Anyway, go ahead. Go ahead. 

Galen Low: Indeed. Awesome. Well, listen, you've got such an interesting background, and I think it will give our listeners just a lot of context on just your take on project metrics. So if I understand correctly, you started as a computer programmer and then you moved to politics, became a mayor, and then found yourself as a CIO before beginning to use your rare Level 3 scrum master certification to help others. 

So I'm just wondering, could you tell us a bit about your journey and how your experiences have shaped the way that you look at things today? 

Fred Fowler: Well, I would say my career resembled being inside a pinball machine.

Start out as a programmer back in 1980. You know, ancient time is working on a machine that was so big and heavy that it basically required special equipment to move it and was less powerful than your average telephone today, your smartphone. But we ran a division of a semiconductor company using it, and I learned my skills there.

Moved on, cause it was Silicon Valley in the early days, which meant there was lots of volunteer volatility. So in the first eight years of my career, I worked for five different companies and it was just incredible, like I say, volatility. And finally at the end of that says, you know, I need some job security so I better work for myself. 

And I became a consultant and I worked for 60 different companies in the next 10 years. You know, again, doing the same stuff, you know, always trying to apply technology to solve business problems, which is really what it's all about. And then there was a company I worked for as a consultant.

They made me an offer I couldn't refuse. Ended up running their IT operation, ended up being, as I say, the CIO, and implemented a lot of techniques that really ended up being scrum techniques, even though I didn't realize it at the time. Empowering people to solve problems, justifying the work based on the return on the investment.

And you know, I, back in those days, you know, I did a lot of projects that really formed my, my whole outlook on how to organize endeavors. Many things I'm proud of. The company had worked hard to build a website using a big three letter computer company everybody would recognize.

And they paid a quarter million dollars to that company to make a pretty pathetic eCommerce solution. And anyway, I got involved and I saw that there was great opportunity for improvement. So I organized a project, organized long scrum lines. 

And then we had, you know, two different kind of technologies involved. There was a legacy, which is a IBM mini computer back then, called the AS/400. That was the back end, but we needed a front end. So what I did was I traveled to China and found a little company there who was ambitious and would do the front end. And so we organized in such a way that the US team did the backend work. The Chinese team did the front end work. And all we had to do was figure out how to get the two platforms to talk to each other.

And that turned out to be pretty simple. So we replaced a quarter million dollar piece of work with a website, which within six months was doing 40% of the company's business and spent $14,000 doing it. $14,000. So, but it was simple. It was just, you know, people who understood the technology turn 'em loose, give them a problem to solve, let 'em solve it.

You know, have teams different parts of the world. That's okay. All you have to do is manage the way they interface with each other.

Galen Low: There you go. Lean teams, data contract, and off you go. 

Fred Fowler: That's right. Right. And the thing that really was the key was to understand what was important to measure.

You know, when you're talking about offshore teams and everything, everybody freaks out, well, how do we know what they're doing? So we want to have all kinds of tools to measure how hard they're working, how busy they are. Because we want them to be busy all the time.

Right? Guess what? That doesn't matter. It makes no difference whether the people who are offshore are busy or not. That's not important. What is important is what they actually deliver, the value of what they deliver. That's what you should measure. Forget about trying to hold stopwatches on people. It doesn't matter, know, if you had.

Here's an example: if you had a team of over 200 people working, you know, 8, 10 hour days for two years versus a team of maybe five or six people, well, 10 people working, you know, regular hours for one year, who do you think would deliver the most value? Well, it turned out that the 200 people who worked for two years created what's called healthcare.gov, which is a website many years ago that turned out to be a total disaster.

It was supposed to be something that would implement Obama Care. And it, it crashed and burned because those 200 people were, they were being measured on how busy they were. And the 10 people over the next year were the ones who completely rewrote the thing and made it work. And, you know, they delivered far more value than those 200 people, otherwise.

Galen Low: I was gonna say, let's dive into that because you know, I think it's a huge point. You touched on one of the reasons why we measure busyness, but you know, in my world, like I come from an agency background and consultancies, and it's all about billable hours. It's about utilization. It's about how many bugs we squashed or how many tasks we completed.

Like why do we have this tendency to measure busyness? 

Fred Fowler: Oh, it's simple. It's because it's easy to measure. You know, all you need is a clock to measure how busy people are. All you need in order to figure out whether people are adhering to a bunch of deadlines is a calendar. It's easy to measure. And you know what? It's the basis of compensation.

You mentioned billable hours. You know, that's a great, great fallacy. You know, the idea that people's time is valuable. Well, people's time is valuable to them, but what's valuable to you is what they do with that time. You know, it'd be much, much better if the world had a good yardstick to measure what the results of people's time is.

And actually, when I talk with companies, I try to tell 'em, you know, what you need to do more than anything else is to figure out the value of what you want created and to be able to divide it into the pieces that make sense, so that it's measurable. And then measure progress based on what the value created is. You know, within lean there's this idea of a minimum viable product.

You know, you do as much of a product as is necessary in order to get something into the hands of the customer. You know why that's a good idea? It's because that something has value, because it's in the hands of a customer. The customer can tell you how valuable it is. And that way you can judge whether the value that was created was worth the expense you went to get it created.

You know, if you have an app that costs half a million dollars to build, well, is that a good investment or not? Well, it depends if the app goes up on iTunes and it's downloads 3 million copies at two bucks each, well, gee, you just made $6 million on a half million dollar investment.

Hey, that's a pretty good deal. I do that any day. Same half million put the app up on iTunes and it only does 20,000 downloads at $2. Well, let's make it 25,000. That means you, you spent 500,000 to create 50,000 worth of value. Same effort, you know, same number of billable hours. You know, but, but the value of the result is different and the value of the result is what's important.

Galen Low: I think you touched on something really important there, that I don't know if everybody fully appreciates about the minimum viable product. You came, I'm gonna circle all the way back to something you said earlier. We measure busyness because sometimes it's a trust thing. We don't trust that people are doing a thing, but if we can hold a clock to them while they work, then at least we know we're working those hours.

But to your point, it doesn't measure value. And I think people will come to me and they'll say, well, I mean, of course we need billable hours. That's the contract. That's how people are getting compensated. That's the deal. But what I like about what you said about the minimum viable product is that, listen, let's get something out there.

It's gonna take an investment. And then as the customer, you can decide whether or not that's valuable. Which in a way, I mean, I guess some people might be like, well, I want to know that it's valuable before I spend the money. But in reality, that doesn't happen either, right? You're like, oh I have $50,000. Okay.

We're gonna build the thing. And then after you spend that $50,000, you might still not have the thing that you wanted that's gonna create value. But I feel like, you know, billable hours and dollars, like a lot of people think, yeah, maybe it is. I mean, I don't know if you feel, do you feel like it's like a necessary evil for business to get done or is it something that we should be trying to creep beyond?

Fred Fowler: Okay. Well, in some ways it's a necessary evil. But you still have to keep people in the straight and narrow by comparing what their cost is to what the valuable result is. Now here's something about the scrum framework. Within scrum, you always have to create something that's done, finished, complete, and ready to give to the customer at the end of every sprint. Right? 

Now why do you suppose that is? Why do you suppose it's important that something has to be done, ready, complete, and able to be given to a customer? Why do you suppose that? 

Galen Low: Okay. I'm gonna hazard to say, so that it's value that can be measured. 

Fred Fowler: That's right. That's the only time something has value. It's when it's done, when it's ready to give to a customer.

And by the way, that's how you measure value. You measure value by how much a customer will pay for it. So scrum has this every two weeks, you create something of value so that you can measure that value and compare it to the cost of creating it. So you ahead of time, whether you're on track to create a $6 million product with a 50,000 or 500,000 investment or a 50,000 product with a 500,000 investment. You need to be able to break it up into pieces that each have measurable value, not, well, I think it's value. No. Measurable value.

You see, that's one thing that the scrum emphasizes. It emphasizes that you make decisions based on things you measure, not guesses, not opinions, things you measure. And the most important thing to measure is value. 

Galen Low: I was wondering if you could walk us through that measurement of value because in my notes here, I'm like, okay.

So if we if measuring busyness isn't all that useful, then what are the metrics that we should be measuring as a team, right? As a sort of scrum team in this scenario. But it strikes me that what you're saying is also kind of putting it, and not necessarily putting it, you know, on a shelf, and putting it into the marketplace.

But who does that evaluation of whether or not something is valuable sprint over sprint? And how is that something that you track?

Fred Fowler: Okay. Well, first of all, it is a good idea to recognize that in the scrum framework, the measurement of value really is only one person's job. You see, scrum divides responsibilities in the three pieces. There's the product owner, there are the developers and then the scrum master. 

Now, the product owner's job is to maximize the value of the work, the team. Okay? Product owner is the one responsible for value. Now, you can't maximize something unless you can measure it, because if you can't measure what you're trying to maximize, you have no idea whether what you're doing is making it better or worse.

You have to able to put a yardstick up against it. Now there are four ways that you can increase value. The most common way is revenue. Again, you know, make an app, sell 3 million copies of it for two bucks each, you know, the value, you can measure the value of that app $6 million. Another way is by reducing the cost of something.

If you make a million widgets a year and you reduce the cost by 50 cents, that's worth half a million dollars. Easy, no brainer, no yardstick really required. I mean, that's how that works. Okay. The third way is by reducing risk. Now that's something I did when I was a CIO. I worked for that company.

We were headquartered in a city south of San Jose, California, south, a little bit south of Silicon Valley. And we had a data center there and we were connected to the outside world through a fiber cable that went up to the main office in San Jose, California. And we basically had our data center there and we connected from there to all 22 North American locations. And pretty much we processed the orders in our headquarters and then sent out instructions to all the different warehouses this year shipped that there.

And then once a year, some eat it with a backhoe between us and San Jose would dig up that fiber cable and break the connection, and put us out of business for a day. And we usually did around a million bucks a day. So what's the cost of that risk? Once a year, million dollar hit a million dollars a year.

Yeah. So it made sense for me to propose that we move the data center. We take it out of our headquarters building and move it to a very secure location outside of Sacramento where Google and Facebook and all those folks have their servers. And this place is, was really interesting. It was run by the ex-nuclear officer of a submarine.

And so it had, but it was secure as anything you had, you know, rent the recognition to get in the door. It had overpressure, so it would blow dust out rather than in. It had power coming in from two different substations, from two different electric grids. It had the biggest dang batteries I've ever seen.

They were like truck trailer-size batteries. They had six of the biggest. Anyway, this thing was never gonna go down. And so we moved it there and we spent 50K. Would you spend 50K to save a million? Oh, yes.

Galen Low: You only got 50K to move your data center? That's great. 

Fred Fowler: Yeah. 

Galen Low: Yes, absolutely. I would.

Fred Fowler: Yeah. Yeah, we did.

We just rented some of their racks, which is what it was. And there were lots, so we put our stuff in there and lock it up and then we just ran everything outta there and they had superb connections. 

So, anyway. So, you reduce risk. Million-dollar-year risk. Cut it down. That's value. Easy to value. Now, so that's three. The fourth way to increase value is to increase opportunity. If you're in a bidding situation and you win one bid out of six, and if you can then do something that makes it more likely you go in two bids outta six.

Well, you can easily add up the money that's involved there. You can use that to compare against the cost of doing so to be able to make a decision. Well, yeah, this makes sense.

Galen Low: That's actually really interesting. So the product owner is responsible for value. They're measuring all this value. You know, we're talking about these four levers to increase value. How are they then funneling that back down to the development team in this model?

Fred Fowler: Okay. Well, first of all, there's four different levers, as you say, four different ways to create value. The partner's job is to measure that and make rational decisions about what the team should work on. Now, it's important to realize you can't measure the value of something that doesn't exist. And by a definition, you know, the people who are creating the product doesn't exist until they create it.

So in effect, the product owner has to guess as to what will be valuable. Okay, that's an investment decision, just like buying stocks or anything like that. You take an educated guess as to what you think will be valuable, and then you direct the teams to create that value. And then they do, and then you put that into the hands of customers to find out how valuable it is. You check and you measure the value by finding out what people will pay for it.

What you're actually saving in terms of cost. So you measure it after the fact, but based on that you make investment decisions and that's the key. It's investments. Now, how do you tell whether Proctor's doing a good job? Well, you look at the return on those investments. If you spend $50,000 on a sprint, do you get more than $50,000 worth of value out of it?

Okay? Now you could say, well, okay, that's all the product owner's job and the developers don't really care about that. Well, guess what? They should care, because how do you think they get paid? Why would somebody want to pay them $50,000 for a sprint and only get $25,000 of value out of it? So in many ways, the product owner and the team are all in the same boat. They've got to deliver more value than their costing.

Galen Low: And that's like such a crisp statement there because I think coming back to what we were saying originally, right? Like actually sometimes our mindset is, well, of course they're gonna pay me. I did 80 hours of work. And I said, I'd do 80 hours of work, and I did 80 hours. Like, why wouldn't they pay me?

But actually, that's like it's we're caught on our own trap there, because it's not a conversation about value. It's about time for dollars, not necessarily value. 

Fred Fowler: That's right. That's right. Right. And once, once you realize that, once developers realize that they realize they have a vested interest in making sure that what they're do is, doing is valuable.

So in effect you have a partnership going. The product owner isn't a technical role. Product owner is a business role. Product owners should identify, Hey, this would be really cool and valuable if we created it. Now the developers are the technicians. The product owners says, what is desirable? The developers tell the product owner what is possible.

And then through a negotiation, you figure out what's practical. You know, what of the possible things we could do would be the most valuable ones. And that's what scrum is all about. Scrum is about a negotiation between people who have responsibilities for those two different areas. And ideally, you know, the product owner really understands the business.

The developers really understand the technology. And so together they can say, okay, here's a business problem. We can apply this technology to it. And bam! We got it. 

Galen Low: I like that word you use, partnership, cuz I don't know if a lot of people see it that way at first. Right? They're like, okay, whatever the product owner decides, that's what we're gonna do and we'll just do it.

And it still feels like the servitude, but actually it's not. The thing you said at the beginning that scrum is about empowerment. It's about empowering individuals and their expertise. And I love that word negotiate. To negotiate that balance between, you know, business value, everything that we want, versus what is feasible to get to that practicality of a product that will deliver value, again, without costing an arm and a leg.

Right? Cuz that's still part of value as well. 

Fred Fowler: Oh, yes, indeed. Yes, indeed. Yeah. And developers can have a lot of influence about how much things cost and some perhaps non-intuitive ways. So, so for instance, let's say the, they're developing some kind of an app, which, you know, contains your personal information.

So you has, have some kind of a way to identify yourself. The product owner might say, okay, well, let's create a login function, you know, the screen and the password and an ID. And, all the stuff that goes along with it, like setting the password, change the password, you get all that stuff. And so the product term might say, okay, please create a login screen with all this stuff.

And the developers might say okay, let's go create another login screen with all this stuff. What the developers should say is, well, have you thought about using something like sign in with Google, sign in with Facebook? Because they've done all that work for us. All we have to do is hook up to that. We can deliver that need without having to do anything much.

Isn't that a good idea? So the developers, you know, a lot of developers say, just tell me what you want me to do and I'll do it. Just tell me what you want me to do. Oh, you want me to reinvent the wheel? Okay, fine. I'll reinvent the wheel. And I'm getting paid by the hour, so why not? What you should ask developers, which you should ask developers is, can you solve this problem? 

You know, the product owner's problem is that he needs users to identify themselves uniquely to this app so they can get that their private data. So the problem is how can this app identify its users? Okay. Developers, how can we do that? And the developers say, oh, well, can you sign it with Google?

Hey phones, these days have facial recognition stuff. We can hook into that, your fingerprint readers. There are lots of ways we can do it without having to reinvent the same old, tired, old login system. So we can tell you what is easy and hard. You can tell us what is valuable or not. So the negotiation is, well, let's figure out the easiest thing we can do that is valuable.

And then that's the plan. Do that, and just make sure you do it in such a way that you can, you can create it in a piece that can be given to a customer so you can measure what the value is. 

Galen Low: I'm wondering because I've definitely been guilty of measuring busyness, or even speed, right?

Like velocity is still a thing. You know, we'll measure that, we'll have our burndown charts, but what does the conversation look like in some of the teams you've worked with, the scrum teams, about value? Does the product owner come back and say, listen, we wanted this to be worth $65, but turns out people only wanna pay $60 for it? Or how does that come back to the team?

And are they thinking about like, okay, let's optimize, let's maximize that value by moving the needle on this metric? Is that kind of how it comes down to it? Or is it more just kind of like shifting the direction, sprint over sprint rather than going, okay, well, the earned value of the thing that we've built so far is only this much, and we need to make it more than that?

Fred Fowler: It kind of comes down to compensation, which you alluded to earlier. If everybody's getting paid by the hour, well, then everybody's incentive is to, you know, do everything the hard way. Do it. And by the way, that's a disease that's inflicting a lot of projects. I mean, I work with a company, a fortune 50 company who you instantly recognize if I told you the name. 

They had a very ambitious project, two years, $500 million to completely replatform all of their business processes. Yeah, and they had an army of people in there and they were busy as hell. They were meetings. There were all kinds of, you know, reports. They were, you know, people writing code.

And by the way, that's where I first learned the term throwaway code. What? What's throwaway code? It's oh, well we thought we needed this and we wrote it up, but it turns out we didn't need it after all.

And anyway, these guys were just churning and busy. The whole place was just a high of activity. And after two years, they called me in. Because after two years and most of that 500 million, they had created no value at all. They had just created a lot of noise and a lot of activity and spent a whole lot of billable hours running around and, you know, basically doing busy work. They didn't know it was busy work at the time, but it turned out to be because there was simply no result that made any value.

So there, there are plenty of horror stories about that. But, but let me let's talk about compensation though. Cause I've actually been thinking about this and saying, you know, what would be the right way to do it? And there are really two aspects of compensation. There's the first piece of it is getting people in the door, getting tell the people in.

And in order to do that, you kind of have to pay market rate. So, you know, an average, junior coder is worth a lot less than your average senior, you know, whatever specialist. And the market reflects that. So in one level you have to, you know, pay according to that. So that's you know, getting somebody in the door. 

Now at the other hand, how do you compensate for the value that people produce? Well, what you have to do is you have to give them part of that value as a reward. So if a team creates, let's say they create a hundred thousand dollars worth of value. Okay, well, companies needs to, you know, pay for its infrastructure and stuff like that.

So maybe they give 20% of that to the team. So they get 20,000 bucks now. Now, how do they divide it up? Do they divide it up according to who has the highest salary? Well, that kind of wouldn't be fair. Would it? Because it could be that junior program who's not worth a whole lot of billable hourly rate might have really saved the day.

So the right thing to do is to give that 20 grand to the team and let them figure out who should get what part of it. And that way they all have an incentive to create a lot of value and nobody knows better than them who deserves the reward. So let them figure out how to divide up that value in a fair way.

Galen Low: It's funny because like, I mean, it actually, it's similar to like a profit sharing model. Right, right? Where it was like, okay, here are the results from the quarter and then, you know, we're bonusing people out. And managers get to figure out that distribution, or in some cases, maybe a team figures out that distribution. But it's actually really interesting in terms of what you're saying is like base salary, get people in the door, plus incentive based on the value that is created and, you know, measured with some level of consistency, by the product owners.

That's very interesting.

Fred Fowler: It's what makes sense, because it gets all the incentives in the right way. Now that's one great thing about the scrum framework. It gets everybody's incentives right. And it gets decision-making put into the hands of the people who are capable of making those decisions and capable for being accountable for them.

So the product owner is basically an investor. Fine. Give the product owner the ability, the authority to invest the team's time, however the product owner see fit. But measure the results of those investments to see whether the product owner's doing a good job or not. And the product owner ought to be the person who makes decisions about, okay, let's do this and not do that.

But then they're answerable for what the results of those decisions were. Likewise, the development team has full authority to figure out how they're going do this. Nobody should tell them what to do. By the way, developers hate that. They really want somebody just to tell me what to do and I'll do my best. Because then they can just do whatever they're told and then go home and, you know, have a life and then come back and do more.

But if they have somebody else tell 'em what to do, then they really can point fingers if anything goes wrong. Oh, you gave me something that was too hard for me to do. Well, that wasn't my fault. That was your fault. You gave it to me. You should have known better. So it's not my problem. It's your problem. You're to blame.

By having the developers have the authority to make all those decisions themselves, they have nobody to point any fingers at except themselves.

Galen Low: And I mean, we haven't done, our industry has not done a good job of fostering accountability because some of the behaviors have been that. Do it this way, because I told you so.

Fred Fowler: That's right. And you know, and that's so counterproductive because it means that all the lessons that are learned while you're doing it, don't impact the people who are making the decisions.

You know, that's why scrum says the development teams have to be self-managing and they have to be cross-functional. Cross-functional means they have to be able to create the product all by themselves. If they aren't, if they can't, then they say, oh, well, we did our part, but you know, they didn't do their part.

So it's their fault. And of course everybody is pointing fingers every way. No, they all, they have to be able to do it themselves so there's no fingers they can point at anybody else. Second of all, they have to be able to organize and manage themselves. They have to make their own decisions. Because if they don't make over their own decisions, they can always blame problems on whoever did make the decisions.

And by the way, whoever did make these decisions didn't learn from the problems and mistakes that were encountered doing that. There's an old saying that says, nothing is impossible if you don't have to do it yourself. 

So if somebody tells you to do something, well, it's not impossible to them because they don't have to do it themselves. It's up to you to try to do. And how many times have you ever been asked to do the impossible? I know, I have been asked to do the impossible many times. 

Galen Low: That's that's actually funny.

It's it's interesting, right? Because it's that it's that balance of empowerment and accountability like together, right? You can empower them, but you're gonna be you, the team's gonna be accountable and that's a journey that doesn't happen overnight. 

Fred Fowler: That's true. But it's three things that have been asked: empowerment, accountability, but capability. The people who are empowered have to be capable of doing it. A product owner has to capable of throwing the responsibility of investing hundreds of thousands, if not millions of dollars, to try to create valuable products. The developers have to be capable of creating the product by working as a team in order to be accountable for doing so, and then therefore have the authority to do it. 

And, you know, that's the scrum master's biggest challenge, always. The scrum master's job is to get everybody working together as a team and understand their own responsibilities. Usually, the scrum master has to try to beat some sense into developer's heads who just wanna be told what to do.

And just say, okay, we'll do our best. And by the way, one good way to help is by introducing a compensation scheme, which rewards them for the actual value they create. Because once they realize, you know, if we don't do a good job, we're not gonna get any bonus. Then the way that we get a bonus is by the measurable value that's created.

Oh, okay. Well, let's get our apps together. 

Galen Low: I like that. Measure value and reward value. 

Fred Fowler: Yeah. Yeah. By the way, let me make one more point. It's very important for the product that a product owner is working on to have a measurable value. If you're working on something but you can't measure its value, it's not a product. And you can't make any rational decisions about how to do it.

Let me give you an example. I worked for a company that had a, basically it is a web based application for financial transactions. And they had three big components. They had, you know, the front end, which was the website and some app engine and things like that. Then they had a middle part which were APIs. The front end talked to.

And then there was the back end that actually did the processing. Okay, so three different levels, beautiful layers. When I got there, the company had three different product owners, one for each level. And there was constant bickering because the, you know, the front end people, you, they wanted, you know, these new capabilities. But they had to argue with the API product owner to get the API product owner to prioritize that.

And then they had to argue with the backend product in order to prioritize that. And there were these, all these pissing contests going on. There was actually one, pissing contest were a crucial update for the front end was held up for two years because the backend product owner didn't find that doing that would be within his compensation plan. 

So he had no interest in doing that. And, but the thing is that there weren't any products. I mean, the, you couldn't measure the pro, the value of the front end without considering the value chain of the front end, the middle and the back end. You couldn't measure the value of the back end without consumer.

So there should have been just one product owner for the whole value chain who would be accountable for the value delivered by the whole thing. And that way all of the, all of the conflicts would go away and you'd actually have a rational development situation. 

Galen Low: So it's such funny that the inhibitor of value is sometimes just politics. Right?

Fred Fowler: Well, yeah. Oh, yeah. Well, I mean, different people with different and the key is no one could measure the value of what they were doing. No one could measure the value of the decisions they were making. So they had, they were random. They had no way of rationally making decisions about what the development team should work on.

Galen Low: Yeah, we have this notion of like the minimum viable experience as well. Right? You know, like you said, it's three layers, but you know, if you're, you have to cut it in slices. Top to bottom, not horizontally because otherwise you're only seeing one layer. And what you're saying, if I'm picking up what you're putting down, what you're saying is that there's probably teams out there who are like, yeah, we can't do scrum.

We don't really produce increments. You know, we don't really have the notion of minimum viable product. But actually they might just not be orienting themselves around a product mindset, which would be to think of it as these slices, not as these component parts that get managed separately and, you know, have different priorities and different backlogs and different product owners.

It's very interesting. It's very cool. 

Fred Fowler: Actually, I check this out. I check this out with Jeff Sutherland by the way. He's the guy who helped create Scrum. And basically, he confirmed that a product is something that can be produced and that has an objectively measurable value. In other words, you can understand the value objectively without some opinion color or what.

Now, how do you measure the value of product? Well, I told you the four ways of increase, but you know you measure the product by selling it. You measure the product by, yeah, like getting somebody to pay for it. And so, you know, if you can't sell something, you can't get somebody to pay for it, you don't have a product.

You've got a part of some other product, which is the real product, which should govern the decisions about how it should be developed. 

Galen Low: I wanna round up with one last question. We've been talking a lot about Scrum and I know you're a huge proponent of Scrum, but when it comes to measuring value and impact over busyness, can this work for other methodologies? And what advice would you give those people? 

Fred Fowler: Other methodologies? Well, yeah. Yeah. And you know what?

Scrum is kind of a layer on top of something deeper. Agile is kind of a layer on top of something deeper and scrum. Scrum is kind of, it's ironic because scrum is all about trying to make products without trying to follow a recipe. You know, the PMI Waterfall model is all about planning, and creating a recipe for some group of people to follow step by step to, to end up with the result.

The trouble is that doesn't work very well, because things change. You know, one of my favorite anecdotes is a guy named Roman Pichler who wrote a book a long time ago, but it was a very good book. Agile Product Management with Scrum. He was one of the first product owners who actually wrote about it all. 

He talked about his experience running a two year project for a medical services company to completely replatform their main product. In other words, they were going to bring their main product up to date. And so they planned it carefully. They did a good old Waterfall model. This guy managed nine separate TAs, brought it all in on time, under budget, two years after the initiation of the project, only to find out that the product was already obsolete before the deliver.

Yeah. So basically things change and what Scrum, you know, following a recipe is no good. That scrum says don't do that. You know, do increments, watch what you're doing, learn, but the trouble is the scrum guide is nothing but a cookbook. It's a recipe for trying to do a project. But the deeper truth underneath that and underneath all the other things is that you have to be able to have qualified people, make decisions that they are accountable for, both in the terms of business and in the terms of product development.

And the developers have to be able to, you know, create the thing and manage themselves. Yeah. Those two things, plus some way of measuring incremental project, product, progress. And that's the basis of scrum. That's the base of can that's the base of all of it. So what I would encourage everybody, no matter what form they're using, make sure that you focus on measuring value as opposed to activity, measure results as opposed to outputs. And if you do that, then I don't care what framework you're using. As long as you are able to do things, measure the results and learn from that. That's the road to success. 

Galen Low: There you have it folks. There it is. Very cool. 

Fred, we were talking about your meetup group. We were talking about the books you've written. Where can folks listening learn more about those two things? 

Fred Fowler: Yeah. I've been running a meetup group since 2015, all about scrum. We call it the Advanced Scrum Case Studies meetup.

So once every two weeks we get together online and I post a case ahead of time, which usually provides some or poses some problem in terms of project management scrum management. You know, some difficulty like for instance, how to deal with offshore on your teams. How to measure value, which we've been talking about a lot.

So we meet once every two weeks. If you're interested, you're free to join. You can find, it's called the Silicon Valley Professional Scrum meetup group. You can search for that on Meetup. And then you'll see the Advanced Scrum Case Studies meetup we have. I'd love to have you. By the way, you know, that meetup has produced a lot of interesting material.

I've gotten notes for about 60 different cases. All very interesting. You know, some submitted by me, some submitted by some of the members. And I've written them all up in a volume called Advanced Scrum Case Studies. It's available on Amazon. You can also buy it on my website, which is www.siliconvalleyscrum.com.

It's got 15 of the very interesting cases and I'm actually working on Volume 2 right now. So be another 15. Like I say, I've got more than 60 cases stockpiled and I'm getting more every couple weeks. So, I'm gonna be documenting them in that way. 

Galen Low: That's super cool. I didn't realize, I didn't realize the book was based on the material from the discussions in the meetup group.

That's so cool. I love that. 

Fred, thank you so much for coming on the show today. I really enjoyed your stories. I really enjoyed your perspective. I loved our conversation on compensation. I think that's a whole 'nother episode in and of itself.

But I hope all of our listeners got a lot of great value from that. Thank you.

Fred Fowler: Thanks. It was, I really enjoyed talking with you. Thanks for having me.

Galen Low: So, what do you think? 

Is it feasible for project teams to orient around value creation instead of hours build or user stories completed? Or are we too deeply dependent on a money-for-labor-hours model? 

Tell us a story: what have been the right metrics to track for your projects? And what kind of changes or results have you seen from having insight into your project data?

Leave your thoughts in the comments below! 

And if you want to hone your skills as a strategic project leader, come and join our collective! 

Head over to thedigitalprojectmanager.com/membership to get access to a supportive community that shares knowledge, solves complex challenges, and shapes the future of our craft—together.

From robust templates and monthly training sessions that save you time and energy, to the peer support offered through our Slack discussions, live events, and mastermind groups, being a member of our community means having over a thousand people in your corner as you navigate your career in digital project delivery. 

And if you like what you heard today, please subscribe and stay in touch on thedigitalprojectmanager.com.

Until next time, thanks for listening.