This was our first episode recorded in a professional studio with an audio engineer. But Paul still did the editing himself. We hope you enjoy the improved sound quality. If you like it, please consider supporting the podcast on Patreon to help us pay for the studio.
Get the book: https://www.amazon.com/Rolling-Rocks-Downhill-Business-mentions-ebook/dp/B00PJ8HBW8/ref=sr_1_1?keywords=Rolling+rocks+downhill&qid=1572345510&sr=8-1
About the author: https://www.clarkeching.com/
Listen to Hamilton :) https://open.spotify.com/album/1kCHru7uhxBUdzkm4gzRQc?si=7YxzJ9Y9QBOnQCMcXd4wqQ
This was our first episode recorded in a professional studio with an audio engineer. But Paul still did the editing himself. We hope you enjoy the improved sound quality. If you like it, please consider supporting the podcast on Patreon to help us pay for the studio.
Get the book: https://www.amazon.com/Rolling-Rocks-Downhill-Business-mentions-ebook/dp/B00PJ8HBW8/ref=sr_1_1?keywords=Rolling+rocks+downhill&qid=1572345510&sr=8-1
About the author: https://www.clarkeching.com/
Listen to Hamilton :) https://open.spotify.com/album/1kCHru7uhxBUdzkm4gzRQc?si=7YxzJ9Y9QBOnQCMcXd4wqQ
Welcome to the agile book club. You are your hosts, Justina and Paul[inaudible].
Speaker 2:Hello. Yes, dinner. Good morning. Is it a good morning? Kind of. Do you want the honest answer or answer for listeners over the listeners can know what's up? This is, this is going to be an interesting one for a couple of reasons. For one, this is kind of a stressful time for both Houston and I, but mostly for use dinner. We've had a lot going on this week. We've got a lot going on next week. We've got a, a new conference that we're launching for the first time on Monday. Mostly that Houston is launching on Monday and so there's a lot of loose ends to take care of there and a lot of running around and such, but that's not the only thing. There's a few other interesting things happening this week, like for example, where we are right now. Oh yes. We are in the new studio is the first time that we feel kind of professional. Like in the previous podcast, Paul was our engineer and now we got help from two other guys, so that's amazing. I hope that the results will be satisfaction for our listeners, that they will feel the difference and that it will be even more fun to listen to the podcast and more fun to edit. I hope so. Now instead we've, we've, we've traded in our our closet for a basement. It feels like a big step up. So the other reason why this is going to be a different light a little bit is that we chose a very different book than any of the books that we've been reviewing up until now. Now, I don't want to say that, I don't want to say that the books up until now have been dry. That wouldn't be fair. But we've been reading a lot of professional books that are very relevant and have lots of new useful ideas. LA, LA, LA, LA, LA, and we decided maybe it was because we were in London, we're having a good time. We wanted to give ourselves a, a bit of a treat. We decided instead of reading a brand new book, we'd revisit a classic. That would be a fun read for us. So listeners, we hope you enjoy this, but, but if we're being completely honest, this one is for us. This week we read rolling rocks down Hill by Clark chain. It's a business novel and it's fun. You still has read it before and she enjoyed it and I have always wanted to read it but I haven't. And so where does start, let's start. Let's start. Let's start like we always do with elevator pitches. Who do you think should read this book and what would you tell them used to that? Okay, so basically as polymers, I wrote this book already some time ago. It was three years ago and that was in completely different position. I was in the smaller environment in the startup world and now when I came back to this book, one, I was doing the coaching for the bigger company. I felt like, Oh my God, this is really the story of the environment that I'm in. So
Speaker 3:if you're working in a hectic changing environments, when someone is constantly pushing work for you and you have no idea on how to handle, how to ship on time and how to build something that your customers want, please do yourself a favor and read this book. It will be fun because it doesn't say even in one sentence word a dialer. It just teach you by experience of other people on how to actually change the environment that you are in by solving the problems on time. And it also gives you tips on how to do it. So it doesn't matter if you are running a cafeteria, if you work in manufacturer or ear, if you are in it company, it will be helpful for you. I bet on that.
Speaker 2:Now that's right there in the subtitle, isn't it? I don't have the book in front of me. I used to know what's the subtitle of this book, how to severe software projects on time every time. Ah, okay. I thought it mentioned somewhere about the, the, the agile software book that never mentions agile. Yes. That was also too yet I just read the first page, but the has this subtitle. I've seen it too, but I don't see it on the cover right now. Yeah, okay. Yeah. You know, I, I had a difficult time with the elevator pitch originally that one of the things that that struck me as unusual about this book as it was written in, it was published in 2014 and by the time it had been published, I had been using scrum for a decade. So it's not like agile was new to me or to anybody else. This book focuses on a lot of agile ideas and a focus on the theory of constraints. Basically the focus has done a lot of things that many, many people had already written quite a lot about already and and so as an introductory text it seemed oddly placed in time. But the thing that I did like about it, I mean the, the, the, the, the reason that I think it was, was fresh is that it could very well be. Now we're going to talk to the author next week and our listeners get to hear about it in two weeks, but I'm, I'm, I'm curious about his motivations, but it could very well be that coming a decade after the introduction of scrum and more than a decade after the introduction of extreme programming, it may very well be that this book addresses people who are already starting to get tired of framework solutions and based on that, but based on people who have, who have, who have either had a bad experience with an agile implementation or people who for one reason or another thing that the frameworks that were available at the time, which is just as true now as it was in 2014 who think the frameworks that are available now are for one reason or another not applicable to them because their situation is exceptional for such people. I think that this book can offer a lot of alternatives to simply doing work the way it's always been done. And what I liked about it is that it illustrates how to apply theory to solving your own problems instead of plug and play frameworks, which I'm not going to say may not be applicable to your situation. I'll say almost certainly are not applicable to your situation because any framework is, was developed to be optimized in one place and won't work exactly the same place anywhere else. So for that said, um, that said, I, I'd say that, uh, this would be good for people who have agile burnout but haven't become so cynical that they think there are no new ideas in the world and people who like to solve their own problems and things with them for themselves. But I also think that, uh, reading this as a person who has been an agile coach and trainer for a very, very, very long time, almost as long as, as these agile ideas have been out there, there's nothing in this book I didn't know. And so my expectation was that while it was a fun read, my expectation was that there'd be nothing in it for me. And I think, um, I can actually add, having read it now recommend this book to experienced agile coaches and trainers because what I did take from it is not only did it's a fun story with amusing and clever pros, um, but it also approaches agility without adherence to any framework. There's a lot of people who find agnosticism to be attractive, especially if they've been stuck in one framework for a long time or if they're facing a lot of resistance from customers. And also I think that agile coaches and trainers will find new ways to think about the things that they already know and add some new metaphors, new stories and new new teaching tools to their toolkit.
Speaker 3:Hmm. Yeah. And it's actually connected with my first takeaway, which is you are not alone right now. And I'm in this organization and I'm talking with teams and then with the team leaders, they are asking and how are we doing? Like compared to other companies compared to other teams. Yes. And because they want to know if they are very good, bad. And it's hard to say. You cannot like put the scale on that. And I think right now I will recommend this book for everyone who feels lost in their situation, that they can feel like a, our company's the worst only we have these kinds of the problems. No, it's, it's so, so common and there are solutions out there so you can just try to look for them. They're, you know, honestly going, our readers,
Speaker 2:our listeners haven't read this book yet. Um, or at least we should assume, or our listeners haven't read this book yet. And so maybe just a little bit of background because this is a different kind of book. It's not a prescriptive manual. Like some of the other books that we've read, this is, it's very clear that the author has read the goal because there are a lot of parallels in the narrative structure. You've got a middle manager who's done reasonably well in their career himself in a, in a, in a really bad situation, which is both affecting their family life and affecting their work life. And they're facing losing their job, which is the same for both books and just like in both books. It's a man who claims that family is very important to him but doesn't act like it. Although the circumstances, yeah, under these circumstances. Yeah. So you always juggling family and work and family always loses, which is the same as in the goal and he's got to pull off the impossible or lose his job in a particularly bad time for his family, for him to be losing his job. So those things were very similar, but the problem he's trying to solve is one that I would hope would, I would have hoped would not be so familiar in 2014 it was one that was very familiar to me back in 2002 2003 2004 when I was building software using a waterfall approaches that the kind of big bang planning up front, the development, the full development, then the dealing with change requests during development. Then all of the testing and integration work and yada yada yada. So he's in this situation in 2014 and it's a nice reminder that even now in 2019 most software is not built using agile methods. There's lots and lots of people who are still working in the world in which Steve, the main character in this book finds himself and his impossible situation just keeps getting more impossible. He's got to deliver something he doesn't think he can deliver and the scope keeps getting bigger and the deadline keeps being shifted forward and forward more and more. So it becomes obvious that traditional ways of working are not going to work for him. And at that particular time, just like in the goal and just like in commitment, which is another business novel, uh, in our field, he runs into a character who has all the answers, not exactly the answers because this character is a theory of constraints, total quality management specialist from a different field. So he doesn't necessarily tell prescriptively you have to do this because I've done this before. He said, this is how we did it in manufacturing or this is how we've done it in the kitchen. And then it becomes the, the main character and the story's responsibility to figure out how to apply that principle to software. And I think that's what makes, that's one of the things I really appreciated about this book. It wasn't some God-like character coming in from the outside with all of the answers because as another one of the, the narrative gimmicks the Clark uses this expert is, is taking a lot of vacation time during this crisis. So first the expert is having his son's wedding and then he's, he's traveling, he's offline a lot. And so rather than simply being available to just pop in and solve everyone's problems all the time, he's just dropping in tidbits and we get to watch the protagonists solve their own problems. So that brings me to to some of my takeaways. So the first big one, and I have kind of mixed feelings about this one, but the first big takeaway is that in so many of these, these prescriptive agile methodology books, they say, do this and you'll double your, your speed or, or they talk about 10 X in your, your productivity and such. And despite all of the dramatic changes that that they make in this project in order to live to deliver it faster and better. Really the most dramatic one that they do is the most obvious one. And that is that when it comes down to it, if you want to dramatically increase the time to market and you want to dramatically reduce technical debt, there's nothing more powerful than cutting scope. So they don't just come in with a process framework and fix it. They slash the heck out of the scope of the project, but they're able to do that because they're delivering more frequently. When you deliver more frequently, there's some expectation that you'll eventually get what you want. And so, so the business people become more comfortable with slashing scope, which is com, which is actually combine to my takeaway when it comes for this coping. You really have to think what barebones would you like to deliver? Because they had lots of discussion about it, like so what will be actually minimum but viable version one of that product. And there was a lot of emphasize put it on that and I really liked it because what tends to happen is that actually we troll around Amelie some of the features that are too hard or too easy, like without thinking about the customer or without thinking the main function that this product has to has to do. So I liked, uh, how he actually put it in the story. And you also get to see him build trust because when you, when you're doing waterfall development, uh, those of you who've experienced this, when you're doing waterfall development, what do you tend to see is really bloated requirements documents because everybody wants to get their stuff in because as they, as he puts it in the book, nobody actually believes there will be a phase two. What typically happens in these big waterfall products is phase one is huge, late over budget and buggy. And what's always promised for phase two gets put off indefinitely. Because once it's launched and customers are getting their hands on this buggy project, whatever budget they have goes into keeping it alive and maintenance and fixing bugs and dealing with technical debt in such. And if nobody honestly believes that phase two will happen, then they have to get everything that they might possibly want in phase one. Whether it makes sense or not, which is one the reasons why, Oh goodness, I hate to cite this, but it's coming out of my mouth anyway. Here it goes. The standards has group chaos report came out that everyone sites, which is something to the neighborhood of 70 72% of all the functionality in the products that they looked at, and this is still a decade ago, but people are still making software this way. We're rarely if ever used, and that's just because people ask for the world because if they don't get it now, they'll never get it. And in this book, when he proposed doing iterative delivery, they didn't dramatically de scope right away. He hadn't developed the trust. It wasn't until a few iterations of this product had gotten out that the product people finally started to trust that, you know, if we do you scope this, we may still get it later and we can always change our priorities at any point. And that's the way it really happens. So it's not just a matter of making promises and getting what you want, it's a matter of making promises and then living up to them and building trust and slowly getting what you want. Yes. And also there was a point at which they said like, it's good if we make happy this customer and then we can just extend based on that rather than disappointed them and under deliver. Yes. So my next, uh, I had two other takeaways. My next takeaway was, and this is, this is just straight up theory of constraints stuff, but I liked the way it was illustrated in this book which is that once they had this iterative process happening and once they were building quality in from the beginning and they still weren't happy with with the rate of delivery, the experts asks, do you know where your bottleneck is and they weren't looking for their bottleneck and the reason that they give for looking for their bottle neck and addressing the bottle neck is that if you don't know where your bottleneck is, then most likely whatever optimization efforts you're making are just adding overhead because with all of the things that could be your bottleneck, whatever it is you're trying to do better probably statistically is unlikely to be the bottleneck, which means anything that you're doing is a waste of time and effort and might actually be distracting from the bottleneck or causing more problems for the bottleneck. Yes. Actually the, it does mention that book, that button legs move so it doesn't matter if you, you have to be aware like if to optimize the bottleneck here. If you reduce it, it will probe show somewhere else. It's never like ended story like it discovered button legs, you removed it, job done forever. Everything will be great. Unfortunately. No. So generally speaking, what I really enjoyed in the book was the key learnings that comes from the cafeteria when a shower is leading Steven around and showing what they tent and what of the name of the revolution was it your own dog foot and what seen in a few
Speaker 3:organizations, like very often they build software, they ship it to the clients, but they don't use it by themselves. Even though that they could be actually the user of that, they know that it's not perfect. They, they, they know that they will be annoyed or whatever. And what Cheryl was telling about her cafeteria was that they were serving food to the customers that were coming, but no one was testing it before. So all like a small fixes like at a salt or pepper or make it spicier or less. Spicer never ever were done before they served. And actually it was also showing the culture thing that was in the cafeteria that they were not proud of what they were doing, that they were not even eating it. So how was that possible that they could serve it to someone else and expect that they will pay, be happy and come back. So I think that it was kind of very nicely named that, you know, eat your own dog food. Like very, you know, getting into the point of something that we do very often in our lives.
Speaker 2:And, and what I think was also very interesting about that was the reason it's, it's amazing to imagine somebody cooking a whole meal in a kitchen or cooking, you know, 50 liters of soup and then dishing it into two bowls and serving it without ever tasting it. But the reason they had gotten into that position is because the management of this cafeteria had originally designed the whole system for idiots. The management assumed that they weren't going to be hiring chefs, they were going to be hiring, they wanted to design a system where they could just hire minimum wage people off the street. And just give them recipes to follow. So by not respecting the people who worked there and just forcing them to do exactly what they were supposed to do, giving them a recipe and forcing them to follow it. They taught people to not respect their own work and they, they, they created an environment in which people really didn't care. And this is something that unfortunately we see too often as well in our industry. How many programmers could tell you why they're doing what they're doing today? Why this task and not a different task? Why this project and not a different project? Why this product and not a different product? And if the answer is I do what my boss tells me to, or I pour things in order of priority and that's all, then you're doing the same thing to an extremely intelligent knowledge worker who's got an engineering degree that this kitchen was doing to minimum wage people off the street. Just giving them such a prescriptive environment that you're basically just reminding them every day. You're not here to think,
Speaker 3:you know, I'm laughing because actually that really reminds me about my story. And my breaking moment when I into it, I'm not sure if you are aware of that, but when I was working for the bigger Oregon big, big, big organization and I was there just after internship, it was big open space and uh, I've seen a way of small improvement that we can do but I didn't feel so empowered like to suggest. So I just decided to come to my team leader and ask like what, what, what does she thinks about it if it will make the process faster and simpler. And she said out loud, you sinner, you are here from typing, not from thinking. And then the next day I just quit. I was I think like 22 something like that. And I did like, I don't think that I want to just type for the 40 plus years in my life. I think that I have a brain for a reason. So let's take like a three months. I have some money left, I'm still studying, but I needed money as well for being able to study. So let's just have these three months and discover what are the places that I can actually think, learn and develop. And this is how I moved into it. I'm not sure if you knew that. No, no,
Speaker 2:I feel the story. I'm so sorry that that was your own.
Speaker 3:But you know, the, the, the worst experiences in our life are actually the best very often. Yeah. Ever. Often they are just giving you the lesson that change the way you live. So I'm, if I would see her again, I would just say thank you. Thank you. Thank you so much.
Speaker 2:Well, you know that that's not so unlike, um, April middle story last night you sit in an, I were at a women in agile event that we organized here in crackle and our speaker was April mills who is the author of a book we might talk about on this podcast one of these days as well. And she was, she talks about about empowerment and empowering yourself and creating empowering environments. But she was telling a horrific story about her first introduction to management where she was given a job to go in. And do culture change activities for diversity inclusion in a shipyard. And she just assumed that since she was hired to do that job and told to do that job by a boss who had supposedly authority, that she inherited the authority and could start telling people how to change their behavior. And she made a lot of enemies in the process and almost could have lost her job. But it was only because of the incredible amount of stress that she found herself under because of all of the people who hated her for, for that management style that she realized the enormity of the opportunity ahead of her. But from the sounds of it, it was, I don't think she gave any dates, but my impression was it was like a six month to a year period of hell that she had to go through that ended up redefining career and making her into the successful change management consultant that she is today. So it is a shame that sometimes horrible things have to happen to make you who you need to be, but well to deal with them.[inaudible] I can live with that. But you know, she, she said that she's very good friends with this, with his manager who called, who made her life so miserable back then. So maybe you should go back to that manager who told you not to think and thank you, thank her for or thank him or her for her. Thank her for saving you from, from an internship that would've just set you up for a life of, of misery and, and discontent.
Speaker 3:Yeah. Okay. So moving to another takeaway. Um, I really enjoyed the introduction to theory of constraints and especially, uh, the spotlight that was put on. We look for the weakest part of the system, not to blind people, but to make them stronger in order to make the healthier system. Because I've seen a few times that people are afraid to say that they are vulnerable, uh, that they have problems. They're afraid to be the bottom line. They are afraid to be the, the weakest part of the company because of the consequences that might come to them. And it's, I think it's a challenging job actually explained that we look for them not to put the blame on them, but to help them to be stronger and more successful and like the whole system working
Speaker 2:better. Now when I'm doing what I'm doing, consulting, I'm always very careful never to to identify people as a bottleneck. And that's the most common thing. If, uh, if for example, you're having trouble getting stuff tested and so developers have to slow down because I mean if, if, if the bottleneck is getting things tested and developers are, are slowing down and taking Slack time and such, that's a very healthy and natural thing to do if you're having difficulty getting stuff tested as fast as it's being developed. But something that I don't tolerate, and that's not to say that I'm, I'm brutal about it, but I always correct people who use such language is saying the testers are our bottleneck or I'm a tester. I'm the bottleneck because it's never a person. It's the system. The bottleneck may be getting things tested, but the solution to the bottleneck probably isn't the testers themselves. It's probably the way in which is probably the practices and processes. It's probably the idea that the way in which developers are working with testers, it's probably the way in which developers are interpreting requirements. It's probably something upstream. And if it, to the extent that it has anything to do with people, it may simply be just a staffing issue. It has nothing to do with the individual people. So people are never, bottlenecks. Systems have bottlenecks. Sorry.
Speaker 3:Yeah, I agree. Any other polls? Yeah,
Speaker 2:I had one and um, I'll, I'll be honest. I'm so sorry Clark. I know you're gonna listen to this. Um, but when I first came across the evaporating cloud, it was reasonably early in the book when, when the, when Steve finally sits down with this theory of constraints, uh, TQM consultant and the TQM consultant pulls out a napkin and, and I, I tensed up a little bit and then he draws stick-figure and I tensed up some more. And then he listed pros and cons of two different positions. And I groaned because I thought, Oh my goodness gracious. It was early in the book and I thought that this was just going to be an exercise in looking at and measuring the pros and cons of making a decision using some silly sick stick sick. There I go, Freudian slip, stick figure, a um, tool. But in fact, and I'm not going to give the whole thing away because it's a short, easy book that you really ought to read and I'm going to highly recommend it to everybody. But there's this one little tool in there which is introduced by the name the evaporating cloud and it is actually a very clever and useful and what's the word I'm looking for? Subtle approach to not, not simply choosing between two different diametrically opposed options, but also fully understanding what makes those two options problematic. How do they relate to your desired outcome and how to extract from all of that thinking a third option. And so to some extent I would say that that what appeared to be just a pros and cons list actually turns out to be a model, which I think is more similar to a simplified a three. And so in the end, I'm sorry for the groan, I ended up very much respecting the evaporating cloud model for evaluating difficult alternatives.
Speaker 3:But I love that one too. And actually yesterday I had the experience of using eight three when I spoke with uh, one of the team leaders and uh, I wanted to tackle some, some problem, get information about the background and then I use this cloud. I gave it to the different person who is right now in them middle of putting the plan for the quarter. I mean they already have a plan for the quarter and they have like lot of um, discussion on where to shift the focus. So I think like you can use both of them depending on the situation. There are both powerful and I left it on his desk. So I'm very curious what he will say when he, uh, finds it. I left it with some tips on how to do it. I will probably have the conversation with him today, but thank you Clark for that, uh, inspiration.
Speaker 2:So can we move on to favorite quotes? Cause this was a fun book with lots of fun stuff in it or do you have something else?
Speaker 3:I have one more take away that actually I put hashtag ask for help that a Oh and it's connected with one of my uh, quotation, maybe I want to say good quotation and then I will say why you have to ask for help. So the quotation goes, and I don't think you should compare my software development project with a kitchen. So it was a, when Steven was kind of offended slash disappointed with Crick, uh, this consultant who wanted him to see how the cafeteria operates because he was thinking like his it department is more important. It's smart and that all cafeteria staff
Speaker 2:as he was citing millions of lines of code that they maintained. And
Speaker 3:exactly. Exactly. And I think that sometimes getting out of our industry and asking for help, people who are in the different world can really open our mind and can open our perspective, brings more and more and more ideas that can really save us. So ask for help. People who do you never ever think that they might have something to say?
Speaker 2:You don't so much of have innovation. I spent a few weeks living with and studying a somewhat obscure approach to problem solving called trees. It's a, comes from the Russian is a Russian acronym for the theory of inventive problem solving. And some of the people who helped develop this, this work early on in Russia are now living in Detroit and running an organization that that's taken it to America. And I spent a few weeks living with them, learning it, and they had it. Ha ha. There's an idea in trees, which is that there are degrees of innovation. And when they were looking at innovative, innovative solutions by reviewing just hundreds of thousands of patent applications, the vast, vast majority of great new ideas are nothing more than an idea, which is common in one industry being transplanted to another industry. Um, and so for that reason, I often encourage people to once a year or once, once every couple of years, read a book on a topic, you have no interest in that, you know, nothing about. Attend a conference, attended an orange theology conference, attend an anthropology conference, attend a medical device conference, something that's completely outside of your field and you will start seeing so many ways in which other people have encountered and solved problems similar to the ones that you see every day that they take for granted and it'll blow your mind. It's, it's, it's the world is full of people who are specialists in one thing. It doesn't make you special. You can be the best in the world and you have to be the best in the world. And one thing to be noticed at all but in to really stand out, being good at two things can make you unique and also listen to[inaudible] musical.
Speaker 3:I still love it and I think there is so many things to learn that if you haven't listened to yet after our last podcast and think how amazing was it? You still have a chance.
Speaker 2:Are you going to do, are you going to share some takeaways from Hamilton now?
Speaker 3:Okay.
Speaker 2:This is such a catchy musical that, that you just didn't, and I were having a meeting about something completely different about a game. It was, it was about a game that we're designing together in order to teach, um, flow thinking it using a role playing game type approach. And uh, we found ourselves constantly interspersing our conversation with Hamilton quotations. There's anything you need to know. It's in Hamilton, but anything else you need to know? Well, listen to us. So my favorite quotes. Okay. My favorite quotes are mostly fun because, Oh, I mean, what I want to illustrate with my selections is how different this book is from so many of the other books that we read in business and in agile management and such. Um, so I want to share a few of the, the jokes. So for example, I felt pretty clever when Steve was, Steve was angry. He had got some really bad news. He was going to storm into his bosses office and, and give him a piece of his mind. I think he was going to go talk to the president. Was he talking to? Going to talk to Eleanor. He was going to go talk to somebody who could fire him on the spot and he was going to talk to them. Angry. And so he writes, I was in a foul mood and I thought, Oh, I'm so clever. I just caught a typographic error in a book, which I do from time to time because I'm good at editing because he spelled foul. F O w L not fou. Well, and then he goes on to say I was in a foul mood when I made it back to my desk. I had turned into a big chicken and pushed the button for the six floor instead of the penthouse. Um, or Declan was waiting outside, sucking on what looked like an orange plastic cigar picture that I presumed it was a nicotine replacement device designed specifically for extroverts. So Clark Chang is a clever guy. He's, he, he's, he's okay. He's good with words. He's good with words, he's good with metaphors. He paints pictures nicely. He creates interesting characters. Business novels are difficult to write because you have to be both a business person who's good at explaining business concepts and you have to be a novelist. And like I said before, being good at two things is uncommon and hard. And so being a business novelist that writes good novels that are also instructive, is hard and, and clutching, does a brilliant job of creating a character that I like and that I wanted to succeed. But that I got annoyed with from time to time. He wasn't, he wasn't just like me, he wasn't somebody I, I entirely emphasize, empathized with. He wasn't a, he wasn't somebody who was always right. He wasn't the golden boy, he was, he was annoying and he could be petulant and he made mistakes and sometimes I didn't liked him and sometimes I didn't like him, but I was always rooting for him and I was interested in what was going to happen to them next. And that's not easy to do. I can tell you, cause I've tried writing a few novels and I haven't finished any of them cause they're heart. Um, and, and so just from, just as a novel, this book is a fun read and I'm still waiting, Paul, for your novel. This one with cats. I, yeah. Yeah.
Speaker 3:Oh, one day we'll review it. I would review with and try and book club without you.
Speaker 2:I've, I'm working on a, on, uh, it might just be a short story, but I'm working on a novel about a whole society in which nobody does anything that their cats don't let them do in which, which people just basically organize their life around their cats and cats are the head of the household.
Speaker 3:I have, I have one more. So we sat and I told them about Catherine's, the scoping of the search features feel set. What stopped her doing that months ago? I said maybe she wasn't desperate enough. So I think that it really pictures, um, a lot of situation in companies that sometimes you have to be really, really under a huge pressure to descope something even more and more. And I, I laughed. I giggled one that one, I've seen this phrase because I said like, yeah, actually that's a factor that makes people descope even faster and more reasonable.
Speaker 2:Yeah. Well she was descoping originally because she hadn't been pressured enough. She hadn't been desperate enough up until then. Ultimately up ultimately she ends up de scoping much, much more as a result of trust. Yeah. And so if you, if you've got two levers, one of them is building trust and the other one is increasing the heat then than it's nice to know that both work but, but my preference is for the one that that involves building trust. But yeah, that was a very realistic observation. Paul, do you have anything more? Um, I did have one more favorite quote and this is just an observation that I liked. So I'll quote as an analyst, she removed ambiguity and uncertainty. As a manager, I figured out how to live with them
Speaker 3:and that resonates. Nate's
Speaker 2:with me because I'm that, that that is a very nice illustration of what analysts do and what managers do and both are necessary. Could I give a quick summary cause there's something else I wanted to say about this book before we, before we wrapped up and that is that there is an observation at the end of this book in which the main character having, I'm not going to say what the main character achieved, but whenever the main character achieved, the main character doesn't lose his job. I'm sorry he doesn't spoiler, I should've said spoiler first anyway, but people know how these things work. The main character asks, so what do you think? And the feedback he gets is, I'm pretty caustic. It's, I think you found yourself in the right situation at the right time with a manager who would, who would kick you and force you to take advice and the right person to give it to you. And that's fair because so many other things could have happened differently. He could've had a manager who just said, just keep doing the same thing better and failed. He have ever had a manager who said, no, you need to talk to this consultant and do whatever she says. And if that consultant was, say, I'm a die hard, but novice safe consultant, for example, not to knock safe, safe can work very, very well in many environments and it does, but safe is not going to solve a massive project with huge amounts of technical debt and overhead that has to be delivered in two months because just implementing safe takes more time than that. So if the consultant was the wrong consultant, if the boss was the wrong boss, if, if the project had not been on fire, he would not have learned any of these things and become the person he was. But a nice, nice wrap up for the story. As you can see, we get to see a person who's got the right boss and the right consultant and the right problem in order to learn all of these lessons. But the reader doesn't need to have a boss kicking them in order to learn these lessons. They can motivate themselves to, to improve. They don't need the right consultant because they've got clerk chain. They've got this book with which all of the ideas and they don't need to have a burning platform. You don't have to have a project that's already on fire in order to start finding better ways of delivering it. And so as a, as a nice kind of a wrap up, if you're not already applying theory of constraints and if you're not already applying TQM and lean ideas to improve your environment and you think that maybe you could, this is a way to do it without a TQM specialist and a fire under your stool medicine. So what should we read next? I have an idea. I know we have an idea and it's um, and, and, and it's partially because of the meeting last night. It's partially because I know how exhausted you are and you're going to agree to just about anything I say. And it's partially because I just found it this morning and I really want to read it. It is this, there is a book published, I think it was just published last month and that's another reason that I want to read it. You've got a ton of travel coming up and a lot of training coming up. And so this book is short and that's why I think it would be a good fit. And I think it's also incredibly important and it's something that's close to both of our hearts that we already know a lot about so we can talk about it easily. And that is a book by Debbie Madden called hire women and agile framework for hiring and retaining women in technology. And I wanted to read that for our next podcast. Will you let me add? Great. All right. Fabulous. So thank you so much for being with us today. Listeners. You know, we love you. Um, I hope that that you've enjoyed the first, uh, experience of listening to us actually doing this in a professional studio with professional equipment and that all of those who have have put up with all of the hissing and buzzing and all of the other artifacts that come from, from the way in which we've moved recording up until now. Uh, this, this is, this is our thanks to you for putting up with that up until now and, uh, and stay tuned because in two weeks we're going to be sharing our interview with the author Clark chain. Yeah. That's exciting actually. Yeah. He seems like such a nice guy. I can't wait to meet him. It's the first outdoor that we really, really didn't know before. Yes, yes. Cause honestly, we didn't know that we'd be able to get all Thursday to talk to us. And so up until now we've only been reading books by people we know. But they were good books. They were good books. Yes. The people who've got the book, we know good people. I know we're about to meet some more and you can meet them with us if you'll join us in two weeks for the next agile book club podcasts. But for now, bye bye. Bye bye. Thank you. Good, good, good. That's it.