“The reality of the world is that the problem changes and you have to be on top of what those changes are, so that you can adapt and have the right solution for the right problem at the right time, that the customer will pay for.” 

Intro:
Welcome to the Agile Digital Transformation podcast, where we explore different aspects of digital transformation and digital experience with your host, Tim Butara, content and community manager at Agiledrop. 

Tim Butara: Hello everyone, thanks for tuning in. Our guest today is Fred Fowler, agile coach and professional scrum expert holding the prestigious professional scrum master level three certification. Fred has worked with companies such as Apple, Oracle, Uber, and of course others, and he's the author of several books, including the just last year released Advanced Scrum Case Studies. 

In today's episode, we will be talking about the importance of finding and solving the right problems in order to drive success in today's super fast paced and highly competitive digital landscape. Welcome to the show, Fred. It's really great having you with us today. Anything you'd like to add to my intro before we jump into the questions? 

Fred Fowler: Well, thanks very much for having me and don't know if there's anything much to add except that I've got several books that are available on Amazon. One is called Advanced Scrum Case Studies. And actually, I also manage a meetup that's called the Silicon Valley Professional Scrum meetup. It's got 2500 members and we meet regularly to discuss advanced scrum topics. So anybody's interested in joining the meetup, please feel free. You're welcome. And again, thanks for having me. 

Tim Butara: Thanks for joining us, Fred. I'll make sure to include both the links to your books and the link to your meetup group in the show notes so that listeners can just check everything out directly. And yeah, we have quite an interesting topic for us today. I think that solving the right problems is definitely the key thing if you want to succeed. But first you have to know what the right problems even are. So Fred, let me ask you, what are the right problems and how do you find out which ones are the right ones? 

Fred Fowler: Well, it seems a very simple topic, but it's actually quite complex if you think about it, because how do you solve a problem? Well, you have to be able to measure your progress. It's useless to try to solve a problem where you have no measurement for whether things are getting better or not. So it's very important. And the Scrum framework emphasizes the use of measurement to make decisions. 

Scrum is based on the theory of empirical process control, which means you make decisions based on things that you have measured. Not about opinions, not about guesses, but about hard facts that have been verified. So it's very important, if you want to solve a good problem, you need to be able to measure the results. 

Now in the creation of new products or new functionalities, it's very important to measure the value of what you're creating. Most companies don't measure the value very well. What they end up measuring is the effort that goes into creating the value. And so there's lots and lots of people who measure how busy their folks are. What hours are they working, are they working ten hour days? Are they working six day weeks? Is everybody busy doing something all the time? 

And people who work for these organizations soon realize that the important thing is being busy. So they make sure that they're busy all the time. They're always in meetings, they're always talking about documentation, their emails going back and forth, working late hours, because that's what's getting measured. But in fact, it doesn't really matter if you're working lots of late hours or lots of meetings. It doesn't matter how busy you are if you're not producing anything of value. 

And that's one thing that Scrump emphasizes. You have to be able to measure the value that is being produced and compare it to the cost of producing it. The most important problems to solve are to figure out how to measure the value of what is going on. It's easy to measure how busy people are. All you need is a stopwatch and a calendar to figure out whether people are working hard. But are they producing anything that's worthwhile? 

And the industry is full of horror stories about huge, big projects that cost hundreds of millions of dollars and produce nothing. There is a famous book written by a guy named Roman Pilcher. He was one of the very first authors about Scrum product ownership. And he wrote a book called Agile Product Management with Scrum; actually wrote it about 20 years ago now, but he talked about his experience as a project manager using traditional waterfall methods. 

The company he worked for wanted to completely replatform their flagship product, which was a medical services tracking application used by big hospitals. And so they decided that they needed to modernize it, bring up into the current technology. And so they set aside a two year timeframe and millions of dollars, and Roman Pilcher managed the project. He managed nine separate paths, which is no mean feat, using the waterfall method. 

And he brought it in on time and under budget two years later, which should have been a success, except it turned out that in the intervening two years, the market had changed and they had created the perfect product for two years prior, and the product was obsolete before it was even finished. 

So it's very important to understand not only the value, what you're creating, but how that value is changing over time. Because what might be very valuable at the beginning of a big project might have no value at the end. So it's really the job of management to keep an eye on the value that is created and to figure out ways to measure it as you go, that's the most important problem to solve. Go ahead. 

Tim Butara: But what can be done, like in this example that you just highlighted with the Roman Pilcher and kind of the solution being two years late, I wanted to ask you about this. So if you find out the right problems and then you develop a solution, and the changes in the marketplace make it so that your solution is no longer relevant in two years’ time or whenever it gets released, what can you even do about it then? Are there any, like, I don't know, preliminary steps that you can take to avoid this as much as possible, or can you salvage it in some way? What can you do? 

Fred Fowler: Well, in that case, what really happened was that the market changed quickly and the development process was slow, slower than the market change. So the difference in time between the beginning of the project and the delivery was far too long to be able to measure what was going on. 

So that's one reason why the Scrum framework says, don't wait two years to find out whether what you're doing is worthwhile. What they do is they say that you need to break up work into small pieces, and there's actually a lean– it's lean but it’s also extreme programming. The idea that you want to put pieces of products into customers' hands often and as quickly as possible so that you can understand whether your idea of what's valuable is the same as what the customer thinks is valuable. 

By the way, if you think it's very valuable and the customer doesn't. Well, guess what? It's not valuable at all. So what Scrum does is it takes a big, long project like that and breaks it into small pieces. Those pieces are called sprints. They're usually two weeks to four weeks. And the idea is not to try to solve the entire problem before you even give anything to the customer, but to solve a little bit of it. And at the end of that period, look and see what you have done and measure how valuable it is in the eyes of a customer. That way, as you go along, if you start to see the market changing, you have a chance to correct it. 

And by the way, there are all kinds of examples of products that turned out to be successful, even though when they were started, they were for a completely different purpose. They adapted the purpose, and they adapted the position of the product as they went to take advantage of trends that they saw as they were developing. If you'd like an example, I'm sure you've heard of Webex, right? 

It's kind of a conferencing program online, one of the early ones that allowed people to interact online and also share each other's screens, share each other's, even their computers. You could actually take over somebody else's computer to do something with it. Okay. And became very useful in terms of collaborative work. But it didn't start out that way. 

Webex was originally created to let Cisco technicians work on customers' router configurations, the Cisco router configurations by, in effect, logging into a customer's local PC, asking the customer to log into the router – so the Cisco tech didn't know what the password was – but then allow the Cisco tech, in effect, to work the keyboard and the screen in order to correct configuration issues. 

So the original purpose was as a customer service tool, but after a while, they realized or somebody realized that, hey, this is much more than that. This is a way for people in far different remote locations to be able to collaborate to the point where they are even working with each other's PCs. So the original value turned out to be unimportant or relatively unimportant compared to the actual value that the customers saw in this product. 

Tim Butara: I think that was a great example. Yeah. A great way to illustrate the point that you made about how this evolves. And how did they find out that they needed to pivot their product or kind of reorient? 

Fred Fowler: Oh, their customers told them. Hey, this is great, what you're doing. Can I do it, too? 

Tim Butara: It's that simple, right? I mean, sometimes it is if you have a groundbreaking product like that. Yeah. And you mentioned before, you also mentioned the key role of management in kind of either finding these problems or helping others, so the people that they're managing, finding and solving the right problems. So how can you make sure that those people who are managing developers, who are ultimately the people creating digital solutions and digital products, how can you make sure that managers are empowering developers to solve the right problems? 

Fred Fowler: Well, first of all, the managers have to put the right problems before the developers to solve. You see, when you sell on a project using scrum, using waterfall, whatever, you're making an investment. You're spending time and money in order to create something of value. So it's very important to be able to measure that value and then compare it to the investment to figure out what the rate of return on investment was, the ROI. 

And in order to figure that out, you have to be able to measure the value of what you produce. Developers can't do that. Developers, their job is to figure out how to create what's desired. And the best way to have them do that is to let them figure it out themselves, pose problems for them to solve, and then challenge them to solve those problems. Again, that's one of the bases of the scrum framework. 

But the most important thing for anybody who is making those investments, in other words, telling developers what to do, is to be able to measure the result. Now, a lot of times, you have people working on things that aren't products, which means they're like components. A good example is, if you have some kind of financial application that has an app-based front end, a middleware portion which translates from the app to the back end, and then you have a back-end system. So you have three layers. 

A great mistake that has made all the time is to put decisions about how those layers should change into separate hands. And the problem is, everybody who makes decisions is basically making priority decisions and making investment decisions. But unless you have some way to measure the value that's produced by those decisions, you have no basis for making any of those choices. 

For instance, if you have a middle layer person, somebody in charge of the middle layer, and they make decisions, well, they can't affect the value of the product without the help of the app front-end folks and the back-end folks. Because as far as the customer is concerned, they are paying for financial service and the service is delivered by the front end, the middleware and the back end put together. 

So if you want to be able to make rational decisions about what would benefit the customer, what the customer would pay for, you have to be able to make priority decisions that govern all three layers, because only the combination of all three layers can produce measurable value. And so if you make an investment decision, only by measuring the value produced by all three layers can you come up with a return on the investment calculation or to figure out whether it was a good idea or not. 

But one of the people who created the scrum framework was a guy named Ken Schwaber, another one was Jeff Sutherland. And they're both very active in the community. And I confirmed with Jeff Sutherland about what a product is in terms of the Scrum framework. And it turns out that a product is something that can be produced and that has an objectively measurable value. 

If you don't have something with an objectively measurable value, then it's not a product. And in effect, you can't make decisions about how to change or improve it with any basis in rationality. So anyway, a product has to have some way of measuring its value. Now, how do you measure the value of something? Well, how do you measure the value of a product? You sell it. You figure out what somebody will pay for it by having somebody actually buy it. That's the only way to measure value. 

Value is measured in dollars and cents. And that's important because if you want to do a return on investment calculation, well, your cost, the costs are all in dollars and cents. So you have to compare the cost of producing something with the value that was produced. And the only way to do it– well, the simplest way to do it is to sell the product. 

Now, there are four ways that I know of increasing value. One of them is – increase revenue and sell the products, and then you can measure the value very simply. Let's say that you have a team and you develop an app for an iPhone, and it's kind of an app called Goofy Birds, some kind of a game. And you put it up on iTunes and it does a million downloads at $2 a piece. 

Well, what's the value of that Goofy Birds app? It's a million times $2. It's $2 million. You’ve just measured the value of that goofy bird app. Now, what was the cost? Well, if it cost 500,000 to produce it and it ended up being worth 2 million, that's a good deal. Let's do that again. If it cost $3 million to produce and it only sold 2 million, well, that's not a very good deal at all. So you can measure the value of the product by selling it. 

Another way of measuring the value of a product, or should say increasing value, is by reducing cost. Let's say your organization makes a million widgets a year, and you undertake a project to reduce the cost per widget by $0.50. Well, what's the value of that reduction? It's half a million dollars a year. So you can then say, okay, that's the value of half a million dollars. Is it worth 25,000 to do that? Yes. Is it worth 750,000 to do it? No. So it's very important to measure value. 

Okay. Now that's two ways. One is prevention, one is cost reduction. The third way is risk reduction. Let's say that– well, good example, I was the CIO of a distribution company in California, and we had a data center in our headquarters. And it was at the end of a long fiber optic cable connection to the main internet offices in San Jose, California. And out of that data center, we ran 21 locations around north America. Pretty much all the business was done in the data center. And then through communication links, instructions were sent to the various warehouses and other offices to say, please fulfill these orders, et cetera. It was all based on that data center in California. 

But once a year, some idiot with a backhoe would dig up that fiber optic cable and cut us off and basically make us lose a day of business. Now, a day of business for us was about a million dollars. So we had a risk that equated to about a million dollars per year because our data center was at the end of this long fiber optic cable. 

So one thing I did was I spent $50,000 to move our core servers out of that data center and into a very secure what's called a colocation facility. It's a huge big data center that places like Google and Facebook and all of those big ones put their servers. And so it was a very secure location, very robust. They had lots of internet connections. They had some of the biggest truck-sized batteries I've ever seen for redundancy in case of power outages – basically, it would never go down. So was it worth $50,000 to move that stuff in order to save a million a year? Heck yes. 

Tim Butara: Even if it were just for one year, even if it were just saving 1 million for a single year, it would still make sense. It would still be the right solution. 

Fred Fowler: Yeah, absolutely. Absolutely. It turned out to be very good for the company's bottom line. I have to admit, I'm quite proud of that. Now, the fourth way to improve value, the first one was increase revenue. The second one is decrease cost. The third one is decrease risk. The fourth one is increase opportunity. Let's say you're in an industry that lives on winning bids, and you win maybe one bid out of six, and each bid is worth $10 million, something like that. 

If you can make an improvement to make it possible for you guys to win two bids out of six, it's easy to calculate how much that's worth, what the value of that is. And again, you could line up that value and increase value with the cost of getting there. So anyway, the most important thing that management can do in a software development environment is figure out what the value is, what's being produced. Is it increasing revenues, is it decreasing cost, is it decreasing risk, increasing opportunity, and put numbers on those measurements and compare them to what the cost is of doing those things. 

Of course, very few people measure value because it's not that straightforward and not that easy. Lots and lots and lots of people measure cost. They measure time spent because it's easy to measure. But it's not important to measure. Not as important as measuring value. 

Tim Butara: Well, as you just highlighted, measuring value is the most surefire way to really be successful, especially in the long term. Yeah, we talked about managers now, and you mentioned that developers usually don't really know which problem they're supposed to solve and that management has to kind of take care of that role. But are there circumstances or are there cases where it actually makes sense to teach developers and engineers to kind of manage themselves so that they can uncover and solve the right problems on their own without having to have a lot of input from management? 

Fred Fowler: Okay, well, yes. And actually, the Scrum framework is designed to facilitate a negotiation between the technical people and the business people. In the Scrum framework, you have a role called product owner, and that's the person who understands the marketplace, understands what the customers need, and can identify valuable things for the developers to do. 

By the way, the product owner needs to put estimates on those values. And really, the product owner is working as an investor at that point, and we'll get on to that a little bit later. But anyway, there's a negotiation between the product owner who says, this is what's desirable. This was what would be so great if we had it. The customers would love it. 

And then the developers have to say, well that's great, but this is what's possible, this is what's technically feasible, and we can't do something, no matter how desirable, if it's just not feasible to do it. But we can do these other things that are feasible. And a lot of times the developers and the product owner have a conversation which in effect helps the product owner understand what is feasible and helps the developers understand what is desirable. 

Just an example, a lot of times inexperienced product owners will say, okay, we need to be able to log into this app, so give me a login screen. And the developers, if they aren't managing themselves very well, let's say, okay, here, let's do this same old login screen we've done time and time again. We'll have some UI stuff and then some JavaScript to capture information. We'll send it to the back end and the back end can process it against our user file and we can do all that. 

But developers, if they understand what's desirable and feasible, they might say, well yeah, we could do that, but well, what about just using sign on with Google, sign on with Facebook? They've done all that work. It's not that you want a login screen, you want a way for the app to identify who's working with it so that person can access their private protected information. 

So by changing this, the ask from “give me a login screen” to “let the app identify who's using it”, then the developers can start to figure out all the different ways that an app could identify somebody using it. Most phones these days have fingerprint readers. There's some facial recognition that's being built in. There are all kinds of options for how to have the app identify who's using it other than a login screen. 

So again, the programmers, the developers need to talk with the product owner about what the need is, not what the product owner asked for, but why. So then they can say, okay, well, we can fill the need with this login screen, but we can also feel it this way, we feel it that way, we feel the other way. What do you think, what would be best? What would the customer like best? 

Tim Butara: Yes. It's always about the user need, not what you're trying to do, or I mean, it's obvious that what you're trying to do should be the goal if it aligns with what your customers, users want, but also in the way that makes it most convenient for them, especially if you want them– in the case of an app, they're much more likely to continue using the product on a regular basis, using the app on a regular basis, if this initial experience is simplified. Right. 

If they have a hard time just logging into the app, then they might just abandon it all together and never really come to the experience that you put a lot of effort and time into developing and tailoring exactly for them. Because you didn't also take the same care in kind of investing the same amount of effort and time and customer care into that initial experience. So the logging in or the recognition.

Fred Fowler: Exactly. By the way, the Scrum framework has a special event within it that's designed to get direct customer feedback and have the developers and the customers talk about what's going on here. If you don't mind, I'd like to tell a little story about something that I participated in that worked out quite well along those lines. 

Some time ago, I was teaching people how to be Scrum masters and product owners. I had courses that I was taking people through, and as part of it, we would do software projects for not-for-profit organizations. We’d basically go to them and say, hey, would you like some free software so we can practice? And then organizers say, yeah, that's great. That's great. 

So anyway, we undertook some of those, and one of them was with an organization called the Taylor Family Foundation. They're a little bit outside of San Francisco. In California. And if I remember correctly, they're kind of the foundation set up by the Taylor wine family. Taylor was a big wine producer, probably still is. But anyway, they had a big estate a little bit east of San Francisco where their vineyard used to be, and they would run summer camps there for children with cancer. They would take these kids who normally live life in hospitals, poke full of needles and tubes and things like that, and just let them be kids for a while. 

Anyway, there's a big garden because these Taylor people, they love plants. They grew grapes and they loved plants. So there was a huge, big garden full of all kinds of very strange and exotic kinds of plants. There was even something called the sticky monkey, which I never saw, but I'm very curious about. 

And the kids loved it. They'd run around in it and say, wow, look at that. Well, look at that. And then but unfortunately, the kids would point to something and say, hey, counselor, what's that? What's that? What's that? And of course, the camp counselors were just college kids and they weren't botanists. And a lot of times they said, well, I'm sorry, I don't know. 

So what the Taylor people asked us to do for them was to create an app. They had a bunch of iPads that had been donated to them. So they asked us to create an app that would let these camp counselors identify the plants and give information about it so they can answer the kids when they asked. 

And so what we ended up doing, we figured out that we could print up QR codes and put QR codes on all the plants, and then we could use the iPad’s camera to basically take a picture of the QR code, interpret it, and then pop up a display about that plant. And on that basis, we got started. And after two weeks, we had what's called a sprint review. And the sprint review is that event I was talking about where the developers and the customers get together to talk about what happened. 

And during the sprint review, the team hadn't been able to print the barcodes yet, but what they were able to do is they were able to display on a wall a projection of one of these QR codes. And then they took the iPad and they took a picture that projected QR code and up popped information about a plant, including a picture. And they showed that to the Taylor people. 

And Taylor says, wow, that's so cool. After two weeks, look, there's a picture. That's great. And can we have more than one picture? Well, you see, the plant doesn't look the same in the springtime as it does in the summer, or the fall, or the winter. And we want the kids to be able to look at the picture, look at the plant and say, yes, that's the right one. 

And then they’d always say, okay, you want a carousel, you want a different picture depending on what season it is. And yeah, the calendar in the iPad is there, so we can figure it out. Is that what you want? And the Taylor people says, you can do that? Developer said, yes, sure, no problem, piece of cake. And then they, wow. And then the product owner wrote down this list, carousel of photographs, season dependent. That was a problem to solve. 

And then one of the developers said, hey, would you like this to talk? And the Taylor folks said, what? Yes, this is iOS. They've got great text-to-speech features. We could put a button on the screen that says Talk. And then when you press the button, it can read the page out loud. Would that be something you want? And the Taylor people says, what? You mean we can give this to kids who are too young to read? We can give this to kids who can't see? And the product owner wrote down text to speech. 

So you see, that's the power of the sprint review. It's actually showing the clients what you created and getting them to talk to you about what's possible to do next. And then using the Scrum framework, that happens every couple of weeks. So, you know, if the poor Roman Pilcher and his medical software application, if they had been checking with the customer every two weeks, they would have been able to see that they were heading in the wrong direction and correct it. 

Tim Butara: You did mention that that was kind of really the textbook waterfall management, the one that Roman Pilcher highlighted. 

Fred Fowler: Yes, that's correct. 

Tim Butara: This would be kind, even just a kind of soft, agile approach would be something totally different. But then scrum is very meticulous, very well thought out, as you've also highlighted throughout this entire episode. It would totally make sense, especially the more that digitalization evolves and the faster innovation is, the likelier it is that a solution will be obsolete if it takes a long time to develop. So I'm guessing that the more digital technology evolves, the more this Scrum or at least some kind of agile approach will be not just viable, but necessary. 

Fred Fowler: Absolutely. You see, Scrum is all about learning what you need to know as you go along. The one real weakness of Waterfall is that it assumes you know everything you need to know at the very beginning. So you know everything you need to know, so then it's possible to create a rationalized plan, to create something, provided you plan enough. 

I think these days, PMI, those people who are the champions of Waterfall are advocating that you spend almost 50% of your project duration simply putting together a plan. And unfortunately, when you put together a plan, you're not really learning anything because you don't learn from planning, you learn from doing. 

Tim Butara: Also, as we just said, things change so quickly that if you just invest into planning, then just by the time you'll be done planning, the plans will be less relevant than when you started to begin planning. So even that starts to make less and less sense if we take it in the context of 2022, innovation, digital transformation and all that. 

Fred Fowler: Yeah. The right thing to ask, the right question to ask is what is the most important problem for us to solve right now? And really that's the basis of the Scrum cycle. Every couple weeks, every month, every sprint, you stop and look and say, okay, what's the most important problem for us to solve right now? 

And that important problem might change over time because again, if you're building the wrong thing, this poor Roman Pilcher is doing, then you probably don't want to do that. You want to focus on something else. You want to pivot, and you will only pivot if you stop and measure what's actually going on and then ask yourself, are we trying to solve the right problem right now? 

Unfortunately, the world of Waterfall is all about figuring out what the problem is in the beginning and then making a big long solution that won't be completed for several years and several million dollars. The reality of the world is that the problem changes and you have to be on top of what those changes are, so that you can adapt and have the right solution for the right problem at the right time that the customer will pay for. 

Tim Butara: That was perfectly put and I think it was also the perfect way to round off our discussion, which, Fred, has been a great one, and I think it will be invaluable for a lot of the people listening right now who maybe haven't yet implemented these methodologies, who are maybe still doing everything following the waterfall method. I think that you did a really great job of selling both the Scrum framework and why it's so valuable in today's landscape. Just before we wrap up our discussion, Fred, if listeners would like to reach out or learn more about you, where can they do that? 

Fred Fowler: Okay, well, fine. Thank you. I'm on LinkedIn, but also I have a website, it's called www.siliconvalleyscrum.com, and that's where I post lots of news and information. It's also where books are available and actually training materials are available. Also, my email address is ffowler@siliconvalleyscrum.com. So please feel free to reach out and I'll be happy to reach back. And Tim, thank you very much for having me on this show. I really enjoyed it very much. Thanks again. 

Tim Butara: Well, I was just about to say thanks again for joining us. I really enjoyed the conversation as well. I'm really glad that we did this, and I hope we get to meet to speak again in the future. 

Fred Fowler: Very good. Yes, indeed. 

Tim Butara: Well, to our listeners, that's all for this episode. Have a great day, everyone, and stay safe. 

Outro: 
Thanks for tuning in. If you'd like to check out our other episodes, you can find all of them at agiledrop.com/podcast, as well as on all the most popular podcasting platforms. Make sure to subscribe so you don't miss any new episodes. And don't forget to share the podcast with your friends, friends and colleagues.