AA78 - Building the Wrong Thing, with Senior Scrum Master Ted Wells

Are we doing building the wrong thing? Is that what we're talking about? Building or the positive version building the right thing. Let's talk about building the right things. I mean, this is better those are two different things. Let's build some wrong things, right? Well, are we building the wrong things, right? I I've done that. building the wrong things. Right? I've done that too. The market just moved on by the time we figured out what we were building like the, the, the segue for this, Hey Ted. Welcome the edge podcast. Thank you. Arguing agile. could be anything. I forgot what the name of our podcast is. You have no idea what the name of your own. I have. No idea is arguing agile. That's what it is. I've been doing too many episodes. I've been in organizations where they say, listen, just build what I'm asking you to build. And then, if you build it, customers build it and they will come. And that always works. Right., knowing actually it almost never works. I've been in a lot of organizations where your product led, meaning we try something and we pivot based on the results versus sales led, meaning, , the customer tells me. If I produce X widget and Y widget, they will sign a deal for, , Z number of dollars, that's like a promised prosperity. I will buy. Yeah. Just Scott build it. I mean, if we agree to build X functionality, you will sign on for Y number of dollars. Here's a contract Mr. Customer. There'll be people out there are listening us saying like, what are you talking about? That's reality. Yeah. But, but, but that, that all that ignores what we've built X functionality, you pay us some money and still, no one's using the functionality, but if you've built your entire business on that model of.. I want you to build X and as long as you build X, no matter whether somebody uses it or not, I'm going to give you money for that. That's a different business model than what we hope we're driving toward, which is give us a small improvement every so often. Maybe that's two weeks, maybe it's a month. Maybe it's longer than that, but it's a small change. Hopefully it's improvement. It's a small change and we give it to you and we see how you like it. Mm-hmm. And then we, as a business say, oh, they seem to like that thing, give 'em more of that. Or, or improve it a little bit, give them a little something different as opposed to like, like you said, build me this big thing. And that's where I think the, we built the wrong thing. Problem comes in because if you're doing it incrementally, you've never built the wrong thing. You've just built a tiny thing that people didn't like mm-hmm and that's fine. Yeah, I'd say, I'd probably reframe that and say, instead of you built this tiny thing that people didn't like, it's they got an early look and they basically nudged you in the right direction of what they're really looking for. Right. So whenever you release something to them, it isn't foreign to them. Like, okay. Oh, wow. That's great. I said, we don't use it that way. We don't want that. That that element of surprise can be avoided by incorporating your customers through your journey. And companies that are building the right thing often you'll find will have the customer with them. Right. Right. throughout the journey. So vet the ideas and not just at the beginning and then some interim points at frequent checkpoints within the process is we said, last time, this is what we kind of discussed. Is this, am I on the right right. Track here, if not be prepared to pivot and pivot quickly. And that's what you mentioned is having the customer there. Mm-hmm at, at key points, it's not just have the management or just have a stakeholder, just have somebody who's signing off on a thing. Yeah. To be in the room or to sign off on the thing it's having the person who's going to be using this thing have representatives, of people who are gonna use this thing there every step of the way to say yes, this thing works for us. Yeah, indeed. Absolutely. So proxy customers is a fallacy. You assume that somebody within your organization knows what the customer wants, because that's an assumption they made mm-hmm and they said, well, I know what they want. They want this. Yeah, we always do this on the podcast. So there are very, very few exceptions to that. there are some visionaries that think through the problems. And say what the market's missing is X. And I go back to that when I always go back to, which is Steve jobs came up with the iPod. Yeah. He didn't ask people. He saw that people were lugging this thing around it was a cassette player. Yeah. And he was quite big. And you strapped at this side of your belt, right? The Sony Walkman. But when the Walkman came out, it was a big deal because, well, you've taken this portable cassette player, portable luggable really, and strike the form factor. He basically answered the need of, you can only take so many cassettes with you with the iPod. You can have hours of music and it's with you all the time. Yeah. Right. And you can book podcasts on, you could do that. Maybe even this podcast. Oh, no. Like we've used that example a couple times. Yeah. We have, and I have to think, and I have to wonder if like Steve jobs in that example, if he's not too high level for the feedback we're talking about, like the feedback I'm talking about is like, Hey, I want to have, , my entire music library, maybe he was the guy in the room being like Hey, I got this giant wall of records. This is Steve jobs. So he probably had a giant wall records. I got this giant wall of records. I wanna have those in my pocket. And that was at the level, the, the, the strategic level he was at. and then somebody had to take that and break that down into smaller well, what does that, I mean, what does that mean? Does that mean one song, two songs, a dozen songs. Maybe we start with 10 songs and then we'll figure out how to manage a catalog of, of thousand yeah. Thousand albums, right? A thousand, 1,010 songs, or a thousand 15 songs or whatever, and whatever an album was in the seventies or whatever Steve jobs, it was how old do you think we are? don't answer that. Please. Those breakthroughs are really rare when you think about any product, really? It isn't that somebody just said, okay, let's produce something and, and, oh, that's gonna be a huge hit. Yeah. When you really look at where that came from, what you're gonna find is they've done their homework. They've figured out a real pain point that they're trying to address. Now, the only thing is it may not be across the spectrum of the customer base. It may be a given subset of that, and that's nothing wrong with that, right? That actually is an agile way of working. Because if it works with that subset, there's a chance it might work with us. It may not, but there's a chance that at least you'll be successful marketing and selling that, that subset. Yeah. So it's not random when these things happen. People might think it is, but it's not. I don't even know where I was going with that. I'm on board where you're going. What I think of like product owner specific, like one specific team, not scaling with the leadership level. here's my vision. In the Amazon book or where they introduce work, working backwards, basically. I can't remember the name of the book. They talk about the, the in Amazon, they would come up with the like this, this is the end-state, right?. And one of, one of the original end states for them is users hate that the shipping time, they, they, they, they don't like the shipping time. So if you're gonna give someone free shipping and take all that outta the equation and be like, Hey, it's gonna be to you within two days and you don't have to pay for it. Like that was a revolutionary breakthrough for them and catapulted their service to the next level. that's probably like the worst example I'm gonna give, cuz it is a difficult, it's a service. It's not really a product. Right. But it's sort of both, it's sort of both, it's like you need the service and the product. So delivery is a product, I guess, right? Yeah. Yeah. But, but you need the service and the product together. Yeah. To do that. The product. when somebody buys something, you have to make sure that it's, it's in a warehouse available within the service distance. And you have to make sure that the service team has capability to deliver it has capacity, I guess, would be the word. So there, there's more involved in that. So that's why I say it's like, it's a, it's a complicated example. I dunno if it's a great example. Well, but it's a hundred small things. It is. Yeah. Right. You know, and which ties back to the small incremental change. Right. It's if like you just said, you have to figure out is this thing available, so let's make sure that we absolutely nail down and optimize figuring out if that thing where that thing is available. Is it in this warehouse? Is it over here? Yeah. How do we get there? And they have the robots that now go in and grab the individual item, but. every single step of that along the way is an opportunity for the product owner, for the team to be able to tweak that just a little bit and say, how can we get that a little bit better? Mm-hmm how can we get that? You know, to get us closer from two weeks shipping to two day shipping to same day shipping. Yeah. Right. Yeah. So, and there are opportunities, every single step of the way. Yeah. It's not, it's not a big bang launch of they, he didn't say probably my guess is he didn't say in a year, six months, we're gonna have two day shipping and it's gonna be free. He probably said something along the lines of this is a problem. Figure it out. Yeah. Right. Get us to that place. Right. Yeah. The working backwards model. I'll find the book that I, this came out of came out and Amazon dealt with discovering and implementing it this way. I'm finding it. I swear. No, no. The book is called working backwards, working backwards by Colin Breer and bill car that's that's the book because Amazon's model is they will, when they want something done, they'll choose a single threaded leader to go lead the initiative and they'll give them the budget and they'll give they'll delegate the task of them. And then it'll be up to that single threaded leader to go implement it. So like in, in my, in my brain, that's the product manager. Hey, I, I want to. Figure out their, their whole thing was rolled into like customer loyalty and stuff. Like they, they knew shipping was kind of the key to customer loyalty. It was the, the Amazon prime that everyone uses now for, for shipping mm-hmm was the original way they implemented it. They handed it off to, to one person and had them build basically the whole program around it program. Well, customer experience. I hate to use terminology. Yeah, yeah. Nonsense. But they built the whole program around, but, but they handed that off to somebody and then that's that somebody engaged in experiments over time to figure out how we're gonna do it, how it's gonna make its money and stuff like that. And then there's a bunch of other stuff in that book that I can go into, but this is, I'm trying not to turn this in the podcast of the working backwards model. Are there any other examples that we can think of like that. In the industry? I mean like under the category of getting feedback, I mean I can think of a bunch of negative examples I could argue against it. Like the arguing, the arguing against it is like you might be working like, you might be like, oh, Brian Amazon's are ridiculous. Like not everyone works in Amazon and all these Silicon valley, Facebook, meta, whatever, you know what I mean? Yeah. The FAANG companies, like that's not what the majority of people work at. The majority of people have to take this evidence based approach to building the right thing or build even building the thing. Right. Even if we're going into that category and you have to adopt that to your current culture. So sometimes management will come down and be like, listen, you just gotta build X, Y, Z, just do it. Just build X, Y, Z some like. You can't fault the teams for just following orders, I guess. Right. But you'll get what you get at the end of it. I mean, contrast that with teams, that challenge that and say, why are we building this? I mean, almost like a five year old, do the five whys we have to, why are we building this well, because, okay, why? Right. And just keep doing that so you can understand it. The, the difficulty is oftentimes we don't see teams challenging those decisions because they're at the team level and these people are higher, you know? So I think it's the onus is on those of us that are working with the teams, scrum masters, agile coaches CPOs, whoever to kind of encourage the team to ask the questions. Yeah. And if that is not well received in the organization, then ask the questions on their behalf. Yeah. But do it in front of the team so they can see that you are leading by example. It's okay to ask questions. If you do that in isolation, you are just another one of those people that are saying, well, no, no, build it this way. Right? Mm-hmm and you don't want that. I've never been in an organization where that sort of top down build this specific thing never happened, but the best results I've seen have come from, I want to move this metric, or I want to get this result. And they say to generally the product owner, they say, get me this thing. Mm-hmm I don't really care how you go about doing that thing, but I want to increase this number. I want to decrease that number, or I want to get this result. Here's the result. I want go figure out how to do that. And the very best product owners take that to the team. And they say I've been tasked with doing X. I have an idea to this or that or this I think we can do it this way. What do you guys think you're in the middle of this system all day long? What better ideas do you guys maybe have? Hit the nail on the head right there. Like I'm very wise the, the best product owners. But so you is what you're saying. The team doesn't always deal with the best product owners. Sometimes the team is the one questioning and the product owner is the one afraid to question I've been on plenty teams. Oh, sure. That way where, where the, where the team is saying like, well, the management is saying, we need to , add a checkbox or something like that. Mm-hmm but, based on what we know about the user, like the user is with us, every sprint review, for example, The users never said they wanted a new checkbox. Like what the user we think is wanting to do is whatever I mean, whatever they think it is. So basically you're challenging against what I'm saying, management in these examples that kind of shortcut us. It could be, it could be sales, it could be support. It could be a lot of other departments in the company. The scrum model, like the, the, the scripture or whatever will say oh, we'll go to your product owner slash manager, and they'll do some experimentation based, whatever. Like the reality is sometimes they don't want to get in front of that. Yeah. You know, kind of, kind of this other category that we were not gonna talk about is like, sometimes they, they don't want to be perceived as a person starting fights management. Management's a great example of this one. Just add a new option in the dropdown, add a new checkbox, add a new, whatever add a new option to select in the mobile app. It's like, oh, is that what the customer wants? Because I don't think that's what they really need. I think what they really need is this new flow in their workflow. That's what you're talking about. Why don't you let me the product person experiment with that? Let's do a little A/B testing. Yep. You know, let, let's add a new option. And we think about social media, for example, let's add a new option. And then every time someone clicks on that, it gets recorded on a database. They get a popup message that says, Hey, Hey, Hey, this is a new function. It's not available yet. We're working on it. Even though we have no intention of working. But that's what it says in the app. Of course. And then we'll just record, like how many times do people click the ability to see more information about whatever. And you're willing to put yourself out on a limb to be like, okay, no users clicked my new box. I guess we'll abandon that and not go down that road. Right? Yep. But the feedback thing is like, are you being perceived as going against management? When you're asking to be like, Hey, let me just put this option out there just to see what yours do. Right. Cause cuz I've been in some organizations where that is not like it's not like E listen, your feedback is not desired. That's where I'm going with this. Well, there are too many, I think product owners, people who, when it, that the. Dictum comes down. Hey, put in a new check box. Yeah. Or put in a new line item or whatever it is. They don't say why, what is if they don't understand the why behind. Yeah. You know, if the reason is, well, we need more signups on this thing or we, we need less things going over here, whatever it is, they probably have a better idea of how to get to that end outcome than the person who told them to do the thing in the first place. But if they don't have the feeling like they can have that conversation and say, why do you want to do that thing? Yeah. Then they're probably just gonna do it. Yeah. I agree with that. I think in that, in those kinds of scenarios, you have the, the product people. Not only saying sometimes, not even saying what they want and why, but simply saying how, say I want a check box. just say what you want. Right. Just say I want the, the ability to select one or multiple options. Yeah. And let the developers figure out what is the best control to use there mm-hmm is it the checkbox? Is it a series of radio buttons? You know, whatever it is, don't dictate to them. Right. So take the work to them, but also take them to the work. Rather don't take the work to them by saying, do this, do this, do this. Just say we need this because that's it. Well, depending on how you ask that question or depending on how the dictate comes down, I could easily see, Hey, I wanna measure XYZ. I wanna do this all the time. I'll say I want to instrument this. I leave it up to the team to come back to me to say, Hey, we implemented this and these are the stats we have for you. And this is the funny thing about me is since I was a QA engineer in a past life, I can be like, you guys, haven't broken this down to you can't tell me which individual, whatever is failing, or which IP addresses sending back me. Like, you need to break that down to this level. Cause I now am gonna ask and the way that you've broken it out and done your first past implementation, it's not deep enough. Right. It's not deep enough to get me what I want. Right. Okay. We have I think about like, I think about people being like, well, Brian, well, you're being pedantic like, oh, you're a product manager, but you shouldn't really care about that. I don't know. Like, should I really not care about that? Or should I partner with my. My, my technical peer on the other side to be like I don't know, if I say I, my servers that serve my service available through APIs in the busy part of the day, I want to know is that is that traffic equally distributed between my farm that manages my APIs or is or is like one server shouldering the burden of all of everything. And then when it gets overloaded, then my time for my customers goes from like 0.3 milliseconds up to like 50 milliseconds or something like that. I think he's gonna say the same thing. I'm gonna say, so go ahead. No, no, no. Please jump on it. No, I was gonna say what then make th those things part of the requirements. Right? So put in the response times that you need put in the load balance and requirements that you have, make it part of the requirements and let the team figure out how, for example, in that scenario, well, what load balances they use? Do they use F five? How many, who cares? That doesn't matter. Yeah. I mean, exactly. It doesn't matter to me, but, but, but the, when I write up those type of requirements and I hand it off to the team, the first time they're implement, I'm talking the first time they're implementing it. I don't know what the responses are gonna be like. So I gotta look at what the response is gonna be like before I write more. Stories on the matter, so like we're talking about building the building the wrong thing. Yeah. Right. The idea between like what, what building the right thing means for me is we gotta put something out there, measure it, take the feedback and adjust. this is a tough one for me, which I, I wanted to bring this one up on a podcast for, for a while. Right. I wanted to bring this one up, up, up on the podcast for a while, which is refactoring. This is, is a good one on LinkedIn, too. Like refactoring refactoring, meaning you're going back through code. That's already in production that works and you're just making it better. Okay. The, the ideal outcome is it usually doesn't see anything. You're just. Easier to maintain, right. Easier to upgrade, easier to read for other people on your team. A product people. I see this topic as especially difficult to, to work with what is the ROI, right. ROI. Like the business people here. Like, I, I I'm like, I'm purely asking this as a rhetorical, right? Cause like I, the QA engineer understand the need to be like, Hey, quite honestly, six months after I write code as a QA engineer, I have no idea what it does. Right. Six months after I have no idea at all, but the next people should be able to read it and maintain it, change it and maintain their changes or whatever. What is the advice to product people in that example of, of, of, we need to. anytime we're in that part of the code, we need to delegate to our people to maintain upgrade. Move along that part of the code. I think it's the intangibility of these things. Did I say that word? Right? Sure. Anyway, so the product people aren't really understanding that most product people, unless they're from a QA environment or a background or some technical background, why aren't you working on things that matter? Mm-hmm right. But what they don't realize is these things matter, cuz you are actually accumulating that tech net and the savvy product owner would say, let's have a dialogue about this. Do you need time? Do you need bandwidth in the sprint? Right. To make things more robust, right. Improve the -ilities, I call it scalability and all of those things. Right? If a product owner thinks that way and doesn't load the sprint with just what they think is needed, but lets the team do some refactoring. Yeah. This is where I like the idea of the, the innovation sprint mm-hmm does it have to be a sprint? I don't know. We can talk about that, but part of every sprint, I mean, yeah. So for me that is the thing. Leave some space in every sprint to go back and fix things up. Well, Polish things, right? The business to my experience tends to not like. The thing that isn't shiny and new, they want, they always want the sexy, shiny new thing. It's incumbent on either the tech person or whoever it is who sees the value in it to be able to express maybe through the scrum master, maybe themselves, but to be able to express what that value's gonna be to be able to say, Hey, that thing that we built last sprint that took us five days to do. If we refactor that it's gonna take us a day and a half next time. Right. You know, or in the future, if we don't refactor it, it's gonna take us a month. To explain what the value is that they're gonna get, because just saying it's cleaner code and it's prettier and more elegant. Is not helpful to a product owner. Cause they're gonna just say, is it faster? Not really. Is it oh, it's just more elegant and I like it better. No, it's not helpful. We did a whole podcast on, the benefits of a non non-technical background, product owner slash manager. Right? I, I feel the, the technical focused product owner slash manager, I hate to say given, can I just say product manager? Okay. Product manager the product manager, who has a deep understanding of technical matters. I don't, I feel I'm not, I'm not helping here. I feel they can more easily lobby. For what we're talking about here. I'm kind of talking about this, but I'm also convincing about, as I'm talking about it, I'm convincing myself with the other of the other side. If you have a product manager who doesn't know anything about the tech, like they just can't, they zone out when you start talking about like, oh, we gotta refactor this method and this function doesn't work for whatever, or we gotta make this more object oriented, or we gotta sub out whatever technology for whatever. And they're like, I don't understand. I don't, I don't really want to be involved in this conversation. I feel the reasons for making things more maintainable. because the idea of more maintainable is in the future, they will be much faster to change and add things soon or refactor when I need to change them. So I I'll be more open to saying like, yes, the end result. When we take on this story, a refactor story, basically the end result will be the user sees no difference, but I know that in the future, I can sell this up to the business because I understand in the future, when I ask for a change, it'll take a half a day, as opposed to now we gotta inherit 3, 4, 6 days, whatever. I mean, the days of changing things yep. That's one of the, -ilities, right? Maintainability is one of the-ilities, so I agree with that. I think part of it is also incumbent upon, the team or the, the, the scrum master, et cetera, to position it in a way that makes sense. So, so we have to make it better. Well, why didn't you build it right the first time. Yeah. Right. So just say in the future, I have literally heard that. Yeah. Yeah. So in the future, we are going to save X number of hours, days, whatever it is, and project, but you know, we're not looking for accuracy, but project and say, so that translates to a savings off X dollars. Now you now you're speaking their language. They understand that we talked a little bit offline around product owners or people who are okay being wrong. Mm-hmm and not knowing or not understanding it, having that. Oh, a couple of them are having, but having, having that kind of sense that I don't know everything is to me a, such a huge win in specifically a product owner, because I've just seen so many of them, the best product owners I've ever had have been able to say. You know, like those old timey pirate maps, where you say, I am here. I want to be here. Here there be dragons. Yeah. Like, I don't know, what's in the middle. I don't know how you're gonna get me there. I don't care what technologies you use to get me to here, but I know where I want to be at the end. Now I have seen very technical POS that, and they are very able, like you said, to be able to advocate for certain things and be able to understand why you need to do certain things, the challenge that I've had with some of them, and this might be just a very singular thing, but is that they can get very tied to a solution. I was gonna say in the weed. Yeah. Yeah. Yeah. I, I, I, I expected. That's where we're going. Where my brain was going was not there. I anchored that because I am that that's, that's the difficulty for me. The more difficult, perspective for me to envision is the PO who just doesn't know mm-hmm like, I, I, for real doesn't know. Yeah. For real yeah. Yeah. If you're talking about building an AP, like I I've built APIs and tested APIs, so I can tell you all about what I want out of an API solution. But I can't even envision a world from someone asking for an API when they don't know anything about how, how an API works, what it means when you solution an API, when you don't like, I, I couldn't even put myself in those shoes cuz I'm so far removed. from that. So I have to think again, if the scrum, like we, this goes back I don't know where we're gonna draw the line on where I, when I say this, but if the scrum master is somehow in between the world of this PO who knows the business domain and knows nothing about technology, and the team who's completely uninformed about the business theory. In reality, as the team learns and works, they will learn about the business. So like a new team, for example, sure. A new team. So somewhere between the product person who knows nothing about development, but knows all about the domain and the development team who knows all about technology implementation, but nothing about the domain. Somewhere in between them is the scrum master facilitation skills. Notice, I didn't say the scrum masters, right? Technical knowledge or domain knowledge or nothing like right. The scrum master's facilitation skills to figure out how to get everyone talking in a manner that kind of moves it forward. I'm trying to unpack and take a side here. I was trying, I was trying what's. What you had talked about earlier, Om, the five whys or seven whys or, however many whys you want to use is kind of what I think part of what we're talking about, because you had said, well, if I need an API for a thing, well, my first question, if you say that is like, why do you need an API? Right. Nobody, no end user needs an API. They need information or they need to be able to contact that server, or they need to do what they don't ever need to contact that server. They need a product or they need something. So the idea that you need an API you've jumped eight steps yeah. Past the actual need that the customer has. So that would be where I'd start is why do you need an API? Yeah. Right. Because. I'm gonna say 99 plus percent of the time. You're right. Yeah. But maybe the team goes, oh, you know what? We actually don't need that. Yeah. We need, we, we have a better way of doing that. Mm-hmm so that's where I'd start. Yep. And that danger is real. When you have a PO who is technical or has a technical background, right? Yeah. They, they almost bring the why mm-hmm. And the what with also the, how a little bit, right. I need an API that does this, but they've already decided they need an API. They may be right. But leave the, the opportunity for the team to ideate yeah. On the issue. Right. And figure out what is the best way to do this. And the challenge in having that facilitation, that, that back and forth is I know in my heart of hearts, You're probably right. like, you're, you probably do need an API. You're gonna be right. More often than not, but the idea to get the team in the middle of that, maybe it's not exactly what you envisioned. Maybe it's slightly different. Maybe it's a different a different build of it in some way that you didn't think of mm-hmm and the fact that you built it out a certain way in your head might not be the best plan for it. Yeah. And put, just putting the, the process in front of them probably is gonna get you better results. Mm-hmm years and years ago, there was a a guy by the name of Roger Vannoy. He wrote a book, small book. He was called a whack on the side of the head and it was all about. You know, instilling creativity and figuring out together, holistically the solution. When you were speaking, my mind went to this anecdote I heard about, I don't even know if it's real or not, but it kind of makes sense. When Einstein was working on stuff like Theory of Relativity, whatever he is working on, he would be locked up in his room for hours and hours and hours doing equations and stuff. So he had a cleaner who would come by and, and clean stuff and look after the place. And he basically said, I'm getting too much, too much interrupt here. So you let her go away for a few days. When she came back, she found two holes in the door that he had made. I son had two cats, a little one, and a big one, and he made two doors. Right. And so she. Innocently pointed out. Well, just the big hole would've been fine. And the guy's working on relativity. So I, I just thought of that anyway. Mm-hmm so sometimes it's best to let people just like ask them ask them, why do we need two holes? Why? Well, I just need my cat out. How do you suggest I, I got two. Maybe just leave the door jar, right? I mean, exactly door, but that's, that's exactly it. You know, if you give it to a product person, they might immediately say, well, guess what? We need two holes. We have two cats. Sure. They might, when in reality, anyway, We're picking on product people, but the majority of the time it's gonna be your leadership being like, oh, we need two holes in the doors and the product person's gonna turn around and be like, yes, sir. We do. Yes, sir. We do. Well, that's why exactly you're right. That's why I said the best product owners I've dealt with have done X, Y, and Z. You know, I've been lucky enough to work with some great POS. They're not all that way. So some of them are exactly what you said, where they just you pivot and you say yes, sir. And you know listen, here's what it is sometimes that, that feedback is not appreciated. Mm-hmm right. It's not at all. Like, do you really need two holes? Like, Ooh, I don't think you fit the culture. Do you? Why you why are you...? Why should yeah. Yeah, yeah. Goodness. Did you not hear that? We had two cats. Yeah. You didn't. I think you you're not, you're being antagonistic. Yeah. You're not a, you're not company, man. Two cats, two cats home. This is, this is the whole start with why thing, right? Like if you, if you are starting from a position where you get to say whatever change management system you use, right? Our initiatives start with a reason, right? If the reason is I need like cast need to go through a door, right. Animals need to pass through a door and you're starting with why you probably can try different things, try different things, try different doors, try different, whatever. Right. And, your product people are probably not incentivized from, well, like where we go on all, all the negative incentives, we go on the podcast of like that. Yeah. You know? Oh, you let down X, Y, Z executive, cuz they told you to implement two holes in the door, but you actually just implemented one large hole. So XY Z executive is not happy with you anymore, even though the stats of the business and the stats of what the customers want were completely fulfilled. So there's like some political factor in it. If you're in a culture of being allowed. To build the right thing, wrong thing, whatever. Even if you're building the wrong thing and your metrics lead you to say, Hey, X number of times you build the wrong thing, it leads into building the right thing. So can we aggregate those stats over all the teams to say our ratio of building the right thing to the wrong thing is like 1.3 or whatever, whatever I'm, I'm making up numbers. Right? Sure, sure. Like are, do we care about that? Are we looking at it like that? Or are we making some kind of fallacy that's like, well, own bills, the wrong thing, three times out of whatever, and we're breaking it down to the individual factor. Yeah. Right. Like what are we being measured on? I'd be remiss to talk about this whole category if I did not also bring up sometimes a culture is not balanced to allow you to fail mm-hmm adjust and show, show your show, your work, show your homework, right. To be like, oh, oh, well, here's the evidence I have to show our directions towards the right thing because I've been in organizations where every time you build the right. it doesn't count on the wall. They don't make a check mark, but every time you build the wrong thing, they make a check mark. And then after whatever five check marks or whatever, they recycle leadership in the program, leadership product, scrum, master, whatever, they recycle the leadership in the product and then they get new people in and then they start and repeat. Right? Yeah. And then, it is just by happen sense or coincidence that some people will come in and happen to build the right thing. Again, going back to what we just said is like, how do you measure what the right thing is? So it's just by having, since they'll bring people in and they'll build the right thing for enough time. So some people will be with the program for three months, get washed out. Some people will be able to program for six months, get washed out. Some people be there for a year, 18 months. Before they get washed out and it doesn't seem at a leadership level. Not that I'm talking, not that anybody at a leadership level's listening to the podcast, but like at a leadership level, it'll seem that it's like, oh, we just can't get the right leadership on this program. And we just keep recycling people. But if we wash out enough people we'll find the person that has the right fit and been in a bunch of organizations like that. Absolutely. Majority of 'em are like that. I would say are hazardous guess, right? So this is that blame culture it, on the flip side, the few that quote unquote, get it right. These people you'll find there's a, there's like a common thread there, the product people aren't coming in saying, we should build this or not listening to leadership saying we should build this. What they're doing is they're putting the customer in the center and they're saying, well, what are your pain points? And then, and then not going away and building something they're going away and creating a wire frame and bringing back to the customer and go, are we going on the right track here. Exactly. And then inspect and adapt to use that phrase. But those people that keep the customer in the center have a much higher likelihood of success right. Than those that just simply say, we know what they want. Well, that's, I mean, the idea of they had so many failures and they get these tick marks. How cheap were those failures? Yeah, because that's, I think the big point to your point, maybe you bring them a a paper wire frame and you say, well, if you click to this button, what would you expect to find on the next page? Well, if they say the opposite of what you expected, that's a failure, but it was super cheap and super fast. Yeah. So that to me is that's a huge win. Yeah. It's a failure in the sense that you didn't get the results you expected. Yeah. But it's a win because you didn't spend a lot of money. Yeah. You got information and you can move forward with the information you got. It's a learning opportunity outside rather than a failure at that point. Right. Cause cuz you know, the further up the chain, you look at that and go, here's what we did. And it was a failure that's frowned upon the F word. So sure. It's a learning opportu. Here's what we learned. And here's what we're doing differently. Mm-hmm and then RINs and repeat that. Yeah. I, I would guess most programs like that, that they're not measured like that they're not measured. Like they don't measure that kind of incremental kind of stuff. Oh, first of all, they don't, they don't instrument their program like that, because if it let's say you have a, let's say you have a large, let's like the largest program that I was part of was like a seven, eight team, something like that. Right. Which is a massive some people listen, so be like, oh, I have 300 people. like, no, you don't that's right. You don't, you think you do every time. I'm like, no, you don't like you, that is broken down. You don't, you trust me, you don't. Like the seven, eight teams was the large program I had and their, their, their instrumentation was never at that level. I always struggle to get their instrumentation of like, Hey talk to the customer find out what they want, find out what you can do in two, three days to prove or disprove your hypothesis and. get 'em on the phone. The difficult part for me was I was in this like pseudo, I was trying to help segment their teams at the rate level and, make sure they had cross-functional team. I was doing a lot of agile coaching stuff, but also at the same time, I was trying to shoulder the burden of good product practices at the same time. And it was super distracting cause I'm like, because I'm like, oh, like forget all the stuff that like, Hey, you're a scrum master. Like forget all the good practices and stuff about like being a scrum master, like forget all that. Forget everything you learned in, in your two day class or whatever. Like forget everything you know about frameworks. Forget all that stop two and a half days. Sorry. It was very intense. Listen, we're not getting yelled at, by CSTs on internet anymore. We, we decided not to do that anymore. No. And yeah. Forget all that and like just focus on, can you do something two or three days. And at the end of that, two or three days, get the customer on the phone, and after that two or three days, can you show them something and get them to tell you if they like it or not? And if they don't like it, like what else to do? I was like, if you can break your program down to that level for every single team, like every single team getting that feedback. Right. I was like, you'll be way ahead. Mm-hmm, proud of people, scrum master team people, whatever, you'd be way ahead of everything. Absolutely. You know, a hundred percent. Yeah. If you can think about that feedback cycle of two or three days before I have a touch point with a customer per team per, per product person. And if you can build your program that. You'll be instrumenting your software correctly. You know, if you can do that without having to talk to anyone, you can see it through behavior you're even doing even better. Right. There's a measure. And it's not scientific by any means. Right? It's it's fit for purpose fit for need either of those, you'd certainly be meeting those measures, right? Yeah. So some people will be very pedantic what do you mean correctly? It's only be four sprints. Well, okay. But you are meeting their need. It's fit for purpose. How do you know that the customer's telling you that? So those teams that say, well, we we'll get the customer in. Maybe at the end of a sprint at the sprint review, don't be ready to that. You don't have to wait till the end of the sprint. As soon as you have something that's reasonable that can stand up. Right. Get 'em on the phone to your point or just show it to 'em. Yeah, right. Yeah. Right. Get 'em in the room if you can. And that's ideal. I mean, Realistically, at least in my experience getting them in every sprint every couple of weeks. That's okay. Like, because most places aren't bringing the users in, even that often you're right. I would love to be in a situation and I have where you're constantly touching the, the customer every couple days, every few days, but if it's every two weeks and that's all you can do. Great. Yeah. Do that. Start there. Yeah. Just do it and get that feedback. Because worst case scenario, you built something that they're not gonna use or that maybe, is off base a little bit and you spent two weeks on it. Yeah. Right. Yeah. The for sure the, the worst case, if you take longer is now you've spent four weeks or now you've spent six or eight or 12 weeks working on a thing they're not gonna use. So. Yeah. It's what's practical. Yeah. Right. A lot of teams don't even have access to their customers. They don't know who they are. Yeah. They're just being told, this is what the customer needs. Right. Believe it, right. Yeah. Yep. Yeah. Sad, but true. this wasn't even part of our discussion to have, but like, I hear like a lot of times when I go to community events and stuff like that, people will ask people will ask, but also people will assume that you're on two week sprints and then they'll kinda like they don't really look down, but they, they kind of they're kind of shocked at people that are on one week sprints. And I kind like as a product person, I kind of think of like I would like to go to one week we experience because if you think about one week sprint, like if you're using the, they eliminated this from a scrum guide, so it's not in there anymore, but if you're using. You know, two hours, whatever per week for planning or whatever, where if you have a, if you have a two week sprint, you're in a room for like half a day to do your sprint planning and stuff like that. If you think about it, you're like, oh, if, if I'm doing one week sprints, basically Monday morning when everyone gets in the office air quotes, right? We're gonna spend the first half a day Monday talking about the plan for the whole week to be like, Hey, we want implement this. Like here are the things I want to get down with the product owner. Here are the things that I'm trying to target getting done this week. And then the team saying, okay, well, in order to do that, we gotta do XYZ, whatever, whatever we talk about scope, we talk about what can be done, what can't be done, the. Break it down. We come up with a plan for the week and it seems to a lot of people that push back on me for a week say, oh, that's, that's a that's grind. It's a re it's a grindy week to week. Yeah. Yeah. That's what they're saying. Even scrum mass is supposed back and they go, what do you mean? I have to do a retro for every yes you do. But it's lightweight compared to the two week one, right? I've I've experienced one week sprint. I tell you if you have access, this is the fundamental premise. If you have access to the customer to get the feedback, you can't beat one week sprint because you're delivering small sliver as of functionality. And you're getting feedback as to whether you're on the right track or not. Yeah, that is fantastic. But oftentimes for practical reasons, that's not possible. The customer's not available. They don't have the time. Yeah. You know, especially the right people. That can say, yes, I accept this or no, you don't have access to them. So yeah, it can be two weeks, but two consistently make sure they're in. Don't have a sprint and go through the mechanical motions of doing a demo and then walk away from it. Yeah. You gotta get that feedback and you gotta get that explicit acceptance. my challenge to people who say that one, week's like, I've talked to a bunch of people that say one week is not, it's not a sustainable cadence. You know what I mean? Like the, the, the sustainability, yeah. Of the, of, of scrum, right? Yeah. Well, one week's not sustainable cadence. I'm like, well, if your customer that you're working on the feature in your in your one week, if they tell you they can't be available Friday morning for the demo why wouldn't you, the product person? Why wouldn't you say like, okay, cool. Well, if you can't be available for the demo Friday morning, then we're gonna push your feature out. Yep. Oh, two weeks, three weeks. Mm-hmm . When, when you tell me the Friday, you can be available and then we'll push even starting working on your feature out and like, like the business people I've been partnered with in the past. That usually gets, that gets butts in seats of like, oh no, no, no, no, no. I'll, I'll push my meetings on Friday. I'll be available for, or Thursday night, whatever, Friday morning, whatever I'll be available, just please start working on my thing like that sells tickets right there. But I also think like even in the two week sprint, even in, in a two week sprint, what, what I am used to first of all, the, the problem with two week experience is, is like the default out of the box. Mm-hmm right. Time period. So most of the teams I've ever worked on two week experience, you have like, well, developer a and B, they're gonna work on feature one and developer C and D. They're gonna work on feature two and a developer, a D or whatever, like this terrible name for developer. the, the other developer who's left out. They're gonna kind of like, they're gonna research some stuff and they're not really working on a feature, but they're maybe they're refactoring or doing some other stuff. Like they're not really working on stuff that's in, in the sprint. it's not like we're focused. The whole team is peer programming on or mob programming on one customer's thing at a time until it's done. They're working on multiple streams of work. Indeed. That's every team I've ever been with is like that. And it introduces waterfall within the sprint because you're right. The developer who is working on something or planning to work on something is gonna say, I've created my task, but I can't work on it until this other developer finishes with their task. So I'm blocked. Right? It's like, how about you lend a hand, or roll up your sleeves, work with that person. Yeah. Right. Or go work on something else. You're still getting stuff done. So this idea, I think originates from the assignment culture, right? The sprint starts and somebody usually the tech lead, or somebody's gonna say, Hey, developer-A, this is assigned to you. That's the problem. Stop that. Yeah. Don't assign stuff. Let 'em just say, as a team, here's a sprint goal. We have to meet, what do we have to. well, it may even say get to the point where they say, well, we don't have to task things out. Mm-hmm we just won't get on with it. We know what we have to do. We have clarity. Let's just go. Yeah. So don't check the box or did they task out? They have to task out don't do any of that stuff. If, of course, if they don't task out, you can't see their burn down. Yeah. But that's the wrong metric to measure 'em by anyway. And you know, we have another podcast coming, I think, for like metrics and stuff. Yeah. So yeah. I've seen the same thing myself. Exactly. For that reason. Share your perspective. Like, what do you think, have you seen that too? Or? No, a hundred percent. And in a two week sprint, generally you, like you said, it's a mini waterfall sometimes where you'd have a developer who says, oh, I'm gonna work on my thing for a week, maybe six days. And then that gives the QA three or four days and then the BA can look at it and then the PO can look at it. So you're not all working on it at once. No, no, no. I gotta do my thing first and then they do their thing next and then I, they do their thing next. Yeah. As opposed to, if you only have a week and the, the pushback that I always hear against shortening a sprint have a one week sprint is there's no way we could get anything done in a week. Right? Yeah. There's no universe where anything can be small enough to be done in a week. Well, let's say we had to, what does that mean? Well, means QA would have to start working with the developer right at the beginning. Well, yeah, that's what we want. Exactly. That's right. We we'd have to be working on at the same time. Yeah. Like you're making my point for me here. Yeah. But I think you hit the nail on the head. Since two weeks is the norm. And look, I, I'm not gonna lie. It's not a terrible cadence. I mean, two weeks is pretty good. Listen, it's better than six weeks. Yeah, sure. Two weeks is pretty good. Six, six weeks is not a sprint by the way. That's a marathon. Yeah. But you know, it's not a terrible thing, but since so many people do it, so many people are comfortable with it. You get into this habit of, of, I have four or five, six days to get my work done. Then they have this time to get their work done and then they have their time to get that work done. So if I have a thing that can take two weeks, that's fine. I won't break it down any smaller than that. And that's, that's a fine thing to do. Yeah. We like, we don't talk about that enough. Probably cuz we don't dig deep enough in the work, usually on the pile. Like we, yeah, like the, the idea of like, well I'm gonna go off and put my headphones on and work on something for four days without anyone looking over my shoulder. And then I'm gonna come out and hold it up, like the lion king and show everyone after X amount of days. And then after that I move into the next phase of the QA person gets to look at it. When they come out, they get to hold it up, like the lion king and certify it like nah, that's like, we're not, we're not collaborating at that point. We're mini waterfall at that point. Exactly. We're not a team of five people, whatever it is, seven people, we're seven teams of one person each. Yeah. Right, right. Yeah. And you're gaining the efficiencies of having that waterfall only be two weeks, which is better than having it be six months, but it's not ideal. I mean, it it's slither crawl, walk, run. Yeah. So get the waterfall down in two weeks and then work with the team to say, okay guys, now, now we can get better. Now we can actually do this stuff all at the same time and we can swarm on things, et cetera, etcetera. Yeah. So you, you can use certain, sorry. I mean, no, no, no. It's just say you can use certain smells for that. Right? It's if you're often seeing things that are dev complete, but not QA complete at the end of the sprint, what is going on there? Mm-hmm you know, so those kinds of things you can introspect on and you try and change things up a bit. I don't think that was the original point. Anyway. So we've gone down like three rabbit holes. We went a bit of field. I think it fits very well into the same category. Cause again, if you're, if you don't get to inspect what you're doing until all your little phase gates, phase, gates are complete. You are faking yourself into thinking you're making progress. That's right. You know what I mean? This is, we've talked about this before on the podcast. This phenomenon is what I call the illusion of progress. You're not making progress. Right. Right. You think you are. And unfortunately the blind leadership will say, great, you're doing great. Right. Because you're feeding them what they're measuring you on. Right. But you're really not moving the needle. Right. Absolutely not. Well, that's, that's, that's this, this last category that we started with was instrumentation mm-hmm so what to measure, right. So if you're measuring like, oh my, my dev drop I think of like cycle time, lead them, right? Yeah. If you're, if you're gaming cycle time, lead time, even further to. Oh, from the time that my developer started on it to the time they dropped it to QA and my developers are only measured on that time. But then my QA are only measured on how long they take the test on over the number of defects that they detect inside. Versus like, you're playing a lot of games. You playing a lot of games at that point. Well, so yeah, exactly. So is a given player on your football team only judged by the number of yards in the game? I don't mean individually cuz everybody's measuring that cause you can, everybody measures stats out, out the ying yang, but your team as a whole doesn't win or lose based on that one. Person's yardage. Yeah. Yeah. And your star player may not get any yard even better, even better. How, how many times they're passed. Yeah. That's like how many times your, your player is festival like, well, your defensive lineman are the most terrible people on your tour at that point. Right? Absolutely. They don't get that. That's not part of the process for them to get the ball. So like, why are you measuring that this is terrible. That's terrible metric. Absolutely. but again, what you incentivize has a huge impact, what you get or you become what you measure. Correct. You know, that's because of that thing, you incentivize that behavior. Yeah. Right. If you say you're gonna get a thousand dollars bonus in six months, if you increase your velocity by 25%, Ooh, that team will absolutely do that. Ooh, because a one becomes a two, a two becomes a three, a three becomes a five and a five becomes an eight. And guess what? I've now increased my velocity. You don't have anything better, but that velocity has increased. Does it make your checks payable to arguing agile it right? I've seen that behavior. Yeah, absolutely. You describe it. Well, you spin that around a little bit and you say, all right, well, how about we're gonna measure number of stories, outputted. That's still not great because it's not value. Right. But, I would argue it's way better, because if you say I got more stories out the door, those are by definition smaller. Yeah. So generally those are gonna be better. It's not great, but it's better. Yeah. So the thing that you're measuring. matters if all you're measuring is velocity or, or yeah. You know, number of stores or whatever, it's gonna have an impact on that team. And it could be slightly good. Could be very terribly bad, but it's gonna have an impact on them. Yeah, you're right. Absolutely measuring the wrong thing, precipitates that behavior. Right? So the team's gonna not only estimate everything at the next level up five becomes an, a cetera, as you said, they may even take something and go that too big. Let's break it up now. It's, it's a five and a five they'll find ways because that's, they figure out very quickly, that's how they reward it or measure it at least forget rewarding. That's how they're measured. Mm-hmm right. So I agree with that. I, I think people that are doing this. Don't know how to measure. And this has been a, a constant theme on the podcast, too. Those people in quote, unquote management, I, I, I'll not use the word leadership cause leaders don't do that. Mm-hmm management, those people grew up a certain way, not in an agile way. They grew up in, in that crack the way waterfall way. So that's all they know. That's what they know. So you can't really sit back and go, ah, those people, they don't know. Well, they don't. Right. And so it it's on us to educate them in the best way possible. As long as they're open to that. I think we've solved the world's problems now. You've solved all the problems. Everything's solved. Cool. So this was a podcast that went kind of different places, but let us know what you think and comment below. And don't forget to smash that like button and we wanna say special. Thank you to Ted for coming up on the podcast as a guest today. Thank you guys. He'll show up again. Hopefully we'll scare him off. I appreciate it. Yeah. Thanks Ted!.