Today we're talking about Mike Burrows' new book, Right to Left.
Get the book: https://www.amazon.com/Right-Left-digital-leaders-guide-ebook/dp/B07W44ZV3S/ref=sr_1_4?keywords=right+to+left&qid=1569845413&s=gateway&sr=8-4
Today we're talking about Mike Burrows' new book, Right to Left.
Get the book: https://www.amazon.com/Right-Left-digital-leaders-guide-ebook/dp/B07W44ZV3S/ref=sr_1_4?keywords=right+to+left&qid=1569845413&s=gateway&sr=8-4
Welcome to the agile book club. You're your hosts. Justina and Paul.
Speaker 2:Yeah, that's where we can look into. But I'd like to check in with the author first and see if they'd be willing to do an interview with us or have some kind of plan for if they say no. So
Speaker 3:I didn't record the second podcast with these outer settlers.
Speaker 1:Do I like about them?
Speaker 2:So it for the author refused to do an interview with us instead again to the author. Is this sock puppet.
Speaker 1:So author, what do you have to say?
Speaker 2:Say about people who say that you're, you're standoffish and, and stuck up. I think that's actually true about me, Paul and Justina. That's why I refused to talk to the press or anybody for that matter. Right.
Speaker 1:Well thank you mr. sock. Puppet, author. Yup. So should we do this?
Speaker 2:Good morning. Good morning. And hello. So this is, um, folks, this is going to be a little, a little bit different, maybe not so different. This is gonna be a little bit different. It's different for us because you sit in an I are not in our studio studio. We're not, we're not in our closet in, in, in the global Hill office. You sit in and I are in London. We're recording this from her Airbnb flat because we came for Klaus Leopold. You remember Klaus Leopold? He was the first person that we interviewed on this podcast and we came to take a flight levels workshop with Klaus Leopold based on the book that we reviewed, which was the very first book that we reviewed on this podcast. And it was fabulous.
Speaker 3:Yes, it was fabulous. Actually one of the thing that I was missing in that book was how to actually implement the flood levels. And the workshop kind of gave me, and I think you answers. So thank you class.
Speaker 2:Yes. He's a lovely man to spend two days with, strongly recommended if you get a chance to do it. So we're here in sunny London and when I say sunny London, I mean in the last three days we're here. I saw this on once, which for London's pretty good. And, uh,
Speaker 3:and one of the things that you have to know if you are going to travel to London, please take Paul because he stops the rain. He's the person with whom when you are walking on the street and it's like really, really, have you ran it just enough that he's outside and it's stopped? So if you don't have good umbrella, ask Paul to come with you.
Speaker 2:Yeah. This, this is kind of a little secret of mine is that I do have the superpower. It doesn't rain on me. It happens everywhere. We were in, um, we were enrollments. Uh, I was in Rome with my family and there was this threatening, torrential downpour. The sky was dark and black and there was thunder everywhere and the bus was late and we were stuck on this very narrow street with high walls who were plastered against, against the wall, just waiting for the rain to break over us. And, and the bus was late and so we were new. We were going to be drenched in the bus, pulled up in the whole, I mean, I knew we weren't going to be dredged. My wife doesn't believe this 20 years. And my wife still doesn't believe that it doesn't rain on me, even though she's seen it so many times. The bus pulls up, we step onto the bus. The moment the doors closed behind us, the, the heavens just opened up and day luge for the entire bus ride. Absolute Day-Lewis just pounding rain. You can't see through the bus windows until we arrive at our destination. About seven or eight minutes later, the doors open and the sun comes out just as, as Adam stepping on. This happens to me all the time. So yes, it's a super powerful and now, now that's a third party, an independent third party has witnessed it. It doesn't rain on me. Yeah. So now this is, this has been a really exciting experience for us and really pleasant experience for us because it's been a stressful, stressful few weeks. Um, you folks don't know this but, but um, you still, it is doing her first solo agile coaching gig and
Speaker 1:that's what you say. That's what they think.
Speaker 2:Not stressful for me. I'm fine, but, Oh, I was talking to a friend of ours. Um, I hope you don't mind. I was talking to a friend of ours about, about your, the coaching gig and that you were really nervous about it and he recorded a little message for you. Do you want to hear it?
Speaker 1:Oh yes.
Speaker 4:Hey, Larry Thomas, the soup Nazi from Seinfeld here. And I have a little message for Justina. So are you seeing up, Paul tells me that you're having a rough time with your first consulting gig and he wanted to remind you that you water's as tough as I am. Well then in that case it should go pretty good. And you would also be collecting plenty of great stories for your podcast, the agile book club. So just go out there and I'm telling them no soup for you or maybe don't tell them that if it doesn't get through the job,
Speaker 1:no soup for, you know, Kanban for you. Oh, Kanban for you. Wasn't that nice of him that listeners, I don't know if you know this because,
Speaker 2:um, I know most of you aren't celebrities. Most people just, it's basic statistics. It's just, just math. Most of you weren't celebrities. You can't be, and it's not, it's not fair, but that's just the way it is. You can't be celebrities because if you are all celebrities, then what would a celebrity be? Right? Celebrities have to be different from, from normal people. And, and I don't know if you know, but we've only been podcasting for what, six episodes now or so, but um, but it does kind of launch you into lofty Heights. So obviously folks like, like the soup Nazi, Larry David from Seinfeld is now a friend of ours as is Arnold Schwarzenegger and una Zelle Zellweger. We started, we started podcasting and the invitation to Hollywood came a little late. It took a couple of weeks. But, um, so, uh, so we are now officially celebrities and things like this just, just happened to us. Famous, famous actors. Just reach out and, and give us a Pat on the back from time to time. Invite us to parties. It's, I, I don't recommend going into podcasting if, if you're not ready for the lifestyle, because I'm telling you, it's crazy. It's the privacy I missed the most about podcasting, the constant scrutiny of my life.
Speaker 3:You know, now the number of people that will ask you to travel with them to make the rain stopped down, destroy their honeymoons and all of this.
Speaker 2:I think we've got a new line of business for Bible Hill.
Speaker 3:Yeah.[inaudible] take Paul with you.
Speaker 2:So, so yes. So let's let, should we get to the, the matter of it, to the matter, into the depth, into the get to the marrow. We read a book, we read the book, we said we were going to read it by an old friend of ours, a fellow we've known for a long time. He's written two other books before. Um, both very good. And so we were really excited when Mike burrows came out with a new book from right to left
Speaker 3:August 15, I guess 2009.
Speaker 5:Okay.
Speaker 3:The data he published,
Speaker 2:you better remember my birthday, if you remember dates like that, you'd better remember my birthday. So yes. Recently published by Mike Burroughs from right to left a book for digital leaders. And, and that's what we're going to be talking about in this episode. So let's kick it off with an elevator pitch. Can you give us your elevator pitch for this book? Houston?
Speaker 3:Yes. Actually I recommend to everyone to read the full title of the book because if you just read right to left, uh, you might be a little bit disappointed with the book, especially if you are agile coach or scrum master or the person who is really in the field. But if you read the subtitle that is a guide for the digital leaders. You get the whole idea of the book that this is the guide. The point of the book is not to dig into all the frameworks and tools, it's rather to give you the overview of what you might find, what you might come across and the where to look for more answers. So in that case, I think this very, very useful book for all the people that are overwhelmed with the amount of the information that is out there and they have no idea what is cram, what is combined on the surface thinking, what is design thinking. All of those things that we constantly hear and we might think that our does buzzwords a nice, nicely collected group of the finishes that we can come across in digital and software development world.
Speaker 2:Yeah, and I think I had a very similar impression. I'd couch it a little bit differently. So yes, if I was, if I was uh, in an elevator, especially if it was in an elevator in a large building, my elevator pitches are a little long winded. I know, imagine in an elevator, in a, in a large building, we're going up to the a hundred and 20th floor. If I was in the elevator with a friend of mine with, with a fellow agile coach for example, I would probably tell them that there is, you should definitely read parts of this book. No question. I think my recommendation to an agile coach would be to read the first chapters. Do you understand what he's talking about? Is his idea of, of, of, of applying right to left thinking. And then for goodness sake, skim or skip over the next two chapters because they are just a survey of all the tools that, that we're very familiar with and it's a very shallow survey. So it's just enough information that if you know nothing about it, you might have a, uh, some insights into, into whether or not it might be useful to you or not. But if you know something about it, you'll either be confused or if you know a lot about it, if it's your favorite tool, your favorite methodology or what have you, you'll probably be angered by how shallow the treatment is. So the next two chapters, or just a survey of lots and lots of tools in the digital world, but the last two chapters I think are fabulous reading for anyone, whether a digital leader, a team lead, an agile coach, what have you, because in those, in those last two chapters, Mike does a, does something very similar to what he did in his last book agenda shift. Um, he lays out some very nice new and original frameworks for meetings and facilitation and organization that are his own ideas and novel and rich and description and easy to implement and useful. And so I think this book is absolutely worth it even if only for the last two chapters alone,
Speaker 3:even for the new people in the field, like for scrum masters who does go their first dog if they need like the guide of what is there still to learn to dig into. I think that that might also be a good place to start.
Speaker 2:But the important thing here is that that this book is specifically written for digital leaders. Yes. And, and if I had to be, uh, if I had to be harsh about it, I would say for digital leaders who have found themselves uncomfortably in that position, cause I know in, in my, in my consulting work, in, in my career, I've come across two kinds of digital leaders. I don't want to be unfair to anybody, but I'm gonna yeah. Okay. Listeners, I'm going to tell you something that's going to, you're listening to, to the agile book club podcast. And so you're probably already deep deep in the agile world and something that we often forget inside of our agile bubble is that as big as the agile bubble has become, it's still a bubble. And the vast, vast, vast majority of software in the world is not made using any kind of a process that could be described as agile. Um, most of, of, of, of most of the successful software that we use is, is developed using waterfall approaches. Um, and so there are a lot of people who are extremely proficient at, at it management but who have had no exposure or very limited exposure to any of the tools, techniques, thought patterns that we take for granted. So if you are in a position of leading a digital team and you are either skeptical or curious about what the agile world, the agile community has to offer and you've heard all of the terms you've heard agile and XP and scrum and Kanban and safe and less and what have you, and you want to just get an overview of all of these various ideas and tools that are available to you as a starting point, then this is the book that was written for you and you will get a lot of value from it. Nothing in this book, none of the descriptions of any of these processes or technologies or tools will be sufficient. Um, but as a survey of the current state of the agile world, I think it's excellent and he does a particularly good job, I think of describing the, the use cases per safe. I think it does a very nice job of summarizing what safe is when it's useful and when it's not. And this is something that, that I know isn't safe, safe as emerging as the de facto standard for large scale digital transformations. And so for digital leaders in corporations, it's becoming essential to have, do at least have an opinion unsafe. And this is a very good place to start in forming an opinion. Although I'm reminded, I'm reminded of a play. What was the play? I saw a play when I was in Chicago a few months ago. It was a one man play and there's one line from it that just stuck out for me. It was a play about a, about a theater critic, a very cynical theater critic. And the line that I can't, cannot forget cause it was just so clever. It was, I didn't form opinions, I just had them. And I think, I think that that resonates because you see that a lot. You see that a lot, every place. Almost all of us. If I throw out something in our community like scrum, what do you think? There are plenty of people who have an opinion. Um, especially if I throw out something like safe[inaudible] and anything that that's new or controversial, the number of people who have an opinion is much larger than the number of people who have any depth of experience. And so if you're trying to form an opinion, this book won't help you do it, but it's a good starting point.
Speaker 3:So was it your first takeaway or extended elevator pitch
Speaker 2:that, Oh, I ramble, I ramble and I ramble. I ramble that that was an extended elevator pitch. That was, you want to get into that? Let's move on. Let's move on. Just keep, keep me moving forward. What's your, what's your first takeaway?
Speaker 3:So I really enjoyed the first part of the chapter when he explains the metaphor from right to left and he actually gives a good point that if you want to present in organization what agile is about, you don't start with saying there are ceremonies, those are the values, those are the new roles that you have to implement. You can just start from the outcomes that will come from implementing agile and valuing it. Like how it will benefit your business. How it will benefit your team members, the whole organization. It's, it's so simple what he, what he wrote. But on the other hand, I think it's so powerful because especially for everyone who's consultant and coach, when they ask you what will you do, sometimes you start with, Oh, there will be this workshop, I will work with this team two days and that and we'll implement stand up retrospectives or maybe grooming. Like you get so much information that those people do not understand. You should start from the outcomes. And actually I wish I read this earlier that I went into the first serious consulting gig because I think that that would help me a little bit too structure of what we want to achieve, um, without taking 100% guarantee that everyone knows what is agile Campbell's crumbs that stuff.
Speaker 2:[inaudible] absolutely. And both the book is titled right to left. That is really the core idea in the book. And um, what are the things that he does in that chapter that I rather like is his, he offers both a left right and a right to left definition of scrum. I think of Kanban as well and indeed, well we're, we're in the mix when we're actually doing the work and you ask us what scrum is, then we talk about what we do, not why we do it and we do it for a right to left reason. The other observation that he made on the same same note, which I rather liked, is that, um, when you, when you look at your process from right to left, you think about your process from right to left. And if folks, if you're listening, Mike, we haven't really defined this very well. So usually you've got, if you're using an agile process, you have some sort of a visualization. It might be digital, it might be on a whiteboard, some sort of a visualization of the knowledge work. And it could be a detailed visualization that shows every single step in the process. Like, like a detailed Kanban board, a huge end to end Kanban board. Or it might be something more simple. I, I've worked with scrum teams that only had three or four columns, you know, like backlog development, testing done. But in any case, there's usually some kind of a visually that stationed on a board and there are columns and on the left hand side you've got the work that hasn't been started yet and on the right hand side you've got the work that is done. And so left to right description of the process is first we organize the backlog, then we prioritize the backlog and side what to do next. Then we develop it, then we tested, then we deploy it, and then the customers have it and we get feedback from them or right to left is inverting the whole thing, which is, so what is it that you're doing with scrum? What we're delivering batches of value to customers on a regular basis. How do you do that? Well, we do that by validating that our assumptions were correct by building software and seeing what they think of it. Well how do you do that? Well we, we, we actually developed the software. Where does that come from? Well, it comes from a backlog. And so right to left thinking is looking at your process from the outcomes of the process rather than from, from this ceremonies in the work that you do to get started. And what I liked about it is not only does it emphasize the customer, it's really customer centric and customer first thinking, but it deemphasizes the plan. And I think, I don't know, I don't think that that Mike States that explicitly in the book, but it's very easy with the amount of work that we put in to collecting a pool of options and to, to building a backlog or, or even a more detailed rollout plan with, with milestones and such, we can get very attached to the plan because we invest a lot of our effort into it and we want the world to see it.
Speaker 6:Yeah.
Speaker 2:And that bias for the plan can interfere with delighting customers. We started trying to delight ourselves. Yes. So, so the customer's customer first approach is more than just a customer first approach. It's also distracting attention, taking attention and energy away from a plan that isn't tested or validated yet. Yeah. So I think like the beginning of the book does shows you how, how much you can achieve by just changing your perspective, where you look at your board, where do you start? Okay. What else? Both. Um, I had, I had a few, I had one kind of overarching observation and uh, that I like and I think it perhaps it's because so many of the books that we read as coaches are aimed at us and this book is specifically into digital leaders, but I really like how this book places scaling agile culture squarely on the shoulders of digital leaders. I think we've see so many failed transformations that start bottom up and end up creating little islands of agile little pockets of agile in an organization at the bottom where you have agile teams but not agile leadership. And the responsibility for bringing agility into the organization is placed on the shoulders of coaches who are mostly working at the team level. And this book throughout as a common thread makes it very clear case that doing that will give you agile teams. But if what you want is an agile organization, that's not something that an external coach can do for you. It's it's you, your responsibility to make that happen, to make that culture happen and he gives a lot of tools. He pretty provides a lot of tools and ideas for how to go about doing that. I think his overview of servant leadership for example is excellent and his descriptions of of alternate ways to do things like service delivery reviews and strategy reviews from an outside in perspective are worth the price of the book in and of themselves.
Speaker 3:Actually Graham for your super, right because that's my second takeaway. I really, and I find that extremely useful what he'd done with service delivery review and service strategy review, both of them both the whole perspective with tips with showing how beneficial for the business is bringing the perspective of the client, product, platform, team and organization. I really liked how he applied and how each of those perspective can benefit with bringing the big picture, the holistic view of your organization and what can you do. Because I've seen, I've seen the people talking about poor, poorly designed strategy or no service deliver review and all the pain that it brought into their organization. And I really see a value in both of them. And if someone never took a part in meeting like that or is just about to face the challenge to design this kind of the meeting, I highly recommend to go to chapter five and read how to do it a two don't forget for example about the user perspective because it's extremely needed too. Don't forget about those people who work in support and helped us because they are the closest to the client. They can tell you so much who those people need. So maybe instead of investing a lot of money in the research, you can just read and listen to what your actual customers are complaining and need right now.
Speaker 2:[inaudible] and it was in that section that he introduced the rule of three, which, which in and of itself was one of my takeaways. So it's a nice segue and I can't say it better than he can so, so I'm just going to share what he wrote. The rule of three is this design your strategy in governance meetings so that they invite to the active participation of at least three levels of seniority include representatives from a range of different disciplines who have skin in the game and are respected for their direct knowledge of the situation. So there's really three things in there. The first one, which in and of itself I think is very powerful is the idea that that in a strategy meeting or the service delivery meeting, you should have at least three levels of the hierarchy. There should be somebody more senior, there should be somebody who's, who's closer to the coalface doing the work. There should be middle-management represented. And that ended up itself is quite powerful because what I see so often in service delivery with reviews is they happen, they happen between maybe one of the more senior people on the team like, like like a a lead developer or something will be on it. Usually somebody who's in a project management or agile coach role, we'll be on it and then there'll be a representative of the client in that meeting. But the outcomes out of that meeting have to be distilled up and down. And it's difficult in both directions when the people who have to understand what comes out of the service delivery room review don't actually participate in it and don't hear it firsthand. And so they have all of their various biases, filtering. Everything that they hear is the outcomes of that meeting. And the same with the people who are actually doing the work, who, who don't attend the meeting. They hear the, the outcomes of the meeting, but they filter it through their own perspectives and biases. And so nobody actually hears the voice of the customer. But the other two items I think are equally important. And that is those people, the, the, those three levels of P of, of, of seniority that are represented should also be people who are participating actively and are known to be involved and informed. They're not just there to supervise, they're not just there to listen in. It's not, it's not a um, it's not reporting meeting. It's not where we're a senior person comes in just to check and make sure that the customer sounds happy. This should be a person who can actively participate in the conversation because they are involved and that can be enormously powerful.
Speaker 3:Hmm. But I think in most of the cases when I heard from people who are actually a part of those kinds of the meetings, they were complaining that this is like finger pointing pointing or like this is the presentation of like slide PowerPoint presentation with lots of charts. That doesn't mean anything because we don't even trust them. We don't know who even made them and that there's not a lot of big value in for the future I would say business. Yeah.
Speaker 2:And I think that's where, where the details that Mike goes into in this book about how that meetings should be arranged and who should share what and in what order information should be shared and what sorts of data should be brought to that meeting is extremely useful. I'm not going to go through all of it on this podcast. Read the book. I think, I think you should read the book. If you're facilitating service deliberate reviews or more importantly, if you're not facilitating service delivery reviews because there are none then, then that's definitely worth reading. I think it'll be inspiring and very helpful to you.
Speaker 3:Or if you want to impress your bosses and you hear that your organization has very poor service, deliver, review, read, read the book, go there and suggest what they could do better. 10 points for you as simple as that and they think else. Paul,
Speaker 2:there was one other thing that that jumped out at me, which I appreciated and I think it's just because I'm not only is the close to my heart, but it also resonates because of, of the last book that we read and it's something that's been coming up more and more. Um, somebody I've been been very aware of lately is cause I've also been having conversations with um, colleagues who are, are struggling with, with metrics and with the proper utilization of metrics inside of their organizations. And it's, it's, it is so problematic that I really appreciated the way that Mike included in this book, which is, uh, that metrics should be collected and shared by a self organizing team to support their own work. And there's a lot in there. There's a whole lot in there because metrics should be collected by the team. They should be shared by the team and they should support the team. What typically happens if there are metrics is metrics are collected automatically by a tool or by some manager and not by the team, but by some manager or by some tool, not for the team, for some manager or just as a vanity metric. And it should be in order to support their own work specifically not as a system of reward or supervision. And that last bit I think is particularly striking in organizations that gather metrics. In the vast majority of the organizations I've seen that actually collect and monitor metrics, especially flow metrics, it seems healthy to look for positive trends. So I see these metrics being distilled up through layers of management. You can see how there's been a 3% improvement in, in our average lead time over the course of the last quarter. Yada yada. What's happening there is that they're being used as a supervisory metric. You've got people who are tracking these metrics and following these metrics to see how their delivery teams are delivering without necessarily having skin in the game without knowing what's going on on the ground without being involved in the process. They want these metrics just as a sort of trailing indicator of where there are problems where they should go in and apply their, their authority or their power. So they're, they're, they're looking for red flags or looking for where the week, where were the struggling parts of the organization are and the real value in flow metrics isn't in there. And using them as a, as a supervisory tool for senior management. Fundamentally metrics should be gathered by the team for the team and used by the team in order for the team to improve. And any other use of such metrics is troubling.
Speaker 3:Mm. Yes. And I think especially when someone is gathering cycle times and then they don't look at the flow efficiency of what they have and they try to shorten the cycle time, but by making people working faster instead of like looking at the time when it's, when the work, it's a actively neglect neglected when no one is working because of the blocker or the dependency. So instead of like looking at this and find a way to help teams overcome that to to reduce that and to make them unleash their full potential, they just try to make them work faster
Speaker 7:results.
Speaker 2:So managers and Andy, senior leadership who don't spend time with the teams and are just watching what's happening based on on metrics that are coming their way, they can't really understand the problem and they have a pretty limited toolkit for addressing it. In the organizations that I've seen, typically they either want to create incentives. So if you deliver on time pizza party for everyone or whatever, any kind of incentive or create some sort of pressure like we're going to work for the weekend or we're going to you, you've got to find a way to way to solve this problem or this going down visiting the team and saying this is very important and, and, and, and I'm not, I don't know how you're going to do it, but this is your responsibility to find when you're just putting the pressure on them or they weren't the helpful kind and they'd just say, send your blockers my way and I will just escalate, escalate, escalate. And at least that last one can be somewhat helpful. But it's just shifting burdens within the organization and it's not improving the organizational agility. It's, it's not leadership, it's, it's firefighting by senior management. And so yes, metrics should be collected by the team and used, used by the team for the team
Speaker 7:stop
Speaker 2:period. Senior senior leadership should, should have reporting mechanisms in place so the team can ask for help when they need it rather than these passive mechanisms that are designed to just give a very shallow view into what's happening without any context.
Speaker 3:And that there are designed actually to make people afraid of metrics and hiding things and hiding problems like under the carpet. Yes. I think that you got the point, but yeah. Yeah. I welcome. It's not so bad. So actually I think it's connected with my last take away, which is the definition of servant leader that he mentioned that there are two components of that role. The first one is people positive because it's mostly focused on trying to help other people to unleash their potential, giving them everything that they need in order to succeed. And I've seen that in this organization. I am right now there's agile coach and she's doing a fabulous job. I have no idea how she is capable of doing it so smoothly. Maybe because she's there for so many years, but for the last two weeks I was just admiring her work, how quickly she solves those little problems that other people are just mentioning, not even complaining like her, her way of working. It's like problem solving. Now there is a, there's obstacle and there this is how we are going to overcome and we do it now. We don't plan it. We don't even put it in the Wiki. Okay, we can put it in the week, but we come back there to solve it. It's not only about complaining, give me your pain. I will try to make it away as much as I can. Oh, beautiful rack. I'm proud. And then the second part of that row, it's actually that complexity that you are, you are aware that what you do with a team serves the whole organization that by helping them, you have the organization to be healthy and to grow. So that was something very useful, especially for scrum masters who calls themselves that they are servant leaders, but sometimes they just use it as opportunity to say, this is not my responsibility. It's team responsibility. I'm just in between those two. And I think if they would understand the role, they would know that, okay, it's not their responsibility, but your responsibilities to create environment that can help those people to solve those problems. I liked that. I thought his handling of certain leadership leadership was excellent. It's inspiring. Thank you Mike. Thank you. Mike. How about favorite quotes? Yes. Okay. I actually have two. One doesn't come from the book, but it comes from the talk that was about a book that Mike recorded on one of the conference. But I think it's really worth to mention, it's the finishing of them. It's, well, someone's need was met. Like this is the essence for me of working based upon outcomes when the user's needs was met. It means that you are done. So that was from one of the conference talk that was titled from right to left. And from the book I have one, don't start with what you can finish as as that
Speaker 2:you're good rule of thumb generally. Yes. Yeah. You know, I was, I was thinking about that definition of Don and I, and I think, um, I might amend it to say when a custard customer's need is when someone's need is adequately met. Oh yeah. Because we in, in in so many cases, not, not to, I'm not a believer in the, the totally satisfied customer, the enthusiastic customer that, that's wonderful I suppose. But I had a business, I had a marketing professor back in business school who used to use the expression, the barely satisfied customer, which I also don't go buy into, but I think it's a good idea. And, and his reasoning was that, um, total customer satisfaction or creating ecstatic customers is an illustration of waste. The goal of the business is to gain and retain customers. And anything that you do above and beyond what you need to do to retain a customer is putting resources into something that's not bringing business value. But, um, but on the flip side, what we so often do by not validating our ideas is we take the customer problem, we implement a solution. The solution partially solves the problem and we call it done. And so if we're not validating that the problem is adequately solved at the customer, that we really understood the problem, then we'll we end up with is a whole product that is just a suite of, of half-baked solutions. Yes. That, that everything works but only barely. And that's very common. Yeah. I think that it got that. Yeah. So I had a few as well. Um, one that I really liked is continuous improvement is no substitute for strategy. That's perfect. Um, he explains it nicely to extend the quotation. It's not enough to solve problems. They have to be the right problems. And indeed in so many, so many organizations and in so many, so many digital, um, departments, the goal is continuous improvement. And there seems to be this idea that if everyone is improving continuously, you will automatically achieve or approach a state of perfection that, that everything. But, but if you're improving the wrong things, if, if you're improving your, your time to market at the cost of quality, for example, we're improving things that don't actually matter in the end, then you're not using your, again, you're not adequately using the time and tools available to you and you might achieve some perfect destination, but it's not the destination your customer wants you to be at. I think it's also kind of excuse, still not perfect because
Speaker 3:it's continuous improved. Uh, it's, it's, uh, it's MVP and this is just excuse you can not, yeah. You have to keep the quality in place as well.
Speaker 2:Define the goal. Make sure that you represent a strategic purpose for that goal, and then execute the improvements that are going to get you to that goal the fastest. Yes. Continuous improvement is no substitute for strategy. Yes. Again, this is a book written for digital leaders and, and if you're just looking at metrics and your mantra is let's keep getting those cycle times down, let's keep eating those cycle times down. That is not a strategy. It's not a digital strategy. You said you had to?
Speaker 3:Yes, I have one more that most failures are failures of communities.
Speaker 2:Oh,
Speaker 3:things so often we are focused on work in front of our desks and work and PPC and PPC and we have the[inaudible]. The against. We are against meetings. We don't see value in them but we don't see the value in them because we already have some resistance. If on those meetings would focus on the work flow, maybe our life would be just easier or if you would focus on how this particular Epic is connected with the, with the strategy that we're working on or how can we benefit out of it? What is the outcome? We would just have the right conversations. I think that will reduce lot of failures
Speaker 2:and, and that is it. That's really so much of what these, these frameworks are designed to provide is to try to encourage the right people to have the right conversation at the right time. Yes. Easy, easy peasy. I've got one more that I really liked this, this, this quotation comes from after Mike's survey of several different tools and frameworks and he wrote, if you come to the realization that one of these frameworks like scrum or Kanban has become the lens by which you view the others. Experiment with taking the opposite perspective and notice how your understanding changes. Yeah, think about that one. This is what happens when scrum people look at combine from a scrum lens and Columbine. People look at scrum from a Kanban lens and and when would any scaling approach looks at, at any other scaling approach. Anytime you would define yourself based on your tools or based on your frameworks, it colors your thinking, your colors, your perspective of everything else. And this is one of the things that I love about being a human. We humans dream and we have rich, rich imaginations. One of the things that allows us to work together is, is our capacity for empathy. A human being can put themselves mentally into a different point of view, another person's point of view with ridiculously little effort. And it's the reason that we're able to work together and collaborate and build, cleanse and tribes and villages and cities and, and, and actually creates wonderful things is because we're able to, to get into each other's head and see each other's points of view and empathize and, and, and find common ground. And it's such a powerful tool. And Nancy Klein talks about this, um, when she talks about incisive questions. So for example, in Nancy Cline's book, time to think, um, she says that when she's talking to somebody and they're trying to solve a problem and they get stuck by something in their own head, when someone gets, gets stuck by something that's only in their own head, like, like for example, you know, we've got these problems, but there's nothing I can do about it because I'm just an intern. She'll ask what she calls an incisive question, which is a question that in sizes that cuts through the barrier, like, well, what if they promoted you to CEO tomorrow? What would you do? And an intern can easily imagine herself as CEO just by trying, well, I was the CEO. I would reorganize this department this way and that might be a really useful idea, which she was incapable of having while she was thinking from the mindset of an intern. But the moment she adopted the mindset of a CEO, she could come to this conclusion. And by the same token,
Speaker 8:yeah,
Speaker 2:you can go through your whole, your whole career as that scrum guy analyzing everything from a scrum point of view. But all it takes is, is a question like the one that might pose is here, which is if you weren't a scrum guy, if you were a Kanban guy, what would you think of this? And you could just shift your mindset and say, well Kanban thinks these things are important and it solves problems in this way. And, and I can see where they're from that point of view. I might see some certain shortcomings in my favorite framework. Maybe there is something to offer from that point of view. So I really enjoy that quotation. Yeah, that's powerful. Powerful shifts of your thinking. Yeah, I might use that. Okay, so what should we read for the next month? You know, I don't have a list this time, but I do recall that there's one book every single time. We've had this conversation for the last few months and there's one book that's come up each time. And we typically have chosen a different book because someone we know recently published a, and we have a bias for recent books. Yes. But I th I think that, I think this podcast can do it. There's so many great books out there and there were so many people out there. Um, what, what is the saying? Um, every day there's someone born who's never seen the Flintstones. And so if you pick one, if you pick the single most popular agile book, I don't know what it is called, they call it, um, the original scrum book, or, or call it Kent Beck's white book or whatever it is, pick the most popular book in the scrum world or in the agile world. And most agile coaches haven't read it. So I think there is value in going back and looking at some of these books that have made it made a real impact. And and sharing them both for the to both to encourage people who haven't read them yet and as a pleasant refresher for people who did read and loved them. So the book that keeps coming up is rolling rocks down Hill by Clark Ching and, and one of the reasons why I want to read it is I love the subtitle. The full title of this book is rolling rocks down Hill, the agile business novel that never mentions agile.
Speaker 3:Yes. I think that that's enough to to say about this book. I read it two years ago when I was on holidays in Portico. I enjoyed it very, very much and I would love to read it again. Let's, let's make the next agile book club podcast about the book that we did
Speaker 2:both. So thank you everyone. This has been an interesting one for us to record because for one thing, we're sitting in an unfamiliar apartment in London for another, there's construction going on outside and I hope you don't hear too much of that. I'm going to do my best to edit as much of that out as I can. And then for another, we were at Hamilton last night and so I don't think either of us got a whole lot of sleep if you haven't seen it yet. Oh my goodness gracious. Hamilton is fabulous now.
Speaker 3:I wish I could sing, I would think for it, but I really canceled.
Speaker 2:Um, no, no, hear it for yourself here. If I could send you the whole score right now. Yeah.
Speaker 3:It gives, give it something, give it something to say sorry to, to the audience. Like they have to have something that they didn't have in the previous episodes.
Speaker 2:All right. I'm going to tell you right now if I'm, if you ever hear me sing on this podcast, that is the episode that breaks the agile book club. That's not going to happen. But, but uh, but I hope you've enjoyed this episode of the agile book club podcast. We're going to be interviewing Mike Burroughs for our next episode so we can get his, his perspective is in his takes and learn a bit about, about his thinking when he was writing this book and the kind of feedback that he's gotten on it. And then what he thinks for the most important parts of it. So, um, so please join us in two weeks for the next agile book club. And thank you so much for listening. Thank you so much.