Transcript: Joe Krebs 0:10 Agile FM radio for the Agile community, www agile.fm. Thank you for tuning in to another episode of Agile FM today, I have a guest here with me. Probably, I would say probably everybody in the Agile community knows probably everybody has a book. In their hands. Every facilitator has a book into hands from Keith McCandless from the liberating structures is what is today with me. And we're going to talk about liberating structures in the book. But we also want to talk about liberating structures beyond the book. But before we get started, welcome to the podcast Keith.Keith McCandless 0:53 Thanks, Joe. Excited to be here.Joe Krebs 0:55 That is awesome. Yeah, I have to say this book was written also by Henry Lipmanowicz . So this co authored this book, anybody knows the surprising power of liberating structures? I think you guys have sold so many books. I think you're in direct competition with Harry Potter. Is that?Keith McCandless 1:16 You? I like your dreaminess, Joe. There are very few books. I mean, yeah, it's sold. Well, it has it has in a in an era when people I'm not sure they read books anymore. ButJoe Krebs 1:30 yeah, that was 2014. And the reason I'm saying that is like everywhere I go, when I talk to people, not only the word liberating structures, everybody has an immediate reaction to it positive, obviously. But also people actually have the book and they're using the liberating structures. And as obviously, that was the that was the intent. So first and foremost, thank you for making these 33 patterns available to the community. I think they really changed the way of how people like Scrum Masters agile culture is probably listening to an episode here on agile FM. But actually more than that facilitators around the world in any kind of way, or shape doesn't have to be agile would really benefit from that. So thanks for doing this guys. Very good work.Keith McCandless 2:18 You're You're welcome. And I love it that you use the word patterns. Because they're, they're simpler than a process. And they're more fun than an icebreaker. Yes, right. So what is that? Where did they even come from? Like, I think that's partly why they've spread a bit is they? They're not cumbersome, like a process. But they're as much serious fun as you can have. So that was a hope we had, although I've got to say the spread of the work? Well, first and foremost started with Agile people. It really did. First ones to catch on to it, and it keeps spreading,Joe Krebs 3:09 keep spreading, keep spreading. Yeah, I'm not I'm not surprised somebody from the Agile community that started they are really to catch on, right? Because of obviously autonomous teams, and how do we get creative ideas out on teams? So it's, I think it's a great, great connection, I want to take you just for a moment here to the time before 2014, before you guys released the book, obviously, you have been in this field of learning and education and facilitation for decades right? So how did this all if you just want to take the listeners here through the journey of you know, obviously we're holding a book in their hands, but why publishing it? And what was what was the what was the trigger of saying like, let's let's write about this? And more importantly, why 33?Keith McCandless 3:59 Yeah. Well, two things were going on. I was working in organizations, as a consultant, and trying to solve problems that weren't being solved. And they were kind of fundamental things. Seemingly, we hit limits to the way to the way everybody organized. And partly it was the relationship between the people doing the work their managers and their bosses and their executives is a fundamental limit. And so I had a variety of clients. And when I met Henry, we started to share clients and develop field work to address really the limits of what current organizing theory and practice was. Right and this was 20 years ago. So we did 10 years of work in the field before we published, of testing these things, trying to get them as simple the minimum specified in each one that we could. And we really didn't know, we were doing research for a book. The only reason there's a book is our clients told us, you've got to kept telling us, you've got to write it, you got to write it down. Yeah. And so there were a bunch of flimsy work, workbooks, in different languages were working internationally. And so we had a flimsy workbook. Number one in Brazil, one of the places we started, and then that was Portuguese. And then there was a Spanish one, and then there was a French one. And so the need the clients asking for, like, write it down, and our, whatever perfectionist tendencies we had. We didn't like the quality of the stuff we were doing, we had to slowly get rid of all of the pieces that weren't critical to making the structures work. And eventually, that resulted in in us finding a good editor. And neither of us are natural mean, we had to work on the writing part. But it got published. Yeah.Joe Krebs 6:27 We are very happy about this. When I saw the, when I saw the book, obviously, when it was published back then, there was this one moment I had, and, you know, take it down a story of mine quick, where I knew the book was extremely powerful. Because until the book was published, I used in my own trainings and working with clients that there was this one time, it's like, you know, where I moved groups from one flip chart to the next flip chart, and they collaborated this way. And there was always an interesting activity of people were like, it took me a little time to explain it, and people got into it. But then the energy level in the room increased significantly every time I did this. And one time, there was a group of executives and those executives, they were stunned. They were like, wow, what is happening? This is so engaging. And when I saw your book, it was the shift and share. I you know, I didn't had a name. And when I saw that, I was like, this is powerful. I need to know the other 32. Because I knew there was so much power in so how did you guys decide on on those 33? What is that? Were you really? I mean, I could imagine at that time, he could have said it could have been 34? It could have been 35? Why did you draw the line? Did you feel like this was enough of a catalog to say let's go live?Keith McCandless 7:47 Well, it represents the repertoire of our, of our joint practice. So those were things that we regularly used. And we're confident anybody could generate, surprisingly reliable results. So reliably, you're gonna get delightful surprises, like that group of leaders who are going like, where did this energy come from? . Well, well, that happens every time with every each of those 33 There will be a, a surprising amount of momentum and insight and action generated. And so those were the ones we were confident about that addressed the concerns of I'm gonna say mostly big organizations that operated across borders. And once we published realized, Oh, my, there's lots of other domains and contexts in which people are operating that they could use the same approaches. But the limits to the repertoire and our decisions about it was what did we know how to do? And what did we actually feel test to the point where it could reliably surprise? .Keith McCandless 9:15 that was kind of the test, the other one Joe, that we mentioned a little bit earlier is Is it close to being simple enough? Easy to learn that after one experience that maybe someone else led as a facilitator or an Agile coach or a scrum master, if they didn't let it once? Could somebody in that group who never thought of themselves in that way, as a facilitator, could pick it up and use it in their local context? Right, so if that didn't if that wasn't possible, it started to drop off the list of the repertoire.Joe Krebs 9:57 Yeah, yeah, definitely. It's a it's very powerful. and it makes it so universally applicable, right? Because it is something that is not only something specific for financial facilitation, let's say in a financial sector or in something else, it's something for everyone right to be shared and across the board. That's, that is super insightful. This journey doesn't end there. Right after those 33 Only because the book is published, the movement is continuing. And I do want to say before we explore some of those techniques, somebody who is possibly I cannot even imagine this but not familiar with liberating structures. Gone are the days where people sit around the table and somebody flips PowerPoint slides. Right? So I think that is that is the idea behind this, like, how can we survive in a creative, innovative world that changes frequently without sourcing the the energy and the opinions for many people at the same time. So I think what you guys are doing has a real price tag next to it for organizations.Keith McCandless 11:04 If only if only Joe, if only those presentations were were done with if only everybody's intelligence was unleashed, if your own and then you made it, everything you did unleashed everybody else's around you. If only that was true. That's not my experience. And so there's a lot more to do. Yeah. And I think the pandemic opens some doors for people, but also closed quite a few. In regard to how open can we make this? How flexible can we be about the future so that all of the worry about the stability of the organization can either close doors or open doors. And I've seen more extreme versions of both over the last few years, more openness to including every voice in shaping what happens next. That's basically what liberating structures do they make it practical, to literally include every voice in shaping your next step? And that's scares the hell out of some people. And and it's new territory. So I'm, I know that we need to do it like you I feel the passion for doing it now and everybody should be doing and why aren't they doing it? I feel that but I also know it's a it's a transition that's going to take take a while, a while longer than I want to wait. ButJoe Krebs 12:52 what's interesting about the leader example, some, you know, I mentioned earlier, I've noticed with liberating structures is that leaders and executives, they like the energy, the liberating structures are producing, but they're not part of the activity itself, which is very often interesting, right? So they're more like bystanders or observers or they, they, you know, they they support liberating structures, obviously, or not, you know, maybe not even know about. Okay, great resolves the teams are producing with these techniques, but they're not part of it. So I myself, like in a training environment, I do have the opportunity to bring them in through a training course. But I'm not sure how many, you know, facilitations take place on leadership. Now, I do have to say my view is agile. So maybe outside of the Agile space, there is more of that. But I that's that's one of the shortcomings I have seen that it hasn't really broken through the to the entire organization is more limited to the teams. Is that something you you observe as well.Keith McCandless 13:55 But well, I'm not always the nicest person. Usually I try. And I don't blame leaders for the situation. But they've gotten themselves the way organizing has been taught and learned. They're busy people, they want things simplified. And so when I'm not nice, we will have just and I often work with leadership groups. And the first step is always let's get all the other people that we possibly can that usually are not in the strategic planning session. Let's say that's what it is. And we will have just mapped I know this is audio but I'm going to move my hands anyway. On the Eco cycle, the whole portfolio of activities and maybe even the relation the strategic relationships, where are they in a birth maturity? Great of this pretty, you know, you got to get that relationship creatively destroyed or or nascent, you know, just just stating not formed yet. We've got the whole thing up there. And we may also have done a critical uncertainties where we look at the four surprisingly, different futures. And then we look again at this portfolio and where all where we are strategically. And I will, I have never been in a situation where that wasn't very new information for all the organizational leaders for the first time, they've seen where all their stuff is. And they see that the the future operating environments for the evolution or adaptability of those things? They haven't really thought about it. Yeah, how are we going to operate our portfolio. In a future that's not predictable, but you know, within a range, it's not predictable. And so because they've been isolated from all the work and where all the work is done, that's a confusing moment. And what I like to do is bring them all in front of the visual chart, you know, here's the Eco cycle, and here's the critical uncertainties we face and go, you knew that right? And, like, I, and they'll kind of look through the site or look down, and, you know, we're just all have a good laugh. Because that's, that's something that arises out of doing the work, and they've never had the opportunity to do the work, because they haven't included everybody. And they don't know how, yeah, as. And so for me, the perspective over time, is we're learning how to include more voices to shape the future in a very volatile. environment. And that's gonna, you know, I wish we all knew how to do that already. But we're, we don't, and we're learning how to do it. And I include myself in there, how do you do that in a way that it gets repeated by everybody in the organization continuously. So that the goals and strategies are being adapted.Joe Krebs 17:30 This must be an interesting finding for you, like just based on your example, right? When you do work with a leadership team, and in terms of trust, right, if somebody does not know that, right, and the technique, eco cycle, why brought this to surface, and all of a sudden is like, this is like a vulnerable point for for a person, or as a group, right. But each individual, it requires a lot of trust, it's like, I did not know that we did not know that as a group. So on a leadership that shakes things up a little bit for for the group, right? It's like, there's a lot of things we do not know, when we would have gone down that path. And, you know, so that must be a very powerful moment to to be in for you as a facilitator.Keith McCandless 18:15 Well, I hope, you know, when you're a consultant, you're there for a while you develop trust with the client, and I do my best to be loving and provocative. At the same time, and that's support for the leader. Ah, they need it. They needed that's when they needed the most and that it's just too easy to blame them for something that isn't happening. But structurally, because attention to the way in which we work, the PowerPoint presentation, the I'm the boss, update me, tell me what I want to know about what's happening, that doesn't work, brainstorming, let's get a few people who are smart and have them figured out those or, or just open it up and have anybody, you know, fight it out over what it should be. Those all generate disappointing results. So until liberating structures are routinely routinely used. And the first people I've seen it, make it sort of routine are Scrum Masters, you know, in with their teams, they have some autonomy over there teams, they can put in regular practice some of the structures that make it possible to some of the time, shape next steps with every voice. Yeah,Joe Krebs 19:42 so it's interesting, right? And some of those 33 patterns are I would call them in not in a in a powerful way, but just in terms of executing them like a 1,2,4,all relatively brief, quick, powerful technique. I use it all the time. But some others like the Eco cycle, or the open space, you know, conversation, these are longer or more elaborate in terms of time commitment, right? It's still the same powerful tool. But it's interesting also, that these liberating structures are tied together, they're not like a single thing where you can use them together can build like a strategy of facilitation, depending on your needs. So so they defined together so it's for everybody who's, again, not familiar with this work is some of those techniques are timewise very brief, like my shifting share too the brief, or it could be a brief technique. But some are, like open space could be three days. SoKeith McCandless 20:43 yeah. The good news is that the 33, and the ones developed since we wrote the book, share a DNA. So there's five design elements that are part of every one. So once you learn a few of them, you understand a micro structure that distributes control, to everybody, to the people closest to the work. So once you've, you have a handful in your personal repertoire, the rest aren't that complicated. And even the most like the ones you mentioned, that take longer, eco cycle, if you've seen somebody use it, it's pretty easy to copy what they've done. So I tell new users, new people who are going to be introducing them, just know, don't get nervous, but the people you work with, they'll copy exactly what you do. So don't screw up. They don't, you know, because that's what they know its power, it's gonna be powerful. It's gonna be you're gonna get a new view, let's say it's eco cycle, you're gonna get a fresh dynamic view of where all of your activities all of your could be your, your products, or your, you know, all of the software you're developing, which which ones are, are already productive, which ones are just ideas, gestating what which ones do you need to put an end to because they're stale in there. So know that it will be powerful, and do your best when you try them? To do a good job with them. And some I can say that and then say they're also forgiving, right? You read the book and started doing 1,2,4 All? All probably Are you already did shift and share? Yeah. Now you had a little more detail maybe about something about how it could be done. And you just did it? Yep. So I recommend once you have a few under your belt, one of the things I think we did, added to the world was the the micro structure, what is the structure of distributed control? What are the five design elements and the fact that the whole repertoire shares that makes them different than individual methods that you can tap makes them a repertory interrelated repertoire that helps you solve complex problems? Yeah.Joe Krebs 23:29 Yeah. So you mentioned earlier that the time to the release of the book, there was like this 10 year roughly time period where you guys, you know, filtered the material selected and defined, and most importantly, wrote about it. Now, since the release. There's another 10 year period right now, almost what we're looking at a similar time period. And you already mentioned, there are some liberating structures. They came after the book was published. So they are currently in the application and the testing, I don't know what kind of terms you guys are using, but basically in the field and being applied. And basically some of them will make the next book the website, whatever is in the, in the making a two things that stood out like one of them is Mad Tea. Right? I think that was one. So just to give the listeners here, a little bit of sense, this is one that goes beyond the 33 that is already some field tested right now. There's people that can engage with you in a Slack community, submit their own liberating structures, I myself will probably submit something to you guys, I have an idea. And there is the strategy not working and not with a KNOT. Tell us a little bit about maybe this one. I think it relates to Scrum Masters and we just mentioned how Scrum Masters relate very well to the liberating structures. So this might be a really good one beyond the book. Tell us a little bit about the strategy knot working and how could this be useful for Scrum Masters and agile coaches?Keith McCandless 25:06 Yeah, so in this 10 year period, in between one thing, one liberating structure that really appealed to Scrum Masters was called purpose to purpose to practice. And there's five elements, and it's very much related to any project. So for, for me, if I have people proposing things to do that, or projects, I need them to answer the five questions and purpose to practice. So that's purpose, principles, participants, structure, and then what are you going to do practice? And if they can articulate that? Okay. You've thought it through? That's good. That's perfect for a project. But one of the limits was, okay, well, what about how all the projects fit together? What about the larger strategic context in which you're operating? Which is bigger than, and so strategy knot working? Includes it's kind of like a purpose to practice where different liberating structures are tapped. It also starts with purpose, but immediately goes to principles, like what are all the things we've learned from practice that we must never do again? Or always do? And then there's another second section that's different about wicked questions. What's the impossible truths? What two things are so true about the complex situation we face? That are undeniable, but we have to address both of them to make progress. Like how can we be an integrated organization and have autonomy in each part? How can we be a whole and a part? It's both integrated and autonomous? Oh, wow. And any strategy that you can get autonomy and integrated integration, that's a really that's a strategy is, is well worth it. And so the strategy knot working isn't a lot more elaborate, detailed way of formulating strategy beyond projects. And that became clear in the 10 year period in between. And so far, we've been doing in LS slack. And we've been doing prototyping, different people in very different domains have been trying it out. And there's some real challenging challenges to making that simple enough. So it hasn't. It's progressed, a lot of people are using it now. But it's not close to being in the repertoire in the next book. But it's well, it's worth worth it. But it doesn't fit my my, the need for easily copied by a new user.Joe Krebs 28:20 Yeah. But there are others in in in the field right now as well. So this is not only one right. So there are several things going on right now. So yeah, you're back into selection process, like which one would make good candidate for? For the next, for the next book, I think you said which was kind of a reveal,Keith McCandless 28:39 not promising. Next book. As an author, I think, you know, you don't want to make promises, because books are hard. Books are hard.Joe Krebs 28:51 How did because your book release was 2014, before the pandemic. And obviously, that was not something you guys could have foreseen. That was coming in 2019? Was it 2019? And how did that change? The liberating structures like movement or your view on the liberating structures? Because I mean, there were lots of facilitators and trainers were looking at this. It's like, well, usually I will do a 1,2,4,all in my training right now. But now, how do I do this online? Or how do I work with a class? It's distributed and remote, and creativity sparked everywhere left and right, which is great. But how do you feel about that? And what were the insights like very specific to the pandemic and the impact on the liberating structures?Keith McCandless 29:41 Well, I'm going to mention two things. One is the very first word when Henry and I felt we needed to prove liberating structures were productive was on superbugs and hospitals. I don't know if you know that but we we really hard problem But the answers needed to come in a distributed way from everyone. There were there were not single answers, we knew a few things that were effective. But really, you had to include every voice to solve the problem. And we're able to do great things. So the pandemic, first of all, was, Oh, my liberating structures are a great fit. We need distributed solutions, and didn't really get them for a variety of reasons. So that was hard. But within a month, I'd say on primarily on Slack, but the global liberating structures community, we who are agile folks, but academic, you name it, um, everybody was in there. The entire repertoire was converted to online, functional online, you know, things that could work that were not face to face that were great. Mostly zoom, but multiple platforms, everybody was trying things and sharing their information. And, and so for me, it was breathtaking to see what a large, diverse community with loose connections to one another very loose, could instantly adapt the whole repertoire. I mean, 98% of the repertoire got adapted. And then the other big change the pandemic, because it was online all of a sudden accessibility like, Okay, you're talking about, including every voice? Hmm. Well, a lot more voices could show up and a lot more attention to accessibility. The online platforms got refined, well, what do you mean, what if people can't hear? What if they can't see what if all of these things deepened? The degree to which liberating structures could include all or at least many more voices in shaping what happens next? So that was it opened new communities, and it opened the depth of what, including all voices means for me? Yeah, at same time in the US, you're in the US, like, social justice became pretty big deal. So people who have four generation has been excluded. Were showing up. We could reach them there, they could reach us more easily. So it's a frothy, exciting mix, Joe, of things that happened, and I'm just touching on a couple. And probably the last thing is the lot losses associated with the pandemic, what did you lose as a result of the pandemic? And so quite a bit more sensitivity to attention to and sensitivity to what has been lost? And how people can show up when they're experiencing some amount of grief or, or going through a transition? And so how do you do that and get the work? How do you attend to people's basic needs? And get some things done? Yeah. So that's a huge set of insights associated with that. So that's more than an Atmore. It was a good question. So I gave you a rambling answer.Joe Krebs 33:39 Surprising power, right?Keith McCandless 33:42 It's, I think I'm the first one surprised every time. Yeah, I think. But yeah, good.Joe Krebs 33:50 So the thing is, I the reason I was asking like in the book, there's a lot of photography, from like actual events, examples on the website liberating structures, you see an actual photograph of the the liberating structure in action. And they are in person, right. So when you see even on the photos, you get the energy. And sometimes there is not a direct translation, but a work around, or it might work or with a different tool. And the creativity that came out of the community, as you said, is obviously fantastic to you know, to take the book and say like, Hey, this works in person, but now we have ways of doing this online. This is really, there wasn't really a very good conversation here Keith that I really really loved. Talking about liberating structures with you and thankful you took the time. We talked a little bit about the past. We talked a little bit about the book. And most importantly, we talked a little bit about the future of what's happening next people can get in touch with you through liberatingstructures.com If they want to submit or go to that slack channel and you know we talked about and yeah, I just I think Everybody's hungry for part two. And there's more to come. And I think, you know, the community can take more. No worries.Keith McCandless 35:10 Well, I've got to tell you, I'm waiting. I'm putting on my schedule. When When will Joe send his idea for the new liberating structure? Soon? Yeah. Yeah. No, it'sJoe Krebs 35:27 it's an open invitation for submitting ideas. I did not know. So I will take advantage of that and share something and and see if it's, if it's something that is applicable to a broader domain.Keith McCandless 35:41 Yeah. Good. Thank you. Yeah. And I appreciate the invitation to join you on the Convo Yeah, delightful, and it's nice to get to know you better.Joe Krebs 35:53 Thank you for listening to Agile FM, the radio for the Agile community. I'm your host Joe Krebs. If you're interested in more programming and additional podcasts, please go to www agile.fm. Talk to you soon.Joe Krebs 30:38 Thank you for listening to Agile FM, the radio for the Agile community. I'm your host Joe Krebs. If you're interested in more programming and additional podcasts, please go to www.agile.fm. Talk to you soon.

Transcript: Joe Krebs 0:10 Agile FM radio for the Agile community, www agile.fm. Welcome thanks for tuning in to another episode of agile FM today I have Jacopo Romei if I pronounced that correctly with me, based out of Torino in Italy. And he is my guest today got to speak about a topic today. It's called extreme contracts he published about this or long, long time ago in Italian. And just recently in 2023, he also finished his English version of his book, extreme contracts. So that's all available. He is also available at his domain name, Jacopo Romei.com. And we will also spell that out on the Show page. So people can just click on the website, as well as the three chapters of the book that will be available on the on the show page. But first and foremost, welcome to the podcast.Jacopo Romei 1:15 Ciao. Hi, how are you?Joe Krebs 1:18 I'm doing great. How are you?Jacopo Romei 1:21 I'm quite good, quite good. Just a reference. My name is can be pronounced your from Germany and you can pronounce it very easily. Jacobo, the J is Ja!Joe Krebs 1:31 Yah, cool. Boy, it is okay. Thank you. Thanks for clarifying. And it is important, right? So sorry about that. Extreme contracts is a word extreme in it. People in the Agile community familiar with extreme programming, maybe the first thing that would stand out is the word extreme. It's like, how does this relate? Why is it extreme? And why contracts? What's so special about contracts, I picked up a YouTube talk from you about extreme contracts, you're very passionate about contracting, work, and we just want to touch base on on that topic. So what's so different about extreme contracts versus regular contracts? Jacopo Romei 2:10 So, u m, I've been a developer since 1996. And I've been an entrepreneur in IT. And then along the years, I shifted to where the broader range of knowledge work. Okay, so let's not to get too much into the details of my job. But and what I noticed when I was doing my intrapreneurial experience is that the commonly used contracts, were somehow capping the maximum performance of my companies, organizations and teams, and even I didn't do as an individual. And so I started experimenting with different and non ordinary ways to negotiate my agreements. And so I mean, I just asked myself, well, what if I could shape a contract from scratch the way I really wanted it to work and support my collaborations with my customers and providers. After a few years experimenting, I started in 2010. And then I realized that there were common principles among the most successful contracts and agreements that I made. And so since I was a very, I still am a very huge fan of Ken Beck's work, Extreme Programming Explained. Actually, I just decided to, to think in somehow in similar analogous terms, so basically, what the word extreme and extreme programming means, what if we bring everything that works every principle and every practice that seems to work? To the extreme? So what if we go from back in the time it was like from two years releases to one month releases? So what if we bring them to one weekly releases or daily releases? Okay, what, what if we go from one to 10? If we go to 11? Right, so I thought the same with negotiating contracts for digital work. And it worked, actually, after a few experiments that, that of the building upon I decided to, I needed a brand actually, I needed a name to, to name the, the group of principals. And so I decided to go for extreme contracts, who was actually that's what they are.Joe Krebs 4:31 Yeah. And we want to definitely explore maybe one or two of those principles, if it see how far we're getting. But one thing that really stood out in your talk about extreme contracts in the first place, I think that was very deep as contracts are because there there because of a lack of trust.Jacopo Romei 4:49 Yeah. I mean, I mean, after so many years, I still strongly strongly believe it. So basically, so what what What's the reasoning behind contract? So, we have to start working together. And we have to know whether you will be delivering you will deliver if you have to know whether our pay or not. So we have doubts, okay, we have fears, we are afraid that we will not be behaving correctly, right. And this fear, the fear of someone else not behaving correctly is called lack of trust. Okay, there is another name. And so contracts are basically a way to surrogate that trust into a piece of paper back in time or in an in an email or in a blockchain based device. And I don't want to get into the smart contracting part, it's not the topic for today. But contracts are a way by which we substitute trust with something that we hope will be enforceable in case things go wrong. And what I noticed along the years is that everybody everyone was had works with two groups of people, there is a bigger group of people we trust, and with which we don't need to send formal papers to sign agreements to be formal and discuss a lot the thing that we are going to do together, and there is another small group, usually made of new leads, that are asking us to, for long conversations, long calls, long video conferences, long email, much much information going back and forth. And actually, these two groups are also different for a long another dimension revenue. And actually, the most of our revenues come from the people we trust. And by the by which we are trusted. And I'm in. So I decided to create a set of principles, I decided to experiment with contracts, as I was saying before, to optimize the time, we require it it is required to build the trust that we need to go to shift the our leads from the first group, sorry, from the second group to the first one. So basically, how fast rather than optimizing contracts for failure recovery, so basically optimizing the contract for how well they will be protecting us in a court. So I prefer the contracts to be creating dynamics by which we go very fast to trust in each other. And in the end, eventually, maybe not even needing the contract. Joe Krebs 7:40 So this is why so this is very interesting. You're not saying that extreme contracts are no contracts at all anymore. Jacopo Romei 7:45 No. Joe Krebs 7:46 that's not what we're saying. Right? What you're saying it's, it's more about, like putting the right content together. And there was another thing that stood out in your work is that a waterfall agreement will never work for non waterfall process.Jacopo Romei 8:03 So I started carrying about it was 2003 the time in May, I started coding my first unit test. Okay, so I got into that. That's the day I I like to think as the my beginning in the Agile world, okay, cool. But after a few years, I realized that with my teams, or other teams, I even owned, we were we were going on discussing again, and again, the way we could improve our practices, our deployments, our bug tracking, our testing, and blah, blah. So all these technical end, even sometimes, even a bit. management practices, okay, like the stand up meeting, or the retrospectives and blah, blah, blah, but only know, every time in the end, we were required, required to deliver a fixed scope, with a fixed budget with a given quality that usually was not, there was never question which is absurd. And in a given then set deadline. And I mean, in the mean, thinking, I'm taught to think about the root causes of the problems. And when I investigated these problems, I ended up having often a problem with the contract with agreement with the expectations of the customer. And so I decided to fix that root cause, despite we can read in the Agile Manifesto that we should pray for collaboration rather than that rather than contract negotiation. But still, if contract negotiation is the roadblock for a proper collaboration, still, we have to fix thatJoe Krebs 9:45 right the scope, right? So when we're talking about scope off of any kind of effort, but isn't that like also based on your experience? Like I can only speak for myself here when working with clients? Isn't it also like a dilemma of business agility that we have have many flourishing product and IT organizations using agile and we have a very traditional procurement department. And when you work within these constraints, I mean legally bound, it is a legal document, you're signing it, and you're adhering to certain sections within your document. And if they are screaming waterfall, it is it is very hard to work this way. Because you do need to deliver, I would assume, right? You cannot just say like I signed a contract or now we'll work Agile is like it the contract itself might be in your way. But what's your experience with that?Jacopo Romei 10:31 I mean, our experience is probably quite common, I agree with you, usually Procurement Offices are a roadblock in the true agility of the of any development experience. Still, okay, so on one side, if I if I were the one who owns the company, the organization, the one who basically paid those procurement officers to, to, to provide for a better for a good selection of providers, I would be worried because actually, we are we have a part of an organization which is somehow hindering the performance of the of the overall performance of the organization they belong to. So if someone owning procurement, or paying for a procurement officers in Now in this podcast, please, please, please, please question their work. Because actually, it's absurd that the strategy of a company gets set by a part of the organization rather than from the, from the organization itself. Okay. On the on the other hand, from from the provider point of view, I think we have a few things to try. First, there is a chance not that I will start from the most radical, just to say that it's not the only one. Okay, so I want to get rid of the most radical approach, which is there. It's a it's an option, which is not working for corporation or for bad procurement officers. But that's, I mean, that's too easy. Someone I know, does it and they're thriving. So it's possible, it's doable, and we can all we could all agree to starve procurement offices, the way that procurement officers around the world, but I mean, this is not really stick. I'm pretty aware of it of this. On the other. Second option that we have is there is one principle among the extreme contracts principle, which is called chaos in small doses, okay. And one thing that I cared so much along these years was to craft principles that could be somehow picked up cherry picked and adapted to our context, so that everybody, in their own context might find a solution to improve their negotiation their agreement. In the procurement department space, one thing that I that I learned to use was the principle called chaos in small doses models, which basically mean being shipped crafting agreements that are short in time, even keeping all other vital variables intact. So basically, considering all the other details the same, we could just shorten the amount of time, money and basically risk that we are exposing ourselves to, and work with those procurement officers with traditional rules in a smaller in a smaller time and space. Someone might argue well, but that's very inefficient, you have to renegotiate every time and you have to negotiate quite often. On the other hand, in my experience, usually the procurement procurement practices that we hate are usually meant to scale in a repetition quite well, sexually, they have somehow Taylorist legacy Okay, heritage. So usually after the first time after the kickoff after the beginning, repeating a collaboration with a procurement officers that have already that has already met you, it's quite easier and you can renew the agreement quite easily. If you have a good agreement, if you have a strong bond with the real actual buyer within the organization, usually at that point, the second the third, the fourth collaboration, the procurement office will not be a problem anymore.Joe Krebs 14:46 Yeah. The very interesting that there would also be trust building I would assume starting in such small batches wide. You know, you go through a very small agreement, you get to know each other you work together. You're building a relationship with a procurement. And what's also fascinating about extreme contracts is that you really, you're highlighting already. I mean, we're in the Agile community, we're focusing on value, right? So it's all about value to be produced. And I think it's fascinating right now. It's, it's June 2023. Many people go back to work or have, you know, arrangements where they work certain hours at home, and it's more flexible since COVID. The workplace and even those things were like defined in the past, right? You will be having working hours and Monday to Friday. And in all of those things, and it is really, I think, what we're noticing when is it's a perfect example, it's about value, right? Where do you where do you produce the most value? Is it? Is it in your office? Is it in your environment? Or is it? Is it on the train? Or is it on a plane? Or is it at home? You know, where? Where can you produce the value, and I think if you are focusing on value, and it's one of your statements here is in you are actually free to focus on all of those things you would like to do like refactoring or unit testing, right? Because they're not, they're not part of of the contract anymore? You say you're focusing on value, but you're not focusing on the actual tasks to be performed? Faster? Yeah. Do you want to, you want to give a little context of why you came to that conclusion, which I think is great.Jacopo Romei 16:21 Okay, so once, three things First, the usually, professionals are not aware of the value they create. So this is a main topic we could discuss about only this topic for like hours and hours, and we won't, but I mean, the point is, I usually when I ask audiences in conferences, like hey, what do you sell code? And actually, it's amazing, because actually, if I, I mean, Joe, if I ask you, do you, would you like, Would you be more glad to receive from a 10 kilograms of gold or 100 kilograms of gold? And I'm pretty sure you will answer as a gift. He will answer one under kilograms. Okay, fine. No, for the same problem. For the same automation of a solution to a given problem, would you like to receive 10 lines of code, or 100 lines of code? Gold is an asset, while code is a liability. Okay. So basically, if if we provide the same value for more code with more code, actually, we are having a big, so a bigger problem maintaining the code, fixing bugs, and blah, blah, blah, okay, and this is true for mostly, most of knowledge work, everything we do usually is not the value that we're selling, the value that we're selling is the reason why people are paying for us. And so, okay, this is what this was the first point, second point, if we sell our time, like in time and material contracts, but even in fixed price, usually you you are estimating for the amount of days that you will be working for the customer, right, you end up selling the cost and not the value of your delivery. Which brings us to the third most critical point. If we sell our time, if I sell to my customer, my hours, they are entitled to question the way I spend my time. Just actually, that's why they are buying. And instead, if we want to sell the value the problem or the solution to their to their problems, actually, all of a sudden, we become free to use our time the way we want. Yeah, you will get more leads nice. It's gonna be a website or newsletter or temporary shop in the main town. Okay. Okay, fine. But the point is that if you get more leads, and I can prove that I brought more leads to you. Actually, that's enough. And if I want to write unit tests, if I want to write documentation, if I want to share the burden with many people, or just alone, it's my business. And I want to decouple my knowledge work from customer interest. As much as we all decouple the work that was needed to build our glasses, our cars, our pens, from the price and the value that we assign to those objects in our lives. I don't know how much my pen is. I know how much is worth. But I know how what was its cost when the producer made it, and no one questioned it. But that's the reason that's because we don't pay the time of the workers that made our washing machine. And instead, we as professionals, knowledge work professionals, we keep on selling our hours. So don't we shouldn't get surprised to be questioned the way we use our time.Joe Krebs 19:57 That's why early on is like this is where we're crossing from I think the word you said is professional, ethical, where the ethical example the software engineer, but I do want to go a little deeper on the liability thing you just mentioned, because I don't know if somebody might be listening to this and said, Oh, wow, we're 10 lines of code or 100 lines of code, do I really care? Do I really care if I get the value? And I would say you do care, right? Because you might have maintenance on 100 lines of code versus 10 lines of code, you could say, less is more, or maybe the 10 codes, the 10 lines of code might be very ugly and haven't been refactored. And nobody wants to touch that segment. So it's a liability, right. It's not like you can measure this in lines of code. And I think that is also an important point that I hope nobody's out there having a contract in places as you're writing 1000 lines of code every day. That will be that would be very sad.Jacopo Romei 20:47 I've heard a few actually, along the years, I've heard a few and not only in one country. I mean, it's, I've read about this in forums, like by the end of the 90s, or like 10 years ago, I mean, it was like people getting paid by the lines of code. But also, I mean, another objection that we might hear is a but there might be value in writing more lines of code, if they are more maintainable if they provide with a more elegant and clear structure. And I agree, obviously. But I mean, this is nitpicking, if you want to get the point that we're making here, dear listener, you can.Joe Krebs 21:31 This is awesome. Should we explore maybe another one? We already saw chaos in small doses. But but maybe maybe we do. skin in the game sounds very interesting. Maybe? Well, we'll take that as an example. And just to give people an exposure to that they can obviously read up on that in your book, extreme contracts, but skin in the game. I use that a lot myself, like for other references. How does that relate to extreme contracts?Speaker 2 21:59 Well, I'm okay. So the saying skin in the game is quite old, but I'm using it in the same with the same meaning and the same usage that I learned reading Nassim Taleb books, anti fragile, and the Black Swan, and even the book itself titled skin in the game. So I'm using skin in the game as a device to reduce risk in all situations. Okay, so the main, one basic example can be if I ask John to build a bridge, and then I asked him to sleep under the bridge, for the first two years after I think I've been built it, probably John will be induced will be given a positive incentive for the quality of the construction, and for somehow providing all that redundancy that gives us safety in life. Okay, we got two lungs, we got two eyes, we have two pilots on planes. And if we go with risking things in engineering, we should provide with options and ways and redundancy to to provide us with ways to the riskiest situations. Usually, when we have designers and programmers and professionals that have no skin in the game, they sell efficiency, which is somehow a way to over optimize things, because the reduction of cost can be sold quite easily. Okay. So, for example, so if we asked John to build the bridge, and then we don't ask him to live under the bridge for two years, he might give us like, an experimental shape, or an experimental design new materials that have not been tested by centuries, and so on. And once in a while, I mean, I'm thinking about the city of Genoa, in Italy, where there was a huge bridge that fell down. I mean, yeah, I mean, the skin of the people in the game is a way by which we can induce a different landscape of rate. Okay, so let me be more concrete because actually, what I'm not saying that John would be somehow militious somehow trying to to game us, okay. But what I'm saying is that our systemic prudence kicks in when we ask people to respond for their their actions. On the other side, we want people to enjoy the results of work they do above expectations. Yeah. So that they have double incentive to perform is actually the problem. So one other suspicion of lack of skin in the game is usually that when I deliver late, I am punished some way one way or another, you can even be dissatisfaction mail. Okay. Right. When I deliver earlier, usually, I don't get any prize. And so I mean, this basically creates no incentive for me to deliver before the deadline. I'm only I'm only having an incentive to on time. Yeah, exactly. So which literally means slightly late, because there is not on time. So okay, so, and skin in the game is the thing that should be reflected in our agreements, I think people working together on anything should be enjoying benefits for over delivering, they don't have to be equal, but they have to be in the same direction. So basically, it's it's like, I mean, for the nerdiest out there, it's I would say that the vector is the point in the same direction but not having the same magnitude. And all the people involved should suffer a little bit of pain if things go worse then then planned that's usually usually usually especially in corporation, we have very huge asymmetry in which people deciding things are able to go away with short term advantages short term benefits and leaving the the mid-term, long-term harm suffered by someone else who was forced to be there, right, which is I mean, from an organization point of view, there is increasing the risk of failure and bankruptcy or failure in generalJoe Krebs 26:50 is a perfect example for a lack of skin in the game like for many offshore contracts, where the whole product was being outsourced offshored onshored, nearshored, whatever whatever it is, by the model, it is basically like delegating everything, but being in control of saying, Are you shipping the right product, which is obviously in a model like that extremely challenging, but also not having any skin in the game? If I if I assess this correct.Speaker 2 27:17 let me give let me bring this point even further, we can say that traditional contracts have complete lack of skin in the game because fixes I mean, I would traditional contracts, I mean, or either fixed price contracts or timing material contracts, okay, I know there are many variation varieties, but basically, these are the two main, like, most of the contracts fall into these two categories. Both these categories of contract lack skin in the game, because in a fixed price contract, actually, the customer is shifting all the burden on the provider, if everything anything goes wrong, for any reason, even systemic reasons, okay. The provider, the supplier has to work past the deadline, which basically means this is nice, because it basically it means working for free, unless you plan for a buffer, which is basically planning for, for stealing money if everything goes fine. I mean, this this, this breaks my head. Yeah, in, in the case of timing material contracts, on the other hand, the risk is completely shifted on the other side, and if anything goes not as planned for any reason. And I mean, we started thinking it might be over in 10 days, and then it requires 20 days. I mean, who cares? The customer is going to pay. I mean, this is not exactly the tone. I expect when we are talking about skin in the game. Joe Krebs 28:49 That is not going to create a healthy customer relationship, right, either. If you're thinking about trust again, right, where we started with our podcasts whereJacopo Romei 29:00 we all go back to the way we try to build trust and the way our contract usually erode our trust. Yeah, that's, that's, that's completely crazy how we can I mean, many people might say, Well, yeah, but it's this is normal. I mean, it's so common, but normal is is a word with two meaning normal is somehow means frequent. But normal also means just right. Okay. And I don't think contracts which are not normal, should be normal.Joe Krebs 29:32 That is awesome. Jacopo, now, yes, here we go. I want to say thank you for spending a few minutes here with me and talking about extreme contracts. I am super thrilled to bring this topic to Agile FM listeners, I think it's really, I mean, a lot of people probably look at templates and documents and contracts, etc. And you're like, maybe something's wrong with that, but I think I feel like an episode of like this and hearing it from you. And obviously you're publishing about this and as I said, beginning to our chapters available on agile FM link there. So you can just go in and start reading for at least three chapters. There is a bigger book in the making. So maybe we'll that's the starting point for, you know, changing the, you know, future DNA of contracts within organizations and obviously, focusing on value. Great name of it too obviously, resonates very well with the Agile community catchy. Thank you for making it and being so passionate about it. Thank you so much.Jacopo Romei 30:35 My pleasure. Thanks to you.Joe Krebs 30:38 Thank you for listening to Agile FM, the radio for the Agile community. I'm your host Joe Krebs. If you're interested in more programming and additional podcasts, please go to www.agile.fm. Talk to you soon.

Transcript: Joe Krebs 0:10 Agile FM radio for the Agile community.www agile.fm.Welcome to another podcast episode here of agile fm, I have Jurgen Appelo creator of unfix, which is a topic we want to talk about here today is unfix.com. That's where you can learn more about this topic. But we want to talk a little bit of what unfix is, where it came from, how old it is, how new it is, and what it can do for organizations out there. A super interesting pattern which I which is important. We want to explore what patterns are everywhere and also talk about what unfix is not. Welcome to the podcast for you. How you doing today?Jurgen Appelo 1:05 I am great. The weather is awesome here in my in my city in Rotterdam in the Netherlands. Looking forward to the trip tomorrow to Lima, Peru, which, which is something that I have been looking forward to quite a few weeks already. So longest trip and those are nice to have every now and then. And yeah, lots of things happening.Joe Krebs 1:29 Lima is are they interested in unfix? Or is this for pleasureJurgen Appelo 1:32 of course. That's what I'll be talking about. That's my keynotes agile, lean agile event. Yeah.Joe Krebs 1:41 All right. unfix is not another scaling framework. It's not a method. It's not a framework. What is it?Jurgen Appelo 1:49 It's a pattern library. That's that's how I call it. There are other pattern libraries such as sociocracy, triolo, and team topologies. And, and so on liberating structures, they are not frameworks, because you don't install them. That's the idea of a framework that you have something to implement. And then you can validate or verify that you did the implementation correctly. You can certify people with in the implementation roadmap, that is not what you do with a pattern library, all of the suggestions are options, there's nothing mandatory with a pattern library. So the best metaphor that I have is Lego. There is not a single block in the Lego box that is mandatory for you. All of them are optional. Some of the blocks are more obvious, then the others, so you will use them more often. Maybe nearly always. Some are more rare for special cases, but not a single part of the Lego toolbox is is mandatory. And that's that's how I see pattern languages. That's the real word that specialists use sometimes Pattern Language. Yeah. And yeah, that's that's what the unfix model is, as well.That is interesting, because in lego, a round shaped kind of piece could be a wheel on the car, or could be a pizza on the table. Right? Exactly. Joe Krebs 2:49 Creative creativity here, right? It's also interesting, because you are, sometimes you build with LEGO not that I have worked on with Lego in a long time. But you could build a house, you can build a street of houses or like a road or alignment, you could build a city. You know, there are some exercises out there in the Agile community where things are being built in isolation and put together there are there is a guy called Christopher Alexander I was exposed to, in the beginning of my career with is an architect where I'm nothing really in the Agile space, but he has influenced a lot of people in that how did how do these people like Christopher Alexander or Gang of Four, and others, there's many, many people out there in the community. How did they influence you? Or unfix?Jurgen Appelo 4:10 Yeah, I have the book actually here, one or two meters behind me the Pattern Language of Christopher Alexander where he published, I think in the 70s or something. He was the first one to recognize the benefits of micro solutions, small solutions to known problems that you have to combine to come up with larger custom made context dependent structures. And that is what cities are. So in the book Pattern Language, you find the public square as a pattern. Anyone knows what a public square is. You have public squares in New York City. I know quite a few famous ones. We have public squares here in Rotterdam. But the cities are completely different. Same with the the promenade as a pattern there are promenades in, in New York and also promenades in Rotterdam, and so on. So this book has 253 patterns that is quite a lot. But then it's up to you as an urban planner, a city designer to come up with ways of combining them that makes sense, within the context of the city, because some cities have mountains, others have lakes and rivers, and whatever, you have to work with the environment that you have. But then, within that environment, you're gonna use the familiar patterns that everyone is using that principle, you also find in while you mentioned it, design patterns are the Gang of Four and then book came out in the 90s, where they came up with familiar patterns in programming, the facade, the singleton, the model view controller, I'm sure many programmers listening to this know what I'm talking about. And it is up to you as an architect to use those patterns and combine them in any way you want, depending on what the software is supposed to do. The interesting thing is, I remember back then that some people implemented all those patterns as a framework that you could literally buy frameworks, like the dotnet implementation of all the patterns that you could then install on your computer. And, and I thought, that's, that's totally not what they meant. With the book, you should not turn those patterns into a framework that you can then install, because you're not supposed to do all of them. You only pick and choose, depending on context, what you need. And I think that is my main problem that I have with frameworks in the Agile community, where you have these rigid structures where something needs to be installed, like well, let's name the big one, the Scaled Agile Framework SAFe, they literally call the smallest version essential safe, it is in the name itself. That part is essential, it is mandatory. If you do not have an agile release, train, you do not have SAFe. So you must have an art, you must have PI planning, you must have quite a few other things that those are together the framework that needs to be installed. I do not believe in that approach. I do believe that the frameworks have lots of good patterns in them. But we have to break them down. We have to decompose them deconstruct into the smaller building blocks. And then let you in your organization, do the recombination, figure out how to combine the different patterns from different toolboxes SAFe. LESS team apologies, whatever. They all have practices that you can combine. And that's what I tried to do with the unfixed model. I just borrowed the good stuff that is already out there. Just as Christopher Alexander has done, cities existed before the book, surprisingly, good organizations that do common sense, good stuff already existed before unfix came out, I just capture the good stuff, I give it a name, I give it a visual say, well, this is what we've seen, that seems to make sense as a micro solution. We add it to the box, the little box as one of the options. And then you take it out when you think you can apply it. And the box is getting larger and larger. Because we need more options, so that you can build more stuff with the, with the pattern language. Joe Krebs 9:02 So this is very interesting, right? Because what you just mentioned about the essential piece of in your example was SAFe, but we could probably take any, any other framework as well. Right? But when we're looking at the essential piece that does not consider the environment you're in right. So we're coming back to Christopher Alexander, he does not see that. What is what is the environment you're in? What's your view of mountains? Do you have lakes Do you have how do we build around it right, you come in with the essential piece and it might not work for that environment right to have a little bit more of a flexible approach I think that is that's a good point now is unfix like buffet style, is that what people are they have to see is like there's a collection of patterns and people go out and says I'm gonna grab this I'm gonna grab this and grab this and I get confidence in the individual pattern, but I need the skills to combine them that they make sense togetherJurgen Appelo 9:55 exactly. I like the metaphor that you're using buffet style that might make it harder to sell things to people because I'm making them do work, I have to convince people that they have to do the thinking themselves don't do just a stupid implementation or something off the shelf. That is not going to work, you have to do your own thinking, according to your context to make things work, interestingly enough, I just read a couple of weeks ago, in a very different context, the scientific results of research into body weight, or body loss or body weight loss, what is the weight loss, weight loss? Weight loss programs?Joe Krebs 10:47 Weight loss? Yeah,Jurgen Appelo 10:48 yeah, that was the term I was looking for. And the evidence is in none of them work. None of the standard programs work. They already know that there is scientific evidence that the only thing that works if you create your own program, out of the common sense suggestions that are captured in all those other programs, the standard programs out there, but it is so context specific, a weight loss program that you have to customize it to who you are, what kind of body you have, what kind of lifestyle you have, et cetera, et cetera. So the following any standard program is, is is going to it's going to fail. Yeah, and that is the equivalent of following a standard standard framework, it's not going to work, you have to break it apart and use the individual components good. There is a lot of good advice in there is just the whole package that is sold that you have to get rid of.Joe Krebs 11:54 So some of the listeners, not fully familiar with with unfix might now think, throw everything out and use unfix that's not what you're saying. Right. So this is also important, because we are talking about SAFe and possibly other frameworks here right now, that does not mean that unfix is replacing these these kinds of things, right? How would they be? How do these coexist? And how to how do you envision to go into an organization say, hey, we'll, let's say there's an organization using a framework of any kind, but as unfix pair up with that approach.Jurgen Appelo 12:33 Now, yeah, I would like to help people stop thinking in terms of frameworks. And how do we implement it well, some suggest that there could be good starting points for customization. I think the jury's out on that argument, I'm not fully convinced that they are a good starting point, I think starting from scratch might sometimes be easier than starting from a framework implementation and then adapting it. But let's give them the benefit of the doubt people who have a framework and want to customize it, they could look at what the unfix model offers in this, and then see what else is in the Lego box that we can use to start changing this implementation that we have here with continuous improvement and, and small step experiments, to turn it into something completely different. So it would be similar to beginning with a standard weight loss program, but then realizing on day one, that there's not going to help, you'll have to you'll have to change the exact diet, the exact exercises and so on to start making it work for you. That I can agree that that might my approach.Joe Krebs 14:02 Yeah. So So that's, that's interesting. Like I for example, I teach a lot of adaptive org design courses, for example, how organizations shift, make the switch towards agility and kind of things to consider. There's a lot of talk about self management and self organization, obviously, in these courses and how to get to states like that does unfix if somebody listens now more from a leadership and managerial role, prior to this podcast is this unfix demand like a full self organized self managed like it's a radical name, right unfix? It's provocative, nice, nicely provocative, right? And it makes you think, does that also mean like we're going to the extremes with adaptive org design? How does a company steer that transition? Not necessarily top down structure, but even like any kind of structure in an organization how does unfix change that? Um, I think What I want to achieve here is to plant a flag on the horizon and show people, this is the direction that we want to be going. And I don't expect you to be here tomorrow. But I want you to move in that direction. And that direction is being a networked organization with a fractal or design. There are some companies, not many, but a few that have evolved quite far in that in that direction, famous one is Haier, the Chinese company where it was 10,12 years ago, where they reorganized themselves into a network of 4,000 micro enterprises was a 4,000 tiny little companies that that collaborate horizontally without big fat middle management layers, no matrix structure, whatever. And they are incredibly adaptive, they are super fast in in responding to opportunities. For example, when COVID hit the Chinese economy Haier was the was the first one to start making masks or a face mask for half the country, basically, because there was an opportunity, and they could respond incredibly fast to this to this new thing emerging. While normally they make vacuum cleaners and and and fridges and whatever, but they switched to face masks short, why not? Why not? Yeah. And so this is a very inspiring company as that shows what you can do as a network company instead of a hierarchical matrix organization. And that is, as I said, the flag on the horizon that I want to offer people try and go in this direction. But I do agree that it is a step by step thing, you'll first want to move into the adjacent possible as some complexity thinkers would would say, you open up opportunities in a new direction, by making small steps, and that unlocks other doors, and then you go through that door. And if something doesn't work out, you make a step back and you move in another direction. I'm sure that is also what Haier has done that local experimentation before they did the big radical change of firing all the middle managers basically, because that was quite a revolutionary thing. That was Kaikaku not Kaizen them at that time, but I'm sure they did some Kaizen before they were sure about the big step they wanted to make. I keep telling everyone started with small experimentation. I have already 150 patterns in the in the pattern language in the model, and more are coming. And there's plenty to experiment with very small things that will harm nobody. So just start playing, get some experience. And then when something seems to be working well, you could make some more radical steps. With your org design,assemble your city, right? Build your city like start small somewhere, right?Jurgen Appelo 18:14 Exactly. And by the way, it's not only about organization design, about crew types, Team types and so on. There's also decision making methods. Also about goal setting patterns are coming out in the next couple of months. So more advanced version of OKRs (objecetves and key results) basically the whole OKRs and MBO (management by objectives) KPI stuff, I have deconstructed into patterns. And that's going to be awesome, I think,for people to playwith and make their own OKRs like approach with the individual patterns that we're going to offer. So yeah, organization structure, business processes and collaboration. There's lots of different angles on on the pattern library. You can start anywhere, whatever is the lowest hanging fruit the smallest pain that you can address. Start playing like with a Lego box. There are 4,000 different types of Lego pieces. Did you know that Joe 4,000 Neither did I. Yes, that's quite a lot of options that but nobody starts with with 4,000 pieces on the table now doesn't that doesn't make sense. You start with a subset of the more obvious ones and then you will dig into the rest later on with when you gained a bit of experience. Joe Krebs 19:44 Before we go into one of the maybe we can explore one of those patterns is one thing I noticed and I just want to follow up on this because we just talked about you know, leadership etc. and organizational change. These are this is a bottom up kind of approach, right? And you just mentioned like some form of middle management and that was reduced or removed. You're not saying unfix we're not have any managers or leaders? And I think we were very clear about this. What is the role of though of leadership? If it's a bottom up movement? How can leadership support unfix? within an organization? If we're seeing on one side, there is some form of streamlining going on within an organization, which I think many organizations would benefit from, as well. Right. But on the other side, it might be the the the question of a leader that says, I don't know what my role is, in all this. How can I support unfix to make the organization a better place?Jurgen Appelo 20:46 So well, that's where my previous work on management 3.0, comes in, I always say manage the system and not the people. And the very same thing, I suggest with the unfix model, where we have the governance crew, which is the team of chiefs, Chief Executive Officer, Chief Information Officer chief whatever. At the base level, and the base is what I'd hire would be the micro enterprise, some might call it a tribe, a self sustaining business unit, whatever small units of, of maybe up to 100, people maybe a little more, but not much, much more than that, that is the unit that we're looking at, that should be autonomous self managing, with a very specific business model proposition that they offer to either the world outside to customers or users or to other parts of the network in within the company. And that unit needs to be managed, that someone has to take responsibility for the success of that unit. All of those 4,000 micro enterprises hat Haier are managed by a chief. And actually, the fascinating thing at hire is that if the chief is not doing well, for three months, there's an automatic re-election triggered, where other people can volunteer to take up the role of the chief and see if they can do better that is interesting. But I will not go there yet with my suggestions because that makes some managers very scared of their of their job. But the fact is, the unit needs management but management of the unit of the system, how does that system work because you need to put some constraints in place on on how those 20 50,100 people in that base, collaborate with each other. And we want to make and that's what the name is about unfix we want to keep that unit as flexible as versatile as possible with its organization structure. That means that you should try and not have managers on teams. So no manager on a scrum team, no manager on a team of coaches, no manager on a platform team or anything because as soon as you have a manager to the air, you create territories, I know from personal experience, how hard it is to change those territories when you put someone there, this is this is now the place that you are going to manage and you will decide how much people get paid within this part of the organization. Then you you just put into in cement a part of your organization, you you should try and not do that. You can have a captain, on on on a crew, for example, that is something else that is like a pilot on a plane. That is a person who has the responsibility for the mission. But the pilot does not decide how much the stewards and stewardesses get paid. They don't have HR responsibility. They do report to the Chiefs how well the mission has gone and who deserves some extra credits or compliments or whatever it is they know everything that goes on, on that mission, but they do not have management responsibility. They are leaders of course captains are leaders that so we offer a captain role and what we call crews as an option, you don't need a captain maybe but it is an option that you can consider and I know companies have great success with Mission leads as they call them. For example, well I call him Captain but that's the same thing. We call that pattern the captain role. But as long as you keep that management responsibility out of it and with management I mean people management HR responsibility and desirable gets paid and career Development and so on, remove that out on the teams put that in the governance crew level, so that the rest of the bases stays flexible.Joe Krebs 25:11 Very, that's very interesting. And I think when you just said that, and you had a smile on your face about exactly like the managing the pay and managing promotions, etc. And I think everybody out there who's listening to this right now might say, that's true in my organization that is a blocker, if we're removing that, that might change the environment. And that makes it a case for a pattern has proven micro solution for a common for a common problem. So this is, this is really cool. What I want to touch on one thing you just mentioned the word crew. What I like about the flexibility of these patterns is that you it's almost like you have name suggestions for these patterns. But you always make the link to alternatives where we say like you might have heard this word before. And this is really what it means over here. So it's like the name of the pattern, right? The same in a cookbook, where it could be a Sicilian tomato sauce, and we could be Northern Italian Italian sauce, but at the end of the day, there will be a tomato in it right? In either or, with subtle nuances in it, but you do speak about a crew. And I think that's like one example I want to take you just mentioned that. I don't know them all from the top of my head. But there are different crews, you just set the governance crew, there's I think there's a platform crew. This might be a lot of crews for somebody who looks at unfix. In the beginning. I like your approach of starting somewhere lowest hanging fruit you mentioned when but why are there different crews? What's What's the benefit of looking at the crews in different ways from different angles?Jurgen Appelo 26:53 Well, let's let's take the two topics. separately first, naming is important. So indeed, I've used the word crew instead of team because the word team is overloaded these days people use the word team for anything. Basically, crew is a bit more specific. I use word base for what other people would call a tribe. Some people complain about cultural appropriation and things like that. So I've tried to steer away from the tribe word. Base is the home the place where people return to I like that word. And we use forum instead of Guild because by default, people assume that guilds are things that emerge bottom up that it always volunteers, that is possible. But a forum could be more formal. So it could be something bottom up. But a forum could also be installed by managers, for example, where they say we want alignment across bases on a certain technology, like we don't want five different testing platforms, we will not one, because that's cheaper. Now you go and figure out with each other which one it is going to be and we want a forum to take care of that. So language is important. But indeed, people can use their own words in the pattern language, you need words to identify things. And I think about what is the best word that comes with as little baggage as possible. But I leave it to people to use their own words in their own organization. If you like the word, pod or squad, instead of crew, go ahead, knock yourself out. The second part of the question was indeed the different crew types I borrow for from Team topologies. Actually, they simply identified 4 patterns before I did, and I credit them for that, which is the typical value stream team, Scrum Kanban. Team, whatever, we know how that works. And then the three exceptions which they call the enabling team, the complicated subsistent team and the platform team. Those are three different kinds of teams that are inward facing. And I borrowed the same ones I changed the name a little bit maybe too off topic to discuss all the reasoning behind it, but I just borrowed the same four and they added three other times that I thought were useful, which is experienced crew partnership crew and the governance crew and we just talked about so the set is seven, seven kinds of crews are teams within the base and they are like Lego blocks you use them as you want. I always tell people I hope you have as many value stream grooves as possible because that is like the most popular block. The Lego block the most beneficial ones I hope seventy percent of your teams aren't that type. But an enterprise of 100,000 people is not 20,000 Scrum teams, that doesn't work, you need some other kinds of teams to hold it all together. And that is why team topologies identify the different kinds. Because not everyone is offering value to a customer, some people are offering value internally to the other employees. And there are different kinds of behaviors that you can identify like a platform, through, as I call them, they offer a value to others on a self service basis, almost like an API, or sometimes literally through an API, in terms of technical infrastructure, or in DevOps capabilities, whatever. But I have seen kindergarten on site at a company where I was a couple of years ago. And you could bring your baby and toddler and throw them in the basement. And by the end of the day, you could pick them up. That's an API as well. That is that is also a platform crew, the kindergarten team. So that's that's that's one kind of platform crew. And then there's others the facilitation crew and capabilities. Again, alternative exceptions to the rule, you could say,Joe Krebs 31:25 but but I do want to reiterate and get your confirmation, this is not something you would be setting up all these crews up front, right, this is you're building piece by piece, you're starting somewhere start small. So this is not completing the picture. And having a crew everywhere, this is not installing unfix, you might start with the value stream crew. AndJurgen Appelo 31:46 I know it sometimes it's more clarifying what people are already doing, or giving it a name to something that seemed sensible. Actually, I had people reach out to me literally, when I published the unfix model for the first time where people said finally now, now we have a language for what we have already been doing for several years. And it seemed natural to us only we didn't we didn't see this visualized in other frameworks like like that. Yeah, so there are several case studies like that, on the unfix website web page already use the patterns, they they didn't have the names yet, I was just giving it a name and a color and that's it. But um, so what what can help is with a pattern language is it helps people to have a conversation, like, Okay, we have a couple of Scrum teams here. That is obvious or Kanban teams, whatever your preferred, agile approach, but a few of the other people are inward facing with the things that they do instead of outward facing what, what are they? Well, that depends on how they behave, do they literally sit with the others? Are they facilitating like agile coaches and so on then they would be facilitation crew, that's a different kind, but that gives you a name it gives you it gives those people recognition like that. So we we are this we are this pattern the facilitation group pattern. And now we we know how to explain what we do to to the others. And if you don't have it, then you might want to consider it like, Okay, you have 10 Scrum teams or something, maybe want to consider facilitation crew because it could offer these benefits. They might be interesting in your in your context. So read up on the available patterns and decide whether this building block is something for you. And then you use it or you don't.Joe Krebs 31:46 Yeah. Awesome. Yeah. So you're talking to a pattern freak, right? I love I love the thinking behind it. I have you know, read all this stuff in the past. And as you mentioned, this started a while back. So really cool stuff. And for everybody out there interested in in unfix obviously on fixed.com is the place to go to learn a little bit about it. As you said, you're on your way to a conference, you're speaking as well as the unfix conferences. What's what's your approach on You know, sharing the wealth of unfix with the world, more conferences is the training programs behind it, etc. How do you how do you multiply Jurgen around the world in a way cloning that your model is sticking?Jurgen Appelo 34:50 I'm glad that we cannot clone ourselves because I'm a difficult enough person as it is. So I wouldn't, I wouldn't want to bother the world where have multiple copies of me. But no kidding kidding, all kidding aside, I do want the word out. And of course, I want people to play with this. I love working on the model and pattern language itself. I'm very, very happy to be doing the research and then pattern analysis and coming up with names and visualizations. I have other people who in their own way try to bring this to an audience. So for example, the unfixcon is organized by other people in Berlin. I know them, well, they use the brand, I am involved, but it is not me doing this. I have a team that is working on partnerships, so people can sign up as a partner and then use the the courseware materials to the unfix foundation classes. And again, I have team for that is not what I do. There's someone else creating an app plotter app that you can use to design on your computer, your org design with the unfixed patterns again, that somebody else so I actually want to enable a lot of people who have an idea of how can I bring this pattern language to certain users customers in any way that that seems sensible, and then enable them to do that. I have someone who creating a webshop with mugs and T shirts, and so on. All right, thumbs up. So and and someone else might be writing books on the topics or creating courseware modules, all of that I delegate to others, I just want to focus on the Patreon side because that makes me happy.Joe Krebs 36:46 Awesome. Well, you're getting to you also speak about it. So have fun with that meet a lot of people. The unfix model is the first thing that's going to strike you when you go to the website is colors, lots of colors, and maybe that is an expression on diversity, diversity and the patterns the approach and maybe the ways of how people approach unfix in in many many different ways.Jurgen Appelo 37:13 true! the colors well actually what I use colors for for 15 years people know me I'm not I consider myself in eternal midlife crisis and I need colors. But at the same time, it gives people a sense of playing with a Lego or having a playful toolbox. It's it should not look boring. I find I find very important. So there is also marketing psychological. It has to be colorful because life is too. Life is too short to use only boring colors. JoeJoe Krebs 37:53 Yeah. Thank you another black T shirt guy. Jurgen thank you so much. Thank you too. And thanks for sharing your thoughts and, and good luck with that. Thank you for listening to Agile FM, the radio for the Agile community. I'm your host Joe Krebs. If you're interested in more programming and additional podcasts, please go to www.agile.fm. Talk to you soon.

Transcript: Joe Krebs 0:10 Agile FM radio for the Agile community. www agile.fm. Thank you for tuning in to another episode of agile FM today. I have Jim Highsmith here. Jim Highsmith just released a book called Wild West to Agile the adventures in software development, evolution and revolution. And it came out by Pearson as a publisher. Well, before we get started taking the book apart, welcome to the podcast. Jim, I'm so happy you're here. Thanks. SoJim Highsmith 0:46 I'm glad to be Joe Krebs 0:47 A lot of people know, Jim for one of the 17 signatories of the Agile Manifesto. And so this is, this is a very interesting book you wrote, because it's about a time period of 60 years of software development, software engineering, but also management leadership topics, and you group them into four eras. And we'll talk a little bit about those, obviously, and discuss if that's if that's possible. But you did write a book in 1999, or something. And the book was called adaptive software development. And without that, without that book, our entire industry would have been possibly called adaptive instead of Agile.Jim Highsmith 1:36 Yeah, it's interesting, you know, before the Agile Manifesto meeting, Kent Beck and I swapped books, or manuscripts before they were published, I read XP, for it was published, and he read my adaptive book for it was published. And so we, we had those went into the Agile Manifesto meeting. And it was it was, is I remember, we had like, 20 words up on the board. And we whittled them down to agile, but adaptive was one of them until the board and I made the point that I didn't think that the name ought to be something that one of us already had.Joe Krebs 2:15 Yeah. And and then we you guys chose the word agile became the Agile Manifesto. And, you know, and that was just the starting point of the fourth out of your four areas you are highlighting in your book. There's three before that, right. And this is this is this is the, this is the interesting piece here is did you take journal, did you write journal for those last 60 years? Or how do you remember, going all the way back when I looked at your book is fascinating to see all of those topics? But by no way? Could I remember all of those things, how you wrote them down? How did you do that? Well,Jim Highsmith 2:54 it's interesting, because the things that I had to look at changed abruptly in the mid 90s, when I started having emails and computerized documents. And the other parts of it, particularly the early years, was basically from memory. It's interesting, as I, as I looked at things as I began to remember, other things came to me. So it was it was interesting how one memory led to another memory.Joe Krebs 3:26 Wow, that's amazing. Yeah. So even Nike made it into the book, right? Yeah. Nice. So what's interesting about this book is I looked at the title. And obviously, it's about a reflection on 60 years of software engineering, from Apollo to SpaceX, if you want to see that. Right. I think that was one of those subtitles. What's interesting is when I first picked it up, I thought it was a book about that wasn't sure let's put it this way, if it's about you, or is it about a historical book about all of what's going on? And then when I started reading it, I was like, Oh, my God, this is fascinating, I's both. It's, it's a reflection on the the eras ors of what was happening in the last six years of software engineering, plus a personal touch from you, and how everything came together. Why did you decide off of putting this together, like your personal experience? And, you know, what do you what do you think is benefiting from the historical aspect of the book?Jim Highsmith 4:32 Well, one of the things about the history that I think is important is that it helped by understanding some of the history, it helps us prepare for the future. I don't try to predict the future in the book. And I say this is, you know, part of being ready for the future is preparation. And it's interesting how this book got started, and why the personal is in there, because it actually started out as a family oriented memoir to my grandkids. And as I, as I developed that and tried to figure out how to make something that would be interesting to teenagers, because they're in their mid teens now, I decided on this kind of scope of 60 years and breaking it into arrows. And once I did that, I realized that a lot of it was my personal stories. And I kept, I kept asking people, which do I emphasize? Do I emphasize historic history? Or do I emphasize the personal and people like Martin Fowler, who was a reader of the manuscript and had a lot of great information and feedback for me? Yeah, pushing me to do more personal or like a memoir. So it is kind of a historical memoir. And I think that it also helped me reduce the scope of the book. As I tell people, it's not the history of software development, it's a history of software development, it's really important, because there are a whole lot of areas that I never really got into. And so they're not in the book. So for example, I worked with people who did object oriented programming, but that was sort of different from what I did. So there's not a lot of history in there about object oriented programming. There's nothing about aerospace, there's nothing about Unix, there's nothing about a whole range of topics that I didn't have any interaction with. And by doing it like that, I was able to scope the book to something reasonable. Yeah.Joe Krebs 6:35 Well, I it's, it's fascinating, right, so you just mentioned those four areas, just to give readers or listeners a little bit context, here is the Wild West. In the beginning, this is how it all started. We got structured, and we got the roots. And obviously, then the Agile space. Now, you just mentioned that a little bit in how it could be helpful for for anybody who to look back into history to make, you know, not predictions, but to learn from history for future events, possibly reflect on it. Now, if somebody and because the Agile era itself is already quite long, at this point, we're recording this in 2023. So some of the listeners right now might only have experience in that era. Right? So what do you think if somebody who is relatively new into software engineering, possibly coming out of college right now, and this is like, this is all I know, this is the way of how I have learned and worked in this is the only thing I know, what are the aspects you feel like you would like to point people back to until I get this, this is interesting stuff, and you should be aware of it.Jim Highsmith 7:45 Um, I had a colleague at ThoughtWorks, who is in her late 20s, she read some of the manuscript help some with it. And it was really interesting talking to her, because in college and and her work, work environment, she had never done anything except that. And so looking back at the history of things, she, she really enjoyed it. And she thought it was very helpful to her to kind of understand, for example, what was the conditions in the world that made agile, kind of take hold in the early 2000s? Was it just because it was a better way to do software, because people really liked it. There were business conditions, technological conditions, that kind of came together at that point in time to make a pivot point. And I think people need to understand these things didn't just grow. Boom, but, they had some background and the other background background, I thought was important was to bring out some of the individuals, some of the people who were pioneers of those different eras, who really contributed to the evolution of software development. I asked people if they did they know who Tom DeMarco can or or Larry Constantine do they know that these people were and most didn't? So I wanted to bring those people forward in people's mind. It'sJoe Krebs 9:32 interesting yeah, no, I and it's nicely written beautiful graphics. And in there too you see like the the era and you saw like with, you know, where technology was produced with the mainframe computers, and you see people like interacting with the machine and you see today are people enjoying technology in their living rooms. So a lot of these kinds of visuals that go in, there's also a visual and that was striking to me that was interesting because you always have like these comparisons in your book where you would say the "then", right? And the "now" piece where you you highlight the different windows here in terms of time. And what's interesting about several times the org charts of organizations comes up. And and then poor was like a hierarchy of organization and the now part is very different. I don't and this is this is something I noticed in the book is that I definitely see that there is a trend towards that. But when I read that, I was like, there are a lot of organizations still out there that are having an old org chart kind of thing they are, they're still today operating in an agile era, with the org chart of, you know, the structured, maybe right kind of approach. What's your advice to them? I mean, there's there seems to be like a less of learning in terms of adaptation?Jim Highsmith 10:56 Well, I think that this is, you know, a big topic now is digital transformation, becoming a digital organism. And I think there are multiple different parts of it. And I think until, well, for example, if you really want to be a digital organization, you're going to have to think about how you measure success, with different measures of success. And then you have now, just like in project management, we had to move from the Agile triangle to something I call the Agile triangle, from the iron triangle to the Agile. And in business, I think you've got to do some work. And so I think organization structure is another one of those things that become digital, and become fast acting and innovating. You've got to look at the organization structure, and have it malleable. meet the needs of a growing company, or of a company that's moving into making some major changes. I think there's there's some people doing that. But it's one of those areas. That's it's just emerging, and I don't think the right model are there yet other than other than Germany and Apple whose unfix model, which I talked about in the book, and it's just getting started, but it's seems to be really taking hold in europe.Joe Krebs 12:23 Yeah, it's interesting. Like, we'll get definitely get there. You just mentioned business one more time, right? So the agile movement is a reaction to the business needs, right? It's not just like you guys thought about, hey, let's work differently. Right? It was business needs that require that. And I think that need is still obviously here. So how did the like, because 95 somewhere in that neighborhood? That would be in your roots era? That was the significant event of the.com bubble burst? How did that influence like business and that era? Do you see like, historically, while you were working on the book, and you're just on the material? Did you see any correlation? Like what happened was that like, also like a massive impact on the way of how people worked? Jim Highsmith 13:16 Well, I think the thing that was the massive impact on how people work was really not connected to the.com bubble. But it was connected to something else. And this is the transition from automating interim systems. Automating customer facing system. I think that was a that was one of the impacts of the internet. And that was a major transition. So for example, there was a late 1980s, my wife and I went together, my chair, and we went to this place. And I finally picked out the right chair and hook it up to the counter, or took the slip up to the counter, wrote the guy check. Now those checks are those little small pieces of paper that we used to use. And said, we helped me put the chair in the car. And he said, Well, you have to come back tomorrow. And I said, well, the chair is right there. My car is over here. Why can't we put it in the car today? He said, Well, our computer system prints out picking tickets overnight. And I can't give you the chair without picking. That's the sort of computer interfaces that we were dealing with in the late 80s, early 90s. And so that move from internal facing systems to external facing system was a big movement and to me that was a bigger thing than the.com.com bust was a temporary reaction, the moving too fast. You can anticipate the same thing for AI now.Joe Krebs 14:59 Maybe Yeah, yeah. That's a wonderful example of how you connect the paths to possibly future events. So I was like, Well, are we possibly going into first year too? Well, that would be for a totally different recording here. Right? That would be awesome to catch up on that as well. Now, I do when I was going through this material in your book, that was also obviously, you know, I have lived through professionally, almost three, I touched on the second one, but then the the roots in an agile myself. What's interesting is there's several topics where you look back, and you're like, oh, wow, I totally forgot about this, right? We did exactly what you did too right. It's like, there are certain steps where you find yourself in your personal story, I found myself, for example, in domain modeling, for example, right? technique I find very useful. Still, today, sometimes I scribble a little bit on a napkin and do these kinds of things. Obviously, Martin Fowler follow, which you mentioned before, right analysis pattern, huge book and everything, but you don't see these things necessarily anymore. I just want to use that as an example. Right? Not necessarily make this a conversation about analysis, patterns ones. But is there anything where you would look back and say like, Okay, we are in the Agile era, but there is something in those previous three eras, we would say that's a shame that they went away, there wasn't useful techniques. They are always like, Oh, why we're not doing this anymore. It might be still a good idea. IsJim Highsmith 16:29 it true? Interesting, as I began looking at some of the stuff that was used, for example, in the structured era, I found out that people are still using data flow diagrams, maybe not to the extent they were before, but there's still a useful tool. So there's some of the diagramming methods that people are still using. And I'm sure some of the diagramming methods in UML are still being used. One of the interesting things that's still being used today, I think a lot of people don't know the origin of it. Was the idea of coupling and cohesion. Yeah, that actually, Larry Constantine, developed those in the 1960s. And so, one of the interviews that I have in the book is with Larry Constantine. Another one is with Tom DeMarco, who, those two people and a few other really kind of started the structured methods movement in the 1980s.Joe Krebs 17:33 Yeah, if I remember correctly, even Larry Constantine even went to the started initiating use case driven approach why and so there was certain I think there was part of that, and that popularized this technique, among others.Jim Highsmith 17:47 I'm not sure he was involved in use cases, but he may have been,Joe Krebs 17:52 yeah, there was there was definitely a ton of movement here. That very interesting, you just mentioned the the unfixed model. And maybe that is something I actually do want to ask you about that. So we have these four eras, which is great material. But there's also topics like unfix, for example, right? You have mentioned in your book, and that's a little bit forward thinking. Now, I myself, I'm a little biased here, because I'm writing about agile kata. But there's also lean change management, flight levels, there's evidence based management is beyond budgeting. There's agenda shift as fast goals, I mean, there's topic after topic after topic. And if I, when I came to reading about the Agile era, I was also like, fascinated about all of those things. Again, I'm a little focused on one of them myself with the Agile Kata. But what I noticed is, are we right now with business agility, the digital transformation you mentioned, are we entering? are we approaching a fifth era right now? Because there is a diversity of techniques right now. It feels like very energetic right now. There's a lot of things that are happening right now. And like in islands, and we're trying to put things together into this business agility right now. Do you feel like we're in the beginning of a new era? Something business?Jim Highsmith 19:17 I think it could be a new era, people have asked me about that quite a bit. I don't know if agile methodologies per se, will continue there as they are today. I think there's a lot of stuff happening and people going in different directions. And somebody asked me the other day, if I thought the 17 would get back together and rewrite the manifesto. And I said no, we're in a completely different era. You know, and and agile is now been spread kind of worldwide. And back then, in 2001, there was a very small contingent that was working in what was then called lightweight methodologies. Right? And so the times are very Very different. So I think that for the future, I think the important things are how do we build agility and adaptive leadership into our organizations? That's the real challenge. And I think agile can be a part of that. I think what we have to do is we have to look at, what do we keep from agile? And what do we change? Yeah. What is it that persists? And one of the things that I think the manifesto did, it was both inspirational and aspirational. I think in some of the newer things that we're seeing, they've lost that inspiration part of it, got some new new project, new principles or new processes, or new names, but it doesn't have the inspiration. The original manifesto. I think that's one of the things may be modified a little bit. But keep Yeah. And then we need to figure out what what goes on beyond that. And whether it's a new methodology called Excalibur doesn't matter to me, as long as it keeps on focus on Agility and adaptively leadership.Joe Krebs 21:15 Yeah, well, I do think like, from from whatever I noticed is I think we're moving forward with the, with the ideas in mind, right, I think, I don't think there's any kind of dead end or anything in terms of the journey. I think this is going to continue. I think it's an expansion right on. Where do we go with this topic in general. And I see like, somewhere in your, in your work, I see parts within the evolution where there's a high increase of new ideas, and then there's a new arrow coming out of it. And I was just wondering if you with all the oversight and things you see and read and hear about, if you feel like and this might my stuff I just mentioned is probably not even a complete list? Definitely not. If there is anything where you would say there is a big, big pool in arsenal of ideas right now, for how do we approach the problems of the future?Jim Highsmith 22:12 Well, I think that there's a lot of new stuff coming down. And both in management, organizational design, software development, and I think you it's going to require integration, we've got to, you've got to be able to use all those different topical areas, and somehow integrate them into something that an organization can use. And I think it's going to be different for every organization. You know, I think that this idea of one methodology fits a lot of different companies, I think one methodology to one company that everybody has to have sort of their role their own, appropriate for them. And I think that's actually the more difficult part. And the difficult part that I've seen all through the eras, which is, there's, there's a number of people who take whatever methodology and say, This is it, we're gonna follow these steps, and we're gonna do these processes, we're gonna fill out these documents. And that's the way we're going to do things. Yeah. As opposed to this is a framework, a guide a guidelines need to be adapted to every different project or every different organization. I think that's the, that continues to be one of the more difficult things to do for organizations is to allow them enough flexibility in how they approach. Yeah.Joe Krebs 23:44 I couldn't agree more with you. And this is you just make me think about all of those things that are ahead of us. As a as a community as a as an industry. When you just mentioned earlier in your book that you had the intent of writing this book for your grandchildren in the beginning, and then add a little bit more other things to it. And the book grew in both sides. It still both it's still personal as well, a historic document you put together. Is it any point that you like, because it we've been up? It's going public, right? In Pearson in here as a book? It's not just for your grandchildren? Did you soften your tone a little bit your when you did this were like, because some of the experience you had you were like, you could read between the lines that it was not necessarily easy. There was some frustration, right? Did you so it's a littleJim Highsmith 24:41 bit so maybe a little bit and you'll notice that with organizations where things went pretty well attended to use the name of the organization, but it didn't go so well. tended to use pseudo name Yeah, yeah. And one of the things that that happened during a book is, you know, I had been used to in my previous books, writing stuff, writing about engineering methods, writing about management methods. And here I was faced with writing about myself. And that's a very different perspective to write from. And luckily, I had a number of people that pushed me to do more and more of that, I think it was the right direction. But it was difficult, but I really challenge other people in our industry do more of that write about themselves and what they're doing, not just write about stone.Joe Krebs 25:43 Yeah. That's, that's interesting. Why because it's the personal touch and the struggles. It's also like, you know, it's not like polished in a way where you would say, that doesn't sound like reality, you can really feel with you in some of the situations, you know, you know, some of them were further back where I can picture like a cubicle or something like that, like, you know, like, all these kinds of things. And it's like, oh, he's going through this, but you see the path of where this is going and how you found your path. So I read by or any kind of personal story that goes along with it. It's, it's makes it more real. Jim, this is a great conversation. Thank you. And I do want to say everyone who is listening to this and has an appetite for hearing more about this and obviously going into those four eras of Wild West structure routes and agile as you grouped them and labelled them. I can only recommend to pick up the book wild west to Agile by Jim Highsmith. Thank you so much, Jim, for your time.Jim Highsmith 26:45 Thank you Joe, I enjoyed it.,Joe Krebs 26:48 Same here., thank you. Thank you for listening to Agile FM, the radio for the Agile community. I'm your host Joe Krebs. If you're interested in more programming and additional podcasts, please go to www agile.fm. Talk to you soon.

Transcript: Joe Krebs 0:00 Agile FM radio for the Agile community. www agile.fm. Thank you for tuning into another podcast here with Agile FM. I am Joe Krebs. And today I have Klaus Leopold with me, Dr. Klaus Leopold. And he is for many in the Kanban Community. Well known figure, he has written books like practical Kanban or Kanban change leadership. He's also you can reach him at leanability.com. He is native Austrian, He's truly a Kanban pioneer. As I said, He is the creator of the flight levels models. We are also going to touch on that a little bit. He has many years of experience as a top management consultant, and is reaching about 1000 workshop participants per year. And so that that says a lot in terms of how he is reaching and approaching leadership. Before we get started. Welcome to the podcast Klaus. Klaus Leopold 1:15 Thank you, Joe. Thanks for having me.Joe Krebs 1:18 Of course, I'm excited. Unfortunately, you're on episode 134 of agile FM if I'm not mistaken. And it's Wait, it's been way too long that we're connecting, you should have been in a much, much earlier episode we should have touched base many years ago. We want to talk a little bit about your latest book that is available. We're also going to talk a little bit about a book that is in the making and soon to be available. But that latest book is rethinking agile, an interesting book. It is an and relatively easy read. There's a lot of deep content, though, when I when I approached the material. And for me as somebody who likes visuals, also very, very impactful on your learning. One of the things maybe we'll get one thing squared away will often talk about agile transitions, Agile transformations. What's your take on on these words? Some people have a hard time with transformation, some like transitions. I myself, I call it transformations. I'm not coming up with a better word right now, but because you do need in that book, you do make several references.Klaus Leopold 2:29 Yeah, well, actually, I don't know, to be honest. So I mean, I use the word transition. And lately I use more transformation. So I think from a linguistic point of view, there is a difference. Yeah, I don't know. I tried to somehow maybe use it interchangeably. But that's probably not the best thing to do. But yeah. Joe Krebs 2:56 My view is, yeah, we might use terms here in this podcast, right. And also, like in your book, we were talking about the conversion converting an organization changing and etc. What's interesting is, and your book gets it right, starts right off with that you're saying, you know, taking teams agile, like development teams, that is not business agility? Klaus Leopold 3:18 Yep. Joe Krebs 3:19 You want to elaborate a little bit with the listeners on why is that and why is that an important point? Right, their business? We have a lot of agile teams, but that's not really business agility?Klaus Leopold 3:31 Yeah. So I mean, business agility itself is quite a broad term. And I think, if we start on the team level, so what I see really quite often is that we are making teams agile, right? And then in the end, let's assume we have 300 teams. Now we have 300, Scrum teams. And finally, our organization is agile. Unfortunately, it's not like this. I mean, of course, you can build cross functional teams, and all these kinds of things. And don't get me wrong. I'm a huge fan of cross functional teams. But this alone does not solve your problem, because most of the time, one team alone cannot deliver customer value. So that's why we need to zoom out a little bit from the team level. And we need to make sure that the right team is working on the right stuff at the right time. This alone does not make your business agile in terms of business agility, but that's the first step into this direction, right? Because, yeah, if I mean, we've seen this so often, when we start to visualize the work across the teams, and you have these agile teams, what you do is the teams they have a backlog, right? And what you see is that yes, work now it's not cumulating in their doing part it's accumulating in the backlog. But the thing is, if you need multiple teams that are connected, you have many full backlogs in the end, so it's not much better from a delivery perspective from a getting things done per se If we are used to work, the work in the backlog somewhere into a huge in a huge value chain, or in the doing part of the team, I mean for the team, it makes a difference. But for the end customer, there's usually no difference. That's the point.Joe Krebs 5:14 And that's also a problem, right? We often see in organizations that teams feel like, and they should feel like they have an accomplishment if they have completed an item. Right. But on the other side, it might not be customer. Something that...Klaus Leopold 5:28 exactly that's what I mean with the with the with the backlog. So this is done from my team, but it lands in the backlog of another team and in this backlog is sitting for another I don't know, whenever they decide that they work on it, right. And that's the point that that's what we're obviously okay make sure that the right team is working on the right stuff at the right time. So we need to zoom out from the team level, see the entire your value creation that's actually going on, and also target these backlogs between the teams, we also need to empty these backlogs between the teams kind ofJoe Krebs 6:00 interesting, right. And then beside the teams also. And I think that is one one sentence, I actually actually wrote down from this book, this is really deep, because I feel along the same line. If the desired state is agility, the way there should be should already be agile, right? And that's really the that's that's the idea. Like, we often go in and, and transform and we take a team, but then there's even if we have an integration with a team, the rest of the organization is not a part of the game. Right? Yes. Also you experience in your work?Klaus Leopold 6:34 Totally. Yeah. And yeah. So it starts with the change process, actually. So I've seen it so often that the desired state is agility. And now let's come up with a waterfall plan to become agile. I mean, there is some humor in it, for sure. But this doesn't make a lot of sense, right. So how we target this usually is that we also think in iterations when we are doing the change process, right? So we contract iterations, each iteration has an outcome that we want to achieve. And then after each iteration, we do a kind of retrospective so that we achieve what we wanted to achieve. What does this mean for the next iteration? And then we contract the next iteration. And well, we call it a change flow. So we try to establish flow in the change process iterations. That's the idea. And when I say contracting, it's not like the legal contracting. It's more like a clarification what we want to achieve, right? YeahJoe Krebs 7:34 yeah, it's interesting, because there was another one I took down. And these are, I think this is the the last one I actually took down word by word. business agility is created for lean processes that rapidly implement ideas, thus allowing teams to be able to deliver something quickly right. So there is this Lean process. And we do need something that is agile, lean in the conversion of creating agility within an organization, to really get out the full value of agility within an organization. I do think this is a topic that's really on the rise. This is definitely something that's coming up quite a bit. Now, there are some organizations out there, and I just use this as an example. Obviously, the name stands for many, many things you can put in place for that. The Spotify model, I just want to touch on that. I think in a previous podcast, I did talk about that a little bit. But just for listeners, I have met people from Spotify engaged with them. But what's interesting is the Spotify model as some blog post, actually, from Spotify, people actually came out, they actually say that the model does not really exist within the organization. It's not a it's not a topic of conversation, right? Exactly. Something the rest of the world is talking about. And now we're making copies of that model. Now, not to go into the specifics of Spotify itself, right on the model. But there is this tendency there of organizations trying to look at something like this and say, like, I want to do thisKlaus Leopold 9:04 Now. That's and I think, as you said, it's not just like the Spotify model, I think it's it's almost, I mean, all numbness are big words, but in many frameworks, they give you this promise, like okay, if you just follow these rules, then everything will be fine. Kind of an like from a perspective of the one who is buying something. So we are buying agility, right? So it's really like there is a market of agile coaches and everything and we buy agility. This somehow makes sense. I mean, it's not working, but it sounds like okay, it makes sense. So I ordered this, and I think it's this mechanistic view of an organization. Our organization is a machine, something is broken here. So I call in a mechanic and they are fixing it to kind of and they have the recipe they do it and then everything He's running smoothly again. But that's unfortunately not reality.Joe Krebs 10:03 Right. And that brings us back to the change management process, right? You just mentioned, right, it's like something that can address these specific needs or and so not to think holistically as an entire organization. Go punctual into like, certain areas of your, of your organization. So maybe because you talked about Scrum, a little bit, but your capacity on Kanban, right, maybe one group might in more benefit from Kanban. And other teams and more can benefit from Scrum. And like, just like the drop down kind of approach might not be might not be a suitable approach. That is, that is awesome. Can I Can I just ask you, because I have no idea. Are you a pilot? Klaus Leopold 10:41 No, not really. Joe Krebs 10:43 Not a pilot. Okay. But you, you are the creator of the flight levels model. And I'm just curious if you were like flying through the clouds and landed and kicked off and started Klaus Leopold 10:55 I am flying drones actually. Joe Krebs 11:00 Different, we have different you have reached different flight levels. Klaus Leopold 11:02 That is true. And I spend quite some time in planes in my former life in my pre COVID life. So yeah, there is some kind of affiliation with this.Joe Krebs 11:14 You're the creator of the flight levels model. As far as I can tell. There is a book in the making to be released somewhere in the June summer timeframe. First in German and in English,Klaus Leopold 11:28 yes. Because German is much easier for me than English.Joe Krebs 11:31 Okay, here we go. And tell me a little bit and I'm pretty sure there's some listeners out there was like, alright, flight levels have heard of. But I'm also sure that there are some people out there listening to this and say, What are flight levels? What are flight levels? And how did you can have with the term what triggered that?Klaus Leopold 11:50 Yeah, what triggered that is actually nice story. So it was really like back in, I don't know, 2010, 2011, something like this. So one two years ago. And I was, as he previously said, I was, so my roots are somehow in the in the company world. And there was this company, and we were talking about 340 pitch teams or something like this. And they were like, Okay, make these teams agile, we want to become an agile company. And I'm like, sounds great. Maybe I can, I can buy my Porsche finally. Right? Because that's really that's a great job. But then I was like, Well, maybe it's good for me, because I can really sell quite a lot of billable hours. But for the company, it doesn't make any sense. And I was struggling to get this message across. Like what I said before, it's not about making the single parts agile, it's the single teams agile, more about make sure that the right team is working on the right stuff at the right time. And this is where I was like, Okay, we need to fly a little bit higher. So the team is like the flight level One, we are close to the ground, right? We see how people are working, what are the technical problems and so on. But when it comes to deliver value to the market, we need to fly a little bit higher. This means we need to see exactly what we've said before about the backlogs. Where are the backlogs filling up, what is the sequence of the teams, how they have to collaborate, and so on and so on. So we need to bring the teams together and fly higher means zoom out a little bit. This means this is flight level two. And this is actually how the flight levels came up. So in the beginning, there was just like flight one and flight level two. That's it. And then later, there was also the flight level three, which is like, okay, it's great that we know how to fly now. Like how to work, but Are we flying in the right direction? So this is flight level three, where we're talking about strategy? And these are the three flight levels flight level one is the operational work of the teams, flight level two is the coordination of the work between the teams make sure that the right team is working on the right stuff at the right time. And flight level three is strategy are actually flying into the right direction.Joe Krebs 14:03 And three would also be as far as I can tell portfolio, right?Klaus Leopold 14:07 Yes and no. So it would be the strategic portfolio management, that would be flight level three, and operational portfolio management would be flight level two. So I'm not sure if this if these terms are widely established, but this is how we are using them in the flight levels community. One thing is like the operational management of multiple value streams have multiple flows. So for instance, a good flight level two system could be a product or a service that's directly on the market. And sometimes it's the case that there are dependencies between products, I think you notice right you change something in this product, then you need to change something in another product and they need another product. So we can build another flight level two system to coordinate these dependencies. And this will be the operational portfolio. And on flight level three, we can align actually our portfolio to the strategy. So this is why we try to distinguish it. So because in big organizations, we often don't see this mapping to the strategy, we just see an operational portfolio. Here are our 500 projects, make portfolio management with it, whatever this means, right. And this is a purely operational point of view. And we would like to link it to the strategy, actually, because then our portfolio makes more sense. And this is why we try to distinguish these two terms.Joe Krebs 15:31 But by listening to you, I have to say that is absolutely clear also based on other conversations, but just it becomes clear that our concerns in the Agile space are shifting to other conversations, right? So not so much about the what you just said, the operational level, we might might be good at this point of introducing agility into a team always room for improvement. Right. But it we're elevating business agility strategy, portfolio management, these are super hot topics. Now, while you were talking, I was just thinking about one of the airlines I very often fly with. It's very interesting, because they have like on I think it's like a certain channel on audio, they have the cockpit conversations with ground. Klaus Leopold 16:18 Oh, really? Joe Krebs 16:19 Listen to what the pilot is getting. That's pretty cool. And what's interesting is there is a lot of conversation on takeoff and landing. There's a little bit once they are cutting through coordination, and once they reached altitude, there is hardly any conversation it is having handshakes in and out. So I felt like it's also the communication level right? on level one, there's much more going on in terms of communication frequency. Now, I'm not saying accordance way, but frequency check in check out and some more coordination, necessarily, then when you reach other flight levels, I just thought I would throw that out.Klaus Leopold 16:53 Yeah, I would think so. Although I think on flight level three, especially on flight level three. So it doesn't make sense to have a daily stand up meeting or something like this on flight level three. But nevertheless, I see that sometimes the other extreme is there that they're having. I mean, they call it a stand up meeting, but it's something we meet four times a year. So that's not a stand up meeting. So even our flight level three, or especially in flight level three, actually, I would like to see a weekly check in. Because flight level three, it's about the future. And when there's one thing which is really uncertain, then it's the future. So it makes sense that we check in on a regular basis. I'm also a fan of flight level three to break down the outcomes to let's say, your quarterly granularity. So we want in the next quarter, we want to achieve these four things or something like this. And then it just makes sense to check in on a weekly basis. Because I always focus on the outcomes, right? And after one week, if I don't see any movement in terms of progress or confidence, like then, okay, I'm relaxed. After two weeks. Yeah, I'm still relaxed, maybe. But if I don't see any movement in progress after four weeks, or after eight weeks, I mean, someone could ask, can we help? What's? What's going on here? Right. So the thing is, I don't want to wait a quarter to see Oh, we didn't meet our goals, our outcomes. I want to react before I actually see this. And that's the whole point of agility. It's not waiting half a year and then see Oh, yeah. Didn't make it react before. It is. Too late.Joe Krebs 18:35 It's cool. Yeah. So that's what I noticed Ed rail interaction between them right on level three, as you said, right, every time they entered a new airspace, they said hello, and goodbye, and so on. So this is things like, just as you said, it's really cool. Now with your background in Kanban talking about flight levels, and a lot of people think Kanban and I know it's not necessarily the only thing in Kanban is but people think WIP limits . How is WIP limits in general, which is obviously a positive thing right. To limit with how does impact your your flight levels, or does it not have any impact? Positively? Klaus Leopold 19:21 Of course, yeah. I mean, limiting work in process is, is a cool thing, right? So what we want to achieve is we want to value finishing work over starting work because starting work costs money finishing work brings money. So yeah, let's focus on earning money and not spending money. That's like the main idea behind it. And but in the flight levels community, we would talk about creating focus so we WIP limits like working process limits is one way of creating focus. There are multiple ways how you can create focus. And like the main ideas always the same, but like different ways work differently on different flight levels. For instance, WIP limits work great on a flight level One on the flight level two, on flight level three static WIP limits doesn't make a lot of sense, because there is something like, Yeah, time boxing is much better. So that's another way how to create focus, right? So we have started policy. So there are different ways of how to create focus. And yes, from the Kanban world, work in progress limits make a lot of sense. And that's also flight levels is not Kanban. If you're doing like, flight levels on the flight level one, you will probably do sprints or, like WIP limits on a flight level two, it's not always so clear, but whip limits is a good shot. But in flight level three, it's different. Joe Krebs 20:55 Okay. Interesting, right. So, so these, these concepts are not just going to be stuck in like it's like on a team level. Right. And I think that's also important that the agility is shining through and different in this particular case and your ideas here on flight levels, which is, I see quite a bit on LinkedIn. Now when people are saying like flight levels and learn about that. So I'm, I'm super thrilled to see that Agile is elevating right in the community. You also said like business agility is not a team sport. It's a company sport. Right. So, so interesting. I'm always walking by that from a from a adoptions perspective, right, one of the things you're sharing is that business agility, transforming to business agility, transforming to flight levels, I would assume in the same way starts at the top. Klaus Leopold 21:51 That's not a bad place to start. Yeah. Joe Krebs 21:56 Why is that? The reason I have to ask you this is because the grassroots movement of agility in the early days, when I was, you know, like, way when the manifesto was was released at that time, it was very often you're on the opposite side, like with teams and everything using like, nowadays stuck with all the way that we have learned, I would assume, right? It's actually a good place to start on the top.Klaus Leopold 22:21 Yeah. And I think the reason is, more or less the summary of what we've talked so far. Because when it comes to like creating focus, I think creating focus is one, not the only but one key element that makes an organization agile, like shifting the thinking from starting work to finishing work. So from like, yeah, achieving outcomes, compared to starting starting starting, right. And the thing is, if you if you only create focus on the team level, exactly what we have talked before is the thing that happens, they probably create focus in their doing part, but the backlog stay are unlimited, and they are full. So this means you don't create focus in your organization, you still have full backlogs, I mean, you have empty team columns on the board, but all the backlogs are full. And usually the team, yeah, they can decide about doing part in an agile organization, but not so much about the backlog. So work is coming into the backlog. So we need to like, yeah, slow down this this backlog growth. And this is something that you can like, so somewhere in flight or two or unflappable, three. And in most organizations, there are different kinds of responsibilities. I mean, on a flight level two, you probably reach, I don't know, 200 people, 300 people, something like this. So there are different responsibilities. And it makes sense that they understand the power how we're actually what they can do in order to improve everything that's going on in your organization. And that's why I want to start here.Joe Krebs 24:05 Yeah, it's also interesting why it is fascinating, right? Because we are seeing more topics popping up at conferences just around the world, right? there are conferences that focus really on cultural, agility culture, and it's always leadership that's coming in and struggles and these are the challenges and, and you would actually say, if we start on the top, I'm gonna tell you the top level way better than seeing the top in, let's say in an organization, like however you want to see that from an org charts perspective, right. But its leadership would have be very, very impactful. That was very different in the beginning.Klaus Leopold 24:42 And I think the important thing is when I say we start on top 10 I don't mean in terms of sponsorship, because that's what we've seen quite often. So there are some sponsors on top and they're like, yes, we are. You are becoming agile. This has nothing to do with us, right? So, become agile, you have our permission, kind of Yeah, but that's not what I want to see when we are talking about. Yeah, starting on top, I think senior management is, it's an it's an it's an part of the game. So they are they are not the one who are like, giving the money. The other one who have the levers in the hand who are really like, can take the right decisions that, yeah, agility, actually, is this doneJoe Krebs 25:30 adapting to a new leadership style as well? Right having? Right, it's, it's not about writing the check, it's about exactly being part of it. And in also understanding and learning how to, you know, create that organization that we want to call agile at the end, because otherwise, you're absolutely right, which is going to have islands of agility within an organization. And you know, and that might be beneficial for an organization, but just not to the full extent.Klaus Leopold 26:00 There's another thing, another observation that I have. So when when when, like the to check leaders, right, who just write the checks, when they write the checks, it's often that they expect, okay, now we have invested this amount of money, now we can start even more projects. But what you're doing in a case like this, you are again, just filling up the backlogs. And it's the opposite most of the time, when when when you only think like Team agility. Because the behavior is like the expectation is we get more things done. So we can start more things. And this exactly goes into the wrong direction. So in these situations, usually the performance goes down, although you invest all this money. So that's really the tricky part.Joe Krebs 26:51 that is awesome. I'm just at the end of our conversation, which I really, really enjoyed, I have to say, is this great connecting with you. You are releasing this book, which has talked a little bit about or the announcement that there will be something coming out this summer about flight levels. Is there anything like a sneak preview anything you can share what this book will be about?Klaus Leopold 27:14 So I'm actually not writing it alone. I'm writing it with my partner in crime Siegfried Kaltenecker and I also wrote the first Kanban book actually with him together Kanban change leadership. And yeah, so it is about flight levels, actually. So what we are doing there, we are basically presenting the latest set of misunderstanding when it comes to the body of knowledge of flight levels. So we talk about flight, what is flight level One, flight over to flight level three, how you build flight level, flight level two boards, how you build flight level three systems, how you do like change leadership, that's actually cities, cities part. Yeah, how you bring managers on board, how you bring the people on board, so that the change actually sticks. We also talk about the actual change process, and all these kinds of things that we actually teach in flight levels Academy. So it's kind of the reference book of the stuff of the workshops that we teach in flight levels Academy.Joe Krebs 28:17 Wonderful, that's awesome. And for everybody who can speak or read in German, they will have the opportunity to enjoy that book a little bit earlier than the English speaking audience will which be slightly delayed.Klaus Leopold 28:31 So I think so I guess the publishing date is June 17th for the German one and we will kind of like incrementally publish the English book chapter by chapter and hopefully the first chapter is also done already by June. Let's see. Joe Krebs 28:47 Sounds like an agile approach.Klaus Leopold 28:49 Now, how crazy is that?Joe Krebs 28:52 Thank you, Klaus for spending a little time with me, the listeners, agile FM and I'm looking forward to the release of the book and the development of flight levels in general. Thank you so much.Klaus Leopold 29:03 Thanks, Joe. Thanks for having me. It was fun talking to you.Joe Krebs 29:06 Thank you for listening to Agile FM, the radio for the Agile community. I'm your host show Gramps. If you're interested in more programming and additional podcasts, please go to www agile.fm. Talk to you soon.