Joe has a book “Agile Kata” in the making, if you like to be the first to know when it launches, please visit www.agilekatabook.com.Transcript: Agile F M radio for the agile community. [00:00:05] Joe Krebs: Thank you for tuning into another episode of Agile FM. Today, I have Dr. Jeffrey Liker with me. You probably know from a, I would say, famous book with the title The Toyota Way. That is a book we want to talk about today a little bit, but there's so much, much more about Jeff, he is a professor of industrial and operations engineering at the University of Michigan.He's president of Liker Lean Advisors, and as I said, he wrote not only the Toyota Way, but he also wrote, if I did the count right, nine other books. That relate to Toyota, and there are two books that more recently were published and we'll have a chance in a different episode to talk about those.One was in June, 2023, Giving Wings to her team with Tilo Schwartz, and we have Engaging the Team at Zingerman's Mail Order and that's more like a comic if you want to see it this way, and he co authored that with Eduardo Lander and Tim Root, so that is the The list of books if I haven't missed anything, but we want to talk a little bit about the Toyota way before we do that.Welcome to the show though, Jeff. [00:01:13] Jeffrey Liker: Thank you. Joe. [00:01:16] Joe Krebs: Awesome. So the Toyota way initially released, I believe 2000, somewhere three, two, somewhere that this book we're talking about is the Toyota way. Second edition. This is also very important. We're talking about the second edition of which, which was released somewhere in the year 2021. Timeframe. [00:01:34] Jeffrey Liker: Yes. Three, about two years old. [00:01:36] Joe Krebs: Yeah. And but there is something that happened in that book that is fundamentally different in, in terms of I, I don't know all the change log and everything, but there's one fundamental change, and that is the inclusion of scientific thinking.[00:01:52] Jeffrey Liker: Right, right. A little over five years ago, Mike Rother than I jointly gave a presentation and the book hit my book Toyota Way was 20 years old. So the 20 year anniversary, and his book to Toyota Kata was, I believe, 10 years old, and. We started talking about the relationship between the two.Mike was one of my students and he had practiced lean transformation for many years and was very familiar with the Toyota way and all the concepts of Toyota and studied Toyota. And then he came up with this thing called Toyota Kata. And I had to kind of struggle to sort of figure out what it was and what he was trying to add to what we know about Toyota.And. What he really did was to reverse engineer what Toyota, we call him Toyota Sensei. Sensei is like a master teacher. So what the Toyota Sensei, who are experts on the Toyota production system, do when they work with a new client outside of Toyota, how do they teach it? And they always teach by doing.And he had a chance to see a lot of companies that these different Toyota masters worked with and their masterpieces. And. Asked the question, What do they have in common? And they're all very successful, like they almost won't even bother working on a project unless they can at least double productivity.And that just happens almost automatically. And so he knew that they got great results. But the question is, what are they doing. And in fact, each of these masters. It has a bit of an ego, and they think that they're doing it the right way and the best way, and nobody else can do it that way, the way they do, but he found an underlying pattern, which he called scientific thinking, and what he noticed is the first thing they do is they grasp, they call it grasp the situation in Toyota, they go in, they see what's going on, they talk to the top leaders, and they ask, what is it that they're trying to accomplish?What is their goal? What is their purpose? What are their goals? Why do they want to learn about lean management? What is their vision for what happened? If they were successful, then they go to the Gemba where the activity is, and it could be a factory that they work. They've worked with where they gave you injections for COVID 19.They've worked with where they made ventilators for COVID 19. They've worked with software houses where they develop software. They don't really care when they will go to the Gemba and they'll see the process and understand the current conditions. So then they'll go back, they'll grasp the situation generally, and then they'll go back and they'll say, here's where you're at.Here's the challenge for you. Yeah. And the challenge is always big, you know, like we will double productivity or we will reduce costs by 30 percent or something pretty big based on the needs of the company may have runaway late deliveries and there's paying a ton for a premium freight.And we'll say we will eliminate all shipping and then they will go back to the Gemba with a team of people from the company. And they will teach them how to see, how to understand the process as it is. And Mike calls this the current condition. And then the people in the company will basically wait and expect answers, solutions from the masters.So what do we do? And the masters will say, that's my question to you. What are you going to do? You see where you are, you see where you want to be. You see all sorts of opportunities. What do you think you should be working on first? And then based on what they say the students say, they they may ask them to go back and look some more.Or they may say, why don't we try it? Usually what these people come in the company, come up with, because it's a big challenge, they come up with a fairly big thing and they, it might be, for example, in a manufacturing facility, moving equipment around and laying it out as a cell and They said a personal last one.Can you do this? And they'll say something like, well, we have to talk to engineering and we have to make sure customers okay with this. We have to line up the maintenance people move the equipment. So, I think we really stretch it. Maybe we could do it in a week. And then the trade master will say, good, I'll be back tomorrow and that like starts the process. Now, of course they can't do it in a day what they might have to do it. They can't get all the approvals. So what the person is trying to get them to do is. You don't have to do a hundred percent in one step. Let's try something that's doable and then see what happens.And then we can learn from it. And then we can think about based on that, what our next step is. Usually what happens is the, like, for example, if they lay out a cell. It'll be a disaster. You'll move the equipment together and they'll realize that the equipment has maintenance issues and it's breaking down and everything stops because they don't have inventory anymore.And usually they can't, they barely make product and the you know, the mentors say, that's okay. Let's start working on the problems down now that we see what the problems are. You were hiding them before. Now let's start working on the problems one by one. So Mike saw that, and he saw it enough times, that he realized that what the, these Master thinkers were doing.We're not teaching tools and methods like most of the Westerners were doing with lean. They were teaching a way of thinking. Yeah. And it was actually very scientific. What's your goal? What's your current condition? Right. You know, fairly precisely with measurements and direct observation. And then let's not try to in one step get to the challenge.Let's break down the problem. And all we really need to understand is our first step. And then after that, our second step, our third step, and each of these steps were structured like experiments. They might ask them, what do you think will happen if we make the cell? And then, you know, the people will say, Oh, well, our productivity will go up or quality will go up.Let's see what happens. Yeah. It's a disaster. Yeah. So what did we learn from that? We learned that we have a lot of problems that we've been hiding. And now we can see the problems we have to solve them. So, and also they're trying to teach the value of running the experiment, learning from it, which then gives you the next step and gives you the next step.So that became the basis for what. Mike call Toyota kata. The other part of it was in the meantime, he was studying about neuroscience and cognitive psychology and how we learn and there's a lot of literature that suggests that none of us are natural scientific thinkers, right? We're driven more by biases and the desire to know things, whether we do or not.So we want a lot of certainty. And we want to be right. We're going to, in fact, fudge the data to make it appear that we're right. That's called confirmation bias, which is really strong in humans. So he realized that to change people, to start to think and act scientifically requires fundamental behavior change.That's right. Yeah. It means changing our habits. And then he asked the question, how do you change habits? And the literature on, on, on cognitive psychology and neuroscience, as well as Practical experience, for example, with coaching sports teams, it all says the same thing, which we have to practice repeatedly with feedback.And it's very common enough times it becomes a new habit. So then he said, asked, how do you, how can we practice scientific thinking? And he said, first, we need a model, which we have, which is challenge current condition, first short term target condition, then experiment, then second target condition and experiment.Then third target condition and experiment. And. Then he said, how can we teach this? And each of those steps has some associated ways of thinking and tools and think practice routines, things to practice. So he laid that out in what he calls the Toyota Kata practice guide, which is pictures and step by step instruction, like, Like a recipe book and he came up with kata, which comes from the martial arts, which mean small practice routines to teach us complex skill by breaking it down and trying the pieces one by one karate.They'll have the first kata and move the second kata until you learn the first kata. That's right. Correctly. So it's an evolution. Yeah, and usually think about, you know, taking a music lesson until you can play the very simple piece. They want. Go on to the next more complicated piece. All right. So, that led to the whole Toyota Kata, which is a model plus the practice routines.And as you practice them, you begin to think more naturally in a scientific way. [00:11:20] Joe Krebs: Right. So what's interesting is so when I started looking at Mike Rothers work right on, on Kata, and obviously I read your first edition, came in to the second edition and it just like became more and more eyeopening is these habit changes or like a habits we have and habits we want to change that's the same in the agile community, right?So we have certain habits of how we. build software or how we release software and go through transformation and all these cultural changes. So it's just like this meta skill. If you want to see it this way, that, that's that's fascinating when I came across this now, I do want to make sure that If I understand this right, this is obviously not that in 2021 Toyota started with scientific thinking.It was there before, right? It is like something that was carved out as something like it should go into the Toyota way as this core thing. So if you look at [00:12:10] Jeffrey Liker: Yeah. So that was the, we ended up giving a presentation where we said Toyota way and Toyota Kata play well together as if there were separate things.And then thinking about some more, I realized that scientific thinking really underlies. What I called in the Toyota way, the four P's of the Toyota way. The first was philosophy, which I refer to as long term systems thinking. And the second is lean processes. The process of trying to work toward one piece flow.And the third is developing people. In problem solving, which is the fourth "P" and I realized these all are connected through scientific thinking, right? And if you're not thinking scientifically, you can't do any of them. For example, you can't be a system thinker. Yeah. If you're a jelly non scientific thinking is reductionist.We assume every individual tool operates on its own. So we implement Kanban to get inventory reductions and we implement standardized work to get productivity improvements. So we're seeing isolated tools as opposed to a whole system, which is what Mike called the Toyota production system. So with that, I then started to rethink the book from the point of view of scientific thinking, being at the center.And also realizing that you can't really talk about lean as if it's a bunch of mechanistic pieces that you individually build and then they just all suddenly fit together. You have to talk about more of an evolutionary learning process. Yeah. Organization. [00:13:48] Joe Krebs: Yeah. This is interesting. So, I have never consulted for Toyota myself but I was told that the word Toyota Kata does not really, it's not a use, it use Toyota.[00:13:58] Jeffrey Liker: That was not their word. It was Mike's. [00:13:59] Joe Krebs: Exactly. Yeah. [00:14:00] Jeffrey Liker: Description from the outside of what he learned in Toyota. And then he went further and say, the Japanese sensei, they tend to be pretty mysterious Yeah. Yeah, it's light. For example, do it tomorrow. Yeah, we'll come and see. So what should I do now? What do you think you should do now?Yeah. So they tend to be mysterious, but he realized that if we want to mass distribute this to people that don't have access to those magical Japanese, we need a very explicit and simple methodology. So he developed in great detail, this methodology that in Toyota, they wouldn't think they had to use because they, what they say is that from the day you enter the company, the culture is so strong.You begin to learn Kaizen. [00:14:49] Joe Krebs: Yeah. Interesting. So, what was that one of the reasons why you decided to call that core scientific thinking, or was it more like, because it's the thinking and not the tool, it's not the pattern [00:15:00] Jeffrey Liker: thinking now it turns out. You go back to the first Japanese pamphlet. Really? It was a document for the first Japanese document that describes the Toyota production system.It says that it's based on scientific thinking. So for people in Toyota, that's not. Unusual. It's not a stretch, but they, and they think of scientific thinking more empirically than theoretically. So there's theoretical science where we just. In the abstract. And then we deduce from that things and we apply the abstract model to a problem.And then there's inductive science where we look at the phenomena and the empirical reality. And then we induce from that principles and solutions. And so in Toyota, they learned that you need very specific solutions to very specific problems. Yeah. Not general solutions to a whole general class of problems.So you need both to some degree, but they're much more focused than most on solving this problem right here, right now. Yeah. So when they see product development in software, we're developing a software program, they see it and maybe they see it as a part of product development, but they're not going to come in and say, here's your 10 step roadmap to great software.They're going to ask, what is your problem? What are you trying to accomplish? What's your goal? Let's go look at your current process. So they want to know the specifics of your situation and your goals. And they want you to learn how to think scientifically, to learn for yourself how to achieve whatever goals you have and adapt and adjust as the environment changes.[00:16:45] Joe Krebs: It is, it's fascinating also when I open up your new book, the second edition, right? There's also a thing where you design a I don't know if that's the content of your masterclass. I do know that you're teaching a lot of masterclasses but it's really the transition from a mechanistic lean, right?Organic lean. And if I go through the list of the organic lean, this is just like, it just translates for me, for somebody who has been now, you know, using, learning, applying Kata thinking more and more it just links like one, one, one to one, like two to the scientific thinking too, right? [00:17:17] Jeffrey Liker: Yeah, the other part is that whatever performance improvement program you have, Whether it's lean or agile or theory of constraints or whatever.If you look at it from what I call mechanistic point of view, then you're trying to fit square pegs in the round holes, you know, your problems, I want your problems to fit into my model. . and the other expression pill uses, if you have a hammer, everything looks like a nail.So, You can apply Lean, you can apply Agile, you can apply Six Sigma mechanistically, or you can apply any of those things organically. You start organically, you start with a problem. You want to engage the people who understand the Gemba the reality the best. And you want to teach them how to think differently about their process.So they developed the skills of problem solving and performance improvement, and you expect to be surprised and you expect that you won't know the answers until you start digging in and trying things, Mechanistic point of view, you, I have the solution and I'm going to sell you the solution, even though I've never been in your place.I've never seen your process. I don't know anything about. Yeah, I have the solution for you. That's kind of taking this abstract solution and assuming it's going to apply in the abstract to any similar type of problem. Staying at that theoretical level. [00:18:49] Joe Krebs: This is this could I want to just take one example.You know, I want to hear your opinion about this as you do teach these classes, right? When you are surrounded by leaders in those workshops, and you do talk about something like, yeah, I find like the right line here. It's not about like organic, Lean. It would be, it's not a project. It's a journey.Right. And I would just like to hear like what kind of responses, what do you hear when you introduce a concept like this, in terms of continuous improvement and it's a journey or it's a. From a cultural perspective, it's not like an initiative that starts here and ends in by the end of March or any arbitrary date you, somebody might pick it as an ongoing activity that obviously shifts from a leadership perspective, entirely the view, like, what did you hear when you challenge people?[00:19:39] Jeffrey Liker: When I teach the masterclass, the people that usually come have titles like director of continuous improvement, vice president operations excellence and then I'll get some people who might be the head of operations or plant manager, but and you're probably this is self selection, but they all agree when we talk about it.That the approach they have used in the past was very mechanistic and the approach that they believe, particularly after they see it in Toyota. So we do this with Toyota is they see the value of engaging all the people and Leaders acting more as coaches than as disciplinarians. And they said, that's what we need.So they, they conclude they want to move toward a more organic approach, but then they also feel a little bit concerned and nervous because I said, you know, my boss's boss expects immediate measurable results from everything we do with lean. And if you're telling me that it takes time, if you're telling me that it takes investment in developing people.And there's a gap, a time gap between the investments we make in developing people, for example, teaching them using Kata and the results that we get, we're going to have a hard time selling that. So what we ended up concluding usually is that you need both, that there is some value in the experts coming in with the tools, eliminating waste and streamlining processes and getting.Quick results on a more expansive part of the organization. Cause these people are coming in with big companies. They might have 30 or 40 or 50 manufacturing plants and the, and that there's a value in piloting within a smaller area, some of the deeper approaches to changing ways of thinking and changing culture with the successes you have in those models.You have something to sell to the senior management, come and see this and see how much better they perform. So that's usually the kind of vision they have is that they have to somehow find a balance. And I have a slide that shows like, the balance of justice and they have to find a balance between the more mechanistic, quick, short term and superficial approach.Deep and a mile wide. And that's deploying the tools and then the more deep one inch wide, a mile deep, the more deep approach to developing people one by one that you would be doing with Kata. So they have to find a balance between those things, and they have to figure that out there through their own scientific thinking journey.They have to figure it out inside their company by trying things by experimenting. So I asked him instead of leaving here with a whole bunch of solutions. that you're going to bring and implement your company, think about one big challenge that would really make a difference. Your ability to deploy lean, sell lean and define that as a challenge.Then the next, what do you do next? And they said, well, we have to solve the problem. Okay. So how do you solve the problem? Do you go back there and say, we need standardized work. We need employ work groups that we saw at Toyota. And they said, no, those are solutions. We have to understand the current condition.First. That's a great, wonderful.[00:23:09] Joe Krebs: Back to scientific thinking.. This is awesome. Your book was initially the first edition came out as we said of. Several years ago, 2002 or something like that. Why do you think at least from the, from an agile perspective there's other terms floating around. I don't want to go into pick any, right, because it's not a complete list necessarily, but why do we.I see like a lack of of these terms actually like being used on a more broader level, right? You have sold so many books and people are looking at this and saying this is wonderful material, but the implementation, it seems to be slow in the transition. Like taking companies to lean or even in, in agile transformations, is it, do you think it has something to do with the the culture, like, like, for example, using Japanese terms or something like that?[00:24:01] Jeffrey Liker: Yeah, I don't think that so much. I mean, I think there is sometimes a sense that since this is a car company and you have a stereotype picture in your mind of what a car company does. And the first thing you often think about is the assembly line, where you have cars running down the assembly line and people are attaching things to the car.And you say, well, that doesn't look anything like what I do, so therefore, it doesn't apply to me. So there's a lot of that, you know, we're different. And it could be anything. It could be that we're a manufacturing company, but we make chemical products. It's not like cars going down the line. Or it could be that we're a finance company and we don't make any physical products.Or it could be that we work with a mining company that does iron ore mining in Australia and we go and we blast and we dig and we have this big batches of stuff. And how do we get to one piece flow? So, the the problem is that you have to shift your thinking from manufacturing. Mechanical solutions.Like I'm trying to look over here to get solutions that apply in an obvious way to me. You have to shift that thinking to there are some general principles here that have been abstract abstracted that I can then bring to my operations and the people who are well trained and lean or in Kata get very comfortable going into any new environment and not knowing What the solutions are, and then digging in and trying to understand the current condition of that operations.So this idea of I think the first easy thing to do is to copy solutions like a template. But if you give me a template, I'll just superimpose on my process and I know what to do. And the harder thing is to take a more abstract concept, like I need to define a challenge., even when I take my classes and I asked them to define a challenge, they struggle, you know, the challenges we want to have a culture of continuous improvement.Well, that's way too abstract. And then if they say, well, the challenges we would want, we'd like five suggestions per employee. That's way too specific. . So finding the right level of the challenge, you know, itself challenging challenges are thinking. And then what do you look at in the current condition?If it doesn't look like a Toyota plant where you can say it takes 60 seconds for each car and we can break down the steps of attaching window wiper into a reach that takes 2 seconds and, you know, They that's their current condition analysis. Your current condition analysis may be very different if you don't have a routine repeating process.But there are ways to understand the current condition in any sort of process. And even and I remember Deming saying that if you don't think you have a process, you can't improve anything. So, that even that idea that, you know, we develop software, and every software project is different. And the process is that we understand what the customer wants, and we do it.There's no process beyond that. You know, so that Just understanding there are processes, there are habits, there are routines that you have and you need to shine a light on them and understand them, and then figure out from where you are how to start to move in the direction. of the ideal model you have in your head.That, you know, it takes a, it takes thinking. Yeah. It's thinking is tiring. [00:27:36] Joe Krebs: Well, that's my recommendation to all of the listeners out there. When I went down the journey and extracted. By doing exactly what you just said, like looking at that material and extracting information saying like, okay, this is not about Toyota.This is not about this. This is about, you know, how would this apply a map to the agile world? I'm just calling it agile Kata out because of the making a dereferencing it to the Toyota. Brand, let's say in this particular case, but the thinking is the same in terms of the scientific thinking, but surrounding it with agile principles and, you know, [00:28:12] Jeffrey Liker: last thing I'd like to say is that as I dug into agile and you and I met.Menlo Innovations, which is kind of a benchmark for Agile and software development. And I looked at what they're doing there, which Richard Sheridan we're doing. And I saw lots of similarities to the Toyota way. And I saw also a lot of similarities to Toyota Kata. And I met, worked on Zingerman's mail order with Tom Root, who is one of the owners.He was originally an IT guy. So the backbone of the mail order business is the IT system. And what I discovered, and I've talked to you and I've talked to a lot of different IT people, what I discovered is that a lot of the concepts of scientific thinking are actually quite natural for programmers, you know, see, if I think in terms, if I say we need to think in terms of systems and how the parts interact, and I go into a manufacturing environment, they might think Treat me like I'm from another planet, but the software guy will say, of course, and then the idea that you have to have a vision for what the software is going to do and understand the customer.And then you have to break that down into small elements of some sort. Call them features, and then you need to develop one feature at a time and then compile them, make sure they work together as a system, and then build the next feature and compile it. And it's a step by step learning process, breaking the big problem into small pieces and then solving each problem one by one.That idea just you know, a software program said, how do you do it any other way? So the high level model of the Kata makes perfect sense. Within the world of software development, but how to do that in a sort of structured systematic way and make it part of the culture and natural.For example at Menlo Innovations, they do unit testing. And if I say unit testing to a software program and say, of course, we know what that is. Let's go and see your program and show me the unit test you've conducted. Exactly. And this kind of, yeah, and it's got to be hopefully more and more examples like this, right?Than than the one you're naming. And so I think somebody might be listening to this. Or reading the second edition of your book of the Toyota way might be building these bridges to whatever environment they are in, right? About in, in the Toyota way I do write about Menlo innovations. And so I, so that's another thing I did in the new edition is add more service examples and software examples and examples from other places, which I didn't have at the time I wrote the original book, I was just describing.So that's in the book. And it. The thinking way is still the same and one of the things that happened with Richard and to tell you the truth is that he started to get kind of turned off by a lot of the agile examples he was seeing, because they like the lean folks were often simply using a tool.Be that agile was almost equivalent to writing things on post it notes. Yeah, and he has all culture. He calls it deliberate culture. He had to develop the whole culture. Out of pairs, paired programming and programs learning from each other and sending what he calls technical anthropologists out to the customer to really deeply understand the Gemba and how they're using software and getting the customer in week by week, every single week to test the software and give feedback to the team.So there's a whole set of practices that he had to create as the standard for the culture of Menlo. That it took an awful lot of work and it was much more than buying a lot of post it notes. [00:32:08] Joe Krebs: Yes, and maybe that was one of the reasons why he decided when we all agreed on we're going to meet in Ann Arbor and it was in September 23 we'll all come together and it was Mike it was you and several others and Richard Sheridan was the first one who says and count me in and I'm offering my office space for this because it's so important.[00:32:25] Jeffrey Liker: So yeah, well he yeah so he didn't understand Kata at first but then I understood it. And he said, yeah, that's pretty much what we do. Isn't it? Then he had to, you know, he then added some things to what they do because they weren't working in a deliberate way using the scientific approach of kind, but the overarching way that they worked and developed all their software was very much the vision, current state, right down to small pieces, solve one problem after another with very quick feedback.Correct feedback, then get it to work. One of the interesting things about Menlo innovations projects, cause they're developing customer software, none of it's off the shelf. And they, if they do a one year project in the 52nd week, the only thing they have to get right is one week of work because 51 weeks of work works perfectly.So there's basically zero, almost zero rework and they have a hundred percent customer satisfaction. The customer takes the software out of the box and they just start using it.. [00:33:37] Joe Krebs: I want to thank you Jeff for some insights on the second edition of the Toyota Way. If the second edition is It's only somewhat successful as the first edition in terms of sales of books.Thousands of books will be sold and thousands of readers out there will be exposed to scientific thinking and it's a good thing through your materials. I want to thank you for that. And also, yeah, just like, to everybody out there, if you are interested go to the show pages, I'm going to list Jeff's books and obviously ways of learning about Kata in a way to apply that in the agile context, I have some additional pointers here of where to go, what to do first and second, and obviously the Kata Bookshelf is growing thanks to you, Jeff, too, and and many more ways to learn about scientific thinking.Thank you, Jeff. [00:34:27] Jeffrey Liker: You're welcome. It's my pleasure, Joe. Take care then.

Joe has a book “Agile Kata” in the making, if you like to be the first to know when it launches, please visit www.agilekatabook.com.Transcript: Agile.FM radio for the agile community. [00:00:05] Joe Krebs: Hi everyone, I'm back with another episode in the Agile Kata series. We're going to explore the topic of cultural and learning and how that relates to color and scientific thinking. And today I have Katie Anderson with me, who wrote the book, learning to lead, leading to learn lessons from Toyota leader Isao Yoshino on a lifetime of continuous learning.And there's a lot of words in it that are relating straight with Kata. Katie, you have been on this podcast before we talked more in depth about the book. This is a little bit more in depth about Kata and how it relates to your book that doesn't mention the word Kata, but there are so many connections and synergies.We got to explore that area a little bit, but first and foremost, welcome. [00:00:53] Katie Anderson: Thanks, Joe. It's great to be back and dive into this conversation with you. I'm so passionate about how, as individuals, leaders, we create learning in our organizations and the patterns and routines about how we do problem solving and coach for problem solving is just so fundamental to that.[00:01:09] Joe Krebs: Absolutely. Now, I have to admit, I listened to your book recently the audio version of it. And in the, so I was listening and in all aspects of life, but then it all came together in the last chapter when you summarized the learnings from the book and summarized, and the word kata wasn't mentioned in the book.But it just screamed cut up everywhere. And I was like, I have to have Katie on the show again, and we need to talk about this because it is about continuous learning. It is about failure. It is about what is it failing or falling seven times and getting up eight times. Why? And things like that.So all of those characteristics you're mentioning in the book are important. Did Isao ever mention the word cut out in your conversations? [00:01:52] Katie Anderson: So no, and actually when Mike Rother's book came out and, it was a little before I met Mr. Yoshino, but we as caught the term Toyota Kata and the word Kata, actually means something in Japanese.It's the routines and practices that, support something usually used in martial arts. And the way Mike Rother used it was around how do we create learn habits of learning the patterns that we go through for problem solving and coaching for problem solving. And in the English language, that's now become ubiquitous with, with Kata means that around problem solving.Mr. Yoshino though, there isn't something called Toyota Kata it's what Mike Rother and other researchers, when they went to Toyota to observe what was happening, trying to undercover that, uncover that secret sauce. They, he observed this pattern of how leaders and managers were showing up.To help people go through a problem solving process. And he said, there is this unspoken or undocumented routine that people are doing. And if you read my book, you will see from Mr. Yoshino's 40 years at working at Toyota. So we cover from the late sixties to the early two thousands, all of his experiences about, how to learn how to problem solve and then how to coach other people through problem solving. Go through this same format. How are you asking really effective questions? How are you guiding people through a learning process and not coming up with the answers? How are you setting the direction, providing the support, and then also continuing to develop yourself as a coach and a leader as well?So the reason I didn't use the word Kata or Toyota Kata in the book was because it didn't exist at the time. There wasn't that label that we now have at the time that Mr. Yoshino was in Japan, or at Toyota. [00:03:35] Joe Krebs: And the book itself was called Toyota Kata because of publishing, not necessarily something that is Like a tool that was developed from [00:03:43] Katie Anderson: no, absolutely.So I take people to Japan on my executive Japan study trips and I'll have people in the past. I've had different participants say, are we going to see Toyota boards up at Toyota? I'm like, no, you won't because this was a framework that was developed to help us outside of Toyota. To learn the pattern to practice the kata, the routines that support this.And so then there, there are a variety of tools that can help us do that, but they don't, that's not what exists at Toyota, but that pattern of the mindset and the behaviors exist, but there, Toyota leaders are not walking around with the five question card and going through this. That's a tool to help us learn that pattern that is inherent.I opened the book, you'll remember this Joe of a quote from Mr. Yoshino from early days when I was interviewing him, half a decade ago, he said the only secret to Toyota is its attitude towards learning. And that's exactly what Mike Rother was documenting and Jeff Liker and others and Jim Womack and so many people, they were documenting and seeing this attitude towards learning, but it's really hard to describe that, right?It's easier to see the tools and the outputs of it. [00:04:52] Joe Krebs: Yeah. So this is very interesting, right? Because you actually in that chapter, right? In, in that final chapter of your book, you do mention words like setting the direction, a challenge. Personally or for the organization or as a team is important experimentation is important.Now, within the book, there is I don't want to take the entire book away. There's a ton of things to be explored, but there is an example of a failed experiment, a very costly failed experiment from Mr Yoshino. And that is from a Kata perspective. Obviously an experiment that failed that's at a large scale, right?And a big learning, I would assume would come out of this exploring new business ideas within an organization, even on smaller scales, I'm sure there were tons of experiments going on in his life and what you have observed, obviously working with the organization and with him directly. How important is that from a learning perspective, that experimentation piece?[00:05:51] Katie Anderson: It's fundamental, right? The reason we don't know the answer is because we don't have the answer yet. And so we need to know directionally where are we trying to get to and then learn our way forward. And so a lot of, if you take away the, the terminology, so much that you've learned through reading this book and from my conversations in the series, are those same patterns?Like, how do you set a target? But doesn't don't worry about it being too precise. You'll learn your way forward as you start doing the experiments. It's about how do you ask those questions? How are you go through the process of learning? You'll remember there's a story where Mr Yoshino was asked to Put together a report and a document and his boss who had asked him to do this.When he went forward to present, he said, what was the process that you took to prepare this report? And he knew he should have gone out and actually done interviews, gone to that quote unquote Gemba and said he went to the library because he didn't feel like he had time. And the boss said, no, that's not the right process for the learning.And so it's that same model in the Kata Kata world or Kata framework that. You want to coach people through the process of learning and not necessarily giving them the answer, but giving them the framework and the structure to be learning their way forward to that answer as well, or to a new answer that you don't even have, right?Oftentimes we're in these complex environments. We're not just giving people assignments for learning their way to us, a set predetermined answer. It's about learning our way forward to innovation and to continuous improvement. [00:07:16] Joe Krebs: I remember that that scene in the book.And it was also, it was interesting for me coming from an agile and from a cutters perspective. One thing was in, in that particular dialogue, I remember it crystal clear now that after you said it is probably not enough research was done on the existing current condition, right? So like, where are we right now in, in terms of the process?It was just not enough to read about it and go to the library. So one of those learnings, right? And that is the scientific thinking of Kata to say step back, slow down, go through where you are in, even in your learning journey. Now that's a key aspect of this one. [00:07:54] Katie Anderson: Absolutely. And I want to emphasize too, that like Kata, as we, that using that term Kata, it's nothing new.Absolutely. Different. So it's not separate from like how we approach continuous improvement, how we approach the scientific method. It is the routines and practices that help us get there. And there's people in the lean world or the agile world. And honestly, it doesn't what we label it.Those are like the tools and the processes. But Fundamental thinking and human behavior aspects are all interrelated there too. And so again, Kata is just those routines and practices that help enable us to be better problem solvers and better coaches of problem solving. [00:08:33] Joe Krebs: I always refer to it as a universal pattern rather than a tool.It could be described as a tool, but sometimes people feel like a tool is like a, like an actual thing, a tangible thing. It's a thing. It's a thinking pattern, in my opinion, most likely gets you through scientific thinking. And if we can agree on that scientific thinking is a good idea it's a good idea.[00:08:53] Katie Anderson: Yes, absolutely. And so there are tools that support that you can have a kata storyboard or a question card that helps you practice, but it's the same thing with anything like learning a sport or something. You have tools that help you practice that pattern in that routine. So it becomes habitual.[00:09:08] Joe Krebs: By in a second, second nature of what you do and then sit, therefore you don't need the clients anymore. I think that's a, that's an important thing. Now, what you just described, this is also something I found as a quote. Be patient, it takes time to develop people and accomplish challenges.That was one of those things I carved out and I think that plays very well with what you just said. It's even though it Kata the routines, the questions, it might be simple. There might be a card, there's a starting point. It's not a quick fix. No. Why is that to establish a learning culture like to stay here on topic for culture and learning and everything.What makes this so fundamentally simple, but it is so hard to do so patience becomes an important thing. Absolutely. It's a long term it's a long term way, creating new habits. It does take time. And we, and I talk about this a lot in recent episodes on my own podcast chain of learning.We are caught in this like doing trap opposed to the being trap we get. Very focused on the achievements, the goals, the outcomes that we need. And it's not that we don't have this vision that we want to be someone who's, taking the time to ask the questions to coach, but we just get stuck in this, focused on the outcomes and the doing.And so when we can take a step back and say. Actually, when we do slow down to ask more questions to help other people learn how to solve problems, we collectively actually will ultimately get there faster because we're going to have better ideas. We're going to have more clarity on what's the real problem we're even trying to solve.And then the creative input. of people on how to get there. So we'll come up with better ideas as well. And so we just started this, we get this short fix, cycle, vicious cycle where the practices of the kata really can help us slow down and remind our, remind us to ask those questions.Have we clearly defined a target? Do we really know what that next step is? Have we defined what the gap is? What are the next steps we're taking, doing? And just get us into that pattern opposed to just jumping to solutions or to action when we really don't even know where we need to go.And also to frame things as experiments. And I think that's a really important part of this is framing everything that we're doing as an experiment. If we do this thing, what do we expect to happen? And then it gives us a place to come back and say what did we learn from that? And how is that helping us move forward?And I think let's stay with this experimentation piece for a sec, because I also think that's a cultural thing, right? So we, or I have observed that failure in an organization of an experiment is very often as a negative. Association with it right within the business world. Not so much within laboratories or so.I would assume that's not my that's not my expertise, but it's not very common to have a culture within organizations to foster like. So when you're saying like I don't know if I quote this right here for seven times, get up eight. How many people can fail for seven times within an organization without ramifications within an organization?So how important is that from a leadership's perspective? And obviously Isao Yoshino was part of a leadership team to create a culture like that. So that experimentation is happening and But not tolerated, but encouraged, right? And also the failed experiments that go along with it.Potentially. [00:12:21] Katie Anderson: Yeah, there's so many different ways that I could start going into that framing of that. But absolutely. So starting with absolutely moving from a culture of blame to a culture that embraces failure as a source of learning is critical. So if we're looking at the process and not blaming the person.Second, it's about. Making sure that our experiments are not so like we're doing micro experiments so that the failures are more of a micro level, right? Opposed to, sometimes we do so much planning, planning for this massive thing. And we haven't done any tests of along the way.And so then, it's much more the impact of a failure is so much bigger at that end, rather than if we had done some micro tests along the way and having that learning. And I think in our culture we do we put so much emphasis on the planning side. The plan and the do, and we don't have as much of that study and reflect.And so because of that planning, then we're taking action, but if we fail on that, it's so much bigger. And so then it feels more, catastrophic. And of course we don't want people getting hurt, things happening. Like we don't, we need to, those are bad. Those are really bad failures.And that's hugely problematic and we should have been doing better tests of change before that. But even as you, you mentioned, earlier in this episode, that. Mr. Yoshino was in charge of this large new business venture that ended up costing Toyota like tens of thousands of dollars when it failed, but also you have to be willing to run those experiments because if you're, if you want to create innovation in your organization, you have to be willing to take some risks.You don't know if something's going to succeed or not. And so they also knew that they, Mr. Cho, who was the president of Toyota at the time said to Mr. Yoshino, You were something, you tried, we gave you a mission and you did your best. And thank you. And the Toyota too, there were some things, some management decisions that impacted the business venture not working out.It wasn't just the result of one person. So that's super important from an organizational standpoint as well. [00:14:16] Joe Krebs: It's also leadership, right? You have a challenge for a team or an individual to be able to experiment within certain boundaries, right? And be safe and knowing what the challenges are and have a direction, not just experimenting for the sake of experimenting.[00:14:30] Katie Anderson: Absolutely. Yeah. And the leader's job is to set up the working conditions for people to be successful. And so that's part of their role. What are the structures and conditions that allow people to do their best work and to learn along the way? Yeah. [00:14:43] Joe Krebs: It was also interesting for everybody listening to this from a lean perspective, like this plan, do check act kind of cycle would be part of each of those experiments that would be taking place within the Kata, within the pattern.You will find lean concepts in what we're talking about here as a general thinking process. What's also interesting was the words you used throughout your entire book about Lerner and coach and coachee or learner in this environment, because that is all, when I started reading or listening to the book I was like, always reminded is this about learning.This is not about a manager and a subordinate. It's about a learner from a cultural perspective. And that obviously links directly to Kata as well, whether it's a learner and as a coach from an agile perspective, the learner could be a group of people. rather than a single person.How important was that in your conversations? And by writing the book and what you have learned since the book was published that this, the constant reminder of that we're learners in a day to day practice of improvement. [00:15:45] Katie Anderson: It's so interesting. You haven't, I haven't thought about that terminology. That's something I think I brought in more in terms of describing you, Mr. Yoshino, when he taught, he does talk about, being a manager and a subordinate, and those are just terms that they use, but because this pattern was already embedded into their ethos of how they are, that, that terminology doesn't matter, but it does matter more for us.And so I was really intentional when I was writing the book about how can I translate. These 40 years of Toyota and experience in a way that's really going to resonate and connect with people and our generation who didn't grow up in the Toyota world to understand the real meaning behind things.And so I the word learner and coach are, are, those are really important to me to really emphasize that this is all about the only secret to Toyota is its attitude towards learning. And so how do we stay in that mindset? And so the words that we use can really be helpful and yeah. [00:16:41] Joe Krebs: What was interesting though, was that the roles shifted with throughout the book, right? So sometimes we saw him being a learner versus a coach, right? So we saw the change of the roles, which was fascinating. And that is also what we have in an agile, in a Kata environment all the time.[00:16:57] Katie Anderson: Absolutely. And that's where the, how I came up with the title of learning to lead, leading to learn. And it's. It's a cyclical situation because you're always you're if you have the learning to lead with a, first thing you learn to do this, learn the practice, the kata routines, you need to learn how to be a leader, how to be a manager, how to be an agile practitioner, all of those things, but you also need to lead with an attitude towards learning.And then as Mr. Yoshino said to he was always learning how to be a better leader at the same time. And so we're never stopping learning. We're just in different roles. Sometimes we're the one being mentored or coached and other times we're doing that coaching or we're in teams and we're like doing it all together.So it is, and that's where that concept of that chain of learning. It's actually a phrase that Mr. Yoshino said to me about how he felt so grateful to be joining Toyota. This is in his early years in his twenties, joining a company that really. Emphasize this chain of learning, how are we all learners and leaders together helping improve and grow and become better people solve more problems.And that's, that was really the inspiration for my podcast title too, because how do we all, we're all connected in that way. [00:18:02] Joe Krebs: Yeah. And we all connected through Kata, through your book, through the work we're doing through podcast. This is awesome. Katie, I want to thank you for some of your thoughts and also bringing, thinking to everybody who has read your book and maybe listens to this podcast. It's Oh yes, I've listened to Kata and this is the connection to it. But also for everybody in the agile community to say wow, man, maybe I can use the basic pattern of Kata to improve my role within the organization, right? So I myself have worked with agile coaches that are using Kata for improving their own personal development within an organization. And then they're using it also for teams to improve for high performance. So the sky's the limit, apparently. [00:18:47] Katie Anderson: Absolutely. It's the pattern. It's the pattern of problem solving. It's the pattern of innovate, how we create innovation. And it's the pattern of how we help each other get better. at getting better. And so no matter what you call it, just practice the routines and the patterns. It's going to help you no matter what your industry is, what your, the focus of your work is, whatever challenge you're moving towards, these routines and patterns are just so transformational.[00:19:13] Joe Krebs: Yeah. Katie, you mentioned it already. There is a podcast out there. You have the chain of learning. There is a website that is a kbjanderson. com and uh, but if somebody just Googles the title of your book, learning to lead, leading to learn, they will find you as well. So thank you for coming back on the show and do that Kata special with me. . [00:19:33] Katie Anderson: Thank you. Thanks Joe. It's a pleasure.

Joe has a book “Agile Kata” in the making, if you like to be the first to know when it launches, please visit www.agilekatabook.com.KataCon10 in Indianapolis April 9-10, 2024Transcript: Agile F M radio for the agile community. [00:00:05] Joe Krebs: Thank you for tuning in to another episode of Agile FM. I'm here today with Jim Huntzinger, who is speaking with me about behavioral patterns. We'll talk a little about the history of Kata. This is the Agile Kata series on Agile FM. So my goal is to bring you people closer from the Kata community to the Agile community and build bridges.So Jim is here with me today. Welcome to the show. [00:00:35] Jim Huntzinger: Yeah. Thank you, Joe. It's great to be here with you. [00:00:37] Joe Krebs: Yeah, and Jim, you are with the Lean Frontiers and as the name indicates, Frontier on many things including the KataCon conference, or actually there's different kind of names, but it emerged.And for all the listeners here on Agile FM who have been going to Agile conferences for a long time, and they are hearing possibly about Kata the very first time they would be surprised that this is going into the 10th year, this conference, the KataCon this year in 2024, and it's going to be in Indiana, [00:01:12] Jim Huntzinger: Indianapolis, you have caught a content in Indianapolis.So yeah, part of will be celebrating I guess the 10th birthday for it at the conference. [00:01:19] Joe Krebs: That is awesome. 10 years in the making, obviously, we want to go down memory lane a little bit together. Today there was obviously a starting point where you got exposed into Kata and scientific thinking.And I would like to go back, like, how did this all start for you? And for all the listeners here, what is an interesting piece of information is there is A person out there who started it like way, way back, 1890s, even. So, let's go [00:01:50] Jim Huntzinger: 1830s around the [00:01:52] Joe Krebs: 1830s, Jim, how did this all start for you?[00:01:57] Jim Huntzinger: Yeah. So, so yeah, I'll tell a little bit about, I'll tell my background, which a little bit of my history, which will bring in some of the. Older history that correlates and also a lot with TWI training within industry, which correlates as well too, and that'll actually come together on kind of that scientific thinking and scientific behavior.So anyway, when I came out of school, I my first job out of school was with a company that was a Toyota group company. That was in the process of transplanting in North America to support the Toyota plants. At that time there was the Toyota in Canada, the NUMMI plant, the joint venture with General Motors in California, and the Georgetown plant, which wasn't even started yet.It was, They were still setting it up at the time I started. And I went to work for Aisin, and they were a Toyota group company. And it's obviously a supplier into the transplanting here to supply into those plants. So, you know, part of my responsibility, I was a manufacturing engineer was helping ramp up the manufacturing processes.As we as we ramped up the plant and when I got there, my half the plant wasn't even built yet. So I was there through the actual construction of half the plant and we were doing great components drums, rotors brake boosters, oil pumps, water pumps on my part of the plant. So I went to Japan for nine weeks to train on the processes we had, the products.I went to different Aisin plants. where the products were made Toyota plant and also get training on the Toyota production system, which at that time didn't really have any meaning to me, you know, but we learned it. So came back and went through that ramp up process. To do that. So from there I left because I want to get more involved in the upfront process development because that was done by the Japanese of engineers, of course.So I moved to Wisconsin and took a job with Briggs and Stratton, who at that time, this is in 1990, were one of the first companies to really do some of the this lean stuff, trying to physically do it. So I was brought in here because supposedly I knew something about TPS, you know, haven't worked for Aisin.But the nice thing about that is basically we had a sandbox to play in. The guy I worked for said go find something you're interested in. Obviously it's beneficial to the company and go do it. So we were, you know, implementing flow production at a relatively now, even looking back now, 30 years, 30 plus years at a very rampant rate across the plant.So we did machining. And assembly of small engines for Briggs and Stratton. Now, the nice thing with me working for Aisin, even though it was a Toyota group company had TPS in it versus Toyota. Obviously Toyota is the practitioner of TPS, but their product is a great big, huge automobile. So you don't physically get all those correlations as easily since it's this big product versus when I worked for Aisin who made components.So the components correlated to the components we made at Briggs of doing one piece flow. So we were doing that, putting in standard work. We got involved with the Shingijutsu out of Japan. And we were doing, we internalized our own Kaizen workshops to do all that, implementing this. So in the course of doing that we changed the plan around entirely and actually a very rapid time all considering.And even to this day, let's go back 30 years ago, the basic designs of the cells, you know, one of these slow cells were actually. Pretty good. The things and attributes we did were very much one piece flow. So partially correlating it to Kata you know, one thing with the improvement Kata is you need to understand your direction or the challenge.Well, essentially our challenge back then was One piece flow, everything we did, we wanted to achieve one piece flow. And in that we had machines, obviously mostly machining the, actually some of the grinders I worked with when I got the manuals to them, the date on the manuals was prior to the U S being bombed at Pearl Harbor.So we had machine tools of that old up to an old, every place in between, you know, newer CNC equipment. So we're trying to put all this into true one piece flow. Now, we did that successfully, but the problem is we couldn't get the consistency that I had seen at Aisin of the consistency of output, consistency to tactile.And I, I didn't really know why, but I knew, you know, working for, you know, Japanese company, actually even some of the managers and engineers here, 37 years later, I still stay in contact with. Japanese are humans like everybody else. I knew they had to have some thing, whatever this thing was. That they were using that we just didn't know about and all that.So over the course of time, I ended up a number of years later, writing a couple books were published, one by Jeff Liker and one by Masaaki Imai. Jeff Liker's, I think, first book Becoming Lean and the one by Misaaki Imai, Gemba Kaizen, around 1997. And I read Liker's book and in it, it mentions this thing called TWI, Training Within Industry, in about a sentence or two.And I thought, what, and World War II program. I thought, what the heck does some World War II program have to do with the Toyota production system? Well, that's interesting, move on. The, about two months later, I miss, Imai's book, it has a couple pages discussing training with industries. And I just, I've got to find out what the heck some World War II program has to do with the Toyota production system.So I started diving into it. Just to jump forward a few years, it took me a while to dig. I was calling Washington, D. C., the archives, just trying to gather up information. And eventually, finding that the Depository Libraries of the United States was supposed to have information on it in the Milwaukee Public Library I finally found some information that there was a report done, which I was able to, in the library alone, to get this 300 page TWI, post World War II, written 1945 report.Got it, went to Kinko's, made copies of it, and then sat on it because I thought, I don't know how excited I am to read a 300 page government report. But eventually I went through all the work to get it. So I eventually pulled down and read it and started reading it. And I couldn't believe what I was reading.What I was reading through the report was it was correlating some of the things I had learned, you know, somewhat indirectly at Aisin. And also when we use the Shingijutsu group, some of the verbiage, it gave me the link to the manuals they use during the war. So I was able to start getting those through a library loan.And as I got the first one, the job methods. One is about improvement and read it. The language verbatim in that manual from 1943 was verbatim. What we had learned with like in Shingijutsu and some of that stuff. But now I understood the source. I understand what it's doing. So that kind of started this, the TWI.Now that now the importance of this TWI is if you look at all the main programs, job instruction is about training. Job methods is about improvement and job relations is about leadership and people problems. All of them used. I have some of the cards here. All of them use a the four step four step methodology based on the scientific method.Now the history with TWI because I got into that is it goes back to at least 1830. So a German philosopher and educator named Johann Harbert had developed a five step program to educate kids. Pedagogy. Five step method. In the 1830s. So in Europe, there are people, they called him herbations.So European herbations that followed his philosophy American herbations that did too. And one of them was a guy by the name of Charles Allen, Charles Skipper Allen. And I, and he was one and he took Harbert's five step methodology and he put it into a four step method, methodology that he called job instruction.And he wrote a book. He wrote a book on it. Around 1918. It's like a 500 page book just on the four step method. It's an amazing book. So in depth, but basically that job instruction when we get when the U. S. Got into World War Two, the guys they put in charge of the T. W. I. Program 3 of the four that were in charge of it.One had worked for Alan directly. The other two have been trained by so they pulled that job instruction forward. Yeah. And that became TWI job instruction and eventually pulling from some other, I won't go through all that history job methods, which is I industrial engineering techniques. That really has their base in the Gilbreth, some of the pioneers in industrial engineering and a guy named Alan Mogenson put that into place.So that was the instructing, the improvement, and then eventually job relations was leadership. So that comes into Toyota post World War II in the early 1950s, as Ono had struggled implementing flow production, trying to emulate the Ford motor company. One piece flow, as we call it today. And he'd struggled with it in their machine shop for about eight years.When the TWI program came in during the post war occupation through their training department, Ohno grabbed onto that. J I all three of them, J I J M and J R. And that's when he started succeeding. Yeah. So see implementing flow production, trying to emulate early Ford motor company. Yeah. So it's all based on a scientific method.[00:11:12] Joe Krebs: Absolutely. And this is, I think this is where we're, we want to go with it. It's the second, this is a great that you're going back in time because I think this is important for everybody to see that this is not like the latest, greatest trend that just emerged just recently. And we'll you were talking about Kata, you know, in a brand new way this has been a well established thinking patterns.Now just to go quickly back to this Johan n Harbart he if I understand this, right, he applied this in a five steps. But that was more on the educational level. He's redesigned instruction for kids in schools, I would assume, and colleges. And so, [00:11:50] Jim Huntzinger: Yeah. So it's for educating kids pedagogy type of thing, although it's very much on.On practicing, which again correlates to what Charles Alan did. He Charles Allen was actually vocational trainer. That's why he was a probation and took that and put it into, because he was trying to train people, especially in shipbuilding on, in, in the, you know, night 1890s, 19. Early 1900s and all that.So he was trying to train people. So it was a very pragmatic way to, to educate children by practice. And he put that into, in a way, educating, training people in vocational training. [00:12:26] Joe Krebs: Yeah. So as a community of Kata thinking, we could say we're speeding things up quite a bit now. Like there were 1830s, 1890s, 1900s 20th century, right?But now things get really into motion and we, you mentioned some of those books the, we're increasing the rate of publications, I think that's what's what has been seen. So I think. Scientific thinking applied outside of education possibly even outside of lean manufacturing becomes really interesting.And that's why we have you on the, in the Agile Kata series, right? How can these things possibly influence things outside of lean manufacturing? [00:13:02] Jim Huntzinger: And I want to, and I'll bring this to Toyota. So, the TWI stuff, as I researched, it was the late 1990s. And very early 2000s. So Mike publishes Toyota Kata in 2009.So, so I got that and read it. And Mike's always been a person that just does a good job of taking things, parsing them down and articulating them very succinctly. Mike's always been very good at that. So I read Toyota Kata and I'm going, what I'm reading through there, I love because this is exactly the behavioral patterns we were doing back in my days.When we were implementing it, Briggs and Stratton. Now we weren't doing it near to the prescriptive level, near to the discipline level, near to any of that, that Mike was doing, but the fundamental patterns. We were doing like for example, like I said, our challenge was one piece flow. We would have to go out and establish the current condition.We didn't use that terminology, the current condition, the machines or the processes as they were, and then we'd have a what our target condition was, how do we put those into one piece flow and we would go through iterative steps. We were practicing scientific method is mainly because we didn't have a choice.We weren't quite sure what we were doing. So we had to go through these iterative steps to figure it out. So experimentation, like Mike says, and my favorite diagram he has in Toyota Kata, he has the one where, you know, on each end, he has the current condition and a target condition. Then kind of in between them is this unclear territory.And that's why I related to it so much. That's exactly what we were doing when we were doing that lean thinking what now all the, you know, there's a few books but not much. There was no internet. So we had literally do this, learn by doing, which actually came from TWI actually learn by doing. So we were doing it through iterative steps, this unclear territory to get it.So that's why the Toyota kind of related to me. And then it gave a pattern, a better, more prescriptive pattern. And also too, when Mike was researching that, as he looked at these different companies, practicing it, none of them did it exactly alike. They had their own way. But of course, again, that's what Mike's good.He had to put it into something a little more prescriptive in order to articulate it back out to everybody, so people could grasp it, you could practice it, people could learn it. Right. And ultimately it is, and that's why the book, I have it here. Sylvain Landry's book bringing scientific to life is so important because that's really, that's what TWI is practicing scientific behavioral patterns, Kata goes through that practicing scientific behavioral patterns so that.You don’t think your way through practice, you practice your way to thinking.. And that's what these are about. And that's why again, Toyota Kata is. So important about practicing so you get in that pattern, it just becomes natural and instinctive. [00:15:42] Joe Krebs: Oh, yes. And the terminology as you said, you reused other terms, right? I think when people are looking at these behavioral patterns, they're realizing, Oh, these are things I have done in a very similar way.And that's good. Right. And you might have used different terminology. I think the benefit of using a consistent terminology within an organization, let's say. It's obviously we all know what, where we are in terms of the journey, but that might change over time. Right? So I think as long as the pattern stays the same, the behavioral patterns.Yeah, one thing with that, I'd like to say over the years is I'll use this and this illustrates the importance of practice and continuing practice. So I say if if you're not using Kata or even TWI the same in three months, that's a problem. Because you need to practice the pattern, practice the behavior.But the other part of that is, if you're using if you're using Kata or TWI the same in three years, that's a problem. Because you should be learning it, so it becomes instinctive, so you do expand out your ability to use it. And it can be used, I realize, anywhere there's people and processes. You can use it.It doesn't have to be in manufacturing. It could be in healthcare. People are successfully using healthcare. In some of the insurance companies, I know people are using these. Anywhere there's people and processes, it's a, it helps you to be more successful because you're using that pattern, those behavioral patterns of scientific thinking.Yeah. To solve problems and move to a better level. Yeah. Oh, absolutely. Your KataCon conference, just to come back to that for one more moment, it's like, I think it's a representation of exactly what you just said. It's like who comes to these conferences, right? It's a broad mix of people. Yes.[00:17:25] Jim Huntzinger: Yeah. Yes. Broad mix of people out of different industries, broad mix of people at different levels along their journey. [00:17:33] Joe Krebs: Yeah. And you're all running as part of these conferences or you have ran these kind of onsite, but also workshops in parallel to these conferences, right? But they are more focused on the lean manufacturing side, if I'm not mistaken, right?But that is very hands on practical skills. Yeah, [00:17:49] Jim Huntzinger: Very hands on. In the case, the comp, so the conference we try, what we do is try to bring together the community. So we, with Lean Frontiers, I guess we like to say we like to build communities within the lean community. So, you know, we've had a lean accounting communities, of course, the Kata community with KataCon, TWI community, product, you know, lean product development, so communities within there.And it's a chance what we want to do is bring together thought leaders, practitioners, sometimes academics, people to come in and just share what they're doing and learning with each other within that community. With our intent is hopefully people make connections and get to know each other. So we don't, we just don't want them there together.You know, the two days or three days of the conference, we like to make them good networking connections. So as they go out the other 300 and some days out of the year they talk with each other. They communicate, they, they help, they share, try to bring what's going on together. So people go out and do good things with it and hopefully come back a year later.Continue to share what they've learned over the last year. Yeah. [00:18:47] Joe Krebs: And Jim how, like for somebody who is like maybe in the agile community right now, it says, this sounds very interesting. I'm listening to the Kata series. I'm starting to maybe read one of the books you you mentioned you on this podcast, how.What's the speaking situation? Like, who's speaking? What's the format of this conference? Because the scientific thinking is you know, is obviously in the forefront of that and the behavioral patterns you're pointing out. But what's the format? Or do people have to envision this conference to look like it's two days, right?[00:19:17] Jim Huntzinger: So what we do with the KataCon, actually, we actually run the KataSummit, KataCon same thing. And the TWI Summit, we run them concurrently. Because there's obviously, just because of the deliberate practice and scientific, there's so much correlation. But we always like to say, if people want to come and all they want to do is Kata, we got them covered.All they want to do is TWI, got you covered. If they want to mix it up, however much they want, they can do that. But we have, Keynotes and our keynotes are usually shorter. Try to make them just the pace, you know, like shorter 15 or 20 minute keynotes we have going on. We have breakout sessions where some are by practitioners.So you're learning what people are doing in companies, some by some thought leaders where they could expand a little bit more. A lot of times they're usually working with companies about what they're doing. We have some deep dive sessions where they're even a little bit longer. They're almost like a, kind of a mini sub workshop where people can go in and practice, you know, some of the aspects a little bit more.We actually have workshops. We have like a level set, a TWI level set and a kata, like their half day kata level set. So if you're kind of new, you could come in and kind of get up to a baseline. So you can, that's pre summit. So you can get more out of the summit, but we have some workshops and then even.Post summit. We have a Kata dojo workshop by Tilo Schwartz, who him with just another good book, giving wings to your team and all that. And we also do the 10 hour session so that TWI was trained actually the same format. It was used during the war, these 10 hour sessions. So there's five two hour sessions.So we run those think we're running for one for job instruction and job relations post summit and also one for Toyota Kata. Where they go through most of the improvement kata, but some on the coaching kata also a 10 hour training so people could come out and get, you know, like a certification on they can go, you know, know how to go practice and those are really practice based kind of workshops, a 10 hour training.[00:21:14] Joe Krebs: And I think that's also important, right? Because it is about practicing scientific thinking. So the practice piece needs to come in. I think for what was pretty awesome in this episode, I want to thank you for that is your background and how you know, take us on this journey of how this all started, but also how deeply rooted it is in many things we do as humans in various different kinds of industries.And even though it's only a small piece of history of what we just covered. The 10 years of KataCon is significant. It's a huge accomplishment. I want to thank you for putting this out there and putting your energy into organize something like this as an a past conference organizer myself. I know how much work that is.[00:21:58] Jim Huntzinger: One of the thing I might touch on because this is also about practicing is we have these are outside of that. the summit. But we have a couple workshops, one called skill point, one called skills lab where you go practice, you go learn TWI and also Toyota Kata. But it's actually on a full scale simulator.So it's a life size line. Now, the reason I'm bringing that up is you learn these skills because these are about skills. you skill of the Toyota Kata, the skill of improvement, Kata skill of the coaching kata. Same thing with TWI, but it's always interesting when we run those workshops we used have people from different companies come in and literally by the end of day one, and certainly by the day two there, these three day workshops, you would think these people had worked together for 10 years.Even though for different industries, different companies, and that's not something we're directly trying to do. So the whole working together as a team and all that, that when you practice these things together, by default, you'll reap that benefit of people understanding each other, people working collaborative together.So it's been fascinating to watch those. Workshops and watch that just spontaneously happen that these people look, I said, they look like they've been working together for 10 years and just met less than 24 hours before. [00:23:12] Joe Krebs: Yeah, it's amazing. Great bonding, right? If you have a shared goal and you work as a team and you collaborate and you have the same language and can navigate.That's fantastic. Jim, I want to thank you. On the show page people will find a way of finding the conference for sure. They can also just Google KataCon and and get in touch and get their tickets and meet you in April in 2024 in Indianapolis. Thank you, Jim. [00:23:39] Jim Huntzinger: Yeah. Indianapolis.Thank you so much, Joe. Yeah. Looking forward to it and thank you so much for taking the time to talk with me today.

Joe has a book “Agile Kata” in the making, if you like to be the first to know when it launches, please visit www.agilekatabook.com.Transcript: Agile.FM Radio for the Agile Community.​[00:00:05] Joe Krebs: Welcome to another episode of Agile FM. And this is a podcast as part of the theme of the Agile Kata series. And I have here today with me, Kelly Mallory, who is an operational excellence leader in a manufacturing facility in New England. Outside of her job, she supports the Kata Geek Girls and the Kata School North east where she is located as so am I here in New York. She is a little further up. Her aim is to spread the knowledge of color scientific thinking to more and more people through these communities. And obviously making the world a better place, which is a big goal we have here in mind. So I'm super excited to have you on the show here, Callie welcome.[00:00:56] Kelly Mallery: Thanks Joe. I'm really excited to be here. [00:00:59] Joe Krebs: Kelly, we are doing something a little bit different here on this podcast as an other podcast where we sometimes speak with authors about their book. We're talking about somebody else's book today. That's going to be Sylvain Landry's book, bringing scientific thinking to life.And we just thought about maybe picking a few items and talk about this this book, which was I don't know, maybe a year ago or so in 2022 or so released relatively new book in the Kata bookshelf. And we want to take a few segments out of the book and obviously then talk about the segments on a broader context.So when obviously we want to bring your experience in as well. Yeah. Sounds great. All right. So let's one of the segments we and I was thinking of like possibly reading out the segment first, so that listeners have a little bit of an idea where this is coming from, obviously all from the same book.And, the first one would be about the improvement Kata is fractal. And in other words, the improvement Kata is fractal, basically the same pattern at all levels, which makes it a meta skill, a target condition or a major obstacle at the strategic level. could in turn become the challenge for the level below and so on.The overall challenge reappears in successive smaller challenges as you move down in the organization and each of those challenges is reached by striving for successive target conditions. This fosters strategic alignment, connect strategy and execution and becomes a source of dialogue, coherence and motivation across the organization, not At least because people at all levels are practicing the same basic scientific way of thinking and acting.Now that's the segment we want to touch on first a little bit on from Sylvan's book. That would be on page 41. If somebody actually has the book in front of them listening to this. This is an interesting one because in the agile community when we are talking about processes like scrum, for example, Kanban there's always a conversation about how does that scale, how does that go into the large, how do we depart from a team to a larger level of the organization.I think that piece here from Sylvain's book hits that right at the mark because it shows how. It possibly could scale. What's your take on that segment from surveillance point? [00:03:29] Kelly Mallery: Yeah, I agree. And my experience in various manufacturing facilities. This comes in from a strategic planning standpoint.That's where my mind immediately goes where. At the highest levels of a company or an organization, you develop strategic plans and visions that are five to 10 years out. And then the expectation is it cascades down to the next level and the time horizon changes. But where I have seen this breakdown is some of that connection and embedding scientific thinking inside of that process.And what I believe Sylvain is talking about here is. Taking that strategic vision and. Morphing it more into the improvement Kata framework. . And how there is a deeper connection then at every level of the organization. Where the vision for a company that's five to 10 years out cascades down into three to five year strategic targets, which become the challenge.At the next level down. . And then they cascade that down to one year achievement targets, which can be cascaded to challenges there. . I love to think about this in the context of how beautiful those coaching interactions would become and how connected the organization becomes in that unified way of thinking.[00:04:58] Joe Krebs: And what I like about this is also that there is a as you just said there is even on the highest strategic level, there's still a goal. There's still something they would like to achieve. Now that might be on a much, much longer radius. In terms of the timeline and size of of the challenge, I remember at in the old days, it's probably not up to date anymore, but at Mercedes Benz, there was a product cycle of development for a new car was about like every seven years, a new car came out, right?From a model and so that is a longer period of time, obviously that is not something you can get some really concrete action items out of it as a team or as an employee. And I think that's, works very nice here in terms of his explanation. And when you read this, these basic steps of scientific thinking, how they trickle down into a small level, how do we break those seven years down?I think that's what he means by that, right? [00:05:49] Kelly Mallery: Yeah, agreed. And I like what you mentioned about the connection of that longer term strategy to the people doing the work. And what I think this, the fractal nature of the improvement kata really helps with there is breaking down that challenge into target conditions that are more achievable and manageable.And inside of that. You have to have right outcome metrics, which tell you, yes, we have achieved that, but there's the leading indicator process level metrics that you experiment against. So it does become much easier to take those big grandiose goals and create really tangible measures and therefore actions and experiments at The people doing the works level so that they can feel connected to the higher level strategy and know exactly on any given day, how do I contribute to that as an individual?How does my work matter? ., absolutely. And I, what I also think is fascinating when he points out that the scientific thinking process is the exact same at all levels. And I think that is an interesting point for linking this is to the agile community where there are other processes, if you're scaling or if you're integrating other parts of the organization, that's actually very different here.[00:07:14] Joe Krebs: I think that's a huge difference we can carve out is the pattern of scientific thinking is still the same. Yeah. Yeah. Yeah. [00:07:28] Kelly Mallery: It is. And it doesn't matter, right? The scope or scale of the work. So if you're working at a CEO COO level, you have a challenge that is very high level and your process for scientific thinking, the difference may just be the time scale.Yeah. And then at the ground floor where the day to day work is done. You're looking, your time horizon is much shorter, but the thinking process stays the exact same. It is wonderful. And imagine, I love imagining, because I have not yet experienced this. And I say yet, because I hope to. An entire organization where everybody has that thinking pattern.And just imagine what you could achieve. [00:08:16] Joe Krebs: Yeah, that is true, right? Obviously, there are some examples on Toyota, but we don't know if that's the exact same thinking pattern in all parts of a very large organization. So that will be very hard. Have you personally experienced any of these levels, not in the entire organization, working with unstrategic items versus very tactical and seeing that in action, what Silvani is talking about?[00:08:43] Kelly Mallery: I have in pockets. So in probably mid 2023 I was a part of a team rolling out strategy and we were looking at it from a cascading challenges perspective. So we got as far as. Taking the site level strategy and actions developing. Okay, the outcome metrics. What does that challenge statement look like?What might the process measures be for that? And therefore, what would the next level downs challenge be? And so we went through that catch ball process of cascading those challenges down. And then beginning to see what the tactical target conditions and experiments would be. So I began to see some of that, but that scale was, it confined to a single shop inside of one value stream.However, what I saw was the clarity that drove up and down the organization. As far as where are we going and how does each level connect to that? Yeah, I think [00:09:51] Joe Krebs: That's a good point, right? Also in terms of a vocabulary, right? So let's say you work with an executive leadership team and you're talking about a target condition and you're working with a team and you're talking about the target condition and you're bringing these streams together for communication.Everybody knows what a target condition is. SO there's not a separate process. It's not like leadership is working with this or in terms of agile teams. That could be safe as a process where it was money's using safe to scale or Nexus or or Scrum at scale or less. And in all of those things so these would be different terminology and vocabulary, which is not the case in this one, which I think is a huge benefit of that.Kelly if you're okay with that let's move on to a second piece of the book. Yes. Okay, and that would be a Toyota Kata and Lean which readers, if you are interested in following up on this topics, that would be somewhere between, I think, 84 and the page here. So that would be chapter six.So the segment here is for the past 25 to 30 years, lean efforts in most organizations have focused on implementing lean tools and practices that were. Benchmarked and copied from Toyota and on eliminating waste through three to five day Kaizen events run by Lean office staff in indeed as Leico Jeffrey Leico in this case mentions too many people think about Lean as a mechanistic process of applying off the shelf solutions to an organization's problems.This is decidedly unscientific compared to these Implementing an event based approaches to continuous improvement. Toyota CARA is clearly about skill building application practice through daily improvement that's aligned with the organization's strategic objectives. Now, that segment, there's a lot of stuff in here to to unpack.What's your take on this segment? It's another highlight of Sylvain's book. There's a lot in there which we can connect to agile, but I'll let you go first. [00:11:59] Kelly Mallery: I, I remember reading this book and when I read this this section I felt like I needed to facepalm a little bit because my entire career of 10 years in manufacturing has been focused on CI and lean and reading this, I had that, oh my gosh.Duh, this is why what I have seen with lean and continuous improvement initiatives have not gone so well and why sustainment is hard because we cherry pick a solution thinking that's exactly what is needed in any given situation compared to really Understanding the problem and determining and figuring out through experimenting, what's the best solution for this problem using guidance and principles from what Toyota has developed from those tools.But if you think about how they got there they developed the tools based on a problem they had. And then because of their success, we assume that just using the tools in that way means we can take them, copy and paste, but I've never seen that work. [00:13:09] Joe Krebs: Yes. And I think in the agile community, we have a very good example for that.There's even something called the Spotify model. So that's a way of Spotify working in agile ways, and they're very transparent about how they operate and make diagrams out of it. And then people follow these things in a totally different company. And and sometimes they often they struggle, sometimes they fail.Because they're applying a solution to for something that was created based on a very unique problem of a company that is in the digital music industry. And that might not work for somebody in a different industry. But the idea is, how do I come up with that model? And I think that's what this is all about, right?So Kada could bring you to, to a model like this. You can say it could be a Spotify model, or there could be a company X, Y, C model that was created using the Kata. And I came up with my own model. Now, inspiration is great. I think that's always good to look outside of your organization and see what's there.But I do think the Kata can help you guide you, steer you into the right direction, I believe. [00:14:14] Kelly Mallery: Agreed. And I think that starting with models or artifacts that already exist. Is great and a wonderful place to start maybe for a first target condition, say, let's try to execute this model or work within this artifact that already exists and see what happens.But I think what's important there and what we miss a lot in this community when we take tools and try to implement them is really observing how is this working in our environment and what can we learn from that? and adjust as needed. Keeping principles in mind over a specific tool. [00:14:56] Joe Krebs: Yeah.What do you think about the following? The, I noticed a sentence that is really specific to, the Kaizen events so the Kaizen events he's pointing out obviously it's more like a philosophy within an organization. However PARA thinking is continuous and there are some organizations that are using, I think that's.I don't want to put words in Sven's mouth here, but maybe he mentions like something like Kaizen events, which are very workshoppy kind of environments where we have a single improvement in mind solving that. And then we feel good about that. Whereas Kata would be possibly improving that, but then continuing improving, right?I think there is a subtle difference. How does that relate for you in terms of Kata and where you come from and what you do in terms of Kaizen versus Kata, continuous work versus workshop for improvements. And then having these feel good moments, it's we're done, we have improved.Everybody's great. But the journey should continue, [00:16:02] Kelly Mallery: right? Yeah. Agreed. My experience with that is very aligned with what you've talked about and what the talks about where my first events that I was part of and facilitated. We're very much, very good prep, good scientific thinking inside of the event, but then Friday comes noon and the report outcomes and you wash your hands of it and you say, look at everything we did.And then sustainment happens, but that's more a check the box and an action newspaper compared to continual learning right at that phase. It's just about implementing and not necessarily experimenting. And my, when I began to learn and practice the improvement kata, I started experimenting with kata inside of Kaizen events over the last couple of years in 2022 and 2023 and found some really wonderful things could happen from that where you can embed coaching cycles inside of the event, get people acclimated to that and that thinking.And then post event. It's not so much about implementing actions, but it then becomes about, okay what's our target condition in this situation are the metrics we expected to achieve from this event? Are we performing to that? And if not, wonderful. What obstacles are preventing us? What are we going to do next?And it becomes more about continued experimenting and learning and not implementing further actions. [00:17:38] Joe Krebs: And it doesn't feel so hard then on the individuals either. It's just Oh, this is this improvement effort now. And how do we go about it? And how do we structure this? And what's the timeline on it?Because you're replacing it with scientific thinking. It's ongoing. It's your new habit. It's there's no interrupt not to the way of how you work, but also what you produce, right? Because you're producing while you're not improving for the next three months and not producing anymore. You're Yeah, [00:18:06] Kelly Mallery: and I think an important thing to shift your mindset about when you, if you want to pursue this kind of thinking inside of events is that an event, a Kaizen event then becomes accelerated target conditions and coaching cycles.So your preparation phase is that initial grasping the current condition. And inside of the event, you strive for multiple target conditions, and you have a focused effort on that. And then afterward, it just becomes a normal target condition and experimenting so that You can continue that learning, and I agree.I think then what has to happen is going into an event. It's not about what is the exact solution we're trying to achieve. It becomes really about do I understand the problem and our current condition, and it does take away a lot of pressure and stress, especially from a facilitator standpoint, which I can speak to, about having to know exactly how it's going to work out and what that solution is going to be. Instead, I just focus on the thinking and the process. And then to your point, it should become more about continued learning and experimenting and not about an action plan afterward. [00:19:27] Joe Krebs: Yeah. What if companies out there already do these kind of improvement workshops?Let's say there was a company and they have the occasional or rhythmic Improvement efforts, but they say we believe in improvement. We have quarterly sessions where we discuss these things and we do certain things. And then after that, we go back to our regular business until the next improvement effort is going to take place.So it could be periodic or not, or rhythmic. Kaizen, let's say, or Kaizen events, right? There's a huge opportunity for using those events to start with Kata, right? So it's actually using them as a. As an as an entry entrance to, to cut us like, okay, this is an event. Why don't we approach that as usual, but then introducing Cata for long lasting change and continuous change.How do you feel about that? [00:20:18] Kelly Mallery: I think that's a brilliant idea because then also you're not trying to add another thing to learn about you embedded into a system that you already have. And then it's just about changing the way that you practice for those events, right? We no longer practice building action plans and practicing accountability.We practice establishing target conditions and experimenting to them and coaching to that. [00:20:49] Joe Krebs: Okay. All right. Awesome. Kelly, number three, shall we do it? Yes. Okay. Here's another soundbite artifacts or mindset question mark, both exclamation point. That's something you would find in pages one 26 to one 29 in Sylvain Landry's book bringing scientific thinking to life.As Leiker and Meyer, 2006 emphasized, the Toyota Kata is about tacit knowledge, non explicit procedural knowledge. Tacit knowledge is the craft type of knowledge that you gain from experience. In the practice practice and reflection rather than from reading a recipe. Of course, there are also specific artifacts such as work standards, A3s, and kanbans that are distinctive elements of the Toyota production system.Perhaps they too can be viewed as a form of cutout or practice routine at Toyota, where they are combined with feedback from a seasoned Toyota coach. So we are exploring artifact versus mindset. For the agile community, that is also a very comical as a tools, a lot of like just to put that out as a lot of agile teams that are using a tool like JIRA from Atlassian and and they feel like.That is agile, like by using the tool or in this particular case, applying a specific artifact or a recipe for some sort. And here, so then makes a connection between both of them. How do you see this shape? [00:22:18] Kelly Mallery: Yeah I've actually had some recent experience with this in about November of 2023.The company I had been working for decided to. rollout, and I will say rollout CADA practice. And the questions that came from that are what is this new thing? Does this replace anything? What if, does this replace A3? Does this replace practical problem solving? And then we ended up getting into large debates about, do you need a storyboard?Do you need the artifact? And lots of schools of thought, and we can go deep into the whole starter kata conversation. buT ultimately scientific thinking and practicing the improvement kata is inside of every lean tool every agile tool, every problem solving. And so the artifact needs to be there to help you learn and practice.But beyond that, once you have that mastery or at least competence, then it's important to understand that it's a thinking process. And that means you don't have to have a board or an A3 in front of you to think scientifically. But the conversations I had, people got very stuck on. I cannot do this if I don't have a storyboard.And they begin to connect the artifact with the thinking process. And I think that's where those questions came from of is Kata replacing something. And so I think as people, we get stuck on needing a physical artifact because it, it's a visualization of thinking pattern and it's easier to learn and practice.So when you want to break away or when you need to break away from the artifact, it is scary because you no longer have that safety net. Yeah. [00:24:16] Joe Krebs: I also, I saw that's not, I believe it's not from a events book, but I saw connections and some really good explanations on the storyboard myself.And I do the idea is that you, when walking through the section of the storyboard, excuse me, you bring the ideas back into your memory. That is a strong thing. And maybe that is kata. [00:24:42] Kelly Mallery: Yes. Yes. So if you read the starter kata or any. Any artifact, which is just a physical manifestation of some process are designed and exist to help us remember and learn something and the connection between physically interacting with a space or an item versus just thinking about it cements that in our minds.So I have no, I don't recall who this quote is. Assigned to, but right. Ink makes you think the act of writing changes the way that you think about things and it cements that into your mind. So the artifacts are really important as learning aids, but then it is also critically important. To try to step away from them, because that will tell you and confirm if the thinking process has been cemented.Yeah. [00:25:36] Joe Krebs: One thing I want to throw into the mix is also that in agile environments, we work in teams. Where if you were looking at Toyota literature, we often see coach and learner as a one to one association doesn't have to be like this, but I'm saying in the HR community would most likely see a team based approach.In that context, I do think a storyboard has a great place, because. The team might not feel like it might actually as you said, ink makes people think. And as a result of that, you might spot some ambiguity and misunderstandings. And I think that's just natural in human language that we would write on a board.Yes, it could be starter. It could be starter Kata related with, so let's practice this on a board. I give you the opportunity to update your board. It's your board. And we're using it in a coaching cycle to reflect on it. And so we're not forgetting anything. So it's like a tool to support you and your mindset, but it's not the mindset [00:26:33] Kelly Mallery: itself.AnD I think you make an excellent point that when collaborating, it is really important to have that information and project work visible for everybody so that you don't run into ambiguity, ambiguities or misinterpretations or misunderstandings. Because that team needs to work together effectively.And if you're just going off of verbals, you lose a lot of context, you miss stuff. What I think Sylvain is talking about here. Within that context is the artifact is important, especially when you are starting, but that when you have that mindset and more experience, you shouldn't be limited by the artifact that it should not become a crutch.And as you progress and evolving your understanding and learning the tool needs to evolve with you the artifact needs to evolve with you. Because [00:27:32] Joe Krebs: thanks for pointing it out. I think that's important. Yes. It might actually have a, it might, be a limit in your thinking if you're relying on the board to have, I think that's also a good, that's a good point for individual use as well as team use of the of the storyboard.There are actually a Miro and Mural storyboards available if somebody is is interested off that storyboard. So for remote teams now, Kelly, I think we said we would pick three items, but while I have you here, I'm, I think we're going to pick a fourth. Go for it. aNd these are more like it's related to the coaching questions.There is something going on. It's very interesting about, there's a set of different kinds of coaching questions. And it started with one set of five questions. And since then it's called the five questions of the, in the coaching cycle, but it has more than five in the current versions, but it's still called the five coaching questions, but the original version was five.And they were from before 2009 and they're called it to Yodakata original five questions. I like those. And so I'm just going to spell them out. So the specific here, first one is what are you trying to achieve? Second one is where are you now? Third one, what's currently in your way? Fourth one, what's your next experiment and what do you expect?And the fifth one would be, when can we see what you have learned from that step? And that has evolved, mushroomed, or whatever the right definition for that is, into something that is much, much more elaborate and many more questions, detailed questions to certain things. What's the story behind the evolution of these questions?I personally like those original five. [00:29:19] Kelly Mallery: I agree. And Honestly, I discovered these original five questions when I read this and it made a really good deep connection for me where I've been practicing the improvement kata and beginning to try to explore. Integrating that more into standard operating practices that, that I have personally and in my work.And when you take, the five questions that were taught from the Toyota Cotta practice guide, where to your point, it's more than five. And if you practice with Cotta Girl Geeks. Cotta School, Cascadia, Cotta School, Northeast. There may be others. There's also the planning phase questions, which are another set of five that are similar, but still more questions.And the specific language in the questions that. I was taught and learned from practicing, don't always connect with people, with every process or problem that you are working on and trying to integrate scientific thinking into. So the, these original five questions. Are a little more vague and I think they're a little more relatable if you have no idea what the Improvement Kata is where you eliminate right target condition, actual condition now, and it's just more about what are you trying to achieve and where are we?[00:30:42] Joe Krebs: So the evolution of the questions is related to the evolution of the community itself, right? So in the beginning, those five questions created somewhat a starter coaching cycle. Thank you. But which was probably easier to accommodate for somebody who's new to color thinking. And then maybe at some point, you might say those five questions don't go deep enough anymore and has evolved into something.But the current set of questions might be too much might be an overload for somebody who's brand new to just starting with. Incorporated cut off thinking or scientific thinking. [00:31:17] Kelly Mallery: Yeah. And I think, especially if you have never practiced or learned about what is a target condition, what does that entail?It's not a colloquial term in the continuous improvement community, or I'm assuming also in the agile community. It is not something that everybody knows about or has heard all of the time. So trying to bring people in. I think this lines up with personal experience where using, do I use the Japanese lean term or do I use an English equivalent and where a single Japanese term may have much more depth.It's also a bit alienating to people who have no idea what you're talking about. And so I, I see the challenge in starting right away with the evolved questions. Interesting. However, I will because I am a firm believer in starter kata. It is important to start with the current best practices for practicing the improvement in coaching kata.And it's just important to make sure that you go through that learning of what do those terms mean? Yes. And what is the understanding there? Because there is a lot of Deep learning and connection that can occur when you have that common language in the context of target condition, actual condition, now obstacles, right?Those words are specific and intentional. [00:32:52] Joe Krebs: Yeah. And it's also actually a good point, right? Maybe the two of us, we know more about the evolution that somebody who was new to Cata. Obviously, if there is anything where we would say that question originally was a mistake and we have replaced it with something else.Through learning, we might say this is not a good idea to go to the original one. But in this particular case, those five questions are in evolution, right? They are just refined stated differently, broken down into different sections. This is pretty cool. And I do want to, I do want to say for everybody listening to this from the Agile community, I'm thinking, oh, is this the daily scrum or is this like this daily standup event or whatever you call that?It's much more than that. And it's different than that. So this is not a one to one equivalent replacement or another term. The beauty is of this podcast was we just jumped right into a book. Looked at segments. You might feel or have felt while we're going through this episode lost as a listener.It's what are they talking about? But the beauty is that there is a book that explains all that. And that is bringing scientific thinking to life by Sylvain Landry. And so I would say. take those sections we just talked about, but also there's so much more in that book. You can start with Qatar thinking and obviously more background from the author himself.But yeah, so we didn't jump in and say what is Qatar? There are other agile episodes for that. We have recorded. And there was book material out there. So that's why we took a little bit more of an advanced approach here. Kelly, I want to thank you so much for being interested in talking with me about Sylvain's book.And also I think we picked great four topics out of the book, different topics makes people think and, yeah. Good luck in your cutout journey and thanks [00:34:39] Kelly Mallery: for your time. Yeah. Thank you, Joe. I've really enjoyed this conversation. And I just like to add to all the listeners, right? Don't go alone.There are communities out there. If you go to, you can just Google kata schools and there are maps that say where your local school may be. And there's a wide community of people who are willing and so generous with their knowledge Information and practice. So if you are interested in getting involved, reach out.[00:35:08] Joe Krebs: That's right. And that is a cut off or anything that is related to Toyota. If you're very specifically interested in how this could be possibly applied in an agile community. We have an additional source. The ones you mentioned are definitely good learning sources, but they can also come to agileKata. pro. Thank you so much, thank you.

Joe has a book “Agile Kata” in the making, if you like to be the first to know when it launches, please visit www.agilekatabook.com.Transcript: Agile.FM Radio for the Agile Community. [00:00:05] Joe Krebs: Thank you for tuning in to another episode of Agile FM and I have here Melissa Perri with me. That is melissaperri. com. She's the author of the book, The Build Trap from 2018. And she just recently in October 23 released another book together with Denise. You have to help me with the last name. Phyllis.Phyllis, right? Product operations, how successful companies build better products at scale. And that was, I think I mentioned that October 23, so that's brand new. We want to talk today a little bit about our product and a topic I'm super interested in and that is Kata up, but before we do that, welcome to the podcast.[00:00:43] Melissa Perri: Thanks for having me[00:00:45] Joe Krebs: Melissa, you are known for your expertise in lean product strategy, user centric product development. You also a COO for Produx labs that is with an X at the end, so not products, it's produx. And I have all the links in the show page that is a product management consultancy, but I want to come back to that book you wrote in 2018, the build trap, because You say companies have a little bit of a dilemma when you wrote this book, because not only did they have to deliver faster, but faster, not only features, but value has anything changed since 2018?Since the book was released, did the dilemma get bigger, smaller, wider?[00:01:27] Melissa Perri: I think it got bigger, but we've seen a lot of progress. So I'm happy. I'm happy with the progress we made in the last five years. It's what happened was, I think. A lot of organizations now, we are not fighting the same battles I was fighting 10 years ago, where it's you must go talk to your users.Not everybody's still talking to your users, but they know they should be, right? Like I don't have to convince them that's a good thing to do. It's just that. Usually politics or systems or something else will get in the way of them actually going to do that. So what I'm observing though is a lot of companies are realizing they're in the build trap.There's a lot of people in the last five years who made strides to get out of the build trap. But there's still a lot of people who are stuck in it because they're just starting this journey. And the people who started this journey 10 years ago are making great progress. The people who started this journey like last year, they might be, a little more slow to be able to realize all the benefits. But the good thing is I don't think we're arguing about, do we actually need product managers What's the role of it? Should we be talking to our customers? How do we focus on value? Like people know that we should be doing those things. Now the question is, how do we do it?I [00:02:34] Joe Krebs: mean, there's still an emphasis based on my experience working with teams on just building features, and there could be like that pressure in an organization off, like releasing more features, but that's really not the goal here. What value do they carry?And so just want to make sure I get this right in terms of the. The build trap, right? [00:02:51] Melissa Perri: Yeah, exactly. The build trap is this place where organizations lose track of what value are we producing? And instead they're really focused on outputs instead of the outcomes. So what we're doing is we're measuring our success on things like how many features did we ship?Did we get everything done in time? Did it go out to our customers? And what happens is a lot of times we're not going back and revisiting. Those things that we released and saying, did they do something for business and for our customers? Did they actually solve a problem? Were they based on a problem?You see this happening with AI right now, right? There's always these places where we are like, Hey, there's a solution. Let's just implement a solution, but we're not pulling it back into what problem is this actually solving. And I had this conversation even with a CTO I was working with the other day where I was like, he has a whole AI strategy.I was like what is it, what are you going to do with that AI strategy, right? What problem is it solving? And we're doing a lot of work right now to uncover some customer problems. So I was like, let's pause this for a second, go and cover the problems and then go back and see if AI is a tool that can help us solve those problems in a unique, differentiated way.And that's how we have to look at. It's keeping the build trap, right? It's being able to really critically think about what we're building and why, and making sure that they go back to solving a need for our customers in a way that's going to scale our business. So it's not about ignoring business opportunities.So we should always be looking at those. But we have to remember that the way that we achieve business value is by. Solving customer problems in unique differentiated ways, [00:04:29] Joe Krebs: This is so this is really cool. I'm going to come back to that build trap here in a second, but I do want to go back to Summer of 2022 here for a second.When I was going to Nashville to the agile 22, which you deliver the keynote. I believe it was a Tuesday or Wednesday, but it was somewhere in the middle of the week. And I remember because I was hanging out in the open jam so that was the first I think after post COVID kind of agile conference, if I'm not mistaken.And it was quiet, it was very quiet on the open jam floor. A lot of people went to talks and everything, and that drastically changed when you deliver your keynote, because you mentioned the word Kata and I was out in a open jam and I constantly wanted to talk about agile Kata in terms of transformation, business agility, et cetera.But you related that to. Product and to your talk and after that keynote, obviously the floodgates were open, so to speak to open jam and people came in you were talking about Kata. How do people, and I think that's the question here to the build trap is how can people use the Kata in your opinion, the improvement Kata Michael Rother would popularize in his book, Toyota Kata to overcome that build trap.[00:05:36] Melissa Perri: I love Toyota kata it because. It makes you really take a step back and consider what you're doing. And it's not like this dogmatic framework that's really prescriptive for a specific moment in time. It can be applied to a lot of things. Like you said, like I actually learned kata. Teaching people Kanban Kata by Håkan Forss, right?And that's how I was introduced to it. And I had been a product manager for awhile and I was subcontracting for Kevin Bear actually, and Jay Bloom, and they introduced me to Kata and they said, can you help them think through their Kata using their Kanban using Kata? And I looked at it and I, once I started understanding more about Kata, I was like, this is how I approach product management.And I had been working with, a company called Lean Startup Machine where they taught a very specific approach to MVPs for companies where it was like, first you do a pitch, then you do a concierge experiment, then you may do a Wizard of Oz or something. And there was like a format to it. And it never the structure never sat right for me as a product manager, cause I'm not building a startup.I was inside of a company because I was like, in certain situations I wouldn't go in this order or I wouldn't do exactly that. And I'm like why doesn't the way that I operate fit into their. And it was having a hard time with it. And I was having a hard time explaining it, how I was thinking to other people.And when I introduced, when I got introduced to Kata, I was like, Oh my God, this is how I approach my thought process, but I've never had it Kata-fied before. And I do think it's a great, like problem solving framework that helps people solve problems and think about what they need to do and how they might get closer to a goal.So for me, what I found is that. When I was a product manager I taught it to other people who are around me. I taught it to my team so that we could build better products together and it caught on really well there. And then I started doing it as a consultant and as a teacher, I started teaching people kata to help them with product strategy and to help them with thinking through what they were going to build.And it kept expanding from there. And why I love teaching it is it's. It's really like a series of questions and it helps you get out of the build trap because it's asking you that critical question of why. And people get stuck in the build trap because they're not thinking about the why behind the features that they're building.And that's what Kata does. It slows you down for a minute to critically think about. Why are we investing in this? What is it going to do? And what do we expect at the end of the day? And I like even use it in informal settings all the time. Just like some of those key questions with leaders.So like I go in, I work with a lot of CEOs. I work with a lot of chief product officers and they'll show me their roadmap. They'll show me what they're building and I'll go, okay. What do you think, what is the goal that you're actually working towards, right? What's the outcome that you're trying to achieve?What do you know about the current state right now? What are the problems about our customers? And sometimes they don't have that answer. So I'm like, okay, let's go do some research, right? Let's now we know what action to take to learn that we can go explore what the problems are. We could go do use the research.We can get some data. Then we'll come back and then we'll set the next goal. And we get into strategy deployment there, right? Where we're setting a goal. We're trying to go out and do some experimentation around it, trying to learn a little bit more. And what it does is it really helps us learn about our businesses, our customers, our current situation.And critically thinking through all those things is what. Gets us to consider more options than just whatever solution idea came to your head first. And that's why I love Kata for product management for product strategy and deployment and creation and thinking through all these things, because it's not just about product management, but it's a broad framework that, anybody.Yeah. Anybody could understand, right? If I ask you, what's the outcome? What do you want to achieve from this? You're gonna, anybody can answer that depending on where you're sitting in this situation. And it's easy to understand, it's easy to grasp and it really helps people stop and start thinking more critically about stuff.So that's how I use it to help companies get out of the build trap. And even if I'm not going to introduce it in a super formalized way, like I've used it with, I have a Google sheet where I stepped through every part of the Kata when I'm experimenting with stuff and go all the way down. And I have some people I've taught love doing that, but even just the questions and the way that it makes us break down our logic and think about what's next, I think is really impactful for working with anybody in an organization just to get them to learn and deeply consider different things.[00:10:04] Joe Krebs: Right. I think something very interesting you said was like to slow down for a little bit, right? [00:10:08] Melissa Perri: Yeah. [00:10:09] Joe Krebs: and to think and really look at the the situation you are in product development and so many teams and an actual transformation aspect where I use the Kata a lot or business agility same thing, right?There's a tendency of all we know what the problem is, let's get started. Versus stepping back and say what, where are we right now? And I think that is a probably aspect in a product, but nobody wants to hear that. So it's let's slow down. Everybody's let's get started. [00:10:33] Melissa Perri: Yeah. [00:10:34] Joe Krebs: And it is getting started.[00:10:36] Melissa Perri: Exactly. It is getting started. That's like the best way to put it. One of the big things that I see people don't do is actually evaluate that current state. And that's a huge part of being able to set great product strategy and get out of the build trap. It's and when you go and look at your current state, and we do this with product ops, like in the book I was talking about, a lot of that is helping you get to that current state.It's about understanding like, what are your users doing now? What kind of customer segments do you serve? Who's using which products, what types of personas are using which products? And you can pull all this information out to get a current landscape of what is my company and my business and my product actually look like today.And if you don't understand that, it's really hard to figure out. Where you should go in the future, right? It's incredibly hard to set a vision. It's very hard to give direction to teams about where you're going. And the Kata introduces that super nicely in the way that it's laid out so that people don't skip over it.Cause a lot of times I'll see leaders go and just create a product vision out of thin air. And you're like based on what, right? But how does that relate back to what we're doing now? So it's been a great tool in helping people take that step back. Look at where we are before they actually want to leap forward and make assumptions about where we should go.[00:11:46] Joe Krebs: This is this is super cool. I do want to ask you something about something that's often connected with cut off thinking and also product development, especially if you're looking. It's a closer at scrum or the role of a product owner. There's a very rhythmic approach through sprints and iterations.Yes, you could do that with the Kata out. I researched product development companies out there and I think tanks. They don't necessarily work in these fixed iterations, right? So they're working more like ad hoc experimental approach. I just want to hear what your take is and how you would connect that maybe to the world of Scrum, the product owner role, and like just that rhythmic approach iterating over a product backlog.Versus more like the experimental approach and what do you see out there companies are doing? Probably also a little challenging because sometimes product development starts much earlier before there is a product backlog, right? Or something defined, iterate over. So there might be two steps to it.[00:12:44] Melissa Perri: Yeah, I have opinions about scrum. So here's where I think a lot of teams get stuck. There is a forcing function that's nice in scrum. Where. You say you need to break this down and make it small. And that's where the two weeks come from, right? So it's that you don't spend six months building a bunch of stuff and never showing it to the world and not getting the feedback.And I firmly agree with the concept of get things in front of customers early, get some feedback. Now that doesn't need to be get half baked ideas in front of 20, 000 customers early. It just means like sometimes we do these things behind the scenes. Like I'll work with B2B enterprises in healthcare and finance and all these completely regulated businesses.And what we'll do is we'll try to figure out how to test things with people early on. So we might. Build a small prototype, or we could build a even small subset of features into a product and let people use it in beta testing. So maybe it reaches 10 people, 20 people, we get feedback, and we iterate on that before we go and launch it to everybody else.To me, That's what scrum is trying to promote is that you get things out and have those feedback loops, but it took on a life of its own. I feel and people got really dogmatic about it, especially with the two week sprints. And I have worked in industries where. It does not take two weeks to actually get something built to be able to show to customers.So then what are you doing? You're just like giving people arbitrary deadlines and they're sprinting sprinting, but they don't have much to show for it. And again, pure scrum, people would say Oh, they're doing it wrong then. And I agree, but some work just takes longer. And to me, scrum is useful when there's.unknowns that you have to go test. But if you have to build something and you know it's going to take six weeks and you have concrete data that's the right thing to build go build it. Like, why are we trying to sprint for two weeks into six week cycles? That doesn't make any sense to me.So a lot of companies out there I think are using Scrum wrong, right? They're not thinking about what do we know, what do we not know about the things that we're building? These known, knowns and the unknowns of the world here. And you want to. In product development, get to a place where you're putting things out quickly and testing it with customers and getting some feedback.And like I said, you could do that in a small way when you're not sure if the solution you're building is the right thing for the customers and that's the thing that we're testing there. What I see with Kata is it allows for the flexibility of that when you started thinking through it. And when I've used it in practice, we, and I've used it with a lot of teams, I'll say to them, what's the first small step we can take to go learn if somebody actually likes this.And they might say, we we tried the prototypes. We think they're usably good. Now we have to build it in some small. Like that, that sometimes becomes the assumption we have to test in which case, maybe we get some beta testers. Like we said, we get 20 beta testers and we build it as code.We release it under a feature flag and we go test it in Kata. You would ask, how long is it going to take to build? That first thing, like when can we go see, right? When can we go see our results? It might be four weeks. It might be five weeks. It might be one week. It might be two weeks, right? There's no, you want to keep thinking about slimming it down as much as you can, but it's not prescriptive about this two week cycle.And that's why I like approaching things more like that rather than trying to time box it things into two weeks. I think time boxing is nice when you've got a Team that's not used to operating that way and it's a forcing function to get them to think smaller, right? So sometimes I'll ask them. Okay, cool.That's gonna take eight weeks. Could you do what could you do in two? What could you do in three? But then we'd have a conversation of yeah But if we did that in two we'd only be able to do this much and we wouldn't be able to get This part of it out and that part is really valuable and you're like, okay what about three right and you have that back and forth negotiation on it?But Scrum doesn't allow for that, right? Like it's nope, everything has to be in two week sprints. In certain forms of how people sprint. That's the part that doesn't sit well with me for Scrum, and where I think people are getting really caught up in the motions, but not thinking about why they're actually doing it.[00:16:57] Joe Krebs: Yeah. What's interesting, right? Because you also just said that about breaking things down into smaller pieces to make them fit, right? What I have seen in the past was like the teams overreact and these items become so, so small. [00:17:10] Melissa Perri: Oh yeah. And you don't want it to be too small, right? And that's a big thing too, where I've worked with a ton of teams who've missed Misunderstood what a minimum viable product is.And I don't even like to use that terminology now because it's just so butchered, but they'll be like, Oh, an MVP is just putting out these core functionality. And you go what are you going to learn when you release that? And that you don't already know now, because sometimes it's like, Oh, all we're going to learn is that it's not enough for people.They want more. And you're like, so why bother? Like why bother? If you know that's going to be the answer. Spend two more weeks and build something that's actually valuable there. And that's the conversations I think we need to be having when we think about breaking down product development and what's small and what's considered.And I do believe there's ways to slice things down into smaller chunks where you can get it out there, but it has to be valuable, right? It can't just be small. It has to be valuable. [00:18:01] Joe Krebs: Exactly. And I feel like that's a key point you're making here is where the Kata, it's almost like when you're talking about what's the next target condition, right?What is, and then you're talking about some valuable things, like there's a discrepancy between where we are right now and where we would like to be. And there's a value in between, right? And if you're aiming for that, and it could be two weeks, it could be one week, it could be two days or could be four weeks.So it's not so much about the time, but how fast can we go to that target condition? This is this is really awesome. So I love hearing your thoughts on these topics. And I hope that the listeners out there listening to this from a product management perspective or product owner role. Got some new ideas, the beauty of the Kata and the agile Kata I'm promoting a lot is that people can start anytime.[00:18:44] Melissa Perri: Yeah. I like that.[00:18:45] Joe Krebs: If you're listening to this and it's like, how do I. Do this, right? Everything's about experimentation. So why not experimenting with the the kind of approach and and try that and see how it works for you. And possibly make some modifications to it. And maybe the product management process itself could also be Kata-ized.So I think that would be awesome. Yeah, that's great. [00:19:04] Melissa Perri: I'd love to see more product managers doing it. I had actually talking to somebody in a couple of days who used it in the government with Congress people. Yeah. Doing product stuff. And I was like, that's cool. So lots of different contexts to do it.I hope it's a good tool that can help people be better product managers. [00:19:20] Joe Krebs: Yeah. And thanks for coming to the Kata series of Agile FM where I'm highlighting the multiple use cases of Kata thinking and how it could fit into the professional world out there. So thanks for taking the role on product management.Thank you, Melissa. [00:19:35] Melissa Perri: Thanks for having me

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.

Jurgen Appelo, creator of unfix and innovator in organizational solutions, discusses the versatile nature of unfix as a pattern library for adaptive methodologies. He critiques rigid frameworks, advocating for a customizable, buffet-style approach that enhances flexibility and collaboration. Appelo likens building organizational structures to Lego, emphasizing small beginnings and gradual expansion. He also redefines leadership within agile frameworks and highlights the importance of creativity and diversity, using colors as a metaphor for problem-solving in agile practices.

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.