In our first episode of the Agile Book Club, we review Klaus Leopold's new book, rethinking Agile.
In our first episode of the Agile Book Club, we review Klaus Leopold's new book, rethinking Agile.
Welcome to the Agile Book Club. Yo, your hosts, Justina and Paul
Speaker 2:This is the Agile Book Club podcast and we're here to talk about our favorite reads in the agile world because we're all about continuous learning, continuous education, always bettering ourselves because we're such such bright and people, I was going to say broken, broken, anything broken people badly in need of reform.
Speaker 3:Okay, I will. I thought that they are going to flatter as a little bit that we are both, you know, oriented for self improvement. So we are reading and reading more and more bad. Okay? Okay. We are broken.
Speaker 2:That's why we need to work. That's why we all need to work so hard. And with this episode we're going to be talking about the book rethinking Agile by Klaus Leopold and here's the format. This is the very first podcast. Nobody has heard this before. You might be the first one ever to hear it. You listening right now, you might've been the first person who downloaded the first person to hear it and so this is what you can expect. What we're going to do is with each podcast we're going to talk about a different book and we're going to talk about what we liked about the book, what we didn't like about the book, what we learned from the book, whether or not you should read it, because we're here to save you time. We read this book five time and money. Yeah, books. Her books are expensive. Time is money. Books or money. Books are tying, so we're kicking it off with rethinking agile, which was a book recently published by our friend and Klaus Leopold, and we're not reading it because he's our friend. We're reading it because it's really colorful and has lots of pictures. Yes, so this is the format we're each going to say how we would try to try to pitch this book to a friend of ours. Not You. We don't know you. Well, we would say if we wanted to pitch this book to a friend of ours used in it, what would you say to a friend who was a chair with this book?
Speaker 3:Yes. I would recommend this book for everyone who went through agile transformation and things that, oh my God, agile is not for me. It was not worth it. It's not working. And I think like this person should read this book to have a look on what went wrong in their transformation because Klaus is getting lots of ideas what could go wrong. And also I would recommend this book for everyone who is wondering if they need it an agile transformation. Transformation or no because it has a set of ideas and potential problems that might come up in your organization.
Speaker 2:and you make it sound like it's a transformation horror story, which I would love to read. That's a whole genre of literature that seems to be missing in our field is transformation Horror stories. Yeah. Mostly limited to just complaining on blogs. I would love to read that. I don't, I don't think this is a transformation horror story. It starts as one, yes, first
Speaker 3:27 books. And for me like Lincoln Park Song in the end, nothing really matters cause it shows that everything was perfectly by the book or even better. But in the end, time to market was even worse. Yeah, fair enough. Fair enough. But that's not what the book is about you. Here's my pitch. My pitch is not so different than yours. Maybe a little less dark. So if you're starting in agile transformation, if you're
Speaker 2:in one and you happen, you were lucky enough to bump into somebody who had just completed a very successful agile transformation and you ask them, so what did you learn? What did you do? And if you were really lucky and they gave you a really helpful, straightforward answer, that was inspiring without being prescriptive, it would be this book. That's my elevator pitch. Beautiful. Thank you. Thank you. But I don't have to sell you. You've already read it twice. One of the things I was thinking is as I was reading it is this is the way we should have been selling agile all along because it goes to something which has been bothering me for quite a few years and which, which I've been talking about at conferences and such, which is this notion that the easiest place to apply agile is agile practices. I should say is at the team level and so that's also where the money is. There's only one executive team in a corporation, but there might be 30 development teams and so do you train the at the senior management team or do you train the the development teams? That's where the money is in the corporation for operations. Always have a budget for training, but that budget is not for executive training. That budget is for line manager and worker training and so the classmates are point in this book as well that that it's very common that executives, even if they want to continue to develop and improve themselves, they very rarely have the time because it's so much more competitive than the line manager, the middle manager, the scrum master, the developer roles. These people all know the importance of making time to learn, but they also are in an environment where they're supported in learning for the most part and their training budgets and conferences and this sort of thing, but by the time the person becomes the CEO of a major corporation, it's very difficult for them to make time for learning. Especially the kind of learning that really challenges your mindset like agile thinking does. And so as a, as a training company, the low hanging fruit, the easy money is let us train all of your teams to be agile and then you'll have agile teams. So what happens is most agile transformations start with the teams. Even if people know better because if the CEO, this team has to show up for training on Wednesday, then that team shows up for training on Wednesday. But if the agile consultant from an outside firm tells the CEO that she needs to assemble her entire executive team for a full day agile workshop, the chances of that falling through of members not being able to make it, people being pulled out by this important thing or that important thing are really high. I have a friend who is a very experienced agile coach and Kanban trainer in the UK and I once watched him suffer through a year long engagement in which he could never get to senior managers to sit down in a room on schedule in the entire year and let alone a full day or a week of training.
Speaker 3:I have a funny expression for that because recently on the agile coach come that they weren't one of our friends. She told me that this is the game. Catch me if you can. That's just how she described her. Her tries to cooperate with executives that it's like impossible for her to catch them. Seems like seven months already, even though that they pay her to change the organization and she's telling them, guys, I use your money but I need you on the board. And since seven months I couldn't make it to meet with you so you can keep paying me nothing. Gonna Change.
Speaker 2:So if this were the first blue book on Agile, I think maybe the agile world we'll do would've evolved and look differently. And you imagined if the agile certifications, if the first certification that came out of the scrum alliance was a one week long certification program for senior management as opposed to the certified scrum master for example. And then then training people lower down was was an after thought because you don't have, obviously we make money training, I'm the trainer I teach combine and I want to keep doing that and I like doing that. It is frustrating for me to teach people how to do things that they're going to have a great deal of difficulty doing or things which they may never be able to do because of the nature of the environment that they're in. But know how different would the world be if, if agile transformations actually always did start at the top and if agile was seen as a senior leadership function, that's kind of the world that a Klaus Paints. But I like the way he paints it. So can we get into the book? Yes. So there's the way class it lays out. This book is first he paints a picture of what is basically a failed agile transformation. It's a company that needs to improve its time to market. And so what we're talking about here is enterprise agility. We're talking about agility at the company level. When you talk about agile teams, you're talking about trying to increase your throughput while maintaining or improving your quality. But that doesn't want help if at the company level you're not actually responding to market change any faster just because some of your teams are producing faster. And so that was the motivation behind the agile transformation is they wanted to get products to the market quick more quickly and they wanted to be able to respond to market changes more quickly because they had small, very agile startups that were starting to nip at their market share. And they just couldn't bring something to market fast enough to stay ahead of these people. And so they did the traditional thing. They brought in a whole bunch of agile coaches and they trained all of their teams and agile processes and agile thinking as well. And then team by team, they learn how to be agile. And what they found is that despite the fact that they did this, what they were planning on doing very successfully, the results were very negative. They were actually there. The time to market was longer. And so the hero's steps into the story, and this is the author of course, of course, surprise, surprise, closley apart. And he comes in. Now this is what I like about the story, is that he essentially talks about what he did and what he did is not just what he did on a very, very practical specific way, which he does do, but also the theory that drives what he was doing in the air. So, so this is not a prescriptive approach. He doesn't say, I did this and then it did this and did this and that's how you should do it. And what he says is, what I'm trying to do is apply these principles and these are how the principles were applied in this particular organization. And those principles essentially are that you need to focus your agile mechanisms on the part of the company that you want to be agile. And so what you want to do is have your products we released in a more agile fashion. Then you should look at the way you think about organizing and managing your products, not your, your proud your teams. The way he puts it in the book is you should apply WIP limits on the thing that you want to improve and in this case as in so many other cases, you start off with these big product ideas and the product ideas if they're implemented, become a backlog of stories in the backlog of stories get broken down in the tasks and then the teams apply WIP limits to the tasks so that the tasks floated the system smoothly and that's great if what you want to do is have tasks flow through the system more smoothly. But if what you want to do is have projects floated the system more smoothly, the exact same mechanisms work, you have to limit your whip and apply visualization tools at the project level and as much pushback as you get when you start talking about WIP limits with teams of rather junior people, your peer programs and your testers and your designers. Imagine how the kind of pushback that you would get from your VP of marketing and your CEO and your CTO to apply WIP limits to their dreams, to their visions for their company. But that's what you say. So what would be your first takeaway from the book? So the first takeaway is that this is lovely. He paints a a rather complex picture of progressive and and dramatic change through an organization. But essentially what he does is divide the organization into three different levels, which he refers to his flight levels, different levels of visibility into the work at the lowest flight level. You're looking at how a team works that a higher flight level, you're looking at how teams related to each other and at the highest flight level you're looking at the organization as a whole delivers value to its customers and the exact same improvement strategies work in all in each of those levels and essentially what he did is for each one he just first visualize what's happening, then limit the work in progress and then implement feedback loops and the feedback loops are basically just meetings or or opportunities for people to talk about the right thing at the right time. And those things don't look exactly the same at every level, but it makes his whole approach to transforming the way a large corporation works. Very simple. Visualize what's happening, limit the work in progress and then implement feedback loops. But it does sound easy, which is why I appreciate the fact it would be really easy to write a few rep theoretical book based on that idea. It would look something like how I would do scrum with an executive team if I did scrum with an executive team and it would probably look a lot like just following the scrum rules. What I appreciate about this is he's, he's also telling a story, which is a true story and at no point does he say you have to to visualize this way. This is how we visualized, you don't have to limit you with this way. This is how we limited the whip and why. And you don't have to have exactly these meetings with these people to implement feedback loops. But this is how it works here. So you get both the theory, but you also get a good example of how it works in practice. And I appreciated that very much. So what works for the team works at other levels as well was my first big takeaway. How about yours?
Speaker 3:I do really like the way close describe the whole situation because there was no negativity. She was really appreciating what they have done was really appreciating the attitude that they have and all the boards visualization, measuring, um, by walking through everything he was discovering, what could it be added to make it successful. I really enjoyed the example with executive managers who actually had too many good ideas and too many initiatives they were trying to implement over the year. And the problem there was that they were making all decisions isolated. They didn't talk with each other because as like most of the big organizations they had planned in December, let's say 2018 that they planned the whole year until next December and they didn't talk during the year. They didn't have any strategy portfolio management. And because of that, all of those great initiatives were like constantly push into the system. And as I said at the beginning, this book might sound like a horror story for the first 27 books, but then 27 pages, sorry. But then it shows how sometimes good attitudes and postures in organization can work out that even though that you try to do good things, it might not work for you.
Speaker 2:I've seen this a lot before. I had the opportunity to participate in annual planning, budgeting and project planning at a few different corporations, and the story is always the same at the highest levels when they're doing the planning for the year, it's always annual. I've never been in an organization that actually plans for a quarter. They plan the quarter, but they've also had the other quarters planned. So the annual planning is, is is a fixture in every corporation that I've been in, and the way it works is people come together into a room. It usually takes at least a day, sometimes as much as a week, and they start out with 50 initiatives that they want to implement and they know they can't have the ball. They know they can implement these 50 initiatives. All of them have bubbled up to the top because they're highly valuable. Oftentimes there's a lot of politics involved. There's, there's people whose egos are attached whose whose positions, but everyone in the room understands that, that the company is not going to be able to do all 50 because this company has never released more than 20 products in a year. Last year they released 20 the year before that they released 18 the year before that they released 15 year before that really 17 it's like 15 to 20 products is what they do every year and so they end up doing the same thing that they do every year. They start having sometimes rational conversations about which of these should be eliminated. Often political conversations about which of these should be eliminated and so they take this big stack of 50 things that they bad they want and they managed to widdle it down to 25 and they were very proud of themselves because they know in their gut that even know their development department has never managed to develop more than 20 new products. They always knew and they believe in their people that they could do it. This time, the agile transformation is going to work this time, they're going to be more focused this time they're going to do things right and wouldn't be a terrible if, if they plan for less than they could handle it and they didn't know what to do with their last quarter. So I think, okay, we're really proud of ourselves. We've managed to knock 25 things off of this list. Now we've got a list, which is stretch goals or this is our optimistic profile or what have you. But once it's set in paper and once it's communicated out, it's communicated out as expectation and
Speaker 3:but will they find a little bit bothering is like they created this big document, they started sometimes in excess, let's say that as a goal, as goals for the year and then after a few weeks, no mother looks there because it's like look updated or there are new initiatives that are ongoing. And the one was those who put two initiatives there if they don't have in the old couple of et cetera. So this strategy plus get up outdated, I would say pretty fast. So I can understand why they don't do it more often. Is it because of the time constraints that it's, you know, created that those executives and they don't have so much time to meet like quarterly or day? It was the way that they have always done it. So why they would do it more often?
Speaker 2:I think it's tied very strongly, kind of like a cause insinuates in this book to the idea of annual budgeting. Okay. So that the budgets attached to the projects and, and, and almost all large corporations budget annually because it's a big project that involves everyone in the corporation and so they batch it. It's, it's a big chunk of work, so they batch at once a year. But just because you've, you've gotten annual budget doesn't mean that you have to, to plan exactly how you're going to spend every cent. Nine months out, I've seen the same thing, but that, that nobody changes it, but usually it's not forgotten. Usually what I've seen happen is they make these plans and then inevitably they start to slip almost immediately. Sometimes that slip isn't noticed at the top because of watermelon reporting. It starts to slip, but the scrum master thinks that they can catch up and so they, they cherry coat it and so their line manager cherry coats it and, and it, it might be, you know, months into the year before you realize that you're already weeks or a month behind the plan. But what's amazing to me is rather than rethinking the plan at that point, because if you're two weeks behind, one month in, that's a very good indication that the promises that you've made for the next 11 and a half months are going to be extremely challenging. That's corporate speak. That's what they say, extremely challenging. But we can do it, know that that mistakes have been made. We know who made them and they were made a few weeks ago
Speaker 3:and we should start doing corrective action now. Instead, all of the discussion is about how can we get this thing back on track and whether that's hiring new people, changing the way they work, often just putting more pressure on people, whatever it is. What's astonishing to me is how these conversations about how to get things back on track can continue throughout the entire year. So I can kind of understand if you get off to a slow start, um, how you can learn from the first few weeks learned from the first couple of months and try to improve based on that. But when you are way behind your annual plan in November and you're still talking about how you're going to cram everything into December and get more done in December, then you got in your first two quarters. That's just, oh, but one of the things that I really like about clouds book and this chapter about strategic portfolio management was actually that he incorporated those strategy calls into the board into the visualization and transparency for all teams that they knew what are the strategy calls and how protest and task that they are having correspond with them. And it was really interesting for me because last week we have, we had the training and one of our colleagues, she said that during these planning sessions they are all on Skype and she has to send the message to her team members to say, okay, now you have to turn on and say, yes, I agree. Or you know, what is your status in that case that they, that their team members are not active in the whole conversation. The whole long Skype calls the, they just get incorporated once they have to raise them forces, so I really liked this example of the port that Klaus designed that really incorporated those strategy calls so all the members could understand why they do what they do. Another take away that you got, oh, that's really tricky because you've covered a lot of that before. We started talking about our takeaways, but my first one was to design your own organizational model and the first part of the book he was giving an example of Spotify and how many organizations try to copy paste that motor mostly because they thought, okay, once we have Spotify model we will be agile and we will succeed with all of our guts and actually world class emphasized is like they were not edgy because they had this model, there were agile because they have the structure that helps them and enable them to deliver customer value to deliver what they promise they deliver, what people are paying them expect. So he really pointed out that you have to try to find the optimal model for your own organization. Okay. You can try with copy paste of a model a and then observing how it works for you and change it by the time there is not like, you know something that depends us by and incorporating your team because it's all themes are different. Spotify doesn't use the Spotify model. Yeah.
Speaker 2:Spotify model just just represents how they were organized at one particular time. Many, many years back in their past they were not, they're not so tied to it that they stuck with it because they are agile learning, learning new and better ways. As the market changes, as the business changes, as they find better ways to work, they change it.
Speaker 3:I also think that this importance of creating your own structure within your organization goes along with those flight levels, this model that Klaus described that you have to understand what is the big picture in your organization. Then zoom it a little bit more to see what are the collaboration between teams and then see what's happening inside your teams and once you have this view you can try to come up with your own structure. What is your takeaway? One more takeaway from Paul.
Speaker 2:I've got plenty more to talk about about this book. It's a short little book, but it's got a lot of great ideas in it. You know, one of the ones that I really liked was just the idea of that transformation takes a lot of time. It's not a project that you can just plan out and roll out in a waterfall manner. That that we're going to do a transformation and so these people need to be trained. The trainings are scheduled for these dates. You can implement a new way of working on these dates and by this day we'll be agile. What we see here rather is that they've gone through that process and they implemented agile practices the way they wanted to even on schedule. But the whole actual process of becoming an agile organization is ongoing and the the work that clause does with this company happens over a period of quite a bit of time. So this, this idea that that it's a thing you do rather than a change in mindset. We're changing. The way in which you think about how the company is run is I think very, it's unhealthy to think that that you can do agile in a fundamentally like, like he says, it's ridiculous to implement an agile transformation in a non agile way. And, and I think that's important.
Speaker 3:I have one good quotation from the book that goes along with what you said, eh, even desired state is agility the way, the way there are,
Speaker 2:the way to get there as agile. Yes. If the desired state is agility, the way to get there as agile. Yes, exactly, and that is amusing, but I think that's an important message too because these sorts of transformation are painful and disappointing. Any transformation is disappointing. Not Not that the outcome is disappointing, but there are points of just disappointment along the way. Expectations always deviate from reality and if the goal is continuous improvement, then that is an ongoing goal. It's not a, it's not a specific outcome and I don't say that to scare anybody off of agile transformation, but there's a lot more to be gained from doing a gradual careful review of how you work on a regular basis at multiple levels over over a long period of time. Then throwing a huge amount of money into hiring dozens of consultants and just doing a big upfront, big bang training endeavor.
Speaker 3:Have you ever seen organization that went to agile transformation and once they realize that results are not good for them, they stopped and came back to what they were doing before. Oh, absolutely. Oh yeah. I think that's more common
Speaker 2:then success. Okay. Many, many Sentricon companies, none of which I won't name in public.
Speaker 3:Okay. So it's like we forget that, that we tried, we come back.
Speaker 2:So what we are doing before, yes. Okay. In fact, many of the companies that you know is as not being particularly agile, have had agile transformations in the past. Sometimes more than one. Even even here in this city we are broadcasting.
Speaker 3:What, what, what was the funniest name of, I don't transformation that you hired because I had like milk out or oh goodness. Off the top of my head.
Speaker 2:Can't do that one at, I'll knock knockout. Yes. Okay. The violence of that. Okay.
Speaker 3:We're knock you out.
Speaker 2:Yeah, that's, yeah. Um, next, next. Moving right along. And you talked a little bit about estimation. I think this was one of my takeaways. I, it's, I'm a big proponent of making estimation as low cost an endeavor as possible. And I do a lot of training in how to use statistical forecasting methods, but I'm not one of these hardcore people in the no estimates camp. I think rather a pragmatic approach is to do no more estimating than necessary. And that can be really tricky because how much estimating is necessary? Oh that was my question too. Well this, this is the problem and this is what happens is, is somebody says, you know, I just want a a thumb suck. I just want a high level estimate, but they don't say it to the person doing the work. So if the CTO says, I just want one, a high level estimate, they tell that to a department manager who tells it to align manager who tells it to the scrum team, who tells it to their developers. And by the time it gets down to the developers, each person, since the reporting to the, to our person was senior to them actually in views more and more weight and significance to the order. And so if, if the CTO or to just grab a developer over lunch and say, how big do you think this is? The developer might be able to read their body language and and make and say, okay, I can see that this person is just asking for for a rough. Yes, but when it comes from your boss's boss's boss's boss's boss, you put a lot more weight on it. And so I think, I think a lot more effort gets put into estimations then the person who requested the estimate really expected what happened. But another thing that happens is with estimations churn into plans. And then when, when, when, when you asked for for a rough estimate and then started getting very frustrated when the project goes 10% over budget or 20% over budget, what you communicate is that you didn't mean you wanted a rough estimate in the first place. You wanted a very accurate estimate. And so those two phenomenon, I'm either working together or independently I think lead to a lot of wasted time and effort. But the point that Klaus makes is if your goal is to try to be agile, then the purpose of estimating shouldn't be to get a highly accurate estimate so that you can do an Roi analysis and roll that up into your annual planning. You should be getting an estimate as late as humanly possible for the purpose of making a decision as quickly as possible and and if, if the estimates are happening lower down in the organization and the information of the estimate is being used high up in the organization, there's probably a huge time lag and that is very agile. The best way to to do an estimate in this particular case, if you'll just try to make a decision between two projects, which one to start next and again in an agile way, you shouldn't be talking about which project to start next when you're sitting in in January, planting your third quarter, the time to be talking about which of these two projects to start next should be. When you have a team that you see is about to be releasing in a few weeks and they're about ready to start preparing to take on a new piece of work. But then you say, okay, well we've got these two things that, that this team has is qualified for the both seem very important to us. We need to make a quick estimate. So grab the right people into the room, make it quick, estimate, take a decision and then start the work. Yes, estimating work that you're not going to start for another six months. Strikes me as is hugely wasteful and very Nolan Agile.
Speaker 3:Yeah. Just the haddock estimating the work that you might not even start next year or never got. It's never going to have them because like, because markets change in our competitor came up with a different idea. And do you have,
Speaker 2:hmm,
Speaker 3:make it better right now? Yes.
Speaker 2:Oh, most ideas
Speaker 3:are never implemented? Yes. Most ideas are never implemented. Most bugs are never fixed. So that gets me to another ranch, which is about bug bug cataloguing and management. I won't go into that because it's not not about the book, but indeed estimating, prioritizing, talking about managing reprioritizing tracking, anything that you're highly unlikely to ever action is all just a waste of human time and effort. Well, more pick away from me, uh, was in the case of team performance, but it doesn't matter if your team, you said most and dark in the organization and as fast as possible because the other team, my start working on that in the next 20 days and it doesn't matter that you deliver that within five days because it's going to say that for the next few days and all of these look out of the musician, my bring system, subtle things, issues. So you have to look at the whole team collaboration in order to find the perfect flow from your organization.
Speaker 2:Yeah, this is, this is one of the parts that I found to be really inspiring in this post because I've spent time in organizations in which teams work independently on independent projects. But astonishingly I, I was in an organization once in which there were several teams, they all were constituted basically the same. They had the same back end programmers, end programmers, designers, UX researchers, the same people in in the same roles sitting in the same office layout in rose side by side and the team's never spoke to each other, never you. You could be you sitting back to back with the person doing a similar role to you on a similar project in the same company and simply never happen the relationship at all. Even if you have, you shared a lot in common like shared it dependencies for example. Now in this case he's talking about a couple of things. One is is the, in this company they had decided that a team would focus on only one product, which is very logical. However, some products are bigger than one team and so even if it was one project per team, it wasn't one team or project and so you might get these, these scenarios in which you've got multiple people working like you were describing multiple teams working on components of a product and but they can't be implemented in the order in which they're being produced and there's no coordination at that level. I do like your example from your previous job
Speaker 3:when you optimize the time of every part of your team, but it really didn't matter because it couldn't be implemented because we're waiting for shared service.
Speaker 2:Yes, that's somebody he didn't deal with much in this book but I, I'd like to talk about it a little bit about it, but like I said earlier, he basically says each each eight places you're trying to, he applies these three steps. You visualize, you limit the whip and you create feedback loops and so for example, when he had multiple teams that were all working on the same product, he encouraged them to create product needs and if there were just a couple of teams, sometimes the product or would replace the teams combined boards because you'd have a product board and it would just have have swim lanes representing each of two or three teams and then they can all come together and when you're doing that, when the teams are actually talking to each other, because that's the feedback loop part. Even if that, if that the teams had one product board, they might have, they might stop having individual team stand ups and have three teams doing their standup in front of the product board. But in bigger projects where there's, there's five or six or seven teams, it would still have a product board, which might be a simplified view of the individual team boards. And once a week representatives of the of the team would have a stand up in front of it and that's where they would discover things like we're about to start working on this feature. And then member of a number, another team would say, we're not going to be able to support that for at least another month because we'd have to build out the back end for that major. And so a decision might be taken to de prioritize that feature in favor of something that can be released earlier. And it's really simple when when management thinks about coordinating between teams, it might look like a lot of overhead, but I think it's only a lot of overhead if you try to manage it. Oh yes. If, if, if you try to to manage and control how teams interact with each other, then that can seem really scary. But if you trust your teams to take decisions, informed decisions between themselves, then encouraging that sort of interaction becomes incredibly agile and incredibly beneficial. But I was thinking of an example with the shared service cause I think this is something that'll let a lot of large corporations deal with. It's not something that Klaus talked about in the book, but it got me thinking, could you do something similar with the shared services team? So let's say for example you've got multiple teams that are building products and they all are interacting with backend systems using an API layer for example. And you've got one API team that's supporting maybe 10 or 20 different product development teams. And I've seen companies try to prioritize work because there's always, when you've got 20 different teams all screaming for the same shared service, somebody has to do prioritization. But prioritization alone doesn't solve the problem because the lowest priority requests from these 20 teams is the highest priority for the team. That got denied. And that team also has deadlines and expectations. And one of the things that I saw in this sort of scenario is a certain predictability at the team level in the need for such a shared service. So if you shared service is deployment, then it's predictable when you're going to need the deployment team to work. What I've never seen is all of the teams that rely on that shared service trying to coordinate their deployments in such a way that they don't slam the shared service. So we're doing a deployment on Monday, well, we were going to do, you'll plummet and Monday, but I guess we'll do it on Tuesday. That way we won't have the deployment team trying to support both of us at once or we're going to need some, some develop, some features that are wind require a new API APIs. We all start developing features of according to API Apis. Well, let's shift one of our are our starting points a bit. So we're not both hitting the API team at the same time. So it's not like that deliver race team,
Speaker 3:the delivery race team B that they just cooperate. Yeah,
Speaker 2:exactly, exactly. And, and, and that's what happens when you visualize dependencies and then the people who have influence over these, these dependencies just talk. And then so that's the visualized limit and feedback loop components. Sometimes just talking is the cheapest way for improvement. Talking is that fee, especially face to face talking is the cheapest way for improvement, but it requires an enormous amount of trust because one of the scenarios they caught us throws out here is the scenario in which a team realizes that the work that they are supposed to be doing is less important than the work being done by another team that needs help. Oh yeah. So, so in my mind, the ultimate agile organization is one in which a team doesn't need management permission to change their goals. They can see that, that their, their time would be better used doing something other than their job. Yeah.
Speaker 3:But also through the conversation could have three interesting discovery over the process that you have like a close at this example, when he started interviewing the teams and he said like, okay, this is your board. So when are you done? Or these before. Okay, so you need to know this extra basket with ideas and those ideas comes from this dear man and et cetera. And just really interesting experience to see how this small board evolved into ash. Huge, huge board that was having so many steps overset
Speaker 2:yeah, absolutely. Yeah. But I also liked the fact that he did this slowly. I once knew a uh, senior Kanban trainer and coach who was given the the impossible job, the almost impossible job of designing a corporate wide workflow for a major multinational corporation that had development and product development teams on every continent and they were trying to do it in the big bang so we could switch to the way we're doing it to do at this, this new massive system. And the best way to, no, no, we're talking more specifically about Kanban when you're talking about end to end value stream mapping. But the easiest way to do that is one, one part at a time and then connect them where they make sense to connect. But that's another example. If in an organization like that, if you were to pursue it slowly by combine Ising different components of the organization and then creating spaces for, for people to talk where it makes sense for them to talk. Some of those, those combined processes could become linked together. Some of them could, could have buffers, but between of them, some of them could even have WIP limits on those buffers so that you've, you've created a more predictable structure. That more particular process that links different parts of the organization. But the ultimate end result of that would not be a single end to end beautiful model because parts of it just wouldn't make sense. And uh, if it evolves organically, what you'll get is not necessarily something pretty but something useful. But it takes a lot of time to do so. Yeah. What else did I want to say about this book? One of the things that I really liked is the way he deals with portfolio management by using the same basic tools but applying them to the work that executives do. I think that could be really going in and telling executives you're going to teach them to be agile by teaching them agile theory is nice, but it doesn't really tell them what to do. Teaching executives, the way that you teach teams doesn't help because what you don't, you don't want your executive team doing scrum the same way that your product development team does scrum, and one of the reasons is a is an observation I really liked from this book, which is that what you expect at the product team level is throughput and what you want to measure, how much they can develop and deliver, but at the highest level, at the portfolio level, what you should be managing, what you should be looking at is outcomes. So if you could do, if you've got the option to do more things or to do one thing that has a bigger impact than the one thing that has a bigger impact should be the priority in it. In a team, you just want to have the high priority tasks, deliver it as fast as you can without sacrificing quality. But the portfolio level, it's the impact that it makes on the company. That's important. So you can't use a set of processes and tools that are designed for throughput when, when you're trying to do something really fuzzy work that is, is designed to maximize the impact. Um, and the way he did it is by using, starting with this high level, which is visualize but don't visualize the way they do cause you do different work, limit your whip, don't limit the whip the way they do because you're doing different sorts of things and you have different sorts of goals and then implement feedback loops so that you can, you can learn and see and feed more information into this process at the appropriate times and change or make decisions as you go. And that you could walk away with a prescriptive idea. Cause the way he does it with this company is, is very clever and attractive, but you can also see how you could apply it in very different environments. And that really appeals to me because I don't think any CTO, once some consultant from outside the company to teach him or her scrolling
Speaker 3:yes and change their mindset and tell them what to
Speaker 2:what I think an executive team would like is somebody to teach them different and better ways of doing what they're already doing. Nobody likes spending a week in budge in annual budget meetings. Nobody likes being locked in a room for a week. If there was a way that they can make better decisions with more timely information, that could be an action too quickly rather than planning that far in advance by simply doing a weekly or biweekly or monthly call executives would would generally really like that. So that appeals to me in it and I think that sounds like a much better way to introduce agile at the highest levels of an organization.
Speaker 3:I also think that the business attorney to start at the top as one, we have those executives on your side, it's easier to manage change because of the Medicaid. They become your change agents. They have lower resistance because they are the part of the change. So why would they say, you know, constantly, no, why would they undermine what you are trying to do? So I really, really believe and this book proves that the do you have to find a way to get them on your side. It will really set your time and energy and their money as well.
Speaker 2:[inaudible] so you sit in, what was your favorite quotation from this book? I had to,
Speaker 3:uh, the truly making it made me laugh. The first one was, uh, about, uh, executives. We are going to implement a waterfall project to become agile.
Speaker 2:Yep. Indeed. That that is just funny. But I mean it worked. It got them to the point that they were at, which made it a lot easier for close to do what he did because he had a good starting point to get to go to work from. But yes, indeed.
Speaker 3:That sounds like a very lonely inside joke that made a lot of tifo glass.
Speaker 2:Yeah. When, when, when, when you talk about an agile transformation plan that involves, you know, the coaches come in here and these trainings happen here, then these strings have happened in these two things have to happen. You could easily envision that whole thing and again to chart however I'll do mine was since the teams are going to be agile as of the deadline, even more projects can be started. And this is, this is what I was talking about when you're doing annual planning, you plan for the, for the company that you want to have, not for the company that you do have.
Speaker 3:Oh yes. I always think about it as a metaphor of spending on the one bonus that you still didn't get in July. You hope to get it in March and expect that it's going be so big. So you already booked your holidays in Asia, but then you realize that your about Bonusly slots. So because you hoped,
Speaker 2:yeah, thank goodness it's street food is cheaper. Yes. So that's what I took away from this book. I highly recommend it. It's a fun read. It's a pretty book. A lot of of time and effort went into visualizing the ideas in the book. This is this, the pretty book in a colorful with lots of fun, fun pictures.
Speaker 3:Well the finishes that are mentioned on the side of the book. So I have found it extremely useful to recall of what some definitions really means. Like you know, it was a really, really nice touch.
Speaker 2:Yes. So it's easy to read. It's a fun read and, and it's a lovely breed and it's well written and it's useful and it covers, it addresses I think a very important aspect of the agile community, which is does not have enough literature to support it right now. And, and that is, that is our review of Klaus Leopold's rethinking agile. So what should we do next?
Speaker 3:I just wanted to ask you that question because of follow the red of the few more books than I know and he's very good at Ricoh.
Speaker 2:She means I'm old.
Speaker 3:Definitely. Whenever I, I found myself into a new topic, I always ask Paul like, oh, what should I read in this topic? So I would address this question to you at this time. Again,
Speaker 2:at some point, I want to get into to some of the more detailed fringe books in in our our world because there's so many interesting things out there in these early episodes. I'd like to deal with some, some of the newer books that have come out, but that address more fundamental topics that are of concern to everyone in the agile community. And so I'm going to suggest that for the next book we read, Dominica Degrandis' Making Work Visible. What do you think? Yes, that's kind of good about this book,
Speaker 3:Beth. It simply shows how you lose your mind when, when you lose your time and how people don't see that time. Stealing
Speaker 2:should be very costly. So yes, I would love to read that book. Okay, so stay tuned for the next episode of the Agile Book Club. We'll, we'll be talking about making work visible. Thank you for listening. Thank you.