Justyna and Paul interview Klaus Leopold, the author of rethinking Agile.
Justyna and Paul interview Klaus Leopold, the author of rethinking Agile.
Welcome to the Agile Book Club. You're your hosts, Justina and Paul[inaudible].
Speaker 2:Hello and welcome to the second episode of the Agile Book Club. I'm here with Houston and we're going to be talking today with close to the vehicle, the author of rethinking agile. And we have, we have a close with us today. He's already listened to last week's podcast, so he might have a few things to say about, um, what we had to say about the book. So we're here today chatting with clubs, Leopold, the author of rethinking agile. Hello.
Speaker 3:Hi.
Speaker 2:So I'm here with Justyna. Hi. And thank you so much for joining us. Thanks for having me. So we want to talk about your last book, rethinking agile and which of course we both read several times. I'm looking at Justyna's copy here. It has, it has more Post-it notes than pages. That's good. Nice. So, so you've heard the podcast already. We, we both very much enjoyed reading the book. Who did you have in mind when you wrote it?
Speaker 3:Well, I heard the podcast and I must say I really enjoyed listening to you guys when, when you were talking about the book, so what caught your attention? And so that was really, it was interesting for me as a writer, you know, you don't get this kind of feedback too often. So your question was what was the reader that I had in mind, right?
Speaker 2:Yes. What did you want to impact? What changed did you wanted to drive?
Speaker 3:Yeah, so I think it was pretty clear actually it was senior ish management as the main target group. That's also the reason why there's not so much texts than more pictures in the book. Some of them might sound funny, but I think the point is that people don't read so much. And even if I think there's, there's a new topic that somewhere arises on the horizon and I'm somehow interested in it and the thing I need to read 300 pages book, I'm like, hmm, well I probably won't do it. So the idea was to deliver something where the barriers a little bit lower for people to, to read it. So top management because I think the top management or senior risk management, the things I try to cover the address actually their needs. That's at least what I thought. And the other group was people who are somehow part of an air child transformation that's already going on. And they're like, okay, that's what probably could be the problem in our scenario. So I give this book to my boss kind of. This was the people I had the moment. Huh.
Speaker 2:So the thing that the way
Speaker 4:to communicate with executive managers is true images because I've heard that so many people have problem with no catching the executed to talk with them or just you know, picture the idea and from the first group that you described, I think that that might be a tricky but very successful way to talk with them.
Speaker 3:Well, I think, um, pictures make stuff a little bit more accessible, so at least I'm quite a visual kind of person. And um, yeah, it somehow helps meet to learn. And I was like, okay. What I usually do is I write text books. He, there are also some charts in there and figures and stuff like this. But um, well I think it, it's different if there is so many illustrations and at least I think the illustrations they are also, um, some of them are really kind of funny. So a, I really love to work with the illustrator, Tsi Seinfeld. I think he really did a great job and I think it just helps to, yeah. To, to get access to the material kind of
Speaker 2:the thing that I really enjoy about this. So aside from the fact that it's aimed at executives and those are the people we really need to reach because, well, for the reasons that are in the book, but I've been involved in the agile community for a long time and I think what you've identified is a problem that a lot of us have faced, but we didn't realize it early on in that is that I suspect it's because of all of the money to be made in scrum training and concentrating on the foot. And then it's a lot easier to sell training to team members than it is to sell training to the managers if only because there are so many more of them. There's more money to be made in selling at the team level. If you could go back to the early days of Agile, back, back when everyone was still excited about XP in scrum was a new thing and there wasn't a scrum alliance, there weren't certifications, there was no lean kanban university. And give us some advice back then before we started on this path to agile training. What would you do?
Speaker 3:Yeah, I think we'd probably shouldn't fall into the trap of, I guess hindsight pyres is how Daniel Kahneman would put this. So now I of course know what I would do better. But back then, well of course if I would have all this knowledge almost, it's almost 20 years actually. Of course it wouldn't be about a software development team. So the route when we looked at XP or so it was software, it was software development, it was teams, but this is just where it originated. I think all this knowledge that we currently have about business agility, so it's, it's for long time, no longer about on the software development and stuff like this site already enter different areas in an organization. So if this would have been here back then of course we would have started on like with Senor coaching, senior training, senior consulting and everything. But I think it emerges out from there. And of course there are business models of training companies, consulting companies, which somehow built around this whole training business. And of course, as you said before, yeah, you can earn more money by teaching, don't know, 300 teams. Additionally, there's only a couple of management teams in an organization. So there's probably something which, yeah, tries to hold back a further development of this because that's where money is being made. But the point I want to make is yes, if we would have known it, it would have been different, I guess. But I think it also emerged from there. So I think nobody back then thought about something like business agility when people started to use XP, you know what I mean?
Speaker 2:Yes, yes, I was there too. So something that I found really, really useful from the book, something that I really enjoy was this simple problem solving approach that you can apply at just about any level. Could you walk us through the process that you use to uncover and visualize and respond to dependencies inside of a corporation?
Speaker 3:Okay. So when it comes to dependency, so usually I always start with, I tried to uncover how this organization is generating value on the market for the customer. And this means, uh, I tried to look for what other products, what are the services, what is basically the offering. I somehow tried to make this visible in the room. So we are not talking about a organizational structure. So we're only talking about, okay, what's actually, yeah, where the market or the customers, what they care about. We make this visible in the room. And in the second step we try to identify dependencies between these services and products. Because often it's the case that one service or one product built on a service, right? So if you want to change something in the product, you need to change. Another service or another product. So try to somehow make this visible just by drawing lines more or less. And then in the third step I try to somehow map the organization into it. So it depends on how huge organization is to, if you're talking about the couple of hundred people, we can already start with teams. So we basically just make the teams visible and somehow tried to connect the teams to the products and services. And usually this ends up in a huge mess because there's tons of dependencies there. If we see something like this, we somehow try to identify where are the most lines this meets, where are the most uh, dependencies. And then we basically try to figure out what could be flight level two systems in on a flat level two system. The idea is to manage end to end from idea to impact. So what could be good flat level two systems and then starting from the flight level two system, we can go up probably cluster some flight level two systems. If we have dependencies between the flight level two systems, we go up to the flood level three system. Where's the strategy? And as the teams are already somewhere visualized, we already know the flight level one systems. This would be somehow the process that I am that I'm usually trying to come up with. Yeah. The dependencies. And it's not only dependencies. What you're also doing is when you come up with something like this, I call it the flight level architecture, you basically have an idea what boards you need to build and who needs to coordinate with whom kind of somehow makes sense. So without drawing it's a little bit difficult I guess. So from your experience, what is the hardest
Speaker 2:part of that process?
Speaker 3:The hardest part? Good question. So the hardest part is always the people. The hardest part is always the people. So I mean actual would be so easy if there wouldn't be any human beings around. Um, so it's, it's really uh, taking the people with you on the journey. That's the, that's definitely the hardest part because one thing, it might make sense that we need to manage all these dependencies and we need to have some standup meetings here and do retrospectives over there. This all might make sense,
Speaker 2:but if you don't have the people on the board, yeah, you're doomed kind of. And I think you mentioned that in the book that in any agile transformation there's going to be a certain human impact when you, when you, when you make a significant change to the way an organization works and thinks they're going to be some people who just simply do not adapt and yes, yes. And remove themselves. True. But yeah, I mean you have to unfold. What can you do? We were talking about dependencies and one of the things, and in fact just missed it, I apologize, but one of the criticisms I raced in the podcast was that this book doesn't address the problem of shared services precisely. Most of the dependencies that you were talking about, where it dependencies between product teams or teams working on the same product. What do you, what is your advice to an organization when the things that are preventing them from delivering more smoothly or faster are overloaded shared services?
Speaker 3:Yeah. So you didn't miss it. Um, but you know, I need material for the next book would be covered in the next book. Yeah, shared services is for sure a thing, especially when we're talking about organizational agility. So not on the agility in, in software development. In an organization you have tons of shared services like lawyers or marketing people, PR people and so on. So there's a lot of, yeah, she had services. It also depends on how huge organization is. But what I kinda like to do is I like to manage them on a flight or two system on the portfolio, flight level two system. So what we see in a portfolio flight level two system is that you see multiple products or services and they are basically all competing about the same. She had services, not the same people. Right? So if your organization is not too large, what you can do is you can come up with like avatars or magnets for your lawyers for instance. So let's say there are four lawyers in your organization and one lawyer can work on five or six cases in parallel. So there's quite a lot of waiting time in between. So let's say five cases and how many lies get a four, I guess. Yeah, so four times five. This means we have 20 magnets so we can place this 20 magnets on our flight double two portfolio board and I can no longer, or I can, I can, so if we need a lawyer, we need to take a decision right now. Right? So that's how we basically somehow make it visible that there are something like a bottleneck and then we can trigger a conversation. So shall we stop working on this case and start working on another case or should we finish one of these cases and then we start on the other one. But that's how I try to do it. Does somehow makes sense?
Speaker 2:Yes, absolutely. You were talking about this just uh, just last week and the concept of flight level to visualization and getting the right people into the room I think opens up so many possibilities. I was saying that what I frequently see as a solution in organizations as solution in air quotes is having some sort of a meeting in which the work on this shared services team has prioritized. So you, you're still getting the same amount of work through the pipeline, but the prior program workers going through first and what I have never seen happen before because I've never implemented a flight level two system, but I can imagine it happening. What I've never seen happen before is upstream decisions being made based on the capacity of a downstream shared service resource source. So yes, for example, if whatever wouldn't build the two products that both depend on the same backend system simultaneously because both of those product teams are going to be hitting the team that supports that system a lot. If we, if we stagger it than that team will become a bottle neck for those two products. So that sort of thing could really happen with uh, uh, flight level two system that works appropriately.
Speaker 3:But I guess that's one of the main purposes of these Flato two systems. So you get the right people in the room. And even so there's always two things you need to manage. So when this work already in flight and there are conflicts, we need to manage them, but we also need to manage it before we are dependencies before we actually start working on it. So usually if you try to align the work in your organization to the strategy, you have something like a strategy meeting where we basically come up with the, let's say business priorities for the next one or, or two months or three months. And then we usually do something like a dependency planning that we exactly come up with a question you just rose or the problem with just rose, can we actually deliver it? And if not, that needs to be some feedback loop to the prioritization. And this is all before we start even working on this stuff. And that's actually the main reason of flight of two systems to, to have this discussion before we start. But usually reality doesn't stick to our plan. So we need to have frequent meetings in front of the board. So that's, that's the second important thing was flexible to systems. You get all the people in front of the board, even marketing and the lawyers and the finance people to get a with it and whoever's in the organization and they basically talk about, yeah, your conflicts that are coming up, popping up.
Speaker 4:Oh, I have a question because at the beginning of our podcast, use the term business agility. And I was just so curious about your definition of business agility and the biggest misconception that you've heard so far.
Speaker 3:That's again, a very good one because I think the term business agility, I somehow tried to avoid it, but I'm not very good in avoiding it. But there's a reason why I want to avoid it because I think it's somehow already burned. So for me, business agility, really, so when I talk about agility, it's not about air child teams or agile it or add on marketing or edge or whatever. What I want to see is that the business, the entire organization is acting as a child on the market. And that's what I would call business agility. But what I see going on, uh, today is that we are applying the same logic like we did in software for software development teams now for business teams and now we call this business agility. Is means that don't know a procurement team needs to do a sprint planning and then they are doing a sprint and I'm like what is going on here? Doesn't make any sense. So that's why I'm a little bit cautious when when I talk about or tried to be cautious not talking about a business agility. This is exactly not business agility for me. So for me not each and every team needs to do an agile method in an organization and then we can call our enterprise or organization like we are our businesses, our child. I think that's totally wrong in my opinion. But that's what I see quite often happening out there. Okay. I'm satisfied. Yeah I even think that in some areas of the of the organization, it even, it even it hinders the organization or its a disadvantage if these teams are agile. So if you are somewhere in an area where you have really repetitive kind of work, it doesn't make any sense to spend effort in doing something like spring planning. So it might be much better if they are doing something like, I don't know, six sigma makes sense. Or if we are in, in other areas in organizations where we really know what's going on and we have the knowledge how to build something, we can do a project plan. I don't have a problem with it. So for me, and I think that's, that's the whole point behind business agility. The business needs to be action on the market and we need to pick the right methods in our organization to achieve this goal. And this doesn't mean that all teams needs to do don't our sprints or something like this. So yeah, something else.
Speaker 2:So one of the things I enjoyed about this book, it's, it's um, I like books that tell a story that I can put myself into. You know, one of, one of the lovely things about the goal as you read the book and you thought, I could be that guy. Those are that isn't that hard to do? When I had the same feeling when I was reading, rethinking agile, I was thinking the next time I get invited into a situation like this, I love just what I'm going to do. Because you're telling the story, you're telling a story about an experience that you actually had with a trouble, troubled agile transformation. Were there any good stories from that experience that you didn't include in the book?
Speaker 3:Good stories that I did not include in the book. Well actually I included quite a lot of stories so well in the beginning, you know I only presented the trend charts of the teams so and the, the channel Trent was that the teams were not improving. This is true. But the other thing is that we're actually teams where, yeah, where did basically they improved Dev velocity for instance, scrum team. So they deliver more, but still the project did not improve for the, how's it called? The time to market of the initiative where they were working on did not improve and then they were like[inaudible] works, you know, our team method works, we are better. But still the project didn't, uh, improve and or the initiative and they just didn't understand it, that this is totally two different kinds of things. And we really had a lot of discussions. You know, we did this ship building exercise and we discussed it for hours basically to get this message across so well in the pockets it's more like, it's not all, it's not everything to the detail, uh, that we've seen. So there were a lot of things going on in terms of building the awareness of, of how this all works and people were, they were somehow puzzle because it doesn't make, it didn't make any sense for them. So in the pocket it was more like, okay, I explained it, they got it and we changed it. But this is only a part of the story. So there was really, there were a lot of tears, sweat and tears, um, yeah, to get to this point more or less. So that's what I completely left out in the book. It's one thing if you hit them hard, it is hard. So yeah. So the book is more like, okay, that was a problem. Then the hero comes in, we fixed the problem kind of, and then everything is great in real life. There was more pain involved. I mean, pain, pain sounds negative, but there was more like, you know, it was more energy involved. Like okay, what is going on? And people didn't understand it and it was really like, oh wow. So yeah, when the goal is to not write more than 140 pages, you need to leave, leave out stuff.
Speaker 2:Mm hmm. I think uh, you were talking about having one agile team that was performing much better than they had been before. Having no impact whatsoever. I think the illustration on the cover of the book illustrates that. The reasons for that very well. I think one of the great takeaways from the book, I had this impression when I was reading about that and analogy of, you know, the scenario where you've got a string of, of firefighters passing buckets of water to put out a fire. If one of the firefighters in the middle can pass the buckets twice as fast, but the rest of the line is behaving exactly the same way. It doesn't actually change a thing. And this is one of the problems is plaguing so many organizations doing their agile transformations. So when you win, if you going in to do an agile transformation, presumably you will speak with the executives in the company. What is it that you're looking for? What kind of attitudes and beliefs or behaviors are you looking for an executives to give you an idea that an agile transformation could be successful in this environment?
Speaker 3:Yeah, so I tried to do is I really try to talk about outcomes because today at least that's my observation. So, but what did I know? Um, but today a lot is about passwords. We want Kanban, we want scrum, we want flight levels, we want safe, less whatever. And I'm like, I don't think that you want to have something like safe or less or camping or flight devils. What is the real problem we are trying to solve? So if we come to this point, we're really talking about this is the outcome that we want to achieve. And we even leave out passwords. Like Agile for me actually is a password that's a huge balloon of hop ear where everything, everybody can somehow protect something into this hot balloon of ear. And we are all talking about ed child, but everybody has a different understanding. For some people, agility means faster. For other people it means we need to hug each and every tree and another, uh, people things. Okay. Throughput goes up and everybody feels well, but what is it really? What is the outcome we want to achieve? I think that's, that's the most important thing. And we need to have something like a commitment that we are working on it and working on it does not mean that we are implementing frameworks working on, on it where, um, yeah, for me it's like that we are allowed to think frameworks are awesome because there's some ideas in there, but we need to apply it, uh, for the context so that we actually changed, um, yeah. Or solve the problem and we want to solve, this is the very first thing I tried to work on. So burn of these um, methods and uh, you know, we should bingo words kind of,
Speaker 2:well speaking of, of methods and Bingo words, I've only read two of the books so far. I'll admit I read, I love to come and change leadership. I thought it was one of the most comprehensive books written on combined at the time that it came out. One that was what, like about five years ago,
Speaker 3:I think the English version was 2015 or so and the Turman washing was 2012 already. Okay. Well I didn't read the German version. Yeah.
Speaker 2:So whenever the English version back in 2015, that was booked that you would already written three years earlier. So it's been awhile now. And I noticed that that book was just flipping through it again recently. It has a very strong team. Could you tell me how you feel you or your understanding of Kanban has evolved between your last book and we thinking agile?
Speaker 3:Well, if we, so Kevin, change leadership. So the English version was 15. The Turman ration was 2012. This means we are talking about experiences. I made something between 2009 to 2011 and that's quite a long time ago. Actually. We are talking about 10 years and um, yeah, roughly 10 years back I was also more into the team camp and new there. There is something like management in an organization of course, and they are important and we need to win them over, but I didn't have any solutions to, uh, so what does this mean if management is somehow child. So I think this thinking has definitely evolved in the last 10 years. From my side. I think I have some really good solutions, uh, for management. I'm not sure if this is still camp then that's the other thing. That's also the reason why, um, somehow call this flight levels because that's somehow, I don't think it has a lot to do with this campaign. If we take a look in camp and we have agendas, we have values, we have service delivery, we have certain roles. And so yeah, my, my thinking about Ken, Ben. So for me there was more stuff added to it like back to in the last 10 years and I basically went the other direction. I took stuff out of it kind of. So for me I always tried to simplify stuff because I think simplifying is really difficult or yeah, having a simple messages is quite difficult actually. I always tried to remove stuff and I think in Tampa there was more stuff at it. I can see that. So you're focused more on fight levels right now. Would have noticed that your company offers flight level training workshops. I'm curious who is attending those kind of workshops? What is it that you teach them to do? Well that that's um, so I think the, the more far away I am from, from Germany, Austria, Switzerland, this, this, this kind of area, um, the more different audiences. So in the beginning of the year had a flight over training in Thailand and they were actually had to flood level trainings in Thailand and it was completely back to c level managers. And the, this was really surprised because usually a, so at least here in Germany, Austria, Switzerland, sea level usually does not show up in, in public training classes. It probably would get them in, in house classes. But in public training classes, that's not the usual case. But it was actually quite nice because they were like, okay, the feedback was really nice. So they were like, okay, now I know what my role is. I went to camp and training, I went to scrum training, I did quite a lot of training. And as a I'm like, yes, that's good stuff, but what is my role in this? And uh, when the attendant, the flight level training, they were like, okay, now it makes sense. At least that was the feedback. They were like, okay, there's more than only one method and flight levels. This somehow Igloo or something like this, which somehow views the air channel island in an organization together and aligns it to the strategy. So that's something where do seeing quite a lot of, um, organizations, um, in particular cases, it makes sense to do scrum on a team level. In other cases make sense to do a campaign over there and maybe less over there and the little bit of safe over there. But everything needs to be somehow aligned to the strategy. And I think that's where a flight levels comes in where you basically somehow blue all these agile islands together and align it to the strategy. And I think that's one of the main tasks for four managers. I think the best description of agile management I've ever heard. Thank you. That sounds cool. We spoke about your previous book now about your current book. So, well we'll be our upcoming book. MM, well I'm, I'm really having my, I'm really thinking of one that I want to start in, uh, in the summer, but I'm not sure because the natural thing would be, um, to dig deeper, like more or less part two of rethinking our child. And uh, so the first thing is more like a, the problem statement and we somehow address, okay, this could be some solutions, but we didn't go deep into it. So, um, that's basically what we are doing in the flight was training. So it would make sense basically to write a book like what we are doing in the flight level training, which is basically nothing else. Like how can we implement all these ideas, uh, in rethinking our child. So this would be the idea for, uh, for the next book. But yeah. Let's see. But you haven't started yet. Well, it's always ending up writing a book. Writing a book is a process I probably already started then a year ago was this book. Um, but it's, it's not only writing, so for me the, the, the storyline is, is more important than the writing process. Um, I can get help in the writing process. People can support me and people can read this stuff and can, can, yeah, it can help me with the writing process. But I think getting the story straight, uh, is quite difficult. And I'm always thinking of how to, how to tell the story. So I think I'm already working on the next book for a year, but maybe it's, yeah, it's, it's, it's ready to put on paper in summer. I'm not sure. Let's see.
Speaker 2:So you started this off by saying it was interesting to hear people just talking about your book, hearing, hearing from your target audience, really, uh, just talking about their experience with the book. What is it that you would want? What is it that you hope that your readers take away after reading, rethinking agile?
Speaker 3:I think one really big hope is that readers take away that you are really allowed to think. So there is no air child silver bullet or whatever out there and there are no recipes, which if you just apply the recipe right, everything will be fine. So I hope that the main takeaway is that people somehow think in systems, try to think in more global optimization kind of way. And there is no silver bullet that you need to come up with your own solution, which basically solves your problem. He inspired for with all the frameworks and methods out there and all these recipes, that's great and there's great stuff in it, but you need to apply the right methods in the right part of your organization if this message gets across. Yeah, this would be awesome. Actually.
Speaker 2:Fabulous. Well, I think you did a great job of communicating that message. Nice. I want to thank you for coming here and being with us today. It's always a pleasure chatting with you. Nice. And uh, thank you so much for the good work that you're doing for the community. Yes, thank you. Thanks for having me. Always nice talking to you guys. Alright, that was great. Bye Bye. Bye Bye. So join us for our next podcast when we will be talking about Dominica Degrandis' book Making Work Visible. Thank you and goodbye.