In today’s episode of the Agile Coaches’ Corner Podcast, host Dan Neumann is joined by Steven Granese, the vice president of the Transform practice at AgileThought. As the VP of the Transform practice, Steven leads a team of the top agile coaches, DevOps consultants and product consultants in the United States.
Today, Dan and Steven will be exploring the “why” behind Scrum and examining the question of why organizations and teams should be using Scrum in the first place. Steven often sees that the clients he works with lose focus on the “why” behind Scrum, or don’t even know what it is to begin with. With these clients, there is a lot of focus on the mechanics of Scrum and the framework itself (i.e. the “how”) without a deep understanding of why they’re using Scrum, what problems they’re trying to solve with Scrum, and what their purpose is for working with Sprints with iterations. In this episode, Steven addresses how organizations can shift their perspective from a “how” mentality to a “why” mentality, as well as many of the misconceptions and incorrect uses of Scrum (so you can be sure to avoid them).
- Why it is important to focus on the “why” behind Scrum rather than the “how”:
- The “why” helps the team and organization understand what problem they’re trying to solve with Scrum in the first place
- Focusing on the “how” (such as: “How do we execute Scrum?”) leads to organizations applying Scrum incorrectly
- Understanding the “why” leads to a deeper understanding of why they’re using Scrum, the problems they’re trying to help solve with it, and what their purpose is in working with Sprints and iterations
- The “why” behind Scrum and where it makes the most sense to use:
- In conditions of high uncertainty
- In environments of high uncertainty
- Incorrect ways Steven sees Scrum being applied:
- As opposed to building a working increment of their product, getting feedback as they go, and adjusting their Sprint-to-Sprint plan based on the feedback (which is the heart and soul of the “why” behind Scrum), they’re not allowing feedback into the process—therefore losing the “why” in the process
- Breaking up work into milestones instead of Sprints
- Treating the Sprint demo like a sales pitch and not letting the customers experience the demo for themselves
- Techniques and tips for achieving the “why” behind Scrum:
- Recognize that the market moves fast; there’s a lot of uncertainty in the world and customers’ needs are changing very quickly
- Match the way you think about your work and deliver your work to that uncertainty (which allows you to move faster)
- Stop over-planning and just start working
- Put increments of the product into the customers’ hands and start getting their feedback
- Get back to the basics and simply focusing on two weeks at a time
- Measuring the right metrics (“You get what you measure”)
- Don’t just use Scrum to measure the team; use it to measure the flow of the entire system
- Focus on getting really high-quality feedback from your customers
- “Begin with the end in mind.”—Stephen Covey
- Through receiving high-quality, real feedback from a Sprint demo, really listen to the feedback and adjust the plan and fix problems accordingly
- Understand where the market is headed (and differentiate between what the customer wants and what is actually needed) by building something and putting it in their hands to get feedback
- Fail fast to learn fast
- Build in thin slices and get feedback as you go—you will learn a ton about what users actually need and also save time by not building unnecessary features
- Misconceptions about the Scrum framework:
- That Scrum is really about product delivery (“Scrum is just as much about discovering the solution as it is about delivering the solution”—Steven Granese)
- Scrum and other agile frameworks are seen as a delivery mechanism (as opposed to a mechanism to discover what the customer actually needs)
- That you have to use Scrum (if you already know exactly what you need to build and if there’s no uncertainty then there’s no need for the Iterative nature of Scrum)
Mentioned in this Episode
Steven Granese’s Book Pick:
- The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations, by Gene Kim, Patrick Debois, John Willis and Jez Humble
- Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, by Nicole Forsgren, Jez Humble and Gene Kim
Transcript [This transcript is auto-generated and not completely accurate in its depiction of the English language or rules of grammar]
Intro: [00:03] Welcome to the Agile Coaches’ Corner by AgileThought, the podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now here’s your host, coach and agile expert, Dan Neumann.
Dan Neumann: [00:16] Welcome to this episode of the Agile Coaches’ Corner. I’m Dan Neumann and excited today to be joined by Steven Granese, the vice president of the transform practice here at AgileThought. Thanks for joining, Steven.
Steven Granese: [00:27] Thank you, Dan. Nice to be with you today.
Dan Neumann: [00:30] All right. We have done quite a number of episodes about Scrum, the events, the artifacts, the roles, and today we’re going to be exploring the why Scrum in the first place. So kind of stepping back from the activity. So how often do you run into that type of question or the need to explain why Scrum in the wild?
Steven Granese: [00:50] Well, you know, that’s why we decided to, to take on this topic of the why behind Scrum is because that’s really the problem that I’m seeing a lot of our clients have. And what I mean by that is there’s a lot of focus on the mechanics of Scrum. There’s a lot of focus on the practices of Scrum, the Framework itself. So things like, you know, what’s the best way to run a Sprint review meeting, uh, or, um, how should I structure my user stories, which is of course not even part of the Scrum Framework itself. Um, but a lot of people think it is. Um, and just a lot of focus on the how, how do we execute Scrum, but there’s not really a deep understanding of why they’re using Scrum to begin with. What’s the problems that Scrum is trying to help them solve? Uh, what’s the purpose even of working with Sprints with iterations? And so I see that a lot from the clients that we’re working with and frankly, some of the clients that, that we’re, uh, trying to work with as well. And so that becomes a lot of the discussions that I’m having. Uh, certainly with teams, but, but also with leaders and organizations, they just, they’ve never really been educated on the why. And so I find myself talking about that topic a lot.
Dan Neumann: [02:08] Yeah. It reminds me a, what was it, Stephen Covey’s, Start with Why, was one of the, uh, one of the principles that he had. And so good place to start with Scrum as well.
Steven Granese: [02:18] Right. Because you know, it’s not for every problem that you’re trying to solve and it does certainly solve problems as we’ll start talking about here. It definitely helps when there’s uncertainty when you’re not exactly sure what you’re trying to do and you’re, you’re trying to move forward in the face of uncertainty. Um, but again, I see it applied in the wrong way, right? So, uh, again, we’ll, we’ll work with clients and we will be helping them figure out, you know, what’s the problem? How are we going to help them from a, uh, from a consulting perspective to say, you know, how can we best help you? Um, and oftentimes they’ll say, well, come measure us in how we’re doing Scrum. And I’ll often say, well, what, first of all, why are you using Scrum? Like, how you trying to get better? Uh, are there new products you’re trying to create? Um, you know, what’s the problems that you’re having in your industry right now? And again, often I get blank stares. Ah, gosh, I don’t really know that, uh, didn’t really think that has anything to do with, uh, the way we’re running our processes. So, so yeah, that’s a, you know, a big theme is really getting back to the basics in my mind, Hey, let’s figure out the problem we’re trying to solve. You know, why would Scrum help us? And then let’s make sure that we’re using Scrum in the right way.
Dan Neumann: [03:26] Yeah. So let’s talk about some of the why of Scrum. Specifically you’d mentioned one of the places Scrum makes a lot of sense is in conditions of high uncertainty. Okay. And so what’s, um, what are you seeing as far as the Scrum Framework as is being really applicable within high uncertainty environments?
Steven Granese: [03:46] Yeah, and so actually I’ll, I’ll start with how I see it being applied, uh, in the incorrect way in my opinion. Um, so what I often see, especially with large enterprise clients that are trying to apply agile, um, and, and therefore they’ve chosen a Framework like Scrum. And what I often see is that the mentality is that of a large project, so we’ll, I’ll start there as an example. So they’ll, they’ll have a, project a large project, let’s say it’s a year long project. Um, they’ve estimated it out might be a software product that they’re trying to create, but they, they’ve estimated out to be about a year. They have budget for a year. They may have 10, 20, 50, a hundred people kind of doesn’t matter. But they think in terms of, uh, of a year, meaning we’re going to release this product at the end of the year. Um, again, our budgets are, are, are focused around that 12 month mark. Um, and the way they use Scrum and the word I use is milestones. Instead of Sprints, they actually have milestones. Meaning they break up their work into, uh, let’s say it’s two week Sprints, but what they really are are milestones so that they can manage their project. Um, and as opposed to they’re actually, uh, building a working increment of, of their product, of their software and getting feedback as they go and adjusting their Sprint to Sprint plan based on the feedback, which is certainly the, the heart and soul of what I talk about when I talk about the why of Scrum. They’re not allowing feedback into the process so they have the plan for the year. Actually, I worked with a client about a year ago that really, uh, really got me thinking on this topic frankly. And they had a whole year plan, a Sprint plan, Sprint one Sprint to Sprint three all the way out to Sprint 26 because you know, two week Sprints and that basically takes up their entire year. They had planned out all of the Sprints. Um, and really it was a, it was a waterfall mentality. You know, they had just put the whole plan together. Um, there was no room for feedback because the feedback came in and they needed to adjust. Uh, maybe they needed to adjust the work that they just did in the previous Sprint, or maybe there were new ideas for new features that they just, they struggle with that because where would we put that? We already have all the Sprints planned out. And so I started to realize that they didn’t understand why they were doing this. They had just, they’re just applying Scrum as a project management Framework, meaning as just a different way of executing the same waterfall mentality that they had, but they weren’t allowing feedback into the process. And so, um, I started realizing that, uh, the Y was missing. Meaning we’re doing this. We’re using Scrum because there are a, there’s a lot of uncertainty. Meaning we have a product idea that we, we think we’ll be successful in the marketplace. Uh, we have customers that we think that there’s a need to build a product that, you know, does something that would solve this need, but we don’t exactly know what it is. Um, so we’re going to need feedback as we go and we realize that even if the need, even if we’re right about this need for the product, the world is changing fast. So if we can get that product out pretty quickly, that’s great, but by the time we get it out, maybe it’s no longer relevant or maybe a competitor came out with something similar or maybe the needs is just not there anymore for, you know, for, for lots of reasons. And so recognizing that the market moves fast, that there’s a ton of uncertainty in the world, that our customers’ needs are changing very quickly. Recognizing that and matching, you know, the way we think about our work, the way we deliver our work, you know, to that uncertainty, it allows us frankly, to move faster. It allows us to stop trying to plan everything out, figure everything out, and just start working and start putting increments of the product into the customer’s hands and getting their feedback, which is the spirit of agile to begin with. Uh, and so in a lot of ways it’s simpler than a lot of organizations are making it, but they can’t get out of their own way, right? Because of historical reasons. They’ve always worked in a certain way. Maybe they have compliance, uh, requirements that they think they have or that they do have and they just don’t know a different way of working. And, um, you know, well, maybe they have annual budgeting processes that again, they, they’re kind of stuck in a rut from, from an agile perspective. Um, so there’s lots of reasons why I see organizations can’t get out of their own way. And what we’re really trying to help them do is, let’s get back to basics. Let’s just focus two weeks at a time. Let’s build something that we think is of value to the, to the customer. Let’s put it in their hands. You know, let’s put that product in their hands and let them use it. Um, let them experience it and then give us feedback and then adjust the plan from there.
Dan Neumann: [08:32] Yeah I think of the water Scrum is one phrase that comes to mind or the waterfall agile where we, um, we, some organizations I should say not we agile thought, but some organizations envision, Hey, we’ll nail all the requirements and then we’ll iterate through it in two week chunks. And the uncertainty really is where Scrum plays well because now we’re getting an increment of software delivered, we’re getting feedback, we’re getting value and we’re reducing risk as we go through, um, on a Sprint by Sprint basis with the Scrum Framework. That’s very cool.
Steven Granese: [09:06] Yeah. You know, a common conversation I think I’ve had with, with several clients in the last, uh, six months, frankly, is that, um, you’ll ask ’em well, you know, how has agile working for you? Oftentimes the first times we’re meeting them and, and sometimes they’ll say, yeah, it’s going okay. You know, we’re not as disciplined as we could be. Um, you know, we’re not really good at writing user stories, you know, things like that. Think frankly things about the mechanics. Um, but they’ll say, but overall we’re doing pretty good. You know, it takes, and I’ll say, I’ll ask questions like, well, how long has it taken you to get a product to market? And they may say, you know, it’s not too bad. It’s about six months. You know, we could be faster than that, but, um, but you know, it’s about six months, nine months, something like that. And when I kind of unpeel the layers back, when I start asking him more questions and I, um, and start digging in a little bit more, what I often find is that, well, that six to nine month delivery is just the IT view of the world, right? The software team’s view of the world. By the time the requirements were handed to them and they were assigned to the project, it yeah, it took about six to nine months to build it, test it, um, you know, go through user acceptance testing and get a little bit of feedback near the end and get it out to their production environment, get it out to their customers. But what often happens is it actually started about two or three years before that, you know, somebody had an idea, let’s say it’s somebody on the, on the leadership team had an idea, maybe a product manager had an idea and it, there’s a lot of process in their organization, so they had to go through all kinds of hoops to get the, the idea approved and to do some analysis and to get budget for and to get people assigned. Um, and those processes have been baked in some of these companies for, you know, for 30, 40, 50 years. And in reality, from the time somebody had the idea until it got into the customer’s hands, it’s two or three years, sometimes four years. And that’s not really speed to market. And it’s, you know, the, and then at the same time, these same clients are saying, you know, we’re losing out to competitors who are moving fast, faster than us. You know, we’re slow to market and getting them to see not just, you know, the, the IT view of the world, which is six, nine, 12 months. But to see the entire system, the entire company’s view, the entire organization’s view, it’s really taking your organization two to three to four years to get these products out to market. That’s the challenge, right? Um, that’s the challenge to get an organization to recognize, well, gosh, how fast can we get an idea into a customer’s hands? And that should be, you know, weeks or months, not, not years, frankly, certainly in the uncertain world that we live in.
Dan Neumann: [11:39] Yeah. I forget where I first encountered the phrase naval gazing. And I don’t know if that, uh, translates well to folks who are listening to other places, but basically staring at your belly button is what that’s referring to. And that’s that mindset. Hey, you know, we’re moving fast. It’s three months or six months to release the product. But it’s looking at that little slice of the, of the whole value chain of building software, turning ideas into software as opposed to where are the ideas coming from and how are we working with the marketing team? What are we doing from a technology standpoint to roll those out? And so, um, for folks maybe who are trying to connect Scrum to getting things through that whole value chain faster, what’s, what are some techniques where for the why of Scrum there, especially as we move away from the, the waterfall agile or, or defining things up front and then just iterating through delivery?
Steven Granese: [12:28] Right. So certainly what we talk with our clients about an AgileThought here is, is really measuring the right thing. So a phrase that we use often is, you know, you get what you measure. So if you’re just gonna measure Scrum metrics, let’s say team level metrics, like a team’s velocity for example, if that’s what you’re going to measure, then you’re going to get behaviors that optimize those metrics, right? So you’re going to get teams that and organizational behavior that’s just going to focus on optimizing the velocity, you know, have a team or just team level metrics. And so we start by saying, well, what is the behavior that you’re looking for? What is it that, um, that you truly want to measure? So, for example, um, you know, we’ll often work with organizations and say, well look, you’re measuring, you know, these team level, uh, metrics, you know, like I said, velocity or some other types of metrics. But let’s measure what if we measured how fast it took your organization from the time an idea came up or maybe until an idea was validated that it’s um, that, you know, cause there could be a ton of ideas and maybe we don’t want to act on all of them, but by the time an idea is validated until you get it into the customer’s hands, what if we measured that, you know, not just from again the IT view of the world, but the leadership view of the world, the product management view, the, uh, finance team approving the funding for it and the budget for it. What if we measured all of that? And what if we broke down the, the work from all of those departments into smaller chunks so that we could move a little bit faster? How would that change things? And frankly that, you know, causes some disruption inside an organization, which is the intent of, of Scrum, right? We, the intent of Scrum is let’s change the way we’re working because it’s, you know, frankly, there are problems. It’s if we, if we didn’t, if we weren’t having any problems, we wouldn’t need to change anything. And so not just using Scrum to, to measure the team, but you know, let’s, let’s again, let’s use, let’s use Lean metrics. Let’s use cycle time and lead time and throughput to measure the flow of the entire system. So oftentimes what we’ll do is we’ll, we’ll apply Lean Kanban methods, for example, and Lean metrics to the entire organization and recognizing that Scrum teams are one part of a, of the flow of that organization. And, and so, but we have to measure the entire system, right? We have to measure how, how things are flowing throughout the entire organization, not just how a Scrum team is doing
Dan Neumann: [15:03] Yeah, you touched on a couple things that, uh, I’ve seen in lots of places and are kind of top of mind for me. One of those is breaking things down into small chunks. So the traditional approach, certainly when I was project managing more directly, we had big thick requirements documents and they moved slowly through the system. There was lots of inspection and validation. It was always kind of hard to tell if something was done or not done. And so in the Scrum Framework where we’re delivering things, every Sprint, we’re delivering an increment, you’re breaking things down into much smaller pieces, easier to validate, they flow through faster. And that’s, that’s a huge advantage to the Scrum Framework in, in my mind.
Steven Granese: [15:43] Yeah, it certainly is. And we know, we talk about, you know, why are we doing this and what I will, um, often talk with clients about, uh, to, to quote Stephen Covey, begin with the end in mind. So why are we doing this? You know, what’s the end state we’re looking for? Well at the end of a Sprint in my mind here, uh, in my opinion, um, at the end of a Sprint, I want to get really quality feedback from my customer. Um, that’s what I need to optimize my team for. It’s not to have a good Sprint demo. Let me, let me talk about that for a second. Cause that’s a behavior that I see often. Yeah. Um, instead, I use the word Sprint demo intentionally because you know, a Sprint review is certainly in the Scrum Framework, but we see a lot of organizations that have drifted into, Oh, it’s a Sprint demo. We’re going to demo our software. And why is that important? Well, um, what I often see is that a team will have a Sprint review meeting. Maybe they’ll call it a Sprint demo, but they’re there to demo their software. They’ll demo, I mean, they’ll put it up on a screen, they’ll invite people, maybe some people will, will show, other people won’t, but they will. Again, they’ll present it like it’s a sales presentation. So if you’ve ever been on a team that’s preparing, you know, for your, for your Sprint demo, and you hear phrases like, okay, everyone, whatever you do, don’t click that button up there in the corner. Because there’s a, there’s a bug there. If we click that, then the whole system blows up. Okay. And we don’t want to have a bad demo. We want it to look really, really good. Um, so it’s a little bit of a dog and pony show that we see often, right? Because we want to have a good demo. The intent of getting, in my mind, the intent of getting really good feedback is to have a working product increment. It works, right? Even if it does one thing, it does it really well and it works, and you don’t demo it to a stakeholder, to a customer, you hand it over to them and you let them experience it. Now, ideally you let them experience it in the environment in which they would use the product. So if they’re gonna, you know, if they’re, if you’re building a software application for someone to use on let’s say a mobile device, like, like an iPad, and that person is going to be out in the middle of a, of a, a field, maybe they’re on a farm and they’re going to be using this device out in the middle of the field. Well, the best place to get feedback in a perfect world is to, is to deploy that, uh, that working product onto that mobile device, onto that iPod and let them use it in their native environment. Not always possible. I get it. However, we’re looking for great, rich feedback. And the best way to do that is to, again, deliver that product to a customer. Again, not a demo, but deliver it to the customer as close to their environment as possible so they can play with it, experience the product, try to use it to solve a particular problem and tell you if they like it or they don’t like it. Right? That’s real feedback. And then based on that real feedback, you now know your team now knows, okay, what should we do next? Should we fix the problem that we just heard about? Maybe we’re heading down the wrong path entirely. Maybe we got an idea from the customer that makes us rethink what we’re even doing here in a good way. And we need to pivot the product entirely. Cause we never really thought about the problems that that customer is actually trying to solve. You know, Sprint demos, demos in a, in a board room, in a meeting room that have nothing to do with the actual customer’s environment. Oftentimes, frankly, in my opinion, most of the time just don’t give you valuable feedback, right? Yeah. You might get some feedback, you might get some interesting ideas, but they just don’t really give the deep rich feedback that you’re looking for. So I think about, you know, think of the end in mind. What’s the point of the Sprint? The Sprint is, the point of the Sprint is to, is to get really deep, rich feedback from your customer so that you know, if you’re heading down the right path.
Dan Neumann: [19:29] So Steven, we’ve talked about applying Scrum in areas of uncertainty and having a really good Sprint review with an opportunity to get rich feedback. Can you share any other misconceptions about the Scrum Framework that you’re running into and people are asking about the why of Scrum?
Steven Granese: [19:49] Yeah, I think the, one of the primary misconceptions that I hear is that, um, that Scrum is really about delivery, you know, product delivery. And what I mean by that is, um, you know, I was mentioning before about how oftentimes what’s really happening inside an organization is they’re taking two or three years to kind of figure out what project that they should be working on, getting approval for it. And then by the, again, by the time it gets to the IT organization, um, they have figured out the problem, meaning they have all of the requirements, they have figured out the solution on paper. Um, and now they’re asking the development team to go build it. Um, so the way I translate that and the language I use is to say, well, that means you, you’re thinking about Scrum and the Scrum Framework as a way to deliver a solution, and again, you’ve already figured out what that should be. Um, and that’s a big misconception because Scrum has just as much about discovering the solution as it is about delivering the solution. And by discovery, I mean really helping the team discover what is it that the customer really wants. So it’s kind of traditional requirements gathering. Um, is that let’s go talk to the customer, talk to our stakeholders, let’s figure out what they want, and then let’s write that all down. Let’s document it, get it into, um, kind of memorialize it into a document so we can all agree and then let’s go build it. But the problem with that thinking is, especially as the world is more uncertain now, is that it’s very hard to really know what the customer needs. No, they may ask for something, you know, they may say, this is what I want, but how do we know that’s what the customer really needs? How do we know that’s what the market is really asking for? You know, you’ll, if you ever listened to books or, or interviews with Steve Jobs, you know, the kind of famous, uh, thinking around some of the decisions that he made running Apple is that, you know, he knew where the market was going. He didn’t ask what the customers wanted. Nobody would have told him that they wanted an iPhone or that they wanted, um, you know, an iPad, things like that. Or, uh, nobody wanted him to remove a floppy disk drives, you know, from, from the, uh, from the laptops. But he knew that’s where the market was going, right? And so he knew that’s what was needed. And so we differentiate between, you know, what the customer wants, what they’re asking for and what, what is actually needed. Well, my mind, the best way to determine what the market needs, what customers need is to build something and put it in their hands and get feedback. I mean, it’s a simple concept. Of course, it’s difficult to execute. Scrum is not easy to execute, but it’s a simple concept. Build them a version of it, an increment of it, put it in their hands and get feedback. Let’s see if they like it, if they use it right, if they use it, if it helps them solve their problem, if it doesn’t, we know that it’s not really what they needed. And so the concept that, um, it’s very popular in the agile world about failing fast, you know, we say, Hey, you’ll, you’ll hear that all the time. You’ll, you’ll hear even leaders talking about, you know, Hey, agile is all about failing fast. And then when you talk to the people inside these organizations, they say, Oh, there’s no way we can fail fast. We’re not allowed to fail around here. I mean, we can talk about failing fast all we want. Um, and then I’ll ask, well, why, why do you think that that’s the case? Why are you not allowed to fail fast? What I find is that, as I was saying before about how organizations are, uh, it takes two to three years oftentimes to get these projects approval. By the time the development team starts working on it, the organization is two to three years into this project. That’s not fast, that’s slow. By that time, they’ve already made many, many decisions about what they’re building. Um, they’ve already gotten approval at many levels. They’ve gotten budget approval at many levels. So by this time, there’s no more failing fast. Now it’s time to execute. And the idea of Scrum is that, you know, let’s decide the market, uh, what, what we think the market needs. Let’s move fast, not two or three years. Let’s get a team and let’s build something quickly, you know, within a matter of weeks. And let’s test that idea out. It could be prototypes, it could be actually fully functioning software, but let’s put a version of that product into the customer’s hands and let them give us feedback. And so if we quickly find out in a matter of weeks that they don’t like this product, or maybe we just didn’t understand the market or where the market was going, that’s failing fast. But that’s learning fast. Um, that doesn’t happen over the, you know, again, over the course of several years. So that’s a big misconception that I see. Just to kind of summarize that is that, um, you know, Scrum and other agile Frameworks for that matter are often seen as a delivery mechanism and not as a mechanism to go discover what the customer actually needs.
Dan Neumann: [24:31] Yeah. And when you do have those long cycles of budgeting and developing and then finally releasing like so much financial as well as political, um, you know, value is locked up in a commitment to deliver. It’s hard to walk. It’s hard to walk away once you’ve spent any money, let alone seven figures and, and so, yeah, it just, it stretches out so long and then it’s, you almost feel like you have to finish.
Steven Granese: [24:57] You do. And, and when you bring the human element into this, so really what you’re mentioning, just kind of really adding to what you were saying there, Dan, um, you know, once several people have made decisions, even if they’re on paper only, Hey, this is the right product to build the, you know, the, the teams start, um, becoming ambivalent to getting real feedback. If they get real feedback that, Hey, maybe this is the wrong thing. Gosh, I don’t know if we want to tell that person who is really already staked their reputation on the fact that we need to build this product. Um, that’s, that’s a difficult problem to solve. You know, rather than everyone in there together saying, let’s run an experiment. Let’s gather data from the market. Let’s not decide before we give it to the market or to our customers about what the right product is. Let’s have a hypothesis that we think they’ll like this product, but let’s put it in their hands quickly and let’s gather data. Let’s let the data make that decision. Let’s let the, the honest feedback make that decision again, rather than individual people’s opinions. Um, that’s really, um, like you were saying about, uh, about why it takes so long, right? If we move quickly and let the market tell us what the right and wrong thing is to do, oftentimes we can’t go wrong.
Dan Neumann: [26:04] And that’s in order to get that feedback from the market. That’s where from a practice standpoint, we start to advocate for a thin slice across all the capabilities that you might need to deliver. Because if you just do step one of a workflow and step two of that workflow, if your product handles multiple steps, you know, by the time you get to step N and you can release it, you’ve sunk so much into it as opposed to a thin slice all the way through or a steel cable all the way through the application, then you can get some, some early adopters, some feedback and figure out where you want to add more capabilities that are really gonna move the needle from a receptivity to what you’re building.
Steven Granese: [26:43] And that’s a really important, uh, topic Dan, um, about the thin slice and it’s, it is a very difficult concept for many organizations again, who have been doing something for a long time. Uh, it’s a really difficult concept for them to wrap their heads around. So let’s use the example of, you know, a simple eCommerce site where you’re going to search for a product, you’re going to look at the details of a product, and then you’re going to add that product to your shopping cart and checkout, uh, you know, let’s say that that was, uh, the product you’re building. Um, we see lots of organizations that map out all the requirements for that entire product. Um, again, they use Scrum to start delivering it in a, in an iterative fashion, but they’re not releasing the product until the end. Let’s say it’s a 12 month, uh, uh, you know, project to, to deliver as opposed to, you know, in the first Sprint or two, let’s build a very simple search capability. Maybe just a search box, you know, that you type a word into and you hit search kind of like Google. And then let’s have a simple page that returns a list of, of results from that search. And, you know, let’s allow the user to, to, um, to add the item to the shopping cart and pay with, uh, you know, one form of payment, like let’s say a visa credit card. You know, rather than adding all different types of payment methods and, uh, you know, uh, whether it’s American express or, or PayPal or Venmo or Bitcoin or, you know, all of these different things. Let’s just do the simplest version, the simplest path through. And then let’s let an actual real customer use this system and get their feedback. Maybe we realized pretty quickly they don’t want to buy this product from us. You know, maybe we can stop right there rather than investing tons of hours and dollars on building out this whole product. Let’s validate that the market even wants this product. And the best way to do that exactly like you said, is build a thin slice and get feedback from him.
Dan Neumann: [28:28] Yeah. You don’t need eight forms of payment acceptance if nobody wants to buy your products.
Steven Granese: [28:33] And you know, another, um, uh, I don’t know if it’s a misconception or maybe it’s just a lack of understanding that we see, uh, from let’s say large enterprises that are building internal software. They’ll often say things like, well, we’re not building this for the markets. We’re not building this for customers. You know, we were building an internal tool. Maybe it’s to help the internal workflow, um, of our, of our organization here. We already have a tool they may say, and so we can’t release the new tool until we finish everything and we convert everybody over. Um, and it’s just a, it’s a normal, uh, kind of mindset that we see. And what the problem is, is that you end up getting organizations that are just rebuilding the same functionality that they already have. Maybe it’s on a modern technology stack. Uh, you know, maybe now it’ll start working on mobile devices rather than before. They could only use desktop computers, things like that. So there are some advantages, but they’re not necessarily challenging. Um, the, the way the old system was built and so we advocate for is well the market could be external, you could think of the market as internal, but we still need to get the feedback from the users who are going to use this product in their native environments, even if that’s internal. So still build it. Um, and in a thin slice, get their feedback as you go. You will learn so much about what the users actually need by doing that. And it will save you so much time and money because you end up not building, um, features and aspects of the product that you just don’t need.
Dan Neumann: [29:59] Yeah re-platforming efforts in my experience have always been notoriously brutal efforts for that reason. You’re, you’re, you’re trying to duplicate the functionality. I’ve, um, participated in as a, an employee somewhere else, a re-platforming where we re-implementing bugs, um, in the old software because it meaningfully changed some calculation that mattered. So we had to leave the bugs in, uh, as opposed to, uh, an approach where we’re shipping early and maybe we’re, we’re strangling off the old system a little bit at a time. And I guess that that’s probably a podcast for a whole other day is how you move from one platform to another. But Scrum and that feedback and the increment and getting it in the actual hands of people is a huge advantage of the Framework.
Steven Granese: [30:47] You know, it is. And, and you know, on that point, Dan, I would never advocate that that Scrum or kind of any agile method is the only way to work. You know, let’s say that you have a, a tool, a product that you’re using and you do need to re-platform it and you know exactly what this product needs to do. It already works fine. Um, you know, you’re really just upgrading the technology. There’s really nothing to discover. Now, I may challenge you if that’s true or not because I would still, uh, challenge that assumption. That maybe there’s a different, uh, and version that really needs to be true. But let’s just go with that assumption that, um, there’s really nothing to discover. We just need to execute. We just need to rebuild what we already have. If that’s true, then I would advocate, don’t bother using Scrum because there’s no uncertainty there. If you really truly don’t have uncertainty, then the iterative nature of the feedback loops of Scrum don’t really help you if you know exactly what you need to build, just go build it. You know, use a waterfall method. And I, and I mean that, right? Scrum helps when there’s uncertainty and when you don’t exactly know what the users need, what your customers need, that’s what Scrum is there for. So it does not have to be applied in every situation.
Dan Neumann: [31:58] Yeah. When the technology is known and the needs are obvious and you’ve done it before, you can hammer through that with not agile. Um, yeah, I joke with my metaphor like I don’t want McDonald’s getting all agile on my burger when I walk in there. I want, I want it to fly through the line as fast as possible the same way they did the last hundred times I got a burger there this year and I just want the burger.
Steven Granese: [32:22] Right. There’s a, yeah, there’s certainly a difference between, you know, creating a new product, uh, which in a software world again is, uh, there’s so much uncertainty out there because there’s so much competition and there’s so many other organizations that are rapidly creating a product that’s intentionally trying to displace your product. Maybe that doesn’t happen as much in, you know, in other industries. But if you already have, let’s say you have a software product, um, that and you’re trying to distribute it out to, you know, your offices or your clients and you’re really a, you know, on the internet. Now, of course it’s, so, it’s, it’s much easier to do that in the old days of, you know, stamping, you know, your application onto a DVD or a CD and shipping that out. Well, at that point it’s really just operations. You know, we already have the product, but now we’re just trying to distribute it. Like your example of the McDonald’s hamburger, we already know what the product is now we just need to replicate it over and over and over. There’s, you know, Scrum is not going to help with that. It may help you to come up with a new product. You know, if McDonald’s is going to create a new product, a new type of sandwich, something like that, um, then yeah, Scrum may help them to rapidly come up with new ideas, get feedback along the way, get feedback in different markets, um, and then ultimately land on the products that they want. Sure. Um, and that’s, that is the challenge that I see with leaders who are trying to understand how to apply Scrum and when to apply Scrum. The question is not, you know, what’s the right Framework? It’s well, what’s the environment that you’re in? Is there truly uncertainty in the environment that you’re developing a product for? And if there is yes, Scrum can help. Um, and if there’s really not, then you know, consider traditional methods. There’s nothing wrong with that.
Dan Neumann: [33:59] So Steven, thanks for bringing us back to the why for Scrum under those areas of uncertainty. And that brings us to the question of what have you been consuming lately that’s got you inspired reading or audible books, those types of things count.
Steven Granese: [34:14] Yeah, I actually do listen to a lot of audible books these days. Um, you know, really for the last year I’ve been focusing on more kind of systems thinking and, and uh, in dev ops and really looking at, uh, the entire value stream. So I just finished up the DevOps handbook it was really a great, uh, read a great, um, kind of extension of some of the work about the goal from Eli Goldrat. Um, and just finish that and now I’m reading, just started the book, Accelerate, another DevOps book. Um, and the reason I, uh, really so intrigued in that that, uh, topic right now is again, looking at the entire value stream. You know, a lot of people think dev ops is really just about you tools and automation. And yes, that’s a component of it, but it’s really looking at the entire value stream of an organization. Uh, like we were talking about before. Let’s measure, uh, how we get an idea through the entire value stream, through our development teams, through our product teams. You know, out to the operations team, how do all those groups collaborate together? So those are um, you know, just some really modern ways of thinking about looking at the organization holistically.
Dan Neumann: [35:23] Yeah. And I love the mindset and the practices that come out of DevOps because they are so enabling for that feedback loop. You know, Scrum is not sufficient and, and you know, the folks who founded Scrum and, and continue to do thought leadership on it, they’ve, they’ve never said it was the be all to end all, in fact, quite the opposite. It’s going to uncover deficiencies and opportunities and places to improve. And I think DevOps just marries really well with that.
Steven Granese: [35:50] It does. And you know, as we often a coach in our, in our practices, DevOps being the extension of agile. And I like thinking about it that way because, uh, you know, Scrum teams and um, and the Scrum Framework is really great for helping teams get organized and to start working more collaboratively and working more effectively. And like you said, it’s not the end all be all. There’s other ways of working to, um, especially in larger organizations to kind of cut through the red tape that are there and the DevOps mentality. Um, like you said, it’s just a, it’s just a great way to start approaching some of these organizational problems.
Dan Neumann: [36:25] Outstanding. Well, we’ll put a pin in that one for another day as well. And uh, thank you for sharing about reading Accelerate. We’ll put that into the show notes at agilethought.com/podcast and people can go find the, all the books that were referenced in the different, uh, visuals here.
Steven Granese: [36:43] All right, well Dan, thanks for having me. I love talking about this topic and, and thank you so much for all the work you do on this podcast. We really appreciate it.
Dan Neumann: [36:51] Thank you very much. We’ll uh, we’ll get you back here, Steven.
Steven Granese: [36:53] Thank you anytime, Dan.
Outro: [36:56] This has been the Agile Coaches’ Corner podcast brought to you by AgileThought. The views, opinions, and information expressed in this podcast are solely those of the hosts and the guests and do not necessarily represent those of AgileThought. Get the show notes and other helpful tips for this episode and other episodes at agilethought.com/podcast.