Podcast appearances and mentions of joe krebs

In this episode, we speak with Joe Krebs, creator of the Agile Kata. Joe shares insights into how the Agile Kata serves as a universal pattern for continuous agile improvement, helping leaders, coaches, and teams foster a culture of scientific thinking and experimentation. He also discusses the Agile Kata Assessment, developed in collaboration with Comparative Agility, and how it enables organizations to evaluate their agility, identify opportunities for growth, and drive meaningful change.

SummaryIn this conversation, Joe Krebs joins us at the ScanAgile24 conference in Helsinki. He discusses the concept of Agile Kata and its role in continuous improvement. He shares his passion for this topic and how it originated from his experience with agile transformations. Joe emphasizes the importance of challenging existing processes and habits to drive meaningful change. He also highlights the need for a continuous improvement mindset and the challenges organizations face in embracing it. Joe shares success stories of organizations applying Kata and the potential benefits it brings. He concludes by discussing the importance of building the Agile Kata community and the slow progress in doing so.TakeawaysAgile Kata is a pattern for continuous improvement that can enhance the world of Agile.Agile transformations should not be treated as projects with an end date but as ongoing journeys of improvement.Kata introduces scientific thinking and challenges existing habits and processes.The biggest challenge in embracing continuous learning and improvement is breaking through existing habits and routines.Chapters00:00Introduction and Background02:24The Importance of Continuous Improvement04:17The Misconception of Agile Transformation05:14Evolution of the Talk on Agile Kata06:12The Challenge of Embracing Continuous Learning07:40Challenges in Challenging Existing Processes09:07The Time Investment for Creating New Habits10:08Using Kata to Improve Business Situations11:36Success Stories of Applying Kata13:31Applying Kata in Lean Manufacturing Environments14:55The Challenge of Having a Continuous Improvement Mindset15:23The Danger of Zombie Scrum20:35Challenging the Sprint-Based Approach24:21Applying Kata in Simple Product Spaces25:20The Slow Progress of Building the Agile Kata Community27:35Question for the Next GuestHosted by Ausha. See ausha.co/privacy-policy for more information.

Transcript: Agile F M radio for the agile community. [00:00:04] Joe Krebs: Thank you for tuning into another episode here of Agile FM. Today I have two guests with me. We are a trio today that is Maureen McCarthy and Zelle Nelson are with me. They both are we're going to go really deep on this the creators of the method that's called the Blueprint of We and they can be reached at collaborativeawareness. com. Welcome to the podcast, Maureen and Zelle. [00:00:28] Maureen McCarthy: I am so thrilled for this conversation, Joe, because. The weaving between Agile and the work we do in the world is brilliant. And I love having the conversation about how that goes on. So [00:00:39] Zelle Nelson: really happy to be here. [00:00:40] Maureen McCarthy: Yeah. Thanks. [00:00:41] Joe Krebs: Awesome. Yeah, we will be talking a little bit about that blueprint of we, but before we do that just to set the stage a little bit with everyone, why the blueprint of we exist, why your work exists.There is a very sad history to this, and that is that Maureen, you found out that you have a rare genetic lung disease, and you are. Operating on 10% lung capacity. Is that correct? [00:01:11] Maureen McCarthy: That is true. I've been on oxygen for 20 years, but nobody lives as long as I have. So it's a, it's very rare. Most people are dead.Within 10 years I've had it 35 . [00:01:21] Maureen McCarthy: So I've had since I was very young. But it's not a sad story. It's actually a very creative story. It's not, I don't, there's lots of crazy stuff that goes on with it, but I don't feel sad about it. We've done so many, we've made the stress of what.A health challenge can be into a creative process of How do you thrive even when stuff is going on that's nuts. [00:01:43] Joe Krebs: Yeah the reason why we connect a little bit the blueprint of we the work you guys are doing and facilitation collaboration is directly tied to this to the lung disease. Can you guys elaborate a little bit on.How this all started for you guys and how you are, obviously your behavior changed as a result of that diagnosis [00:02:08] Maureen McCarthy: we actually met the year my doctors told me that I would die. So it was my 10 year mark of when most people are dead and meeting somebody. We both had our own individual businesses at that point, but meeting somebody the year you're supposed to die, you don't measure anything up against forever.You have to look at what's here right now and decide what you want to do with it. And we realized like the normal path when you meet someone is, do you want to date and get engaged and get married and have a white picket fence? Like you actually have those things that just project in your mind, because that's expected, to at least ask those questions. [00:02:44] Zelle Nelson: There was nothing for us to pull off the shelf to say, this is how you do it. [00:02:48] Maureen McCarthy: Yeah. [00:02:49] Zelle Nelson: So we had to design it for ourselves [00:02:51] Maureen McCarthy: and we created this. Document this relationship design document. We realize we've got to design something that's so specific to us and there's things that we want to No one understand about ourselves, about each other, but most specifically about who we are together.If this isn't what doing what you normally do when you become a couple, what the heck is it? So that design process we wrote down, we're like, let's do a design process, a design document, let's make it iterative and changeable and. Upgraded over time to, to show us who we are when we learn more about ourselves, about another, when we go through the chaos of in and out of the hospital and losing more lung capacity and massive levels of pain and just crazy things.You've got to be agile. You literally have to be agile. And without the design document, I think we could have gotten lost. In a path that can be very chaotic, especially because lots of people around us got worried. It made me understand the difference between worry and care. Like when people worry for me, all my pain gets worse.It's harder to breathe when people care about me. It's two different ways we're using our neurocircuitry, right? And care is a way to support other people. Worry is a way to add more stress and fear and the weightiness of all that. And when you've got 10 percent lung capacity. You feel weightiness unlike other people.Yeah, this is, I'm like a little like a little experiment of my own body of what it means to be like collaborative and connected, because everything that's going on in my body, we use as a way to be part of the design. Like this, there's chaos going on in here. How does that mirror the chaos of the world and how do we design healthy relationships and healthy interactions based on, what could be considered chaos?[00:04:40] Joe Krebs: Yeah, so this blueprint you guys, we're going to go a little bit deeper here. It's really something you build, it's a process. It's a relationship design process used to build resilient, collaborative relationships in startups, communities, and organizations worldwide.And I think what's, so I just read that out. That's, I saw that, but what's important about that is that you'll have a very personal story. This process is something that was created between you guys to find out how you guys going to transition. And now you're taking this process and bringing it back to the world.So there's these things live every day to the fullest, and make the best out of every day. You are making the best out of every day. Is that part of your blueprint? Can you give like listeners to Agile FM? So what's the difference between you as a couple, right? Different to or not necessarily different, but maybe similar to how teams should be operating or when they're working in pairs, let's say.[00:05:44] Maureen McCarthy: This was an interesting evolution of the document. So the blueprint of, we began because of this design conversation, we thought it was just going to be for us. Then we did it with their kids. Their first blueprint they wrote was when they were four and six years old. We did one as a family. Then we started realizing, so we both had our separate consulting businesses.And we woke up one day and said, traditional legal contracts felt like they didn't have the spirit of what we were designing in our life. And so we made what we thought was the scariest choice imaginable. We said, you know what, we're going to stop using traditional legal contracts. And only use the blueprint in our contracting process because it takes both everything you're agreeing to and who the people are and how you're going to do it together into consideration.And so we made a list of colleagues, we could send any of our clients. Our clients are, governments and universities and international corporations like they're, they live and die by their contracts, right? And we were really nervous to say, yes, thank you for wanting us to do your contract and we're going to do a blueprint instead, if that doesn't work for you, here's a list of colleagues that you can contact and we thought we'd lose most of our clients and we never lost one in all these years.And so it moved into the situation there where now companies, people we were, doing work with started to understand that because we did a blueprint with them. That's how we created a contract. And then they turned around and said, can you come in and teach us to our organization? Can you bring this whole concept for the groups and people and teams and things that are working together?So it was really the organizations telling us. Oh my god, we're missing this piece of how we work together. [00:07:22] Joe Krebs: Yeah. [00:07:22] Maureen McCarthy: And then it just spread. We were asked to speak at an international peace conference in Russia. And that you had to either speak English, Russian, or bring an interpreter. I think there were 39 countries represented.And suddenly it spread like wildfire. So it took on a life of its own. [00:07:38] Zelle Nelson: Yes, it's really about having clarity in each individual having getting as much clarity as they can, and then having a conversation where you can ask questions and get curious and actually. Have a artifact that holds what is our conversation and how are we going to be together in any relationship?There's at least three entities. There's you, there's me, and there's this third entity of we, and we need to give energy and understanding to how these all will work together and how we're going to come together to Do what we want to do. [00:08:14] Maureen McCarthy: We have this term we call the WECO system. It's the ecosystem of the we, and the notion is that in any work situation you're in, there's an entire ecosystem of all the different pieces and who's working on what and what our roles and responsibilities and who's the customer.All of that, but it often doesn't take the relationship of the people and who we are together into consideration. So when you get a team to start looking at okay, you've got even like the working agreements that happen in agile, right? Those are agreements on all the different pieces of the ecosystem, but the people are not built around that because.I know agile is all about people first, right? So if you think about that, we need to have those as part of our agreements. Who are you? How do you work best? What do you look like when you're stressed out? What can I do for you to help you get you out of it? You tell me what your stress looks like.You tell me what the best inflow day you've ever had looks like. And then we can exchange some information. You could know that about me. And then when Zelle talks about the artifact. I can be self aware myself, you can be self aware yourself but together there is no artifact. I hold me inside of me and my brain.There isn't anything for this we, for who we are together. So we coined the term collaborative awareness because that is like the design and understanding of who we are together. And you can build that. The blueprint becomes a document, an artifact, a process that you're actually, but it's like open space.It's simple, it's elegant. It doesn't have a lot of. There's not a lot that you have to do to really make it sing like we'll, we can do an open space. We use open space, world cafe, different large group dialogue tools to actually have people do their blueprint in a really short amount of time, like fast paced process.So it's not some but you, it's iterative. So you're constantly upgrading it as you grow is all the different elements change. Because you need to be adaptable. [00:10:11] Joe Krebs: Yeah. Do you have an example for that? Like for the iteration piece of your process of where you do like certain loops and refinements of some sort?Because we assume it's not static, right? [00:10:23] Maureen McCarthy: It's oh my God. No, the document that Zelle and I first did years ago, we've been together 25 years now. So that document was actually. Looks nothing like our document today. It has changed drastically over time because we've changed. The reasons why we're in have changed.What matters to us has changed. And so that keeping track of that means it's a little more mindful of why are you here? Why do you want to be part of this? Keep that lit up. I want to know how you've been evolving because of all the stuff that's gone on in your life. So part of it is a group will come together.They first write something called the blueprint of me. Each individual is a set of questions in the five components that make up the blueprint of we and me. And those five components are first is the story of me. This is in the blueprint of me version where you're writing about yourself. So what is the story of me?What got me here to this work, this team, what I'm about in the world. The second is called interaction styles and stress messages. So this is where I share Hey, this is what I look like when I'm having an inflow day. This is what can help me stay in that space. This is what's important to me.Sometimes it seems like here's how I want to be contacted. Don't call me before this time of day, or make sure that we write it all in an email as well as talking about it, because I need documentation. Whatever those things that make me do my job best to make me feel like my whole self can be here. I want you to know those because otherwise we end up going into these modes where I think everybody's a little bit like me, so of course, you're only just going to want it like I want it.[00:11:55] Joe Krebs: Yeah. [00:11:55] Maureen McCarthy: And we all know that's not actually true and our brains are operating. So we call this the filing system of the mind. If you think about how we engage the world, we basically take in all the bits of data and information that goes on around us. And it's like filling a metaphorical filing system in our mind.Everything someone said as we were a child, what our co worker said yesterday, a book, a movie, whatever it is. We file things away. Okay. And that's why our brain is basically a meaning making machine. [00:12:27] Zelle Nelson: All these files filter what we see, what we perceive, what we interpret as what other people do. So in the blueprint, why not exchange and give you my files of me?You don't have to make assumptions about who I am, how I show up. What makes you, [00:12:42] Maureen McCarthy: you're using your filing system in order to make sense of him.Don't do that because you might be mistaken. Let him give you the files of who he is. [00:12:51] Zelle Nelson: So again, we start with a blueprint of me where each person shares their files of me.This is who I am. So I show up the third component is custom design, where we look at. What are our values? What are the principles that we want to design from? And what are, we start with some, maybe some opening design questions of this is what I think we're doing. And this is, my suggestions, [00:13:16] Maureen McCarthy: but it can also be roles and responsibilities [00:13:19] Zelle Nelson: it evolves.[00:13:19] Maureen McCarthy: You add that over time, but this is the section where you're saying, this is what matters to us. So it's, what are the what are your values, but what do you want to feel? Every time we're working together. What kind of energy do you want to bring into this? Because that's a great lens to say, Hey, we're at the end of this meeting.Did that feel energizing? That's one of your words. We can check in right then and say, Yeah, it did or no, it didn't. Okay. How do we iterate the design? So we have more of that energy next time. But it also includes what traditional legal contracts can include. So anything, in fact, there are lawyers, mediators, judges that are huge fans of the blueprint around the world.There's a couple of law schools that are teaching it. You can use the blueprint process as a traditional contracting process, and it will hold up in a court of law, the same as any other contract. But it has the people involved, which I think if a judge had to see it, it would feel quite different.[00:14:16] Joe Krebs: This is very interesting because you just mingled a few things together in your design process, but also in the team agreements and the me and the we, right? It would be a much easier and easier to understand world if everybody would be thinking exactly like me. Wouldn't it? I wish. You wish, right?But it would be easier, right? So we do need tools like this, but just to give listeners a, an example what I came across, which is fascinating is that the two of you guys don't really have a working agreement. I don't want to call it a working agreement. That sounds too business-y for this. But I learned that Zelle is actually asking you every single day if he if you still want to marry him. [00:14:53] Zelle Nelson: Yes, [00:14:53] Joe Krebs: that is a daily [00:14:55] Maureen McCarthy: literally for 25 years. I'm not kidding you every single day or [00:14:58] Zelle Nelson: she will ask me. [00:14:59] Maureen McCarthy: Yeah, 1 of us just said [00:15:01] Zelle Nelson: it doesn't need to be 1 or the other, but 1 of us will ask the other. [00:15:05] Maureen McCarthy: He asked me this morning. I said, yes, but I am that in. Every day, because we chose to be together for a day.And then we choose again every day. That is, there is something really different about that because I have to ask myself every day, why am I in this? Why is this where I want to be? It could be, it could have been a crazy day. We could have gotten in a big fight. But I still have to sit back and go, do I want to be here?And you do, because every day you're building up the trust, the respect. We define what trust and respect looks like. I know what that looks like for him. He knows what it looks like for me. And so the in, Now, granted, tomorrow, one of us could say no, but shockingly, we have a healthy, insanely live, like a live relationship.And I could never have predicted that, especially with the chaos that living in this body is. [00:15:59] Zelle Nelson: And then there was so much we didn't know at the beginning, and that's what made it so iterative. And such a learning process, not only learning about what the other person needs, but learning about what I need.Like I would come up and, show up in a certain way. And, she'd be like why are you doing that like that? And I might say, I don't know. [00:16:18] Maureen McCarthy: But it's not, you move from judgment to curiosity. [00:16:21] Zelle Nelson: Yes. [00:16:22] Maureen McCarthy: It's not a judgmental question. It's just it's just I'm so curious. Like you've told me about all these different things and Hey, I noticed this.Tell me more about what that is. Like we're endlessly curious. Because our minds are open. We're not, we're, we don't live in a judgmental space anymore like we did when we first met. I couldn't have predicted that either. It's fascinating. [00:16:42] Joe Krebs: Yeah. That's, it's very interesting, right? Because if somebody listens to this and again, like living day by day that was just a reminder when I heard that you guys are asking each other every single day that really emphasizes how you live in the moment.And I think. If you're taking this to the to teamwork, also interesting. I learned something about the you tell me if it's the blueprint or just collaboration in general is that you're really promoting a switch within your brain from defensive stances to proactive connectivity.What do I have to picture when I study defensive stance, proactive connectivity? How does that shift look like with your method? It sounds great and totally defensive. What would be the ideal scenario? [00:17:30] Maureen McCarthy: So what's interesting when you think about the filing system of the mind and how you take in all this data, we have two basic. Neural networks that happen in our brain that are, and they're the two ways that our brain is evolved to keep us alive. [00:17:43] Zelle Nelson: That's why we thrive as a species.[00:17:44] Maureen McCarthy: Yeah. So we're either protecting or we're connecting and it's a whole set of neural circuitry that can look different in different people's minds. It's not just one certain path, right? So you take things in someone in front of me saying this, doing this, showing up like this. And I'm either using my, I'm really, it's more of a continuum of safety brain to connect to brain neural circuitry.I can either take in what you're doing and feel that protection, the stress, the judgment, all those things that happen when we feel like we're at risk. And we have a world that has been built in problem solution thinking of scanning our landscape constantly for problems, and we get a dopamine hit with a solution.But what we found over the years is with people. Problem solution thinking is not robust enough to hold us in fast paced environments. So we started thinking about the fact that if I've got these two levels of neural circuitry, I can wake up and doom scroll the news and add more files to the safety brain version of my system.Or I can do something to actually add more files to our connected brain neural circuitry. And it means that when I stand in front of the person who's saying this and doing this, I can make meaning in two different ways. I need my safety brain. I want it on when it is necessary, but we've made it our main mode of operation.We are so enthralled with protection, and victim mentality too, of like being afraid of whatever somebody else is doing, that we literally cut off. Here's one of the things that's so interesting. When it's very, it's more recent neuroscience research in social neural neuroscience that says when we're focused on a problem, our brain literally becomes tunnel vision.Because initially it was like, if the bear is coming at me, I need to tunnel down. I can't be creative. I can't be empathic. I can't be connected. I have to zero down. But what happens when we're in that space. Is we have to beat out, weed out every single thing that doesn't say, I know you, I know what you're going to do, you look like me, you act like me, you're going to talk like me, I can't see those things anymore.So then the person I'm working with, who works very differently than me, if I'm using my safety brain neurocircuitry, I can't let them in. They're not exactly like me. So that now I begin to create other and push people away. That's the protection part of it. If on the other hand, I'm moving from judgment to curiosity.I want to know and understand what somebody's about. I'm doing a blueprint with them. So they give me a chance to get their own files from them. Now I have the space to be able to show up. And, be in good feedback loops and listen to other people's ideas and feel engaged by the fact that someone doesn't think like me because I'm going to learn something more about how we're going to do this project.[00:20:28] Zelle Nelson: You're going to bring something else that I don't have. [00:20:30] Maureen McCarthy: Yeah. [00:20:31] Zelle Nelson: That I want to invite. And I think there's a really kind of simple explanation or example might be. Take the behavior of someone closing their door in the middle of the day. To their office. That can be interpreted in a lot of different ways.If I had a boss who anytime they closed their door, it meant they were talking about secret things and someone was gonna get fired. I would be really freaked out if someone closed the door in their office. But if I, [00:20:57] Maureen McCarthy: not even the boss, just anyone else, anyone, my neural circuitry might say, that means there's a problem.[00:21:02] Zelle Nelson: Yes, in if I were in, in the connected brain space. Someone closes their door. I might get curious about what's happening or why they might be closing their door. Maybe they need to focus. Maybe there's something going on with them that, they need a little privacy or maybe we've had a conversation in our blueprint.Earlier that said, here's the times when I closed my door, I have a project. I really need to get finished. I need to focus. If you need to talk to me feel free to knock on the door. There's you talk to, you start to have conversations about how do we set up? What do these things mean? I don't have to be upset about them.I can actually be. Excited or curious about them and that engages my connected brain. When I get curious about who you are and how you show up and you do the same with me, it grows our trust. It grows our connection as grows our adaptability as well. And I can, if you have a closed door policy and that's really hard for me, we can have a conversation about, Hey, how are we going to make this work?I need to have access to you and be able to talk with you and [00:22:05] Maureen McCarthy: you start building bridges because there are differences. There will be more and more differences. Yeah. Because things are changing so fast. Yeah. So how do you, in calm moments, build the bridge instead of getting in stressful situations about it?[00:22:17] Joe Krebs: It's also interesting when you say that with the door, I also saw the opposite, right? There were environments where there was no door. Yes. And then people felt, this obviously, like here and there, a situation where people felt uncomfortable because, They had to talk to a doctor or something like that, personal phone call and a very important one.And they couldn't find privacy. Yeah. And it just felt like, where can I take this call? So they were not really focused on something. So it could, it could go either way, right? Where's this person trying to find a phone call, right? And it's not always that easy. [00:22:51] Maureen McCarthy: Yeah. [00:22:51] Joe Krebs: You just mentioned problems a little bit our companies are there.Yeah. They're thriving on problems. We often look at problems. But in scrum, for example, when I work with agile teams, myself, I always remind people that people are not problems. The relationships could be a problem. How does your blueprint address something like this? That it's really like problem management and how you work with organizations that are Like, hyper focused on fixing problems and like seeing everything as a problem whereas the human side or people are not necessarily the problem.[00:23:27] Maureen McCarthy: Yeah. It's, you are so spot on when it's helping people recognize that people aren't the problem, but actually even the relationship itself is not a problem. It's an opportunity to redesign. We call it stress as a messenger. So instead of stress being a warning sign, if you think about it as a message, it's like a text on your phone that just dings and you're like, Oh, this is.Pinging me because this matters to me. I care about meeting deadlines on time and this person's not handing me something they need to hand me. So that feels Oh, there's a problem in our relationship. But it just means that the way the relationship is being created needs a little more mindful design.But when you start talking about there's something up with the design, let's upgrade our design is a very different conversation. Then there's a problem here. Why are you doing this? [00:24:22] Zelle Nelson: Oh, Zelle, you're a problem. How much energy do I have to comment? Be better to be curious. It moves me into my safety brain.[00:24:29] Maureen McCarthy: Yes. [00:24:30] Zelle Nelson: I want to be in a design conversation where we find clarity around what's important. And that stress message, that ping, that ding on my phone is saying, Hey, something's important. Something could be more fluid here. [00:24:42] Maureen McCarthy: How do we design for that? [00:24:43] Zelle Nelson: Let's get curious. Let's find out what that is. And let's design something that works.[00:24:48] Maureen McCarthy: And we've been using these tools with groups around the world. We have facilitators around the world and it's the same everywhere. Humans show up and need those design conversations because we're not taught that in a problem solution world. When you're focusing on the problem, nobody's actually taught how to design.In fact, even, so there's a whole set of what we call our clear mind tools. Where both individually and collectively you upgrade your brains to be running more connected brain neural circuitry than safety brain. And in that space you begin to realize that this is not a this is not a world of problems and it's actually easy to start upgrading the filing system of your mind.One of the great sort of visuals I created a while back. Was what we call pick up the sled and it's the notion that if you're standing at the top of a snowy hill with a sled in your hands, if you sled down the left side of the hill, just a couple of times, you creates a rut in the snow. You don't need to steer anymore.It just goes down. That's an analogy for how neural circuitry is made in the brain. Okay. But what you need to do, so if the left side of the hill is my stressful thinking around that person I'm working with, the only thing I can do to change that, because that's stress on me, they do what they do. And I get to pick whether I'm stressed or not, but what I want to have is a path down the right side of the hill as another option more curious, relaxed open perspective on the same person, same topic, and then I want to create just like I could create a positive perspective on the right side of the hill, go down a couple of times and that can become a rut as well.But what we do is we fill the filing system with things that are down the left side of the hill, right? So what you first need to do is actually pick up the sled in an awareness phase. I can't drag the sled from one side of the hill to the other. It's too hard. But I can't stop for a moment and say, let me pick up that sled.I just going to notice for a while. Oh, there's me thinking that way again, there's me feeling all that stress about what he did. I want to notice first. I don't want to change it. I don't want to say it's bad and wrong. It's just what's happening. Okay. And what happens when you begin this awareness that you're doing these things, our brain, like the rut in the snow.We don't wake up and choose to be stressed out. It's like it comes and grabs us and drags us down the hill. So when I pick up the sled or even just notice I'm stressed and go, Oh my God, I want to pick up the sled. I can't tell you the number of times I've said those words. Now I begin to move that storm of the stress two miles away.I can start to see it and how I can handle something when I'm in the eye of the storm and how I handle something when it's two miles off the coast is different. And then once you do an awareness phase for a bit, could be a week, a month, however long it takes, you'll know when you feel like you've moved that storm and then you can start making a new path down the right side of the hill that feels more life giving and positive because what ultimately we're doing with our work is helping to give people options.I don't ever want to not think negative things or not be stressed or whatever. There's nothing out there that we're against or demonizing or anything. They're all just opportunities for design. So how can I have as many options as possible? When that person shows up doing that thing, I want more options and how to react.[00:28:03] Zelle Nelson: Again, it allows us to be more agile and adaptable to any situation when I have a broader scope of ways I can engage. [00:28:11] Maureen McCarthy: And then everything outside of you can be fluctuating all the time and be chaotic. But when you can keep doing that, then you can feel more of the calm consistently. Or you can get out of it faster.We still get stressed out. We'll still have an argument. We get out of it so fast. I'd be dead if I didn't get out of it fast. [00:28:29] Joe Krebs: I just wanted to say that for you, it's a very important, personally, a very important decision on what side you're going, [00:28:35] Maureen McCarthy: exactly. It is literally a life giving. [00:28:39] Zelle Nelson: I've learned the nuances as well in my own self, because I got had Maureen as an example of, wow, this is stress. I can't run that. , [00:28:48] Maureen McCarthy: like the princess and the pea. I feel stress earlier than other people, but it happens to everybody. [00:28:54] Joe Krebs: But I think we can agree to that. It's you have an immediate, obviously, essential reaction to that. But it doesn't mean that it's not helpful for everybody else. Now if people want to get in touch with you, Maureen and Zell e both of you guys are working on a book. You guys are speaking, you guys are facilitating, you guys are obviously working in the blueprint of we, and I just learned the me and we in this podcast.I just want to thank you guys for carving out some time, especially, and I do want to say this for somebody who's Who you guys designed something for a day by day experience that you shared for 30 minutes of your day today with the Agile FM listeners. I'm extremely thankful for that. And you made them part of your day and vice versa.And just want to guys for stopping by and sharing a story here on Agile FM. [00:29:49] Zelle Nelson: Oh, you're so welcome. Thanks so much. Great to be here. And you can find us at collaborativeawareness. com. [00:29:55] Joe Krebs: That's correct. Thank you guys.

You can grab Coco's book: The Full Potential Relationship - The Soccer Field Method®Transcript: Agile F M Radio for the Agile Community. [00:00:07] Joe Krebs: Thank you for tuning in to another episode of Agile FM. Today, I'm here with Coco Decrouppé, um, and she is an author, a team trainer, a top 15 leadership coach. She's a blogger, she is, and this is what we want to talk about here today, the creator of the Soccer Field Method, where she also wrote a book about.The book is full title is The Full Potential Relationship and the Soccer Field Method. Welcome to the podcast. [00:00:36] Coco Decrouppé: Thank you, Joe. I'm very excited to be here. I'm looking forward to the conversation and I'm honored that you asked me. [00:00:43] Joe Krebs: Wonderful. And this book which we, I just mentioned the full potential relationship, the soccer field method.I was immediately drawn to it as I'm a huge soccer fan myself, but soccer is not, or knowledge about soccer is really not important when reading or approaching the book or the method itself. And I think that's a correct statement, right? [00:01:03] Coco Decrouppé: Absolutely. Absolutely. It's not needed. [00:01:06] Joe Krebs: Awesome.Yeah. So the book actually is a grouped into three areas and I want to touch on those if possible with you. Today, the first one is the relationship with yourself because it is about the full potential relationship, the book. The second one is the relationship with another. And the third one is the relationship with the team.And that relates to listeners on the Agile FM podcast. Now I do have to say your background is not in Agile, but I believe there is. A lot of things the agile community can take away from from your writing. If that's okay with you, I would just start diving into the first part. [00:01:43] Coco Decrouppé: Yes, please. .[00:01:44] Joe Krebs: , the first thing I noticed when I read the book was like the biggest chunk, just in terms of material of your book is actually in the first part about yourself, like just in terms of pages really focusing on. On the first one. So we often work in agile teams. But when we're looking at individuals within the team, how could this the soccer field method in particular be relevant for an individual team member, for example, like a software engineer or a leader or a coach that you do.You do coach to coaches, right? And in this case, it would be an agile coach. How would this technique and what's so special about your soccer field method? In looking at a soccer field itself how is this important for an individual on a team? How could this be helpful? [00:02:32] Coco Decrouppé: Yeah, very good question.Very important question I feel. So the soccer field really is an analogy for a relationship, and we all have relationships. in private and business life. So it doesn't matter what your role is. It's not important what you're in, what industry you're in. We all have relationships. And we really need only two lines of the field.It's the middle line that separates us and the outer line that connects us again. And one challenge for leaders is the question, when do I need to be with my team? And when do I, when is it okay to set boundaries for myself? And that is a solution. approach to deal with this question on a daily basis in difficult situations.And the first step is the self leadership. So we have the two lines, the middle line, the outer line, and we have the two spaces. You have your side of the field. I have my side of the field. And this is where we can show up a hundred percent authentically with our skills, with everything we are. And our world is fast.There are lots of expectations, no matter what your role is. And we tend to think a lot outside of us. instead of thinking for ourselves, what can I actually control? And this is what the self leadership stands for. How do I step back, calm myself down and reflect on what is actually needed? What are my responsibilities actually?What are my values? What are my thoughts? What are my emotions? Even this goes deep here. So a lot about emotional intelligence, but it's a lot about stepping back. And we need this in every role, especially when we talk about transformation, change, all these things that cause Lots of confusion and stress for people.[00:04:34] Joe Krebs: This is also like related to how I show up in the morning for work. What I take away from work, like very, like, selfishly speaking, right? It sounds like it's all about me at this point, right? So this is the part of your method is all about me. Is that a fair statement? [00:04:51] Coco Decrouppé: Yes. It has a lot to do with the mindset and how you show up because every team Or every team member leads the team with their mindset.So it's very important to be aware of how we show up and this is also the power that we have. I don't like calling it selfish. Like, yeah, it's a very important word actually and how we phrase that. I call it more self determined. to really pay attention that we do need oxygen. First, we need to step back, we need to calm ourselves down and pay attention to our needs.First, before we then go and help other people and strengthen the team and support each other.[00:05:35] Joe Krebs: Yeah. So from a methods perspective, let's say I'm a software engineer. Is that you just mentioned like the emotions, right. How I would show up, but also from a self determined in terms of learning, right? So I come to work, possibly want to improve how I want to be as a professional within my team.Right. But what do I want? How do I grow? Does that also fall into my side of the soccer field. [00:06:03] Coco Decrouppé: Absolutely, that we understand what do I need also in working together, what is important to me. Sometimes I need more details from a person. Sometimes I need less details for a person, for example, and we need to communicate our needs in order to work together.And then there is what comes natural to us, right? Some are more technical oriented and others have an easier time in creating and building relationships, building trust. [00:06:34] Joe Krebs: Yeah. [00:06:35] Coco Decrouppé: And whatever comes natural to us, we always have to outbalance the other side. We also have to focus on the other thing.So when the technical side comes easy, we also need to pay attention. How do we actually connect? How do we communicate? So like we stayed in the beginning, we have the midline that separates us and the outer line that connects us. For some people, it's easier to set the boundary and be more intro, they're more introverts possibly.And for others, it's easy to connect. So we need both lines and both skills. In order to really work together. [00:07:10] Joe Krebs: So even within my own field of the soccer field, I still have different segments, right, in terms of learning, how I possibly open up to other people, communication, collaboration what are my skills and capabilities?So we can look also inside the team a little bit of an agile team, but if we're looking a little bit more on the The outside of the team that could be leaders stakeholders, people that are interacting with the team. And I know you do work a lot with leaders and provide leadership workshops with your method.What's, what could, do you have an example for a leader, like in that own segment within your own part of the soccer field and that individual said, like, and what kind of things would a leader be watching out for interacting with others? [00:08:01] Coco Decrouppé: . So this, whoever's looking at the field gets. Their side of the field, so everybody has , the self leadership. Right. That is step one. Step two is the conversational part of it, and it's not important really. Who's on the other side? That could be a client. Could be a customer. Customer, it could be a team member, it could be a family member even.This is a space in the middle that we haven't talked about now, but this is a space in the middle where we communicate. And connect again and have simple methods to help us structure our conversations and get our point across, but also listen to what the other person needs. It's a dialogue.It's a dialogue. Right? [00:08:45] Joe Krebs: Yeah. [00:08:46] Coco Decrouppé: And learning how to do that is, is simple, but it does take a little bit of time and effort to do that. Since this method always starts with the self leadership, I want to first of all, calm myself down and understand what do I actually want from the other side without crossing that boundary, respecting that boundary.And once I have identified on the self leadership, what I actually want and what my expectations are from the other side, it's much easier to communicate. But often I hear leaders who Find themselves in a challenge where they don't know why their team doesn't react. That they themselves are not. clear on what they actually expect on the self leadership level from the other person. Yeah. So we need to be clear first what we want also from the other side and then communicate it in a solution oriented way. [00:09:41] Joe Krebs: Interesting. So there's, so what's, what I think is interesting about this method is a few pieces to it is obviously is it's universally applicable, right, to leaders, as you said.The interaction with clients or even family. This is not limited, obviously, to anything in the agile space, but it also applies very well to the agile space. I found myself while going through the material. You just mentioned that there is. The other side of the field. So far, we have just spoken about the one side of the field, our own, and what goes into that.Let's explore the other side a little bit. What I like about the soccer field method, not only that I am interested in the sport myself, is that I do like metaphors of learning, right? So I feel like the technique, the method you're introducing is very easy for everyone to capture, and I'm pretty sure everybody has seen the soccer field.And how it works. Now, what's interesting in your technique is when you look at a soccer field, there's usually a circle in the center of the field. For you, it's a heart. Why? What does the heart represent? It's wonderful visual there. [00:10:51] Coco Decrouppé: Yeah, [00:10:51] Joe Krebs: do these two sides of the field connect and why is there a heart?[00:10:55] Coco Decrouppé: Yeah, I wanted to make it cheesy. So for the yeah, so it all starts, like you said, with the self leadership, your side of the field and the goal where we have our calm place, so we know how to calm ourselves down. And then we step forward to communicate in the middle of the field where I call it the heart of communication, which is the heart of communication.It stands for a human way of communicating on an eye to eye level, which is a very human need. And we understand, we communicate directly and transparently. It doesn't matter if the other person knows the method or not, we are responsible and at the same time, it's our power that we come in a certain mindset and communicate whatever we think is needed in combination with the listening skills.So this is the glue of the method, the heart of communication and communication itself. It's the glue to relationships and teams and organizations. We need communication to connect. [00:12:04] Joe Krebs: Right. And that is particularly like the one to one kind of communication, right, between two individuals. And something like that I could easily foresee in an agile team being very important, not only as a team level, but one on one in something we often do.It's called pair programming. Why is that so important? Like in pair programming, there would be two individuals. Sharing a keyboard, but sitting next to each other in a space and communicating a lot about what they're seeing in front of them and working collaboratively together. Why is that so important in your method that it gets its own space?Not only the individual, not only the team, but there's this one on one. [00:12:45] Coco Decrouppé: Yeah. I actually think it's both really important right there on an individual level one on one, but also on a team level, there's a lot of impact that we can have when we look at team meetings, and you're in a leadership position.And the one on one is so important because we need to talk about how we can work together. what you need from the other person. We feel like it's logical to me. So it should be logical to the other person. That's not the case. And I feel like I've said it already once, but the other person for some reason did not hear it.So we need to repeat and really sit down, not only what we were, but also how we work together. And it's always easier to start and, play the ball to the other side first and say, okay, what do you need for us? In order for us to work better together, what do you need? And may I share what I feel will be best, what I need from my perspective. So we really share both sides. [00:13:44] Joe Krebs: Right. And that is in software engineering, super important. There's so much ambiguity, so many misunderstandings, somebody explains it in a certain way, and I might still be listening to it. But I might just totally understand it in a very different way than the sender has sent me.The message might come across very different, like the telephone game very typical. Yeah. So why the heart beside cheesy, like it is the heart of communication? [00:14:14] Coco Decrouppé: Yeah, it is the heart because it stands for the human conversation. It's really, I feel like it needs more heart in business. We need to have that heart to heart conversations.There are conversations we need to have as a leader when you need to let somebody go. There are difficult conversations all the time. And we might really like the person and want to keep the person on the team, but we don't see the performance. So we can have a transparent conversation or see, I really value our relationship.And for this position, I need a certain kind of skill set that I don't see right now. So we can be more transparent, a lot more transparent, actually, to build trust, even in these kind of conversations. And it has a lot to do with a respectful frame to really approach each other. No matter what our backgrounds are, our experiences are, our culture is, right, really and [00:15:12] Joe Krebs: even the spoken languages might be different.Right. So absolutely. [00:15:15] Coco Decrouppé: Yeah. [00:15:15] Joe Krebs: So much to consider. Now, taking this to the next level in our conversation just notice that it is already complex. Two people to communicate and, having a shared understanding. Now, if you're taking this to a team level, the complexity increases even more.So that would be the relationship with the team. So we're still having our own side. We're still having the one on one we're still having the heart, but now there's an additional complexity coming in when. When we have a relationship with the team what's in your method that, where you address this kind of complexity when you're working in teams and how does that look like?[00:15:57] Coco Decrouppé: Yeah. So it basically multiplies by the number of. people on the team, right? Because everybody comes with their backpack, emotional backpack. And it's like when you think of a hurricane, some transformation, sometimes transformation or change can feel like very confusing. And we want to help people, or this is what I do too, in teams or individual, with individuals, I help them go to that eye of the hurricane, basically, to be in the calm, while there's a lot happening on the outside.And you can Make big decisions and do a lot, but on the inside, I invite you to feel calm and know how to step back. That's the same thing for the team, like, because it becomes just more intense with more people, whoever looks at the model and method always gets the one side of the field. And with the team, we have like in the image, we have more people on the other side, not one individual, but more people.So it becomes more a 3D like skyscrapers, but that everybody comes with 100 percent field and with their emotions and expectations. And there is crucial to really respect the boundary in the middle, because we tend to either go on the other side and want to do. Work for others because they don't get it done or we allow them to come on our side and we are completely exhausted at the end of the day or end of the week because we let basically everybody in so it's important to. understand that in order to have that balance, it's okay to set the boundary in the middle. It's okay to say no sometimes. That's a difficult one for people. It will help us to not take things too personal. We respect that boundary and we leave whatever they say or do or not to on the other side where they are.And then we come to the conversational part in the middle where we do need to talk about things and about our goal. So the balance again between the self leadership, staying calm on your side, knowing what is yours, what is it not. And the balance to holding the outer line for the team. So reminding them like a soccer coach or any team coach, we, we come together and you remind them, this is our goal, this is our strategy.They are the experts, but still we need to be reminded that we are playing on the same field. So the leader needs to know, and everybody on the team really, how to step back, calm down, but also connect through communication in the middle to strengthen the outer line and the team and the organization.[00:18:50] Joe Krebs: Yeah, this is awesome. So boundary management is important. The lines are there for a reason. In a field, I think like in every sport, right? We we see now there is just one example for everybody listening to this. Why this is not, you don't need necessarily soccer skills to participate in any of your workshops.And here's one there is a situation I just want to take that as an example here with you. It's never really happening in, in the actual game. But there is a chance that somebody might swap shoes or switch shoes, with another and that's just like an interesting metaphor as well. I think we often use walk in my shoes kind of concept.That is where we're actually swapping the shoes I would assume. Can you just give a little detail on what that means just for listeners to see that? This is not fully soccer. This is obviously [00:19:37] Coco Decrouppé: yeah, it is a metaphor and like, it's not about playing against each other. The soccer field method is all about playing with each other and becoming a stronger team.So swapping the shoes is I think that's a tricky one for people because We tend, and it's a beautiful thing too. We tend to think for other people and feel for other people. , some of us Right. Others have a more difficult time. And it's great to understand what is happening on the other side and what a person feels on the other side, but that doesn't necessarily mean that I have to feel the same thing.. So I can be at the calm place in the goal and still create the space for the other person to express how they feel. or what their challenges are. And because I'm not confused with them, I'm not overwhelmed with them, but I'm there holding the space, I'm able to guide them and accompany them through the process of reaching a goal and moving forward. So I think stepping in each other's shoes can be helpful as long as I stay on my side emotionally. It's, I mean, very important to listen what the other person is going through. And that way. [00:20:57] Joe Krebs: Yes, it's an awesome technique. Now, this is audio recording only, so people can't really see that. A lot of smiling faces. There's a lot of cards there is, as you can imagine is lots of tools that are being shared within the classroom. Lots of in person kind of delivery and you're taking this metaphor, obviously into the workshop itself. What is the like the common feedback from people that exit your course?So what is it you often hear, like, just like a quick like maybe what's a common theme, like just in terms of self reflection when they give you an evaluation or if they follow up with you? What do you hear? I know it's positive because I see smiling faces everywhere. [00:21:41] Coco Decrouppé: So yeah, the workshops are very interactive. I believe in a light atmosphere and spirits because we're talking about serious deep complex topics. And yes, of course, there's soccer field is a big part of it. But it's also one card of a 26 cards toolbox for leaders that are created. And it's a fun way and gives us just topics to discuss that are very practical for people.So the methods they use in the workshop is like, are like Lego serious play, very interactive, colorful, playful approaches to talk about this serious topics. And we do start with clarifying what is impactful leadership? What is it not? And I invite everybody to share their experiences. And by doing that, people find themselves. Hearing about other situations that they didn't even think of. And they're very personal stories. So we connect right away and that makes, creates a very trusting mindset and atmosphere right from the beginning. And therefore I believe, because it's a very human approach people come with their personalities and we invite everyone to be authentic, obviously, and the combination with my tools, in the end people leave.Thankfully, very fired and what I hear a lot is that they knew about self leadership, but now they understand why it is so important in order to lead an impactful team. And this is really also my main motivation because I feel that we don't talk enough about the self leadership and in the end we are by slowing down, we are quicker at our goals.[00:23:32] Joe Krebs: Yeah Coco, this is this is awesome. And I want to thank you for spending some time here with the listeners of Agile FM. You do more than soccer field method training courses. Obviously I wanted to connect the technique to the agile community. Also doing a lot of training and coaching.In other areas. I wanted to use the soccer field method as a way to connecting the agile community to maybe a new tool in the toolkit to explore. And yeah, and then for everybody who is interested in your workshops, they can also find us on the show page obviously, but also at cocodecrouppe.com.Everything will be there. So I want to say thank you and good luck with the soccer field method. [00:24:14] Coco Decrouppé: Thank you very much, Joe. Thank you for having me.

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. Thank you for joining me again for another podcast episode of Agile FM in the Agile Kata series. Today I have Oscar Roche with me, who is based out in Australia. That's where we're recording from. And he is with the training within industry TWI and the visual workplace. He was actually told by a person called Mike Esposito from the historic construction That he makes philosophy and principles consumable.And we got to talk about Kata. I hope I got that quote we're going to talk about Kata in this episode. We're going to talk a little bit about some scientific thinking. We'll talk about where Oscar is coming from. He is a well known figure in the Kata community. And but before we do that, I want to welcome you to the podcast.[00:00:56] Oscar Roche: Thank you. Thanks, Joe. Happy to be here. Even at this time of day, 7 a. m. [00:01:02] Joe Krebs: So the voice needs to be oiled a little bit in the morning hours to get into into the podcast feel. Thanks for joining. And obviously you're in the Kata series here a few things you're very obviously with that statement we just heard about you You make this consumable.You are, you're thinking about, how could you take these practices that are surrounding Kata and turning them into something that is useful for your clients, for the people you work with, obviously. But you're also a little concerned about Kata community and, there is an article you we were exchanging ideas about by I forgot his Stephen Spears and Bowen in the Harvard Business Review from 1999.And and that puts a little light spotlight on, on Kata indirectly through the, how Kata influences the world of Toyota, but people out there in the community see Kata and scientific thinking and the way of how. Toyota Works is very different, right? . [00:02:00] Oscar Roche: Yeah, they do. I don't think that connection has been, I don't think we, we as in our world has made that connection very strong.I think one of the problems we run into is that people say we don't make cars or we're not Toyota. We're not a big corporation and all we don't make cars. So I think that's one of the problems, but I guess. In terms of that Spear and Bowen article, it was, I read that probably in 2018 or 2019 And I was introduced to Kata in 2011, and it was only when I read that article, I thought, ah, this is what. This is what we're getting at. This is what we're trying to get at with Kata. And what that article said was the Spear and Bowen article, one of the things it said was that Toyota aims It said two things that made the penny drop with me.One was it says Toyota aims to develop a community of scientists, and I thought, ah, that's interesting. And the second thing it says was that Toyota views every standard as a hypothesis. In other words, even their production standards are hypothetical. If we do this, we expect that. But we need to run it and see what happens.So every, in essence, every production run is an experiment. And I thought, wow, that is a very interesting way of looking at the world. And that's what Mike Rother's getting at. That's where he wants us to be. He doesn't want us, he doesn't want us to be at Kata. Kata is, the Kata patterns are just a means of getting to this utopian world.Every standard is a hypothesis and we're a community of scientists. Yeah. And that was when the penny dropped. I thought, ah, it took seven years, or whatever that was, six years. [00:03:57] Joe Krebs: But I got there. Yeah, [00:03:59] Oscar Roche: what's interesting is actually, I think I got there. I think I got there. I'll find out. [00:04:05] Joe Krebs: Yeah, exactly. What's interesting is when you look at Toyota, I don't have any insights into hands on employee experience or anything, but if you look at Toyota, yeah, but if you look at the production facilities of Any kind of carmaker let's not even say Toyota, right?Any carmaker, let's see some like some construction belt and the products are moving by, but the company, what and how they think, especially about Toyota is very different. [00:04:34] Oscar Roche: Very different. And I think it, the other thing that attracted me to that thought in the Spear and Barron article was how liberating that is.Yeah. If you could adopt that philosophy of every time we run production, it's an experiment, then I think you started to, you start to move away from right versus wrong, blame versus not blame and all those sort of things that go with, we are going to run this and we are going to get it right because this is the way we do things.I think you start to move away. I think you would change. You would completely. With that philosophy, that thinking, I think there's a very good chance you completely change the the work environment, if you like, it becomes, we're going to try this and see what happens. And if it doesn't work out as we expect, then we know how we're going to think when that happens.[00:05:26] Joe Krebs: Yeah. But in that article, they also talking a lot about that there is an absolute detail and emphasis on, let's say documentation in general, it's like about the core production process where. Seats go. And so there's a lot of detail, but the detail is actually evolving over time. So there's absolutely constantly being challenged.And I think some [00:05:47] Oscar Roche: because it's a hypothesis because the data is a hypothesis. That's why it's being challenged. [00:05:53] Joe Krebs: Yeah. And what we see in organization is when an organization is that these handbooks and these processes are, they're just staying [00:06:00] Oscar Roche: and they get stuck [00:06:01] Joe Krebs: and they get stuck and they don't challenge those procedures.[00:06:06] Oscar Roche: No. And the worst thing is they end up on the shelf. [00:06:08] Joe Krebs: Yeah. Yeah. So what also is in this article, I want to hear your take on this is there's also a mention on that what you would be observing, obviously, they have studied this for several years. There's no command and control. So if you would look at the production facilities and you look at it.It feels, it might look like command and control, somebody's being told what to do, but it's not, right? It's not. There's a different system in place. What's your take on that and especially this style of leadership compared or in contrast to scientific thinking and possibly Kata? Good[00:06:47] Oscar Roche: question.So my take on this on that is it would be something that's extremely hard to develop. No, I don't know that it's hard to develop, but it's going to take time. And one of the point, if you got everyone thinking this way, everyone thinking as a, we've developed this community of scientists. So we're all thinking that way.And every standard is hypothesis. Then you're in it. You're in a point. And management is thinking that way, then you're at a point where it can work, but getting to there, there's going to be, I think one of the troubles we run into is, we recognize that's what Toyota started is doing now or in 1999, but when did they start trying to do this?About 1952. Yeah. So we, about in 2019, with the Institute, a group of us went to Japan and we spent time with Mr. Isao Kato, who was Ono's HR advisor, and he gave us a timeline of when they started to when they started to, On this journey, and I hate that word when they started on their journey to where they are now, and it was not, it was, I'm pretty sure, if I remember rightly, it was 1952, it was 51, 52, 53.We've got to also remember that's for, when Speer and Bowen did that article in 1999, let's say there's 47 years of this stuff evolving when they, for them to be able to get to that point. The problem we run into is, and it's a very valid point, that no other organization has 47 years to get to that point.But, so therefore, I think we've got to, we've got to look at how they might have got there, or what we think we can do to accelerate. Exercise of that process for one of a better word of getting there and one of the things we can do is practice is use things like the Kata patterns to help develop these behaviors and these way of thinking.So get back to your question. If everyone's thinking that way, then it just happens. Yeah, but how, but when some are and some aren't. Then it's difficult. And if management aren't forget it. Yeah. [00:09:04] Joe Krebs: That's obviously the challenges with many transformations out there now you're very you're making a strong comment when you when we were exchanging ideas, a little bit of what we could talk about and you have a very strong comment.Yeah. Opinion about Kata being seen as nowadays with the gaining popularity people started talking more about, about it. Maybe more and more people are trying it. My goal with this podcast is obviously to bring Kata closer to the agile community. But what's interesting is that you see the Kata is wrongly seen as really frustrating for you as the goal rather than the start.Of that journey. I think we're talking about why. What's your warning to people out there? I agree with you. Obviously, Kata is the starting point. But what's your recommendation for people out there that are trying to experiment with Kata in terms of the mindset, how to approach this? [00:10:03] Oscar Roche: Yeah, sure. So I think, and it's evolved in the conversation we had before this podcast started, I think one of the we try and explain the, we try and explain the world that Kata can take you to, to people but how can you explain something that can't be seen?It's a little bit of a problem. So perhaps what we need to understand is what are we moving away from? Because we can see that now. So what we're moving away from is random actions, pulling things out of the air, acting on whim, illogical actions, if you like. So I guess an approach might be, to what extent are we randomly thinking now?To what extent are we heading here, heading there, depending on what manager walks in the room or, what person of authority or what person with a strong personality? To what extent are we doing that? Because if we would go down this track of practicing or using Dakata patterns, we're going to be moving away from that, and that's not fun.Random thinking creates waste, random thinking creates frustration, random thinking creates a lot of things that aren't good for engagement at a workplace. Yeah. So perhaps rather than try and describe Where we want to get to, let's try and describe where we want to, what we want to get away from.That might be more because we can feel where we are now. It's hard to sense, it's hard to sense something that's a year away. Yeah. Perhaps that might be a worthwhile thing to consider. [00:11:37] Joe Krebs: And that target out there, like 12 months from now, that's a moving target even more right?[00:11:43] Oscar Roche: Correct. It is. But where we want to be is not thinking randomly, not acting on whims. Not being pressured into doing something because someone forceful has walked in the room or a senior manager has said, do this. We want to get away from that. Yeah. But that does, the, you mentioned Mike Esposito before he's a he works with, or he's a part owner in Story Construction in Iowa, in Ames, Iowa.And he, I do, they're my favorite client, and I'll tell a lot of people that, and the reason for that is because he and a fellow owner who's the chief operating officer, Pat Geary, they have a very clear vision of where they want to be, and it's not that far off that 99, that 1999 article by Spear and Bowen but they have that long term view.And they know there's going to be setbacks and they know there's going to be frustrations and they know they're going to make mistakes. Yeah. And they do. But they, when they do, mistakes are only mistakes in hindsight. They're not mistakes beforehand, they're mistakes in hindsight. So when it happens they learn from those and they adjust so they've got the mindset.They've got the, those two guys have, and Pat in particular, has the mindset that will get that organization to where they want it to be. Yeah. Unfortunately. That mindset in that level of leadership, I find to be extremely rare. Yeah because you need to have a long term view, not a one year view, or even a two or three year view.a bit longer than that. It's very interesting, right? In the agile community, I often hear the separation between agile ways of working and an agile mindset. And I think what you are, what you're describing here is the Kata is the. Not even the ways of working, it's the ways of getting started, right?It's the ways of getting started, whereas the scientific thinking or the non random thinking is the mindset if you want to establish over time. And that is obviously something the Kharak can kick start us with, but eventually our own Habits are taking over, still in the scientific thinking mode, but it's like it will change, it will move, it will transform into something else that doesn't look like the Kata and necessarily anymore that we started with.So we want to leave that behind, but it's the starting point for that journey. And I think that's what you're pointing out wrong. No, you are right. So as I was thinking as you were speaking, so Kata is the way we start to develop a way of thinking. If we think that way enough, that'll become our way of working.And I think, I suspect, I'll never know, I suspect that's what's happened to Toyota. Yes. The problem is that people who work at Toyota now can never explain that. There's no chance they're ever going to be explaining it because they just, it just is the way we are. But we have a Toyota guy who works for us and does mentoring in Melbourne.He left Toyota in 2011 and he poohoos Kata. Yeah. Directly poohoos it. But I've watched the way he works and he works exactly the way that Kata is intended for him to work down the track. So I watch the way he works, I watch the way he think, I watch, I listen to what he says and he acts and works that way.Yeah. Because he, naturally, because he can't recognize how he's got there because he's, he just, it's just the way they are. Yeah. Interesting. That's truly. Yeah. Why would you need Kata to do this? You just do it. Yeah. [00:15:23] Joe Krebs: Says you. Who has been doing this for a while. [00:15:27] Oscar Roche: Exactly. Says you. But what about everyone else who is the majority of us?How are we going to get there? Yeah. [00:15:34] Joe Krebs: Toyota also has a commitment to learning continuously. There are various aspects of learning going on. How do you manage those expectations when you do work with leaders? [00:15:46] Oscar Roche: How that fits is that scientific thinking itself is learning. So I'm looking at a definition of scientific thinking I have on my screen here and it says it's a continuous, this has come from Mike, it's a continuous comparison between what we predict will happen next, seeing what actually happens, and adjusting our understanding and actions based on what we learn from any difference.So if we're thinking this way, We can't help but learn, because we're going to adjust our understanding and actions based on what we learn from a difference. Learning, we don't have to. Learning is not the goal. Adjusting our understanding and actions based on what we see from a difference will mean that we learn.[00:16:31] Joe Krebs: That's the verification I wanted to hear from you. Exactly. It's an ongoing, it's an ongoing process. It's built in. It's part of, PDCA. [00:16:41] Oscar Roche: Exactly. Yeah. It will, it just is. If we think this way, we will learn. We can't help but learn. Yeah, [00:16:49] Joe Krebs: but it's on the job learning, right?It's not a, it's not a theoretical kind of classroom experience or program that extensive program people are going through and learning about these things. This is very hands on. It starts on day one. [00:17:03] Oscar Roche: Exactly. And I think also it almost requires two views or two mindsets at the same time.One is I'm doing this work. The other is, I'm looking at this work from the outside, so I think that's difficult. I'm going to do two things. I'm going to do the work as per the standard, the way we do it today, but I'm also going to look at the way I do the work to see if I can, to see if what we predict is going to happen happens, and if it doesn't, then we've got to work on the difference and learn from that and make adjustments.So that's where, I think that gets a bit hard too, to do two things. One is do the work. In other words, we're inside it and the other is look at the work from the outside as I do it and question it. That takes time and energy and all the rest of it. That's not easy.It's not hard if you practice a pattern, yes but that energy of to practice that pattern takes a bit, it takes a little bit of amount. It's, it's a tough one to climb. [00:18:01] Joe Krebs: So I just want to map this to some folks that are listening, maybe from an agile angle that learning would be some learning that we in, in, in processes such as scrum or extreme programming and so on, have experience in retrospectives where internal learning that's taking place.I want to ask you a last question here while I have you. Is somebody is listening to this podcast right now, likes what you're saying wants to get started with Kata. Like it's a very practical I want to use the Kata to get started with that kind of thinking Like very practical.What would be like a very first step? Just a realistic step. We know it's a longer journey for people with longer term vision, right? Of where to take a company or a product or a team. But what would be for you, like something to start with? What would you suggest to somebody listening to this and says, I want to experiment with the approach maybe even, [00:18:56] Oscar Roche: it's a fine line between reading too many books and just having a crack. Yeah. I think and different people are different. Some people need to read a book or two before they're going to before they're going to jump in. And the original, the original 2009 Toyota Kata book is not a bad place to start.I think there's been some that have evolved since that have made it more complex than perhaps it need to be, I've spoke to Mike about the practice guide and the practice guide is written from an engineer's perspective with an engineering view and it goes in quite deep. I would imagine that to be a lot of people, non engineers, non manufacturing people would be quite frightened about that.It's, the reason I'm stalling a little bit on the answer is it just depends. It depends on the person how they best get started. Do they just need to know enough about the improvement model to be able and some guidelines to get it started? Is that a 10 minute conversation? Some yes, some they need to read a book.I'm happy to be contacted. I think actually, I think. The way I always approach this is I need to understand the individual and the organization before we say, do this, because this might help. Yeah, [00:20:10] Joe Krebs: Makes total sense. And, there's also conferences out there, they can attend.Training courses they can attend. There is a hands on workshops they can attend. There's a variety of learning tools available et cetera, just to start with their journey and obviously practicing kata and picking up a book might be another option to just get started. [00:20:32] Oscar Roche: I don't want to give people the impression of do this and it'll work for you. [00:20:37] Joe Krebs: Absolutely not. Yes. But what I'm trying to say is there's a bunch of resources. Oscar. Thank you so much for joining this podcast and sharing your thoughts.[00:20:45] Oscar Roche: I hope it's a value to the people who listen.​

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:09] Joe Krebs: All right, thank you for tuning into another episode of Agile FM in the Agile Kata series. Today I have two guests with me, actually three guests with me. I have Dan Roman and Richard Sheridan from Menlo Innovations. We have Dexter with us in the background. He might or might not. Contribute to this recording as he's a dog, Dan is a frontline worker at Menlo.He's a a lead, but he's also primarily a software developer. We're going to talk a little bit about Kata in development and obviously Richard Sheridan, author of the books, The Chief Joy Officer and Joy Inc. Is it fair to say you're the Chief Joy Officer of Menlo. [00:00:54] Rich Sheridan: A chief storyteller is the more typical title they give me here.[00:00:59] Joe Krebs: Awesome. All right. The chief storyteller, Richard and Dan, welcome to the podcast.[00:01:04] Dan Roman: Thank you for having [00:01:05] Rich Sheridan: us. Thanks Joe. Good to see you. [00:01:08] Joe Krebs: Yeah. Good to connect. And this episode we're going to focus a little bit on development. We want to talk about how do teams build agile teams? How do they build a product?Here in particular software development products. Now, Dan you are, as far as I know from a website, your keynoting together with Richard there is, you have a focus on software for manufacturers of medical instruments and software for space researchers. So this is. This is I would say complicated, complex stuff you're working on and as far as I can tell and we talked about that during our visit in in Ann Arbor, where you guys are located, that there is no formal process like Scrum or Kanban or like to the book extreme programming deployed at Menlo Innovation.Is that correct? [00:02:01] Dan Roman: 100%. We have plenty of people who come and visit and we'll see what we're doing and find that what we're doing matches with one of their models. So we didn't set out to be agile, but agilists who come in say, Oh, Menlo is agile, or we have lean practitioners come in and they say, Oh, Menlo is lean.But our processes, we never started from a place of. We want to be agile. Let's do it this way or we want to be lean. Let's do it that way. [00:02:27] Joe Krebs: As you're obviously working with different kinds of companies and clients. And obviously also with different kinds of products you guys are creating. Now, I would be interesting because.There is a term that's being used, I was told, on the floor at Menlo, this is run the experiment. That seems to be a frequent term. Can you just specify, either one of you, what that means, or maybe both, right? And how that comes into play, working in agile ways. [00:02:55] Rich Sheridan: I would say, Joe, that phrase is born out of a background philosophy at Menlo that says, let probably pump fear out of the room.We think that fear is a culture killer. Filler fear is a mind killer. I think there's a line in doom that says something like that. And so if someone has a new idea here, rather than. Hey, let's form a committee to write a policy on that. I do. Let's take a meeting. Our inclination is to take action with that simple phrase.If somebody has an idea, somebody else might see. Great. Let's run the experiment. See what happens. And that can typically the things we try are on fairly small scale. We don't upend the whole place every week to try some new, crazy new way of working. But usually it is some small incremental change to an existing process or an enhancement to the way we do things here.Because somebody believed that there was a problem to solve and this experiment may help us address that problem. Again, trying it and see how it works. And the experiments that succeed are the ones that last a long time and others might just thritter away because they didn't actually solve an actual problem.Probably more often than not an experiment. Morphs over time. We had the original idea, we tried it, it didn't work the way we hoped. We try something a little different. [00:04:23] Joe Krebs: So it could go into either direction. So when we talked about this a little bit about the experimental part and obviously I'm very public about my my work and my interest in Kata and scientific thinking through Michael Rother and Jeffrey Liker.We, we met in Ann Arbor. And obviously when you hear the word experiment in connection with Kata , then it becomes, obviously the question is, how does this whole setup look like in Menlo? How do you guys operate? How does this all work? Do you guys have a product owner within Menlo? Do you guys have scrum masters?Do you guys have project managers, agile coaches? What do people listening to us right now have to imagine when they just picture Menlo and cannot visit you guys in person? [00:05:10] Rich Sheridan: It's probably valuable to know, just for your listeners, a little bit of background on what Menlo does for a living, where we make our money.We are doing custom software development on behalf of our clients. So Dan has done a lot of projects for us over the years that he's been here. He will work in with manufacturing companies who are trying to enhance their ERP systems. He'll work with furniture retailers who are trying to improve how things happen on the sales floor.So all these companies are coming to us because as Joe, everybody in the world needs software to run their businesses these days. And so we are bringing in clients from every industry imaginable to come in and work with us. We have a fairly simple structure to our team. The teams that Dan is a part of that are working on those various projects will consist of a project manager who is typically paired with we'll call it a product owner on the customer side of the equation.And for us, the customers are the people who are paying us to do this work. They aren't necessarily be going to be the end users, almost never the end users. Software building. We have a set of people on our team that have a very fun and unusual title and a great role called high tech anthropologists, and their job is to understand the humans that will one day use the software, the end users in software.Then we have our software development team, which comprises the biggest part of our company. And then Formal quality assurance role that works alongside the software development team. So every project at Menlo has some component of each of those four pieces. And and we work on a weekly iterative basis here.essentially right sizing every project for exactly the workload, right sizing it with the types of people it needs. We're more in the discovery phase. There'll be more high tech anthropology. If we're more in the software development phase, there will be more people like Dan on the project. The project manager and the QA teams are shared amongst variety projects, and they are they are constant throughout the course of each of the projects.In any given moment in time, we're a team of about 50 people. We have, probably right now, I'm going to guess about 15 different projects. at various stages. Some of the projects are large. They'll have 8 to 10 people on them. Some of the projects are small. They only have a couple. And it's probably worth noting that we pair.That pairing is a big construct here. That was an early experiment that took hold in the 23 years ago when we founded Menlo. And it has never let up since. [00:07:44] Joe Krebs: So running the experiment seems to be something like a, for testing and verifying the process in place, like programming, right? Is this an interesting, is this you have read about it, you, the teams might try it and find Found it useful, like many teams found their programming useful, right?So it's an interesting thing. So you're using that kind of experimentation approach for the process you're using, but you're also using experimentation for building the products for your clients. And that's where I want to go a little closer here. So you have your how do you protect your end user, your users?Your clients or your customers that are the product owner or acting out that role. If you want to say it this way. But then how do these requests come in? There's a ton of teams that are there that are using user stories product backlogs, ordering activities, refinement activities planning, sprint planning activities, and so on.How does this all look like at Menlo? How do you guys incorporate that if you work in different ways? I would be curious to hear. [00:08:42] Rich Sheridan: Yeah, the biggest starting point and starting is always hard for every project is starts with our high tech anthropology team and really attempt to answer three questions and use a lot of experiments to get to the answers to these questions.What problem are we actually trying to solve different than perhaps the one even the customer presented to us? Who exactly are we trying to solve this problem for? What types of people? And we'll use personas and persona maps for that exercise. But a lot of that discovery work is done out in the field.And so a lot of the early experiments are to be able to find these typical end users of the products we're working on out in the world. And that is often where some of the key experiments start early on. I'll give you a fun example, way back in our earliest days, long before anybody had iPhones or any kind of GPS devices, we were working with a company that wanted to create lanyard type devices that people who were on cruise ships would use to navigate the cities they would arrive in as the cruise ships pulled into port.And so imagine they had around their necks, they had these GPS driven devices with moving map displays and that sort of thing. So we had to figure out simple questions like do people know how to read maps? Because, if you ask a group of people, do you know how to read maps? Everybody would say, absolutely, I know how to read a map.If you ask people to read maps, you find that hardly 50 percent of people know how to read maps. And so it would be very expensive to try and do this on a cruise ship. We did get one cruise ship ride throughout the course of this project. But before that, we went to a local theme park here, locally here, just to watch people try and use maps.So we would run into that. with them. We would walk up to them with a map in our hand and say, Hey, can you show me where the Edison exhibit is? And we obviously have the map in our hand and we would see if that people would grab the map and what they would do with it and how they would orient it. And 50 percent of the people said, Oh, I can never read these things.See that circle I over there, the information booth, you should go ask them. So we found out right away that about 50 percent of people self report they don't know how to read maps. But this was really early experimental data that we could collect very inexpensively around what kind of challenges would people get to if they don't know how to read maps and we're creating a device that's supposed to allow them to navigate a city.And we get very creative. We try and do things inexpensively. And then ultimately we experiment with the potential designs, often with paper based prototypes to see what will actually work for people. Once we get into the actual software development, once we've secured that we understand what design and work for them, then there's a lot of other experiments that Dan and his fellow developers here at Memo will use.Sometimes those experiments are technical ones, technological ones. Sometimes it's most of the time, I would say they're often human ones because we were often working with developers. And our client sites, we have to figure out how to work with them, given the way we work. [00:11:55] Joe Krebs: Dan I'm curious, like just to take it to the software development side and take advantage of you being here on on this podcast as well, right?So it's a great insight to see business and the leadership of the organization, but also to see the actual implementation of these products, right? So let's say we're doing these visioning techniques and obviously as a. As Richard pointed out, there's a lot of cost savings finding out early on that people can read a map, right?Could you imagine you were building something assuming they can read a map? That would be a very costly detour later on. But I want to go a little bit deeper because there's so many teams, agile teams out there that are preparing for sprint planning activities or iteration planning. And they're using user stories or and then they're basically have planned everything and laid it out and implemented.You guys have through that experimental process, a different thing in place. I think it's much more lightweight, if I'm not mistaken. Can you walk the listeners maybe through once these requests come in and you're actually in the software development part of how you're still using experiments for that?[00:13:00] Dan Roman: Sure. So to as Rich was telling us about those experiments, it reminded me a little bit that every development iteration at Menlo, I would argue, is itself an experiment. So the beginning of the iteration happens after a show and tell, where the software development team will actually have the client or customer demo back to the development team the work that was accomplished for the previous iteration.And then based on that demo we'll authorize the next week's worth of work which comes out to some 40 planned hours worth of work. And when I think about Kata, I think about declaring a desired future state. And that's ultimately what we're doing. When we set out a plan for the iteration, we're saying the plan is we will end up in a state where these cards have been completed and there'll be completed in this effort.And then the rest of the iteration is the steps that we as a development team take to try and realize that. Future state. And then by the time we get to the end we'll basically start the cycle over again, which will again reminds me a little bit of Kata where we'll compare. All right, we started with a plan to get to this future state.We've run the iteration for a week. Let's compare where we are compared to where we want to be. And ultimately, all of that happens through obviously the software developers doing the work, but that all happens through . The story cards, which are our fundamental unit of work and these are three by five index cards on which are written the work items that the developers will go and implement and our quality advocates will go and test.And typically our high tech anthropologists are part of writing in the first place. .[00:14:28] Joe Krebs: Is there still like, are you pulling from an organized formal product backlog as so many scrum teams? are doing, or is this process a little bit more ad hoc and fluid based on the work you did in previous iterations where you're getting instant feedback from your customers and how does that all look like?The show and tell, that's where this comes together, I would assume. [00:14:50] Dan Roman: Yep. That's a very good question. So it's a little bit of all of the above. So what Rich was alluding to at the beginning of our engagements, the high tech anthropologists will do a lot of the Upfront work of describing here's based on our research and our observational data, what we believe the application needs to do.And that sets as a starting off point for the engagement itself. But over the course of every engagement, we are also discovering new work. So over the course of a given iteration, as the developers are doing work, they might write. They may write other story cards or the quality advocates may write some story cards or even at show and tell the client might may say, Oh, we didn't think about the fact that the user might need to do this certain thing.One of the fundamental rules that Menlo is that everyone can write a story card. Now just because you've written a story card doesn't mean that it'll get authorized or that'll get put on a weekly iteration. But we are certainly collecting the scope that's being executed nonstop over the course of the engagement.[00:15:49] Joe Krebs: How does maybe I love this story cards, right? Obviously, there is a story to be told and collaborated on as a team. How detailed are you? As teams now within Menlo, how detailed are you with the planning activities? Are you planning very ad hoc? Is this like in subgroups or pairs or how let's say, this, these requests are coming in.You have these stories and you're experimenting, I would assume also on those. How detailed are those or all the questions? [00:16:22] Rich Sheridan: Yeah. The important element of our planning that I think probably differs from many development teams is how collaborative it is with our customers. Number one, we're putting together at a high level a story mapped version that might map out a year or two worth of key milestones for this client broken down into achievable goals that might run.Okay. A month, two, three, four months. And then we start laying out the story cards for that very first goal. And the customer is standing alongside of us choosing these story cards that should go into that plan. Obviously we're giving them some advice from a technical standpoint as to if there's a more appropriate sequence of things that makes more sense, but we really want the business feeling like they're driving this we often find it When we hear of other teams challenges in planning and estimating and that sort of thing, you often find that it's an adversarial relationship with the business sponsors, where somebody is I can't believe it's going to take that long, or you need to get this done in a shorter amount of time.Our approach isn't to try and argue against the importance of a date or features within that date, but to simply argue with the data of here's what fits, given your budget, given your burn rate, given the team size we have. And then it's a question of, can we make responsible trade off decisions with our client to get to that particular goal?And then, as Dan said, on a weekly iterative basis, we're going to review the progress against our original plan. Because, no plan actually holds up once it hits reality. So we're going to get, sometimes we get more done than we expected, sometimes we get less done. But that weekly visit into what exactly do we get done in the weekly opportunity to now look ahead in that longer plan and say, okay, what we've learned now, should we make adjustments to the plan?Have we discovered new things that need to be done? Should we write story cards and estimate those story cards? Should we take some things off that we originally thought should be part of the plan in favor of newer, more important things? Collaborative planning happens on a week by week basis on all of our projects.I think the most fun thing I see happen is that often we use paper based planning techniques, which is again, unusual for software teams to use paper. Typically in the earliest part of our planning, all of our story cards are on white paper. But as time goes on, and as customers start to get nervous that we don't seem to be making as much progress, we often switch to, say, hot pink paper for things that were newly discovered or that somebody raised their hand in a meeting and said, hey we didn't think of this when we talked to you about it originally.And so we'll write that story card up, we'll estimate it, but when we put it in the paper based planning process, we make it hot pink. And over time, what you can see is The actual physical real estate of our planning sheets being taken up by more and more hot pink work Which essentially says hey, there was a lot of stuff for some reason we didn't discover early on Yes wrong with that, but let's at least acknowledge With this, these colorful pieces of paper that we are now three months into this project and 25 percent of the things we're working on are things neither one of us thought of at the beginning of the project.That can be really helpful to maintaining executive sponsorship of a project because. Now we can have explicit discussions about new things that came in. It isn't some theoretical wave your hands in the air. There were a few new things that came along. No, it is clear what the new things are that came along because it's on this different color.[00:20:18] Joe Krebs: Yeah. Creating truly a partnership, right? With with the business the clients in this case do to showcase this, right? And obviously as a client, I would assume they're all very happy with us to see that. They are late changes are being incorporated some way or the other, and [00:20:34] Rich Sheridan: happiness is an interesting word in this.So it would be fun to believe that the people on the other side of the planning table at Menlo have all of the power and all of the authority to make these changes. But typically they're reporting up to an executive somewhere that has some other budgetary constraints. . We're not so much trying to make happy customers out of this process.We're trying to make informed customers so they can have intelligent conversations when they go back to their offices to say, Hey, I thought you were going to have all of this. What happened? And what you really want to do is give them the physical artifacts they need to be able to create a story. scale all the way up, perhaps to the CEO of the company to figure out why is this project where it's at right now.[00:21:27] Joe Krebs: . That's a good point. And thanks for clarifying. I think makes makes perfect sense. Dan Richard's mentioned the word a few times. I want to go a little bit deeper. That's the word estimates. Are you guys estimating there's a lot of different kind of estimation techniques out there.Agile teams are using, I'm just curious with this approach where you're going into more experimental activities, if estimation is actually still a thing here, or if it's an, if so, how lightweight it is. [00:21:58] Dan Roman: Sure. So to start right off the bat, yes, we do estimate it's part of that weekly iteration cycle.So every development team is sitting down and looking at the cards in play, as well as cards likely to be played in the future and estimating those story cards. That takes about an hour of time for regardless of the size of the dev team and we estimate in hours and in powers of two. So a given story card at Menlo would sit between two hours and 32 hours again on that power of two spectrum which can feel pretty radical for some organizations where things like velocity.I know that's a very popular way to, Fibonacci numbers as a means of calculating velocity or t shirt sizes, another sort of abstraction. I think that there are a couple of things that necessitate, or at least why we as Menlonians prefer that method. One is because estimating in hours is a universal language that when we get to that planning game after the show and tell with our stakeholders.There's no need to do any translation between 13 Fibonacci points or a medium t shirt size. We can say we've got 40 hours of effort for a given pair to plan for. And this card is 16, and that's 16 hours worth of work. And that's something that is instantly understandable by our stakeholders.I think part of the reason that we as a team are able to do that and Not in all cases, but in some cases, why other teams choose those kinds of abstractions at Menlo. We have a very healthy relationship between the technical folks who are doing the work and the project managers and stakeholders who are authorizing and planning the work.And that's manifest in this sort of contract. That's very explicit and part of, as I understand it, our project management training. There's a dual responsibility for maintaining our estimates. So any software developer pair that's doing work on a card. As soon as they know they're going to miss the estimate.So if Rich and I were pairing on a story card and we were on an eight hour card and we started to realize, Oh, wait, this is bigger. This is going to be at least double that. This is a 16 hour card. Now we have a obligation to go out to our project manager, for example, Lisa, she's one of our PMs and telling her, Hey, Lisa, we are working on this card.It was originally estimated as an 8, but because of these reasons, we see it as a 16. That's our half of the sort of contract. The other half of that is the one that lives on Lisa's side, or the PM's side, which is to say, Thank you for your estimate, and smile. And that sounds like a really simple little strategy, but it's That kind of strategy that sucks the fear out of the room that would otherwise inhibit Rich and I from volunteering that information or giving an honest, updated estimate on the card.And that's why a lot of other teams can run into those abstractions is because it's scary or painful when you let some set of stakeholders know, oh, this thing we originally estimated will take a day is now going to take more than that. Yeah, [00:24:59] Joe Krebs: well, there's definitely a lot of controversy out there about.Estimation and the techniques and in communicated and sometimes they're so like inflated to o just to be safe, depending on what organization and teams you work for. So that's, does not seem to be the approach at Menlo and obviously you guys. I've taken an expert estimate on the work at that time and see what, what comes out of it.Once you start working on it very interesting thing. Now you just mentioned that I want to follow up on that word too, because I think the listeners out there who are. Used to agile coaches scrum masters, et cetera, et cetera. They are probably not saying did he just say the word project manager?Did he just use that term? And because that sometimes that is a term that has been removed and replaced and you guys are using it actively, as far as I understand what's the role of a project manager at? Menlo, if you're working so in so agile ways and in experiments and et cetera what would be the role of a project manager other than nodding and saying, thanks for your estimate and smiling.[00:26:09] Rich Sheridan: So the primary role of a project manager at Menlo is to be the voice of the customer, people who pay us to do the work when the customer isn't in the room. And so their job is to answer questions from the development team about the general direction of the project, where it's going, how we're going to get there, what what the overall overarching goals for the project are if the cause, if the project manager doesn't know they will reach out to the client who isn't imminently available every time we want to reach out to them.That's why we need somebody who's advocating on their behalf when the client isn't around or not available by phone and that sort of thing. The the other role important role project manager does is to help the team remove obstacles. Dan and his pair partner will be rolling along and a card gets stuck.Have a question, need to reach out to somebody, you can just let Lisa know and say, Hey, Lisa, I just want to let you know we're stuck here. We wrote to the client. We're waiting for an answer. We're going to red dot that card, which means they're going to stop it. We're going to move on to the next card in the lane.And if there's anything you can do to help remove that obstacle, that would be awesome. Project managers also keeping close track. Our customers are spending a lot of money with us, so keeping close track on the budget relative to the total budget relative to the burndown for that budget, all those kinds of things.I guess there's a tremendous amount of, financial oversight that comes with every one of our projects, we're often working on projects that run into the millions of dollars. And so project managers are helping manage that part of the process with us. And you're also making a lot of decisions alongside people like Dan is to what should the composition of the team be this week.So it's a very collaborative role for the people doing the work I mentioned before we pair, we switch the pairs every five business days and. over time, systematically rotate people in and out of the projects to avoid burnout, to avoid towers of knowledge issues, all that kind of stuff. And the project managers will work very closely with the team to figure out what would be the best composition of people who should pair with whom who who would be good candidates for these story cards, that sort of thing.[00:28:27] Dan Roman: I think there's one element that's important too for Menlo, but I would also argue this is true of other organizations. But the roles and the titles that we have for the work that each of us as Menlonians do does describe a primary role. But that is not to say that the team is not responsible for also doing some of the other responsibilities of the other roles.For example, I am primarily a software developer at Menlo. But on a day to day basis, I am contributing to the conversations Rich is talking about where it's planning the resources for the project, making sure that the customer is appraised of any changes to the plan or keeping in mind the decisions that we're making today and what impact that has on the end user, the way that our high tech anthropologists might be considering.So I think it's one of those things where it's like we, we have those titles and those roles to an easy heuristic to generally describe what we do within Menlo, but at the end of the day, there's actually a lot of blending or blurring of the lines that exist between our individual roles.[00:29:30] Joe Krebs: Yeah. I think that's also it speaks to the self managing aspect of agility in general. Now I'm so thrilled to have you both on this podcast episode, because we had in this Kata series so far, we had different topics. We talked about transformational cultural things. I, this is a and I think that's a really great, wonderful episode.I believe it's a wonderful episode that really focused on Developing in agile ways, but in a non prescriptive or existing frameworks. That are out there and you can almost say like, when I listen to your conversation. It's almost it's almost sounds like cherry picking, right? Of how we're using this concept, or we are estimating, but a little bit different, or we have paper, but some of them are pink.And and so what I and working in pairs and we're shifting pairs and the way of how you operate with clients rather than the product owner being in house, the product owner is the actual client. So there's a lot of things. So there are some terminologies or project manager, just to name another one versus a scrum master.And what's really fascinating, I think, is for one of the goals of this episode is to show existing Agile teams if something's not working with an existing framework or with the process they have chosen, as you guys said, run the experiment, right? Try something new. Adjust your process. That's one element.And maybe you find ways of changing the way of how you currently work with breaking something. Obviously, that is recommended, but you're saying it's not working for us. That's not us. And that would be whatever you shared about. Menlo and the culture, but there's also the way of using this way of working to build the product itself, right?So there's two aspects to it, shape the process, how you want to work, but also the way of how you build a product for your clients. So I want to thank you guys for that. That is really nice. Thank you. [00:31:22] Rich Sheridan: You bet. Yeah. I think our general philosophy is all of these tools, methodologies, ways of thinking have value to offer and why would we constrain ourselves to simply one of them?Why don't we borrow pieces and parts? And put, I think for us, we do refer to our general system of work here as the Menlo way of working. . And but if you probed, you would see we borrowed all these pieces from this so we don't find ourselves resisting any of them. We find ourselves embracing them, looking at them deciding, oh, that might work here.And every project has its own unique, qualities to it as well. I [00:32:02] Dan Roman: think one of the pieces that reminds me of is the notion that when we're designing our process, we're setting out to solve a problem and our problem isn't that we're not doing agile. It's not that we're not doing scrum and we need to start doing scrum.We're trying to provide value to a customer on a frequent and consistent basis such that they can respond to feedback and make planning decisions. There are times when that desire or attempt to solve that problem will line up pretty closely with what Agile might seem like or Lean. But at the end of the day, it all starts from let's solve a problem and the absence of some predetermined process is not itself a problem.. [00:32:42] Joe Krebs: Yeah. This is, that's wonderful. And then maybe a good word to end the the podcast episode here together. And obviously there is. An opportunity to take a tour with Menlo and see that all in action. So I invite the listeners to go and reach out to you. There's a, there's tons of tours you guys are doing on a yearly basis.Ann Arbor is the place to visit in Michigan. And and then they can see all what we just talked about in action.[00:33:08] Rich Sheridan: And one of our experiments during the pandemic were virtual tours that we continue to this day, even though. The in person tours have resumed. , [00:33:17] Joe Krebs: even cooler. So this could be done just from your couch.Thank you so much. [00:33:22] Dan Roman: Thank you.​

How can we effect change in our tech teams to become more agile? Perhaps you've tried Scrum Agile and found that you're stuck with new vocabulary for the same old problems. If so, you may be ready for Agile Kata! Originating in martial arts, a 'Kata' involves deliberate, repetitive practice to master a form. By practicing business agility with Agile Kata, an organization can build new habits and skills to shift a corporate culture. It certainly worked for Toyota.Today's guest is Joe Krebs, the creator of the Agile Kata certification program, host of the Agile.fm podcast, and founder of Incrementor which specializes in agile training. There couldn't be a more knowledgeable person to speak on the virtues of Agile Kata than Joe! Today's episode is sure to make you consider how you can incorporate the patterns of change management into your tech team and business! It's a fresh, hot topic that we are sure you will enjoy. Please join us."You can see it (Agile Kata) as a pattern of change management towards any kind of agility." ~ Joe KrebsIn This Episode:- What is Agile Kata? - Agile Kata in four steps- How to get from your current condition to your target condition- How to combine Agile Kata with Scrum- How to use Agile Kata instead of Scrum- Agile Kata as a grassroots movement- Where does Agile Kata fit in with OKRs?- How do I know if I need Agile Kata for my tech team? - Do you need an Agile Kata coach for implementation? And more!Connect with Joe Krebs:- Agile Kata Book - https://www.agilekatabook.com/- Agile Kata Certification - https://www.agilekata.pro/Connect with Debbie Madden:- Website - https://www.stride.build/- LinkedIn – https://www.linkedin.com/in/debbiemadden1/- LinkedIn - https://www.linkedin.com/company/stride-consulting/

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 in to another episode here of Agile.FM. Today I have Tilo Schwarz with me, and we will be exploring in the Agile Kata series, which we are in, and Tilo is joining. We're going to explore the topic of Coaching, Kata coaching, to be more specific, before we get started, everybody should know that Tilo is the author of two books, the Toyota Kata Memory Jogger, released in 2018 and recently is in summer 2023, giving wings to her team that was in 2023.And that is a novel about coaching and Kata, welcome to the show, Tilo. [00:00:49] Tilo Schwarz: Joe, it's a pleasure to be here with you again. Awesome. [00:00:52] Joe Krebs: Awesome. Yeah. We want to talk and emphasize and focus a little bit on, on coaching and Kata in this episode, the other elements of the Kata series here on my podcast, they go into different kinds of corners, but for everybody listening today is all about coaching.All about Kata and coaching. So my first question is really there are two Kata. If somebody is reading about Toyota Kata, that's the improvement and coaching Kata. Can you do improvement without a coach and without a coaching kata? [00:01:25] Tilo Schwarz: Good question, Joe. Sure you can. I mean, many of us probably do, like at least once in a while, I mean, you know, something annoys you like your cable on your desk when you're moving the mouse.And so we push the cable out of the way fix it with some sticky tape to hold in place. And of course, also you could hire an expert, you know, like consultant coming in to implement some improvements for you for both. You don't need a coach. You know? I mean, the issue here of course is that these kind of improvements starting with bumping into some waste.And not necessarily return relevant improvement, right? I mean, for the investment, we're making time, ingenuity, budget, and so on. So basically that's why maybe waste walks, 5S audits, postmortems, that kind of thing might not be such a good starting point for improvement because the improvement just tends to be for improvement's sake, you know, where we bring up some ideas, they turn into long task lists and then array of projects.And at the end it might be very arbitrary and effects are random, right? So in a way you could say, back to your question, I mean, before coaching improvement should start with setting goals, right? So where are we what is it we want to achieve? Yeah but the cutter, they are separated from each other, right?So we can do improvement without the coaching cutter and that would be something a lot of people experience, let's say at the beginning of a year when they have their New Year's resolution. So I'm just going to work on this by myself. The track record is very known. for that. So why do we need coaching to get improvement?So building on that now, so imagining that we have set, you know, what do you say your new year's resolutions or in a business context striving for a challenging goal. Now at some point. And we'll enter the unknown zone. So I mean, that's the point where we've kind of, you know, all the quick wins, all the low hanging fruits done.Yeah. But we've done everything we had in mind the kind of the ideas we had up our sleeve but actually our desired condition is still way out. Time's ticking. So we're kind of running low on chips, as they say in poker. So not only will this happen inevitably over time in a business context, I even think we should look for that.So we should make sure we run out of solutions. Because you know, competitiveness comes from solving things that others haven't solved yet or solving them in a completely different way. Right. So now while you might still wonder, why do we need coaching? Now reaching that threshold of knowledge is kind of create stress.Okay. So we're out of solutions. We're out of chips. And that's when our biases kick in. So first and foremost if you're, I guess you're familiar with thinking fast and slow we start making assumptions based on our experience. So we reach for what has worked in the past, and it's quite likely that we ignore that circumstances might have changed or we conclude.It's impossible, right? So now besides these biases there's also some in a business context, there's often some group dynamics at play. So when we run out of solutions and you can imagine your team starting to discuss if the group has similar experiences, made similar experiences something like groupthink might kick in and we're even more convinced that this is the way to go.Or if, you know, everybody has different opinions this might get a heated discussion and then in the end, you know, it's all about opinion. We're actually not discussing facts anymore. And then the most senior person or whoever's most convincing wins. So that is kind of. is at stake? What's happening?We will run out of solutions and then biases, noise, group dynamics will kick in. Hope is not lost. Changing that is not as difficult as we might think because there's actually a powerful countermeasure available and that is practice of scientific thinking skills. So scientific thinking is a meta skill.And it helps us counter these effects. And that is actually the purpose of Toyota Kata, develop the meta skill of scientific thinking as a group and ultimately make it part of our culture. So the way we do things on a side note, that's actually the second meaning of the suffix Kata, a way of doing things now.So when we talk about all this, I think it's becoming clear, this is about habit change. This is about changing thinking patterns. Now our brain has this natural tendency to follow existing paths. So a new path. So whenever you try something new, we'll, by default. Be uncomfortable or make you feel uncomfortable.And it also will suck a lot of energy. And that is why we need a coach. So basically we need a coach to help us stay on track until this new neural pathway is strong enough and becomes a habit. And I mean, then you could say but then coaching ends. It doesn't end because in sports. a pro always has a coach, right?So to take the game to the next level. And that is why having managers as a coach is so important. Because a habit needs a trigger and you want to take it to the next level. So basically this is all about develop scientific thinking skills. Make them a habit and then trigger them, trigger their use on a daily basis on all levels.[00:07:26] Joe Krebs: Tilo, this is it sounds interesting. You just mentioned in the intro you were talking a little bit about experts in this. What you just described, it might sound for somebody out there like a severe undertaking, right? Why don't just hire an expert for that improvement we need? [00:07:43] Tilo Schwarz: Sure. I mean, that certainly could be an option in, in, in some situations.Now what I like to kind of remind myself of is hiring an expert is outsourcing, right? So we're outsourcing the knowledge work. And then besides that, an expert. I mean, we're all experts on a certain topic. You are, I am an expert is an expert because of the experience the expert has made with solving similar problems.So now If there's more and more new problems to be solved in the world there will be less and less experts, right? Or in other words in, in a changing world, volatile conditions, learning, speed of learning beats having experience and knowledge. And that's why we talk about the learning organization a lot.Now, a learning organization has the ability to evolve the business, to improve the products, develop new products, improve the processes, and do that over and over. So developing that kind of organization, a system, an organism, you could say, that evolves itself, if that is our goal, then, I mean, we cannot hire experts from the outside, right?So we have to develop this ability within the organization. And I think that is, that's very crucial. [00:09:10] Joe Krebs: So we already touched on that there are two Kata, the improvement and the coaching Kata. Early on we talked a little bit about the improvement Kata, but what makes the coaching Kata approach so special or so different in this context, if we're just isolating and focusing on that.[00:09:27] Tilo Schwarz: Yeah. So for me, it's the dual purpose. So there's different coaching approaches. And the idea of coaching in a business context is of course not completely new. So just to be clear here this is not about you know, being right or wrong or, you know, coaching is the only approach and no, this is not the point.Coaching is situational. And it's all about what is your purpose for using a coaching approach in this situation that is at hand. So it's about what is it we want to achieve? Now the first purpose of coaching, and I think that is true for any kind of coaching approach is helping an individual or a team to reach a specific goal or solve a problem.So I mean, if you think of business coaching, personal coaching, sports coaching even marriage counseling, right? It's always about reach a goal, solve a problem. So of course this purpose the coaching kata has that purpose too help the person you coach achieve a goal, remove an obstacle.Now, in addition, and that's that dual purpose thing. In addition, the coaching kata has a second purpose. And that is what, in my opinion, makes it very unique. Because the second purpose is that while we work towards reaching a specific goal. In addition, we want to become better or make the person that we coach better at a meta skill.So becoming better at scientific thinking. So to make that maybe I'll try an example. So maybe it's best compared to a sports coach where you say, so the sports coach is coaching a to win this specific game. And at the same time, learn how to play the game even better. So that is what for me makes the coaching kind of special.This dual purpose.. [00:11:30] Joe Krebs: This is awesome. We just touched a little bit on the coach itself, on the role of the coach. And the and the coaching Kata and the improvement Kata, but let's go back to that coach for a second, that individual what are the skills and characteristics you will be looking at by looking at what what's that coach in terms of characteristics and skills, responsibilities.[00:11:50] Tilo Schwarz: I'm a bit hesitant with the question here, you know, because this sounds like a checklist. It's kind of, you know, what criteria do I need to fulfill to be a coach? And I sometimes feel at least around coaching Kata, we've, we think too much of the coach being a job or a title. Connected with a certificate maybe?So a sports coach, that's a distinct job, okay? Or a personal coach, that's a job too. A systemic coach, that's the title. You have to earn it and then you get a certificate. That's why there maybe is a list of skills and you need to learn them. And then if you match them, you get the certificate, right?Now, as far as the coaching Kata of is concerned the coach is maybe more a momentary role, a role you take in a conversation, like, you know, when we talk about my project, you're coaching me. So you're the coach. When we're talking about your project. I might be coaching you, so then I'm the coach, right?So now let's take that in a business context where we're talking about managers should be coaching, managers as coaches. Rather than making this list of criteria, I prefer to talk about why should we be coaching? And then if we say like, okay so this is why then, Hey, how can we learn this?Yeah. And I don't know if we have time but just digging into that a little bit. So why should we be coaching? I think first adding an increasing amount of coaching to our daily management work might be the only option, viable option forward. I mean, given the unpredictability we have.Right. Because telling people what to do basically requires to have the answer, which is probably more and more unlikely to happen even inhumane to expect that from managers. You always have to have the answer. Then again, only setting targets defining projects and then say, okay, get out.I'll get out of the way. You figure it out. Might not work either. Because our team doesn't have the answer, or at least it raises the question if this is kind of manager's task, set the target, then get out of the way, what do we need managers for in the future? I mean, JetGPT can probably produce a, you know, scan our strategic target list analyze the running projects for impediments, and then create a list.That's what to work on today. So basically in a way you could say why do we need more coaching? Because I believe we'll be more and more operating in that area where neither we as the manager nor our team has the answer. And then we need to start coaching. How can we help our team to find the answer?Another reason, I mean, we're talking about people development. And and that's kind of a second aspect. So helping people to reach their potential, I think that is one of our main tasks in a leadership role. And I mean, I see it this way, very personally. I mean, when I watch this over, everything is said, everything's done, you look back on your life, you don't want to end up, you know, kind of thinking of people you've been working with, you've worked with, you've lived with and go like.Oh, they didn't reach their full potential because of me. And not just because I didn't help them because maybe I even was in their way. You don't want that. Right. If we, the need for coaching, I think is growing and I think it's also that what makes the role of good leadership. So if we want to learn this and that maybe gets closer to your question of a skill list.I'll go high level here. So number one, I think coaching, learning to coach starts with a posture, the underlying mindset we have. And basically it's like this. It's not about you. It's about the people developing the people you're responsible for. It's not about you putting in your ideas and solutions.And then. And if that is you then you can start your learning journey. And I think that's the second aspect, understanding that becoming a better coach is a learning journey because coaching is a skill. There's no hack. It's not like you can read a book, you can sit in the classroom and that's knowledge.That's not skill. And that is really what I love about the coaching kata. Right from the start, I realized, Hey the coaching kata provides a set of questions. I can get started with, and it's not 100 questions. It's a set of questions. It's structured in five phases. And I felt like back when I was a plant manager yeah, I stand a chance.I can do that. I can do that even in the whirlwind of my daily management. Yeah. Okay. Start with the posture is not about you and coaching is a learning journey. Right. And I think that, that's a good starting point. [00:17:08] Joe Krebs: Very good starting point and thanks for clarifying a little bit.It's not so much of a list or something like that, or of skills. It's more like a. The thing, and as you said, in sports, sometimes ex athletes who are trying to become coaches are not good coaches. It turns out that they're departing from that profession. So it is a skill that needs to be added on.So just being a good athlete, it's just a good piece, but it's just not the full person. So you just mentioned a little bit, the questions you would be asking there is a coaching cycle where the coach and the coachee is going to meet. And there are some questions that are being asked.What's the purpose of these coaching questions in an, in a coaching cycle like this? [00:17:53] Tilo Schwarz: As I said first the questions of the coaching kata provide a starting point for practicing, for getting our practice started. And then over time, of course, it's not about, you know, talking like a robot forever.So over time, as our coaching skills develop our brain will turn these questions into question phases. Like a five phase coaching model. And then using this five phase model intuitively like a scaffold is what enables us to coach in actually nearly any kind of situation, like in a one on one, in a meeting, and even when there's just pressure, yeah.And once we have this underlying model as a scaffold in our mind for, You know, running our conversations, running our meetings, it really releases this pressure of having to have all the answers. And at the same time, it's not just saying, okay, you do it. It's, it also provides a way, you know, we can have our team to move forward.So when that is when kind of the coaching kind of questions show their second purpose, because you asked about purpose or what do they do they become you could say like a measurement instrument. So here's what I mean. So I don't know, Joe have you ever done downhill skiing? Are you a skier?I'm not sure. A[00:19:12] Joe Krebs: little bit downhill. A little bit. Okay. Okay. [00:19:14] Tilo Schwarz: That's good. Okay. So let's quickly run this mental experiment, or not experiment, just this, you can imagine so you can ski and now you want to up your game. So for the weekend, you take a ski instructor. Now, when you meet and after saying, hi what is.What's the first thing this ski instructor is going to, what she's going to do? [00:19:37] Joe Krebs: Probably assessing my, State.[00:19:38] Tilo Schwarz: Current condition. Yes, exactly. And so basically developing skills starts with assessing current condition. So how does she do that? She tells you, Hey, Joe, go down this part of the slope, right?And then, exactly. So she wants to see you, she wants to see you ski, yeah. And that helps her to understand. where you're at. And then she can take it from there. Okay. So developing skills starts with understanding current condition. Where's the person at? And that is what the questions do.Okay. So when you ask the question, the coaching Kata question, one of them, they are like a measurement instrument. So it's not so much about the question. It's about listening to the answer. And then this answer will give you a glimpse in how the other person is thinking. So I'll make an example. So imagine you ask a question from phase three, like, which one obstacle or impediment are you addressing now?And then your counterpart says we have to update the software on the controller. So you probably right away hear, this is not an obstacle, it's a countermeasure. Update software on controller. So mentally you realize your counterpart is already moving towards taking action. Now depending on the situation, that might be okay.But imagine maybe the past three days, we've been throwing all kinds of things, you know, action at some arbitrary attempts to get this solved. Then maybe you don't want to move with that and say wait. So a good follow up question might be, so what obstacle or impediment are you addressing by updating the software?So in a way, this coaching kata question you started with, which one helps you addressing, and then listening to the answer helps you understand where the person's at. That's like the ski coach saying, Hey, Joe, go down the slope here. Yeah. Right. So basically the, back to your question, coaching kata questions at the beginning, they provide a starting point.Then they turn into this five phase model, a scaffold, and the questions themselves become your measurement instrument. [00:21:53] Joe Krebs: Right. Cool. So when I got exposed to Kata and several years ago one thing that really, you know, brought me, I guess something extremely powerful was the concept of a second coach. And this is really a cool concept because there is not only one coach, there is a possibly a second coach that is part of that, that coaching cycle.What's the power of that? You want to explore this a little bit together. [00:22:19] Tilo Schwarz: Yeah, so let's talk about why is it helpful to have a second coach? We said coaching is a skill and develops through practice. In the longer run, we want to add coaching to our leadership portfolio. And.You know, this is not a knowledge problem. I mean, managers, no, I can tell you from my own experience as a manager we know we should be coaching. We've read books. We've had some two day coaching training or whatever, a course. Yeah. We know the issue is any given day, somebody steps into your office and says, we have a problem.And you have like 21, 22, 23. to make a decision, right? Do you tell? Do you delegate? Do you coach? Okay. So that's the issue. It's like in the moment, in the heat. Yeah. Pull the coaching card. And skill development of course is best done with a coach, right? Because we can't observe ourselves. And that is where this power of this having a second coach comes in, helping me.If coaching is a learning journey, helping me to move forward on this learning journey. [00:23:36] Joe Krebs: Yeah, this is really cool. As we said in the beginning, you are the author of Giving Wings to Her Team, a novel you wrote together with Dr. Jeffrey Liker. And There is a character called Denise in your book and I just want to bring listeners to the book.Obviously, there's an awareness that there is a book, it's a novel, and there's some form of Kata, obviously, and coaching involved. Can you name one struggle from Denise, which is one of the characters in the book that is very common when somebody is starting with [00:24:08] Tilo Schwarz: Sure. Sure. Just a bit of context here for your listeners.So Denise is the main character. She's a young manager, has taken her first managerial role has a background as a consultant and because yeah she just wants to lead her team in a, you know, timely manner a modern way of working together. So she has this aspiration of coaching her team and she runs some experiments.And because of her background as a consultant and having some coaching training, she said, okay, I can do this. Okay. So I'll just read a part from the book if that's okay. So Wednesday, February 2nd, 6. 35 PM. What a long day at work. Denise parked hercar at the fitness studio, grabbed her duffel bag and made her way to the changing room. She had met with Joan Mark, her team leaders, twice today to discuss the target conditions they were working on this week. It seemed that after an initial burst of energy early in the week, Denise had tried to coach them using approaches she had learned during a training program at the consultancy she worked for.What are you trying to achieve? Getting that damn quality issue solved, Joe had said in frustration at one point. What options do you have? Was another question Denise had lobbed at him. At first, Joe and Mark had come up with suggestions. Denise had encouraged them to try them out right away.Unfortunately, they did not work. They were further disillusioned. What other options can you think of? was the question Denise had tried next. Mark had just stared at her. Nothing, he said. I've tried everything. It's just impossible. Oh no, back to where we started, Denise had thought. She had tried to encourage them and also awaken their ambitions by asking, So how would it feel to be successful?How would it feel? Mark had replied. I'd say relieved, because then we could stop these stupid interviews. Then she had tried yet another approach. What is the real challenge here for you? The real challenge is that I don't know how to solve the quality issue. Joe had snapped back at her. So what options do you see?Denise had asked him. I don't know, Joe had said. I've tried everything. It just doesn't work. Okay, what else could we do? I don't know, Joe had replied, even more annoyed than before. These interrogations you call coaching are driving me crazy. Please just tell me what you want me to do. Denise had been just as frustrated as Joe.This had been exactly where she didn't want to go, but she knew she was running out of alternatives and had started making suggestions. Joe and Mark quickly shot each idea down. That doesn't work. We tried that. That doesn't work either. I need to talk to Maggie, desperately, Denise thought as she grabbed her towel and left the changing room.She entered the gym hall, walked over to the stationary bicycles, looking around for Maggie, but Denise couldn't see her anywhere. She started her workout. So Maggie is her second coach. That's the person she's looking for. And yeah, this is not a few, this is another Joe, by the way, Joe, just for clarity.[00:27:58] Joe Krebs: I know why you picked this example. [00:27:59] Tilo Schwarz: So let's kind of, Think about that passage for a second. So what we see happening here is a very common struggle for coaches or when we try to coach. Happened to me too, yeah. Basically checking in and asking a few questions is not coaching, right?Because this is unlikely to help the other person when they're stuck. So we're having a situation here where the team is stuck. And then a second struggle is because then when Denise realized we're getting nowhere, she started to enter in her ideas. So that's kind of a second thing that is a big issue when coaching.So sometimes people ask me what do you mean I should stay away from my own ideas? But then, I mean, how can I coach if I don't have knowledge and understanding about the topic? I often say, if you don't have a deep knowledge about the process or topic you're coaching on that might actually be helpful because if you have you're probably going to be sucked in by your own ideas.And at some point you're going to start to, yeah. What do you think about this? Have you thought about this? Yeah. This is not coaching. I mean, this is consulting, counseling, sparing solving problems together. So then people ask, so how can I coach them without? You know, without, if I don't have knowledge, how can I coach?Basically we can by coaching on the how, on the meta level of how people approach things and help them do it in a scientific way. And that's kind of this, the secret power of the coaching kata, you could say. So it helps the coach to move to this meta level. And then instead of, you know, talking about the topic, coach people on how they work towards the target, help them to do it in a scientific way and not challenge what they do to reach their target and compare it with our own ideas. So these are two common struggles if you ask that. So it's like, Hey, coaching isn't just asking any kind of questions. And if you start entering your own ideas. It's like, Hey, how can I coach my team? So they come up with the idea I had in mind, right? This is not coaching. [00:30:16] Joe Krebs: Okay. Yes. I think that's an important differentiation on what is coaching or not thanks for that.Tilo, now somebody might be listening to this and this sounds all very interesting. I would like to try this but my organization does not have a culture of scientific thinking nor does it have coaching culture. How do they get started? And most importantly, let's just say, like, it's a slightly bigger or large organization.How do they scale that across an organization, that kind of thinking combined with coaching if they don't have that experience and that expertise, how do they get started?[00:30:52] Tilo Schwarz: So first let's look at the arrival point. What is it we need to achieve? So finally, or ultimately two things have to come together. And that is good coaching skill on all levels of the organization combined with working on important goals. I mean, we're coaching for developing people so they can reach challenging goals, which means having managers with good coaching skills on all levels of the organization is the bottleneck.That's the big hairy thing to be addressed. So how can we get started towards that? So step one, start small. This is not like you don't start with a program two day training for all managers hand out the question card. Please don't do this. So it's start with building a first group of good coaches because this gives you.gives you, you know, a, like, like a crystal, you know, a crystal starts with a seed. So this is about building the seed. It also is provides you with a proof of concept. So start small, build a first group of good coaches. Now, how do you do that? These coaches need to get an intuitive feeling of a scientific way of working.I mean, rationally, this is totally clear. But in the moment when you hear the answer, just like the ski coach, when you go down the hill, now your ski instructor needs to have a picture in mind. And if you do a left turn, she will compare what she sees you doing with the picture. If she hadn't had that picture she couldn't be your ski instructor, right?So this is what I call a coach's reference. So before we can coach, we need to build this reference or this kind of goes together. No reference, no coaching because you can ask the questions, but any answer goes, right? What's a good answer? What's a bad answer? So these coaches need to build this intuitive feeling of a scientific way of working.Otherwise they won't be able to coach for scientific thinking in their teams. Otherwise, they would be asking the questions, but would not focus on the meta level. They will probably use their content, their technical knowledge, and try to coach people towards what they have in mind. So you could say wannabe coaches should have a coach first.So how do you do it? Find a good coach. And what I mean here is not just any kind of coach, but someone that has particular experience in practicing coaching kata. Right. At the beginning, this person is likely coming from the outside and that's okay. And it just kept, I mean, by the way, this is a huge upside of Toyota Kata because over the last 10 plus years really a global base of practitioners has developed like grassroots.Yeah. There's likely going to be somebody in your region, so find someone in your region who can help you get started. Then of course, also the Kata Coaching Dojo is an accelerator for learning to coach. You, it's, you could think of it like a flight simulator, what a flight simulator does for pilots the Kata Coaching Dojo does for coaches.So offering frequent coaching practice in a safe space. And then once you got that first, the seed, this first group of internal coaches. Start growing the crystal, yeah. So link coaching, so develop more coaches step by step, because now you have these coaches and they can coach the next, you know, group and exactly.And then at that point, it's very important to think about this second aspect. So that is link coaching to working on strategic goals. So coaching people as part of their daily work, working towards relevant, meaningful goals. And once you're at that stage basically there's another good book actually at that stage, it's called Toyota Kata Culture that describes that kind of, you know, from the seed to the crystal, how do you do it?And, Combining good coaching with working towards strategic targets on all levels, that is when the power unfolds exponentially. Okay. So now the rocket is off the launching pad. Yeah. Because really what we see happen is people can outperform the expected through practicing scientific thinking.and with the help of a coach. And I firmly believe, and that is why Jeff and I wrote this book. It's like this book describes this journey for the individual, the coach, as well as for the organization. So from the starting point to the seed, to growing the crystal and combining it with working on strategic goals.You know, and we firmly believe you and the listeners, yeah your team can do it too. They need you as a coach and the coaching cata can help you become that kind of coach, the coach you always wanted to be and the coach your team needs you to be. Right. And that is why our book has this title, Giving Wings, yeah?So just like Denise is giving wings to her team, you can give wings to your team. [00:36:09] Joe Krebs: And Tilo, I could not even think of better words to end this podcast episode here with you. Giving wings to our teams. Thank you for coming on, talking about coaching, Kata coaching in particular with the with the listeners here in the Agile Kata series on Agile FM.Thank you so much. [00:36:28] Tilo Schwarz: Joe, thank you. It's been 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

Download our Leading from the front template below: https://enterpriseexcellenceacademy.com/downloads#leadSummary Keywordsleaders, people, mate, part, team, years, work, place, talk, person, good, productivity, shadow, learn, lead, 1000s, safety.Introduction Welcome to episode 157 of the Enterprise Excellence Podcast. It is a pleasure to have Mr. Rob Telford on the show with us today. I came across the work Rob did culturally within BHP on one of my BHP Operating Systems Assessments of their Yandi site. I was amazed to find a site that lived many behaviours that were not even visually shown on walls or documented; they were just part of the language for the site. I saw work areas with the most amazing cleanliness and orderliness without markings or visual 5S-style structures. I met people passionate about safety, having each other's backs and looking out for their mates without being through extensive training and coaching programs. Rob led out the original vision and plan for safety and productivity at BHP, which became what is now known as the BHP Operating Systems. I am so excited about this conversation with Rob today as he played a large part, including others, in achieving what I saw and was amazed by. We are proudly sponsored by S A Partners, a world-leading business transformation consultancy.Episode Links:Youtube Full episode: https://youtu.be/SLnEapIeTdsEnterprise Excellence Academy https://www.enterpriseexcellenceacademy.com/podcast/episode/7d09ee51/157-how-to-achieve-cultural-change-through-leadership-behaviour-with-mr-rob-telford-of-bhpContacts Brad: connect via LinkedIn or call him on 0402 448 445 or email bjeavons@iqi.com.au. Rob Telford - LinkedIn - https://www.linkedin.com/in/rob-telford-0672521a9?lipi=urn%3Ali%3Apage%3Ad_flagship3_profile_view_base_contact_details%3Bqt6chDT0RAWiFipBXFks1A%3D%3DWhat's next?Join our next community! https://www.enterpriseexcellenceacademy.com/communityListen to another podcast episode with Joe Krebs on Agile Kata.a)     listen on our website - https://www.enterpriseexcellenceacademy.com/podcast/episode/7ef0eeef/117-joe-krebs-agile-katab)     Watch on YouTube - https://youtu.be/CgW3S_sb530?si=tKuBXfLlHq-1WWO5. To learn more about what we do, visit www.enterpriseexcellenceacademy.com.Thanks for your time, and thanks for helping to create a better future.

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

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

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

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

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

Transcript: Joe Krebs 0:20 Today I'm here with Staffan Noeteberg, who is the author of two books that is mono tasking that was released in 2020. And a little bit earlier, Pomodoro technique illustrated, I believe it was in 2011 that was forwarded by the one of the creators of the Pomodoro Technique, Francesco Cirillo and Henrik Kniberg. So what we have here with Staffan is a person that is very well connected with the Agile community as well as it is super interesting topic of mono tasking, what we want to talk about today, he's an Agile coach. He lives in Stockholm, Sweden, as well as in Istanbul, Turkey. If I'm informed here correctly, he has trained 1000s of people on improving their personal productivity. He has sold over 700,000 copies of his book. I'm super thrilled to have you on the podcast. Thank you for being here.Staffan Nöteberg 1:22 Thank you for having me. Joe Krebs 1:23 Yeah, this is this is awesome. We want to talk today really about mono tasking, that is that is obviously your latest book. And we want to connect a few dots because this could be super interesting for everybody listening to this podcast today from two angles. One of them is individually improving productivity as a as a person you know, in everyday life situations as well as professionally at work. But also how we can connect mono tasking maybe to agile teams and agile roles, maybe we can touch on that as well. So I think these are the two angles we want to explore here a little bit today. Mono as part of that title, if I go back in times and I'm like just thinking about audio mono was something that I would now relate with something negative right mono is like it's simple and and everything we're like all thinking about stereo at this point Dolby Stereo. Using mono in terms of tasking is something for the future. What is mono tasking, Staffan? Joe Krebs 2:30 It is interested that you mentioned that mono mono is something negative, because I think that the in job ads maybe 10 years ago, 20 years ago, there were often the demand for people that were they were looking for property property that said you you can juggle many balls at the same time, that's where our, that's what we're looking for. And nowadays, maybe they say you should be able to finish something to complete something. And that's and in order to do that maybe you shouldn't stop so many things and all these Kanban things that has been popular now for 20 years in software industry is very much about this stop starting and start finishing. So weekly meats and things like that, but I mean the mono tasking method then came out I wrote this Pomodoro technique book which is a personal productivity method. It's a particular concern about focusing on focusing. So, how do you really focus but I wanted to see this broader and I read many many personal productivity books and I think most of them almost everyone or almost none of them consider complexity and cohesion. I will explain what I mean by cohesion they like these books are often create order these books this these methods these processes are often made by engineers people like like you and me programmers or software engineers and the idea in them is often to like keep a list or multiple lists of in like in shipshape and Bristol fashion, you say ship ship in Bristol fashion in the US, or is that a British idiom?Joe Krebs 3:36 Which one is that?Staffan Nöteberg 4:28 Ship shape and Bristol fashion is one of my favorite idioms. We are doing everything under control and everything. We need to add the unit at the link in the show notes. Joe Krebs 4:51 We will definitely be in the data link for that. Yes.Staffan Nöteberg 4:53 Yeah. So so the idea of most personal productivity method is to have a lot of lists and they should be be perfect all the time. And they should contain a lot of ideas, everything that you you plan to do and why you're doing it. And so, and then there's the processes are often kind of, if else logic. So, if this happened to that, if that happened if this, but they are, I mean, that may work for you and me and other engineers, but for most people, it demands too much discipline. And it doesn't really accept that there are humans that are willing to use these methods, I wanted to create something that is more creative and more suitable for humans. So it's not like you're a silo, and you are fed from the top with the new tasks, and you work on them, and you complete them and just throw them out. Because there is some cohesion, you have your co-workers and, your teammates, and you have your stakeholders, your your product managers, you have your customers, and all these people, they change the mind, sometimes sometimes they say they want something. But they changed, they changed the mind, or they didn't explain it in a way that you understood, really started to do something else. So it's not really only about taking it as completing it. And doing that as fast as possible. And with the highest quality. It's more like you're putting in a big ecosystem. And you need to manage within that ecosystem. And I think that in that way, if you think of personal productivity in that way, it can be hard to have, like saying that you should do exactly like this, and exact like that maybe we should think more in arranging your environment and your circumstances, to have the best the best possibilities to succeed. So I started to read a lot of books and papers about what science says about human cognition, and evolutionary psychology and so on, I tried to create a method, which is little bit different from other methods that like embraces the human intuition and the human cognition and human heuristics, so that you don't have to maintain your there, you don't have to maintain all this list and doing all this documentation, and instead can use your intuition and in most cases, do the correct choices anyway, because we as humans are very good in this complexity, if we use our intuition to see what is most important than what what is not most important.Joe Krebs 7:52 Right? So it's interesting, right? So first and foremost, I'm thrilled to hear that I'm not the only one who experiences stakeholders changing their minds on things. So I'm kidding. Obviously, I think this is a, this is a huge problem in our, in our, you know, work in general, I think that's typical. But it's also fascinating what I've heard, I don't know if you would second that is that humans are pretty much incapable of multitasking. Right? So it's some basic things we can do. We can walk and talk at the same time, or I don't think that's going to cause a conflict. But we cannot work on two different kinds of systems at the same time, that causes a conflict, obviously. And that's where we're transitioning. So you're saying already with mono tasking, you're saying like, work with a reduced list of task, right? I believe you were mentioning something about like five shortlist or something like that, or like five items, or five tasks or something. And why is that? Why is why is the list? Short? We're not saying we're working on five items at the same time, right? We're just saying there's a list of five items. Where, Why? Why the number five? And why is it so short? Or why does the list exists? What What's your reasoning behind it? I'm just curious.Staffan Nöteberg 9:12 So you're right about multitasking that most people we cannot multitask if you don't have to pay attention to things like breathing and work at same time. But most people can't pay attention to more than one thing. And when we think that we are doing that, like we're listening to lecture and we're taking notes, were actually task switching. So we're switching back and forth. And when we're task switching, we make more errors, science shows and researchers and we're slower and we forget about good ideas. And in general, it's not the best way to complete things from what we learned in Lean, for example, when we're doing many things and so one one idea here in the book is our in this method is the shortlist as you mentioned, and the shortlist is like, in the morning, from the top of your head, write down five things on a paper on the piece of paper, instead of looking at your, you know, in, in my trainings, I am an exercise where we're asked people to, to, to write down every source of tasks that they have. And they think less about them and say, I have some things in my brain, I have something in my email inbox, I have some things in Trello. And I have some things in JIRA, I have some things on my refrigerator, and I have some post it's on my display. And there's a lot of sources of all these tasks. And then the next step is to look at all these and say, roughly how many tasks do I have in each of these. And usually, it aggregates to something between 80 and 200. So like, if you have 200 tasks there, if you have 100 tasks, it's impossible to make a prioritization to choose the best one because you can think about 100 tasks at the same time and see which one of these is most important right now. So instead, when you start morning, write down maximum five tasks on a piece of paper in front of you. Maximum five, and these are small tasks, so they should estimate them. If you estimate roughly you don't have to write down, it should not be things that takes more than two hours or something like that should be things that the tasks that take 10 minutes, two hours, some something in this, if they're bigger than YouTube, break something out and put them on on your list. And this is not the plan. It's not a competition or some kind of gamification, so that this is the sort of fight that I'm doing to complete today. It's more like moving away the tension of of gamification, instead of saying, These are my five candidates for my next, the one I'm going to pay attention to next, right, and then you don't have to think about anything else, all the other 100 tasks that you have promised someone or that you have thought about that you pressed you do. So because you have in front of you only these five, five is not magic, of course, but five is, is a number that usually we can look at five things and maybe compare them together. If it comes to 6, 7, 8, 9, then we have to make to look at some of them. So maybe you should have have have less than five, but not not more than five, I believe for most people. Yeah. And then then you pick one of these and say, I'm going to focus on this one. And you set an alarm, maybe to the next hour or something like that, to remind you to not stay too long, because maybe when you have worked with at one after an hour, you need to take a break or maybe you should reprioritize because he didn't believe that this was this was going to take this long time that that it took so you need some alarm to wake you up and then use your stop focus on on that that single task. And during the day if if something comes up, you get a new idea, either either you should write it down and put it somewhere else. Or you need to trade away something from your shortlist. You should never have more than five things on your on your shortlist. And this this many people try this and say it works for some people doesn't work but you need to you need to try yourself and be you know you we are different. So it might not be suitable for everyone.Joe Krebs 14:04 But I think you just answered my next question. I just want to clarify because that is the bridge to my next topic about agility here is so that the list is maximum five, right? Let's say this as a as a number here to work with, right? What would happen if like that stakeholder out there changes his mind and there would be a sixth item or a seventh item, because there is the risk that the list is going to grow. So you're saying like keep it at five, right? Something has to go from there. Yep. Just to keep it manageable,Staffan Nöteberg 14:35 maximum five, maybe have completed something so you'll have four three. Okay. And of course, these numbers are heuristics. You can use any number but it's good to put the limit and see how much but five is a good starting number. According to me at least.Joe Krebs 14:54 Yeah, there is also in your book. I don't I don't know the from the top of my head. Add, I don't know the exact details here right now. But you also have some advice on the time-boxing, right? How much time would be dedicated to these tasks. So let's say you're starting a task, let's say at 10.25am. In the morning, that timer would be set to 11 o'clock or something like that, right? So there's some some concrete advice at your book. But the time box is relatively manageable and short too right?. So it's short working increments before you take a break. Staffan Nöteberg 15:24 Yeah, a break or reprioritize, you looked at your shortlist again, and see, should I continue with this one? Or do that? One, do something else, maybe because I completed that one, or maybe something else became more prioritized. But you trust during that period that time box, your trust, your prioritization, I think that you shouldn't you distinguish between focusing and prioritizing. So when you have decided to focus, then you need to explore it. That and oh, and trust that you have chosen the right one, if something else comes up, write it down or, or something like that, but don't change your business idea. Every few minutes, just because something comes up.Joe Krebs 16:15 Yeah. Interesting. So so what I what I would like to touch on is and I think that is to connect with you have with the Pomodoro Technique, right, where it's also a time or is involved in time intervals. So time boxing, just in the Agile world, in general is a is a is a good strategy. Now, I do know that let's say in Scrum, the product backlog is not necessarily a list of tasks, why but it's just to see a container of things to be to be worked on eventually, but also the sprint backlog has has items in it. Let's say a product backlog very often has more than five items in it. How would you idea like map to like some some agile teams, you know missing? Some of those mono tasking techniques could be applied to a personal level? Is there anything we can do as a team is anything as an Agile team could do like a scrum team or a kanban team or somewhere that says like, we're gonna start introducing and mono tasking techniques to make us more productive, effective as a team. But also help us with the prioritization ordering effort as well, as you know, just like staying focus is is there any connect between those techniques?Staffan Nöteberg 17:33 I think so one thing is, of course, you can learn from my monitor skin that and then scale it to the team level and think what would that mean to do the same thing on the team level. But another thing is that what I talked about cohesion, so the team members are part of the same ecosystem as you are. And if you're a team, then you probably have a shared goal, you have the same goal. Otherwise, you're more like a group of people that have the same manager or something like that. But if your team you have the same goal, so So what what you're looking for, is to succeed with the school together. And if you're all skilled in this method, the monitors method, which which is a lot a lot of thing about how to progress and how to cooperate and how to treat stakeholders and recharging and so. But if you're all successful, I think you also responsible since you have a shared goal, to support each other, to help each other to be better at Mono tasking or whatever personal productivity method you're using. So you, as I said, we want to arrange an environment and circumstances so that we can be productive as individuals. But that also, since we have a shared do need that we need to create circumstances environment for teammates, so that they can be successful, then there are, of course, mob programming and pair programming, and then you're working together. But when we work individually, we need to help each other to work individually in a good way. Also, it's not not only that, I take care of my environment and my circumstances so that I can do mono tasking or Pomodoro, or GTD (Getting Things Done) or something else. It's also the issue to help other people with thatJoe Krebs 19:26 Yeah. So one thing I wanted to clarify and this is this is a great connect between the team and the individual and how this technique applies on different kinds of levels. I think that's great. There's obviously a lot to take away from teams have a very long laundry list of things to do, right? And just feel like they are not getting you know, like their time or they're not using their time necessarily wisely. That's what they're thinking and but they might not know like, what is the what's the missing thing and maybe it is something like that to really focus on on a few things. Now, here's something that I want to clarify this with you? If I read this, right, if I heard thi right, it's fascinating because, you know, way, way back when I was running, I did like cross country kind of running myself, there was always this thing of, if there was a hill, let's say, you would always try to run up the hill. And if you if you had to take a break, you know, for whatever reason, it was right on the top of the hill, not before the top of the hill, because you wanted to make sure it's easier to restart running again. So stopping at the hill was always like seeing something like very hard to restart running again, because you're already in the middle of a hill. But it was always when you're on the top of the hill was very easy for you to run. Now you're mono tasking is like by task. The second is don't finish the task at the end of the day. Because it makes it easier to start and transition into the next day. When I saw that, I was like thinking about that. I was like, that is very interesting. Tell me like how, because it's so opposite to how people think. Right? So it's like finishing a task before they go home. And let's say at the end of the day, and might put these 1015 minutes extra in, and then I would just want to finish my tasks, but you're saying mono tasking says don't finish it all by the end of the day? Because it makes it easier to start in the morning. Can you elaborate a little bit on this? Because I think that's great.Staffan Nöteberg 21:20 Yeah. So there was a researcher 100 years ago in Berlin called Bluma Zeigarnik. I think she came from Russia originally. But she worked in with psychology research in psychology in Berlin. She and her friends went to the coffee shops in Berlin. Every day and sister was psychologist, they had some psychology researchers that had a lot to talk about with each other. And so they stayed there for hours. And they ordered things and they discussed things and then they ordered more and discuss things. And after some hours, they call for the waiter and said, Hey, waiter can can we pay now. And then the waiter always knew exactly how much they had ordered, even though he didn't take any notes. And that was a little bit provocative to a group of psychologists, researchers. So they made an experiment one day. So they they sat there discussing ordering, discussing ordering, and they say hey, can we pay, and the waiter knew exactly how much they had ordered, and they paid. But then they stayed there for another 30 minutes, then the call for the waiter again. And when the waiter came there, they asked him, Hey, how much did we pay 30 minutes ago? And what do you think he answered?Joe Krebs 22:56 He didn't know.Staffan Nöteberg 22:58 He didn't know. He said, I've dropped out How could I know now. So he knew about it, as long as it was like an open Task to remember this. But as soon as, as they had paid it dropped it. So it didn't take in place in in his brain. And this was interesting, but this experiment is not very scientific, because it was only one person's very small sample. But Illuma went back to her office and made an experiment with, like, the first 150 people or something like that. And they got 20 tasks each small things like creating a clay finger or translating something from German, to to French, or, or something. And what it didn't know was a part of this experiment was that in 10, out of these 20, they were interrupted. So blue mark came there and said, Oh, I see you're working with task number six. Yeah, stop that and go on and work with task number seven. And afterwards, when when when they had finished everything. Bluma said like, can you write down now all the 20 tasks that you worked on on paper? And you know, if you have 20 things you have done, you won't remember all of them. So then she counted at the fact was that those that are interrupted in the remember twice as many of these compared to those that they had completed. So things that we haven't finished that we have started but we haven't finished demand room in our brain. But you can see in a positive way that we are still analyzing them and working on them and thinking about them. So if we end the day, usually, if you're commuting, and you think that before I go home, I need to complete this. And then I will take a bus or take my car or something home. But if you think in the other way, and think like, before I leave the office, I need to stop something, and leave in the middle I should have a read test if I'm a software engineer. So you stop something and you leave in the middle, then the next morning, you will be much eager to start with that one. And we knew about procrastination, that the hardest time that whatever we procrastinate, most is in the morning, if we can just stop procrastinating in the morning, then we will continue for the whole day because we have started something. So if instead stop something before we go home, then then we will be very eager to start with on that one. Immediately, when we come to the office usually will not tell this in trainings, someone raises their hand and say like, Hey, I'll try that. And if I do that, I can't sleep for the whole night because I have a problem. Of course, you shouldn't try it, you shouldn't do this. But for many people who are trying this, this is really helpful.Joe Krebs 26:19 Wow, this is this is cool that this is quite interesting that that person had sleep problems by trying this. Why? Because part of mono tasking is also you know, taking care of things like sleep and breaks and, and healthy living. Why? Why is that like part of money? It's an interesting, it's an interesting approach. It's so with all that research and science that goes into something like this. It's also like to do take breaks, and to purposely slow down. I don't know if that's exactly at those time limits of these tasks are describing but also to, to just to sleep, and have a healthy lifestyle that includes nutrition and everything. Why why is that so important? Staffan Nöteberg 27:05 so the method or the book is divided into six different areas where one is called recharge, creative thinking. So these sorts of things, the six things that I suggest that you should think about to be able to mono task, to be able to focus. And one of these students reached out creative thinking says, I mean, I'm not the expert of all the Healthy Living, I'm personally. But what I found, and I think most people agree on this is that if you are going to be the best version of yourself, if you are going to be the best due tomorrow, then you will have a much better probability or higher probability of being that if you have a healthier living, if you sleep the same hours every night, if you eat fruits and vegetables, if your exercise. And if you don't do that, it will be much harder to focus and focus on one thing.Joe Krebs 28:11 Yeah, that is that is also important for agile teams, where I would do very often I'm, you know, working with teams or organizations, but that is not part of the ritual, right? And for a variety of reasons, and sometimes it's just like, you know, what the things are in organizations, but it is an important piece to point out like we're humans, we're part of this, of, let's say, any kind of method and recharging is a key thing, right? How is something like that being incorporated into an into an Agile team, right? On an individual level? I think that's a great idea, and probably easier to do, right? Because it's me influencing my own thing, but how does it work on a team? We're not gonna say you guys go into sleeping chambers during the day and taking breaks or anything like that, but how would that look like on a on a team level?Staffan Nöteberg 29:04 I think first I want to say that it's not that you shouldn't be an Olympic athlete, it's more like, you can always be a bit better than than what you were yesterday. But I think in an Agile team, you know, in extreme programming, there's one of these best practices was first called 40 hours a week, and then it was changed to a sustainable pace. If I remember correctly, it was a long time ago, I read this book. I think it's part of this, it. Ultimately, it's a personal responsibility, of course, but as a team, you can create a culture where it's not cool to stay the whole night to fix some bugs or something like that. You need to have a sustainable base. As Kent Beck pointed out already, and if I think no, this is a credit card, that if you overcharge the credit card, you can buy something right now that you couldn't buy otherwise, but you will have to pay with interest in the long term and that that's the same for teams. I think that if they have a culture where they don't take care of the people in the team, when it comes to breaks, and weekends and other things, then they will have to pay with interest in the long term.Joe Krebs 30:33 Yeah. Yeah, no, definitely I agree. And that was part of Extreme Programming even before Agile Manifesto. So this is deeply, deeply rooted, sustainable pace and having you know, if there was an overtime in a sprint, or iteration that there wouldn't be one in the following. So there was some form of balancing going on your book itself, which is great. I like visuals in a book, right? You drew them yourself. Which is, which is also great to see those notes and supported by visuals. I just like to read books like this, I think it just reinforces but you also say in this mono tasking, it's better for teams to or individuals to write by hand. Notes in journaling, rather than on a laptop.Staffan Nöteberg 31:20 I think depends on what you're going to use use it for. If if writing something that you want to distribute to the that you want to save for a long time, it's much better right in a computer, of course. But if you want want your brain to digest things to analyze it, in, we learn from doing things not from listening, when we listen to something like your podcast, you might get inspired but if we don't do something about it, or think about it or discuss it with someone then we will have forgotten about it one week later. So there are a lot of research showing that if if you write down something in need to like, think and that's especially if if you draw something if you make a mind mapping more or try to try to think of it in in pictures, what does this mean all the diagrams connecting,Joe Krebs 32:25 sketchnoting, for example?Staffan Nöteberg 32:27 Yeah, exactly. Then you learn more it stays in your head because in the brain the memory in the brain is not like a structured database. It's not like SQL, it's more like many many fragments of associations. And when you have new you learn something new and when you hear something new, you need to connect it to some of these fragments and when you think about it more then maybe some door opens in there are some fried fragment comes up some other Association and you can connect your your new learning to that one. And if you have a discussion about something like something you hear in this podcast or something new you learn that you have written down or so then it's more much more likely that you will save it actually and have it connected to some some other Association Yeah. And as I understand it, it's not an issue that or memory is not big enough we can read would be it would be possible to know a lot more than anyone has known so far. And the problem is that we it's not structured in in the heads we need to it's a different thing than the computer database and we need to connect it so we can pick it up when it when it's suitable. Joe Krebs 34:00 Yeah very very interesting stuff and obviously the book is filled with lots of material like this a lot of individuals and teams might find useful applying in their in their day to day work. Did you write your book using mono tasking? Did you use some of those techniques like like you basically just you know took your method in your in your own writing.Staffan Nöteberg 34:24 I did exactly like that. But I'm saying that this doesn't mean that this is the best method for everyone. But I think that if you read something like this, a book like this, then you will learn a lot of things and maybe you can try some some of these and test them and maybe some some will suit you and some will not suit you but you will learn more about your own productivity.Joe Krebs 34:53 Absolutely. I also see coaches Scrum Masters leaders working within organizations increasing agility, he's taking some of the research you have put together in that book, and providing the evidence to really run some experiments within the organization. Right. So there's continuous improvement going on, within organizations, change management. And some of those concept could be, could be applied to any of these efforts and run some experiments on are they showing the same impact as they will do in an individual productivity improvement also on on other levels, so I think it's might give some food for thought for. For some, some employees in organizations listening to the answers, I'd take a piece of that and run an experiment and see how that goes to just like the task switching or preventing task switching, and possibly do take the breaks and things like that we discussed. We're not finishing a task by the end of the day, things we have discussed here in this podcast together and just like try some experiments, but again, the book has many, many more. You also mentioned in your in your book, someone I think there was a little side story, where somebody actually got a promotion probably not only because of that, but somebody got a promotion and one thing was that somebody started listening to podcasts in their transition time going from home to work. And using that transition time effectively somebody listened to podcasts and got a promotion out of it now I cannot guarantee by listening to Agile FM that you will be getting a promotion out of this thing but you might be listening to this in your car right now while driving so please drive safely. But transition time is also part of mono tasking and and to use that wisely could be having really really good benefits. So thank you Staffan for being my guest today and sharing your thoughts great thoughts on mono tasking here with me? But more importantly with all the listeners out there that possibly already or will be becoming interested in mono tasking. Thank you so much, Staffan.Staffan Nöteberg 37:02 Thanks, you it's been a pleasure to talk to you.Joe Krebs 37:06 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:20 Welcome back to another episode of Agile FM, my first recording of 2023. I'm going into my second decade of agile FM. And I'm super, super happy to have Jeff Gothelf back to Agile FM, author doesn't really need an introduction, but he's the author of Lean UX, Sense and Respond and Forever Employable and Lean vs Agile versus Design Thinking. And maybe there is another one in the making, we can talk about. First and foremost, Jeff, welcome to the podcast again. Jeff Gothelf 0:53 It's a pleasure to see you. We were just talking before you hit record how long we've known each other. And it's fun, it's fun to keep chatting all these years and seeing where these conversations go. Because because they do get interesting. Like they don't they don't get stale. And it all evolves, you know, Joe Krebs 1:08 thank you. Yes, and we go all the way back, I mean, to today's we're agile are very, very different. You wrote several books in between. I've been active not only here on the podcast, but also through work. And so our paths constantly cross. And obviously, you always have interesting content to share. Today, we want to talk a little bit about our OKR's. On social media, I see you a lot of responses and material you're releasing on OKR's. And you are obviously very, very interested in this topic. And it's not brand new. So there are some people that are talking about OKRs. What is OKRs? But I did some research on it. It's It's It's old, but obviously it hasn't really taken off at that time. So it really started like, way before, but Google really started introducing OKRs as far as that's my understanding, but even at that time, it wasn't really popularized. What's what's attracted you to OKRs? Jeff Gothelf 2:11 Yeah, super interesting, right? So it's a technique, it's been around for more than 40 years, Andy Grove at Intel. And for him, you know, managing by walking, management by objective, sorry, management by objective was kind of the first name for it. And then Google popularized it. What's interesting to me about it, and it's kind of like the same thing that happened with with sort of Lean and Agile and Lean startup and all these different things is that I think the reason why objectives and key results are having their moment in the sun right now. And everybody's interested, is because the technology that we use to deliver products and services, and build businesses on top of today is continuous. And it allows us to learn continuously, and at the pace of the market. So whereas if you think about, you know, when I started working professionally, in the late 90s, I worked in America Online, you know, it was far from continuous, right? We, it was very much not continuous, we worked for nine months to build software, and then print 15 million CDs, and then send them out, and then wait to see what happens, right? I think OKRs would have failed, because it would take too long to get feedback on whether or not you had a meaningful impact on the people who used your, your product or your service. And so as a goal setting framework, it would have been too bad. But today, you can get feedback instantaneously, if you've got enough of an audience size, and certainly very quickly in in a in the majority of cases. And so this is why this is an interesting topic. For me. Number one, I think this is why it's getting a lot of attention. The interesting thing here is that, in my opinion, and I can explain this in a minute, I think objectives and key results are the gateway to agility. Right? So if we can keep capital A agile out of it for just a second, right? And we talk about the the noun agility. I think that objectives and key results, when done correctly, demand that an organization behaves in an agile way that they increase their agility, we can explain why. But to me, that's why I'm so passionate about it these days, is because for all the organizations that have implemented some version of agile some version of Lean UX for Lean startup or design thinking, and I've struggled with it. I believe that if now if they if they kind of give it another shot and they start with OKR's as their goals, they stand a better chance of succeeding.Joe Krebs 5:02 Goal setting. And I actually like your your comment about the entry point or the the access point for for agility. That aside, I've been in my career I've been goal setting and goal and strategies and etc. I've been listening to this for a long, long time in organizations since I can think of in my professional career. Why is it so difficult? There? What do you think why, from a leadership perspective? Why does it seem so, so hard? The goal setting piece, I think, and I don't want to speak for everybody, but it feels like we're pretty good whether, you know, agile on the team level, building a product, maybe scaling, things like that. So there's a lot of things we have, but it's like the goal setting piece seems to be like, struggling, why do you think that is? Jeff Gothelf 5:52 Yeah, look, I think leadership has been trained on 100 years of management, Canon that's based heavily in production, right. And we've I know, we've talked about this in the past, but their managers are trained to optimize production even today, which doesn't make sense in a software based world as, as you know. And so you've got the, the staff of a team of an enterprise or an organization trying to work in an agile way. And they have demands being put on them that are very linear, that are production oriented, that are very prescriptive, go build me this thing, make sure it does these three things, doesn't mean this way, and just try to get it done by Friday, if you can, and that grinds the gears grind there, right? You got agile sort of turned teams trying to go one way, and the organizational and leadership demands going the other way. And but but it's first of all, management's comfortable with that way of setting goals. It's super easy to measure. It's binary. Right? But it's it's you know, did you make the thing? Yeah, here's the thing. I made it, right. Yeah. So if you made the thing, then you did a good job, and I should reward you and I can, and it's easy to measure, right? I didn't make the thing that didn't make the thing, easy to measure, easy to manage, easy to reward. When we change the goal. And this is what OKR's does, right? This is OKR's. At its core, when done correctly, and why it's powerful is the goal changes from output to outcome, it changes from making a thing to positively impact the behavior of the person using the thing, right. Now, the interesting thing about that is that that is not binary. So for example, let's talk, you know, you could say, an output goal could be build a mobile app. Okay, maybe we built the mobile app, okay. And outcome version of that said, we'd like to get at least 50% of our revenue to come through the mobile channel. Like we'd like people to spend at least 50% of the money that they spend with us through the mobile channel, right? That's a behavior change. Right? The goal is not deliver a mobile app, the goal is get folks to spend at least half of their of their, you know, lifetime value, whatever you want to call it. Through the mobile channel. Yeah. Now, let's say, let's say that you give that goal to a team. And at the end of a quarter, six months, they come back and say, look, we got you know, about 27% of the revenues coming through the mobile channel. What do you do with that team? Did they do a good job? They do a bad job? Did you fire them? Like they didn't they didn't hit 50%. And that becomes really difficult. That's one of the ways why this becomes difficult, right? Is this sense of... Well, I don't know what to do with that. Because like, what if they hit 42%? Or 27? May be right. But if they got to 42%, or 43%? What do you do with that as a manager? Right. And I don't think that leadership is the folks who are in leadership positions are necessarily equipped to deal with that today. And I think that's, that's one of the main reasons why this goal setting is challenging. The other reason why this is challenging is because I think leaders are used to telling people what to do. Go make this thing, build it this way and ship it by Friday, when you change that when you change from output to outcome, or build me the mobile app. Clear, super clear in the sense that like, okay, and I want the mobile app to enable online commerce and search and make sure everybody's got a profile. Okay. Right. Drive 50% of revenue through the mobile channel, does not tell the team what to do. And that is really scary for people in a leadership position. Because all of a sudden, they don't really have an answer to the question. Well, what is the team doing right now? What's the team working on? And that's terrifying, because they feel like they should know that and a certain degree they should. And they also feel like they should be telling them that. So there's that there's a trust that they have to have in a team that the team is making good decisions. Joe Krebs 10:14 Seems to be like a cultural changes is needed, not only for OKR, but also for everything that follows the OKR. Right? Because it's the it's not only the framework of understanding how to set goals differently, but it's also how to work differently, right, to your point like 42%. I mean, is that a negative result? You know, in 50%, we are on you know, if that was a lengthy process, let's say, of building a product, there could be many things could happen, that could be still a success, right? So it's an interesting thing. In terms of leadership, there is another tool for for leaders to acquire. Right? That's, I think that's what I'm hearing. Like, it's not only you understand OKR, but also to understand the Agile piece entirely working with teams. Jeff Gothelf 11:00 It's, it's highly complementary to Agile or Agility. Number one, and we'll talk about that in a second. But the it's such a simple concept. And yet it is so difficult to implement simply by switching from managing the output to managing outcome, right? So overall, if we just I can define it for you in 30 seconds, right? The objective is qualitative, aspirational, inspirational and time bound. The reason we get out of bed every morning, right? We want to be the go to destination for online furniture sales in Europe by the end of the year. Right? That's a qualitative aspiration. Why are we doing this? Because we're trying to be the go to destination for online furniture sales in Europe by the end of the year. Okay, easy enough? How do we know we've done that the key results are measures of human behavior, right, they are the things that people will do differently, that tell us that we are the go to destination for online furniture sales in Europe. Right? That is that, that that's critical. And it's things like, it could be average order value, could be repeat customer, the percentage of repeat customers, it could be referrals as plus lots of different behaviors that we could measure. They're super easy concept. But as you start to implement it, this is where it gets difficult. So we talked about measurement, right? We talked about the fact that you're not telling teams, what to build, and then and then on top, but the compatibility here with agile ways of working and agility is, is it's nearly an overlapping circle. Because essentially, what you're saying is team, I need you to go out and discover continuous learning and improvement and iteration, the best combination of code, copy, design, value proposition, business model, that will affect behavior change in this way. So the team conceives hypotheses, begins to do discovery work and discovery work is design thinking, Lean UX, lean startup research, etc. And then based on that evidence, they start to invest in the hypotheses that deliver the behavior change that they're looking for. And they remove effort or or pivot or kill the hypotheses that don't deliver the behavior change that we're looking for. And to be clear, changing course, based on evidence is being agile. So it's highly, highly compatible. But it takes this tremendous, to your point, cultural and organizational shift in understanding how, how work has to shift to to account for this new goal.Joe Krebs 14:00 We got the leadership, there's definitely a different kind of engagement and involvement is needed, right? Coming in, you know, using OKR's. And working with agile teams, if we're going on to the agile team level. So what I hear is, the teams are focusing on outcomes rather than output. Right. And but you also and this is very interesting, because I think that brings out the self-organization, part of an often team really clearly is the team's should not be focused on the features. So we shouldn't be focusing on features we should be focusing on the on the outcome. How do we have to see that that's an interesting piece. I came across one of your LinkedIn in posts recently, and it was it was quite interesting why so not to focus on the features but to focus on the outcomes that really drives a total behavioral change on a team level? Jeff Gothelf 14:53 Yeah.Joe Krebs 14:56 And so let's explore a little bit. Jeff Gothelf 15:00 Go back 20 years in time, the delivery of software to production 20 years ago, even 10 years ago, for the majority of organizations out there was an event. Right? It was a thing. Like, I mean, honestly, we had parties. Literally, we literally threw parties when we delivered software to production, because it took nine months to get there. Right. Right. And, and you know, and we get a t-shirt with the name of the project on and we celebrate the delivery of software, right? Today, you can ship software to production, if you choose to as an organization as fast as you want. There's literally no limit on it, Amazon's doing it once every second. That's, that's kind of the speed. And so the delivery of software is a non event at this point, right? Our ability to get ideas into the hands of customers, to learn whether or not it positively impacted their behavior in ways that we expect it or not. And then to react to that to ship sense and respond if you'll indulge me a little promotion of our second book, right. Is is it's in everybody's fingertips. Right. And so this, this idea that we're focusing on a feature doesn't really matter, of course, we have to ship the features. But we can ship anything we want as quickly as we want. And so the sooner at end, any of our assumptions or hypotheses are going to be wrong to some extent. And so the sooner that we can find out where we're wrong, and where we're right, allows us to change course, and to adjust more quickly, right, that's the agility that we're looking for. And so that begins. And because the delivery of software is is a non event, the focus isn't on, did we get the thing out the door? It's getting the thing out the door, shift the behavior in the right way? And if it didn't? Let's find out why. And if it did, let's find out why. And do more of that. To me, that's, it's a really difficult conversation for everybody involved in the management and the delivery of products, digital products and services. Because it's really easy to think about features. It's a concrete thing.Joe Krebs 17:20 Well, Jeff, you have so far published 4 books, right, if I counted correctly. And this is not the big reveal, I would assume and in the world of agile books, but there is a book 5 in the making. Jeff Gothelf 17:33 There is there is and I'm super excited to be co-writing with Josh Seidenn again, I've continued to work with Josh Seiden and continuously for 15 years at this point, we wrote Lean UX together, we wrote Sense and Respond together, we've built a couple of businesses together and we continue to deliver work together on a regular basis. And he had a tremendously successful that continue to be successful called Outcomes over Output. And so we decided to join forces again on a book and put out an OKR book, we're still working on a title, but the goal is to get it out in October of this year. And it's designed to be the practical, tactical guide for justifying OKR's and then writing them and kind of what happens next and how to implement them and what what to watch out for in a large organization. So if you think about sort of "Measure What Matters" John Doerr's book, sort of as the kind of the big, lofty introduction to OKRs, which has a few things in it that I don't necessarily agree with. Anything about Christina Wodtke's book, "Radical Focus", and if it was 2.0 is being fantastic. generally focused on a single team, though so it's kind of where's the sort of the practical guide for larger teams and teams at scale? That's what we are going for with this book. Super. Joe Krebs 17:33 Yeah, super exciting right. And you also have a course like a self paced course about OKRs when you do a JeffGothelf.com if you if you had to, you know have like a thread through like in terms of topics and how they are like intertwined and you know, linked together out of those books do you see like, like lean UX obviously was a that was a big book coming out in the beginning of not your career, but authors career, right. And then obviously, now there is a book about OKR how does this all connect with each other? If you had to say like, okay, I wrote Lean UX I wrote sense and respond then lean versus agile versus design thinking and now there comes the other one, maybe even the one from Josh, that book that somehow also topic-wise fits in. But what is the theme here? What is what is it? Jeff Gothelf 19:51 Yeah, it's a good question. And no one's ever asked me that question. So I liked this question. So lean UX was a sharing back of ways that we had figured out through trial and error for practicing design, user experience and design in Agile software development environments. That's kind of where it started in its first edition. And it's third edition. Now, it's a bit more broad about kind of how to how to teams design and build great products in an agile environment. The feedback from Lean UX since the day it came out was generally speaking. "I love the book", would love to work this way. My boss doesn't want let me my company doesn't work this way. And so to Josh and I, that was a clear call a sent a signal from the market that said, there's there's something to be done here. People want to work this way. But their bosses don't understand why or how. And so sense and respond was literally a response to the feedback that we sent from Lean UX. It was it was a business book, designed for leaders, I think we've met I think we may be used the word agile in there twice, in 50,000 words, and that was by design, right? It wasn't it was to try to build to write an evergreen book. And that that worked out well. And what's interesting is that, then folks began to take that advice to heart. And they started getting their team's training. And so we're hearing from our clients while we're in their training with with maybe with lean, lean UX, product discovery, design thinking. You know, there's a lot of agile training going on. And the feedback from organizations was looking for training everybody in lean startup and and Lean thinking and design thinking and lean UX and, and Agile and Scrum, and the magic isn't happening. Right? Why isn't the magic happening? And it's interesting, because I felt like we were pretty successful, like, convincing folks that stuff in Lean UX was good stuff in sense and respond was accurate. And now they were trying to make it all happen. But they were kind of buying sort of ad hoc training and trying to make it all together, make it all work together. So that's where Lean versus agile versus Design Thinking came from. And in hindsight, I regret not calling it lean and agile and design thinking, right? Like, that's the only the only change I would make, because fundamentally the the philosophies is the same in my opinion underneath those, those ideas. And so that would have helped people kind of get a better sense of how to unite those processes and build those environments. And then finally, kind of coming full circle to this OKR book today. It feels like, well, it's what we talked about before, right? It feels like the product development parts of an organization get it, right, they get, you know, lean agile and design thinking. But the leadership part of the organization is still making demands on them, that reflect reflect old ways of thinking and old ways of working. So, an OKR book, if it can convince an organization to set goals in this new way, paves the way for the product development teams to be successful with everything else. We've provided them over the last decade. So that's the thread between it all. And it's almost like we should have been done the OKR book first and come his way. But you know, here we are. Joe Krebs 23:26 Yeah, no, it's it's awesome is many of those readers out there listeners, when we have read your material, they will know that not only will you write about it, it was going to be a great book away and as the other ones too. But it's also going to probably going to create a bigger interest in in that topic. So I'm excited about that. Because OKR's from what I understand is also creating a higher level of experimentation. Inspires is something I'm personally very interested about. Right. Soleaders, obviously, as we already pointed out, is is something that that would need to be coming on board with that kind of concept. And I think holistically drive this. This is super interesting. Yeah, that is, so if material out you have you you have training about this topic, you're writing a book about OKRs. And the title is still unknown. We don't know that yet. Jeff Gothelf 24:26 It's TBD. I've been asking Chad GPT to help me and it's done. Okay, it's generated some decent site overall, at least at least. Something has sparked the brainstorm.Joe Krebs 24:39 Yeah. Two quick questions at the at the end here. Before we before we depart. So if some leaders out there it's like is first time I really hear OKRs maybe something's like I've heard about it, but I really have no idea about OKR, what what's your recommendation for Leaders how to get started with that or possibly get warmed up to the topic. And also for maybe the other side, we have touched on in this podcast the teams, right? Like let's say there's a Scrum team. Let's just make it very specific. Right. And let's say there's a scrum team. How does Scrum and OKRs? How does that all link together? In your opinion? Jeff Gothelf 25:21 Yeah. So, look, I think, I think there's a challenge. I wouldn't recommend Measure What Matters any more than what's on every executive desk, just because there's some things in there. Fundamentally, he's okay with, with outputs as key results, and I'm not. So so I have to disagree with that, I'm sorry. But otherwise, and I think like Christina's Wodtk's books are amazing, Christina Wodtke's Radical Focus is amazing. I just, you know, it's generally focused on startups and single teams. And so if you're looking for for sort of a quick primer, there is, first of all, is endless content on my blog, but the OKR course, which is, which is super, in my opinion, super affordable. It's 68 minutes of video. And I think that that's a fair ask, if you're looking for a very short distillation of that. I did a, I did a kind of a video podcast about two years ago, with a show called product beats. Swedish. Okay, folks, I think, and it was like 18 minutes long. And all I did was talk about OKRs for 18 minutes. And so if you just want to invest 18 minutes, that's a great, that's a great little podcast to get into. And that would really kind of break it down very, very clearly as to the what, how the why some of the, the traps and the things to watch out for. So those are good places to start. All those are good places to start. Joe Krebs 26:52 Yeah, maybe people will later refer to this 25 minute podcast of Agile FM and say like that might be the starting point of the starting points, right?Jeff Gothelf 27:00 I hope so.Joe Krebs 27:02 What about teams? What are the changes on a scrum team? For example, if somebody says, Hey, we're going to introduce OKR's into our organization, what's the impact on the scrum team, for example? Jeff Gothelf 27:11 So this is where it gets it. This is where it gets interesting, right? Because again, like, if you don't, if you don't tell the team what to make, they've got to go discover there, they've got to go figure it out. If they don't know how to do discovery, or if they're not allowed to do discovery, then they're just going to retrofit their existing backlog into the goals that you've set for them. And that gets us nowhere, right? Doesn't we've changed nothing at that point, right. And so what changes at the team level is you have to start doing discovery, and then building that into your sprints. So dual track agile, we know that term for a long time, by discovering delivery, with the same team doing both types of work, writing hypotheses, testing them changing things based on evidence, that's key. So if you don't know how to do that, you have to get training for it. If your company won't allow you to do that, but they're setting OKRs as goals, you have to raise your hand, you have to say, look, I appreciate you going down this path. But if we can't go and talk to customers, if we can't run experiments, if you won't allow us to carve time out of every sprint for learning, then we've changed nothing. You're not going anywhere. Joe Krebs 28:21 Oh, that's cool. That's great advice, Jeff. This is, this is awesome. So we learned a lot. Jeff is working on a new book, it's gonna be about OKR's or related content. We heard a little bit about leaders, teams. We got a little bit of advice, and it's all packed into 25 minutes. There's only one sad piece about this podcast, and that is that I heard that we are not having any kind of launch parties anymore, no more printed T shirts those days are over. So for everybody releasing software today, you're missing out. But other than that, we're gonna see great improvements. That's awesome.Jeff Gothelf 29:03 It is sad. I mean, I miss my projects diamond T-Shirt. Project emerald. That was the one after diamond. That was amazing. Joe Krebs 29:13 It's awesome. Thanks, Jeff, for joining me on this podcast. Jeff Gothelf 29:17 My pleasure. Thanks so much for having me. It's great chatting with us. Good to see you again.Joe Krebs 29:23 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 2023 marks the beginning of the second decade of agile and for the past 10 years, I've been releasing podcast episodes with a variety of speakers and topics to you. And I hope you enjoy the ride so far. I don't know how many of you guys actually know the beginning of agile, and how it all started. While I started, the idea of a podcast actually started after a visit with Jean Tabaka in New York City, where we recorded again, a audio segment for the New York City community. After the recording, she pointed out that this was a really interesting conversation. And she really enjoyed it. And she thought, why am I only releasing this content to the New York City crowd and not on a world level as a podcast? So I began thinking about it, produced a podcast, and eventually it turned into agile FM, something you'll hopefully enjoy today. So as a tribute to Jean Tabaka, which left us way too soon, in 2016, I decided to re release that original content from 2013 with her. And what's amazing after I really listened to that audio segment with her is how much she already talked about organizational agility, somehow business agility, and some collaboration issues that are still valid today. So thank you, gene for, you know, helping me to get into the podcasting. And, you know, having me indirectly meet so many people on this podcast recordings. But I also wanted to make sure that everybody out there knows how influential Ginger Baker was in a variety of ways, and how valid her books and contents still are today, in 23. So I hope you enjoy this one. And in memoriam here is Jean Tabaka. Agile New York City 2013. Joe Krebs 1:56 I am your host Joe Krebs, and today I'm here with Jean Tabaka. Welcome to the podcast. Thank you so much, Joe. Jean, you're in town for a very special event to the edge on New York City community. We're celebrating our fifth birthday. Today, actually here at Pace University in beautiful, sunny New York City today. So thank you "A" for coming to the podcast. And "B" more important is actually speaking tonight to the edge on New York City community. That's a that's a wonderful thing for you.Jean Tabaka 2:26 Thank you. Thank you so much for inviting me. And I guess I could take a little bit of credit for the wonderful weather I brought from Colorado. What the heck. Yeah. And to be part of the fifth anniversary. Wow, what an honor. So seriously, thank you so much. This is great.Joe Krebs 2:45 Well, thank you, Jean, when I was when I was researching a little bit around your book, actually, in preparation for this podcast, I realized that, although we're turning five years, your book is older than five years. Yeah. Well, your book prior to the creation of agile in New York City. Wow. And it's still up to date. No, no. Should we say the book is timeless? It is it's still valid. I mean, people still read it. It's still a topic of conversation. It's not like a programming language has been outdated. The book is still very relevant. It's collaboration explained.Jean Tabaka 3:23 Right. Interestingly enough. About 2003. I think it was, I'll be talking about this in my talk this evening. But I'd like to really bring it up now. So thank you very much. And I was approached by the executive editor of the Agile Software Development series that was being run by Alistair Cockburn and Jim Highsmith. And he said, someone told me to talk to you. Wow, that was a bit frightening right there. And he said, I gathered that you have a great passion around collaboration, and specifically about how to facilitate collaboration. And I said, Yes, because I believe in the human aspect of agile, I read about it. And I don't see in the books, clear guidance about how to bring about self organization, how to make sure all the voices are heard, and how you can gather the greatest pools of insight. And he said, well, then write a book about it. I said, I could do that. But I think these sorts of things are much better transferred in person. And he said, well write the book. And it took me a long time to write the book, because very honestly, I didn't believe in it. I kept saying to him, but no one will read it. And he said, No, I believe in this book. And in fact, back to your point, Joe, he said, This is material, I believe will live on fact beyond many of the other books and he said if it doesn't, I promise su I'll work with you. I won't publish it if we really don't believe in it. And shoot. It's, it got published. It's gone beyond my wildest expectations. I am blown away, truly humbled by the people who still come to me worldwide and say, Thank you. Thank you for this book. I seriously never would have imagined and the gentleman who urged me to do this. Well, he was right. Yeah.Joe Krebs 5:40 Being persistent, right, and making you believe in, in what you're doing? Yes, even though you might not be seeing it at that point. But I did.Jean Tabaka 5:49 And I think you and I were talking earlier about our technical backgrounds. And I kept thinking, my book really isn't technical. Is it going to allow others to see that I have a technical background? Will it look like soft, fuzzy skills. And that was a part of the challenge for me as well to publish the book. And it's, again, just humbling that it's been welcomed into the community as it has.Joe Krebs 6:18 Well, the the other part of your title collaboration explained is actually facilitation skills for software project leaders. Yes. So what I actually like about this, two aspects of it, which are actually more important than ever, in our Agile community facilitation skills. And in 2006, when he was published your you talked about leadership?Jean Tabaka 6:40 Yes. In fact, that's the first chapter in the book. Wow. Thank you, Joe. Yeah, the first chapter of the book is on servant leadership, and what it takes. And there were people who had told me, Well, first of all, get rid of that chapter. And I just wouldn't, I refused. I believe that as we not just inform the Scrum Masters and the Agile coaches within our agile world, that is, we scale and have agile move outside development organizations, we move out what I'll call the value stream, that organizationally, we have to invite the notion of servant leaders, and people who believe in the insights of the teams as they bring forth their visions. That was very important to me. And that's why I lead the book off with that.Joe Krebs 7:39 So you have been doing this since 98. Yeah, the actual communityJean Tabaka 7:42 I am one of the Agile grandmothers.Joe Krebs 7:47 Since 98, there was also the word software in your book with would that be a word we could almost now like years later, almost eliminated, like because so many people do Agile outside of software development?Jean Tabaka 8:00 That yeah, I think that at the time, because my background was strictly software. I have a graduate degree in computer science learn. And that's all I've ever known about the world. And there's been this slow transformation of how I've gone from being analytical, to be more aware of the creative and humane side of how we create software. When the book first came out, I remember I had a gentleman contact me six months to a year afterward and say, he was from New Zealand. So right then and there again, I was blown away. Wow, my book was selling in New Zealand. And he wrote to me to say, why didn't you put the word software in this title? This book is not about software. It's about how to help organizations really be collaborative, how to facilitate collaboration. I knew about that, only in the software world at the time. And as I now look farther out, and around me, I see that and hear from people. This really isn't just about software. And thank you for helping software people understand the value of it.Joe Krebs 9:18 Why do you think it is that we have seen so many technologies come and go. And the topic of collaboration, facilitation is still very much a coot. I would actually say like it. It's important, more important than ever. What do you think is why technology can't solve specific problems in human behavior? We have all these tools will be now and but it seems like the projects are still not more successful from a from a collaborations perspective. Did you agree or do you do you think just been done some progress?Jean Tabaka 9:54 It's interesting. Originally, my target audience was For people who felt that more control would provide more success in the software world. And so I was trying to help command and control environments move to more collaborative environments. Some stuff I've been reading lately, interestingly enough, is pushing back on the agile movement saying, no people need to be able to work on their own to be truly creative. And I've been responding to that and a couple of posts here and there saying, I all the more believe in facilitation as a role because in this world where creativity needs to come both from the group, the the team, as well as the individual where creativity comes from both spaces. A really well informed and well seasoned facilitator is also sort of paid to be an observer, and to bring out the strengths of the team and the individual. So we raise the overall wisdom of the team, by individual contribution, and by overall team contribution. I don't know if that really answers your question orJoe Krebs 11:14 not? Well, yeah, I've seen like teams, distributed teams primarily, there was like, honestly, Cyril collaboration. They were assigning tickets to each other, talking. And that's not the collaboration I have in mind right?Jean Tabaka 11:29 Now it's not and and thank you for bringing that up. I've worked with a lot of distributed teams teams distributed within the same city within the same same state within the same country within the same continent, and then across three different continents. And again, the assumption is, well, we need to add more and more control. And I recognize that the scaffolding around these environments does require a bit more work than when the team is co located, we lose so much of the communication and the implicit versus explicit communication flow. The the tacit versus tribal knowledge. At the same time, when I've been traveling in India, and China, and Texas, sorry, I had to throw that in there. Talk about three different cultures. And what I have been doing is trying to help leaders in these types of environments understand good facilitation is all the more important. Because what I discovered that is that without good strong facilitation, in each of the remote areas, or distributed areas, as well as across the distributed teams, we can't really be reap the benefits of agile at all. In fact, people will start to become very alienated. And assume, frankly, sabotage by the other people. The only commitment the only communication device you have is a ticket. it for some reason, carries a little, little seed of blame and shame with it. Yes, that's not the intent. But boy, do I see shame and blame flying, you know, transcontinental.Joe Krebs 13:37 It's true. It's true. It's really true. Yeah. Well, you mentioned the Agile. I don't know exactly what you say as a movement or agile. You want to push back a little bit. You actually seeking a lot of advice outside of the Agile community. In your talk tonight, tell me why the Golden Circle of Agile? You you actually outline on our website, which is on www agile nyc.org. You actually say? Simon's you were very much influenced by Simon Sinek actually by a TED talk. Yes. So you're actually reaching out to totally other communities, tribes, so forth for for advice, and you map that to, to agility. Is that right?Jean Tabaka 14:24 Yes. Yeah, I want to clarify that I'm not pushing back on agile. What I'm doing is I'm inviting in and pulling in more resources into my technical world than I ever would have imagined. So initially, I was proud and eager to read as many agile books as I possibly could, and seek out the Agile speakers. Go to Agile conferences. What I'm discovering is that over time for Our agile adoptions to move into Agile transformations to move into organizational transformation. I'm being pulled to seek new guidance back to the talk for this evening. Tell me why and the golden the Golden Circle of Agile. When I saw the TED Talk by Simon Sinek, let's start with I was watching TED Talks. What I've been doing that five years ago. No, is Simon's talk about agile. No. But I listened to it multiple times, and took my own interpretations around it. They're not specifically what Simon says, oh, that sounds funny. Sorry. And then I bought his book, start with why. And it gives so much wonderful humanity underneath this thing called the Golden Circle of why, how what. And I said to myself, that really speaks to me. And it falls in line with some other authors and their books that I've been looking at, again, to broad the value of Agile to reap more benefits of Agile. They're not agile books.Joe Krebs 16:24 You do want to you want to share them with the Agile New York City community, what's on your bookshelf right now? What do you what are you interested in?Jean Tabaka 16:30 Actually, you know, oddly enough, what's more, well, yes, I have a bookshelf full of books. But, okay, this is a little bit of a nod to the Kindle. Because I love these books so much, I bought a Kindle, so I can carry them with me wherever. And, frankly, seriously, I use a Kindle as my library, as my reference library. So if you come through what I have on there, you'll discover every one of these books, I think that one of the biggest influences on me with regard to being a change agent, and therefore someone who believes in Agile transformation has been Seth Gordon. And admittedly, I haven't read all his books. But I would say this was a transformative book for me, and it's linchpin. I don't know if you've read that one, it blows me away. And it he talks about being prepared to bring your gifts and your artistry into your work. And I was thinking about how agile asks so much of us, and that our organizations deserve and should value our gifts and our artistry, I think agile invites that but it never really used those words. And he also says that we with our sense of artistry should be prepared to lean in to do hard things. And as we lean in a true artist chips, there are a couple of other things, he adds him with that. But I'd have to pull up my library to tell you this. Boy have those meant a lot to me with regard to talking about what Agile and how we as individuals work within an Agile transformation, and how an organization should be inviting our artistry and our gifts should help us lean in and ship. A book very similar to that. Daniel Pink's drive, and that has a lot to do with how intrinsic motivation is far more compelling for individuals and teams than extrinsic rewards, or extrinsic. Punishment is too strong a term but if you don't get this done, then you're in trouble. So you have to go into this depth tomorrow. Yeah. Wow, another book, I've been doing a lot. I've been going back to time and time again. And in fact, excuse me. Pardon me, I'm using sort of my metaphor for the year is Dan Heath and Chip his book switch. Again, nothing to do with agile, but has to do with when we're prepared to preparing to be transformative, and they have three metaphors there which are, drive the rider so set a vision, motivate the elephant, which is look into the emotions and the heart of what it takes to go to transformation and then shape the path so ensure that that can occur. And again, I think about Wow, all these things I care passionately with regard to agile, agile teams, agile organizations. I want to give these gifts to people about I get how hard it is. And we're worth we're worthy of what we can get out of that. And then a bit more technical.Joe Krebs 20:14 How do you fight broadening that scope? By looking into other industries? What do you what do you think is going to happen to our community? Or where would you like to see the Agile community? Getting stronger getting? Or emphasizing certain topics? Is there anything based on what you're seeing around? Yeah, John community?Jean Tabaka 20:39 I think I wouldn't be telling you anything new with this answer, but I'll give it to you.Joe Krebs 20:43 Please give it to me. You can decide.Jean Tabaka 20:46 And I believe the original agile movement, had a wonderful focus on how to help development teams deliver, and how to protect them from the tyranny that tended to surround them that held them hostage, in some ways. What I'm hopeful about with regard to reading these new things, and the way that I would invite them into agile communities, is that we are broadening, agile scope. And its focus, and inviting, and we're broadening both into the individual values, and our quality of life. And we're broadening out to the organizational view, and organizational quality of life. This is a hard sell, when I go talk to large organizations, they'll still look at the bottom line. And the reading I've been doing is that the bottom line will take care of itself sounds pretty Frou Frou, whatever the bottom line will take care of itself. When you really believe in the people. Every one of these books says believe in the people care and the people and these other things will take care of themselves. I've also been reading Don Reinertsen must be so I feel sorry. That's okay, I keep interrupting you. So.Joe Krebs 22:21 But that has to be true, right? Like a truthful. You believe in your people? I mean, it has to be, it has to be done right. From an organizational perspective. A lot of people say that it's just like I believe, just take care of your department and takes care of itself. Just focus on the customer. Or other say just focus on the employees, like whatever your viewpoint is. But some organizations try that. And it's still not successful, because they might not be really meeting it. But they're saying, right, yeah, so I guess there's a hidden agenda.Jean Tabaka 22:54 Yes, yes. And again, thinking about some of the things I've been reading in the agile and Google Groups, etc. And talking with organizations is I wonderfully I get paid to go talk with and listen to people. How did I get this lucky? And I hear that agile still puts them on Death Marches instead of one death march at the end. Now we have a death marked every two weeks. Yeah, let's sign up for Agile. And and they're under the Agile tyranny. Yeah, they're they're under some sort of tyranny of time box.Joe Krebs 23:33 So torture. Yeah, every two weeks. And that was not the intent. No, that's that's not the intent. Yeah.Jean Tabaka 23:39 And so as we're trying to do the right thing with agile, I think it's valuable for us to look outside of agile and say, Can we reinforce ourselves of what the intent was? And can we actually have it grow through our nurturing of the intent through these through these other guides?Joe Krebs 24:00 I do want to come back to something very, very tiny, narrow topics is meetings, you said, we already had focus we have created we have created where we are delivering software. So you're doing all these good things with agile but I still observe and I just wanted to ask you, obviously you're sharing this battle Holly, Holly, anyone meetings, meetings, Ali run any in any kind of shape, they run in an effective way? Do you have any advice for the listeners out there? I do like one tip or something, how to run meetings, a little bit more effectiveJean Tabaka 24:39 Habits of Highly Effective facilitator. Okay. And sometimes I think people are looking at me and saying, Well, Jean, when you see everything is a nail, yeah, your hammer is the right tool. I would like to use my company rally software as an example this coming August 1, I'm celebrating my eighth anniversary with the company. Thank you. And I was the first consultant hired into the company. Here I was writing a book I was hired in in 2004. I was writing a book on collaboration and facilitation specifically. We were very small group at the time. And I approached the CEO, Tim and the founder, Ryan, and said, I think we could really benefit from having facilitated meetings, Agile has so many meetings. And they said, Okay, ceremonies that Yeah, show us what you've got eight, seven and a half years later, we do not have any major meetings without a facilitator. We are an organization of facilitation. And this has not been through me pushing it on people. It has been through groups pulling it. This is not just the development teams, it's every department in the company. We have retrospectives, we have planning meetings. And we now actually have a facilitators group. And we check in with one another about what are you running into? What are some more things you've been reading besides genes, but we truly believe now we are a facilitation driven organization. And when I can bring that message into other organizations, because they say, agile is killing us there are too many meetings, then what I talked about with them is how effective are your meetings? What are you doing to ensure that they meet a purpose that they don't go on forever and ever, that they don't suffer from what I call LV di D? Yeah, loudest voice driven development, loudest voice decision making driven decisions. The facilitator is there to protect everyone and make sure everyone's heard and understood in a safe environment that I believe is truly critical to Agile. And that's why I think facilitation is a isn't great and necessary tool in the Agile set of tools.Joe Krebs 27:11 How do you see like social media networks, influencing the focus of today's meetings? Do you think that's like with Twitter, with Facebook with all these technical capabilities of instant messaging? Do you think that has any influence negatively on an agile project?Jean Tabaka 27:31 Well, what I can say is that being the one of the grandmothers out there, figure template inish, initially, I put push back very hard on no electronics in meetings, what I've come to believe more valuable is our intentions in meetings, and how electronic service services again, I'll just use my own company. But I've seen it in other companies, where we make agreements with one another at the start of a meeting, we declare our intentions, and the use of electronics. For instance, recently, we had a meeting where we wanted a colleague engaged. And so we just put her in Google Chat, turned in video chat and turned around and sat in a chair and major part of our meeting. In almost every one of our conference rooms, we now have very large high def, panel screens on the walls, so that we can have people in the meetings. And people will also say I need electrons, I need to have my electronics on because I need to stay in I Am. Part of it is so that we make decisions very quickly that we remove the waste of if someone's not in the meeting, we bring in their information to make decisions more informed and faster than waiting until outside the meeting. So theJoe Krebs 29:02 technology is related to the meeting itself to the Yeah, no, it's not like just chatting with somebody about something totally unrelated to the meeting. WeJean Tabaka 29:10 have meetings that still suffer from that. Yeah. And we as facilitators are learning how to check in with people about the agreements, the intentions and the norms. And I'll ask very specifically, who knows right now that they need to be in email. Okay. Yeah, email. Well, yeah, tell me that. Yes. I I have a burning issue that I need to be engaged in and therefore the rest of the group understands why that person is doing email and the others aren't. Yeah. And we still struggle with that.Joe Krebs 29:44 You said you started as a consultant with a rally Yes, but your title now is fellow keen on finding out what a fellow does for rally. Ah, tell me a little bit about Your day. What are how does a typical day of gene debate look like? What I would ColoradoJean Tabaka 30:06 in Boulder, beautiful Boulder, Colorado? Believe it or not, this is something of an emotional question and answer for me. I have loved my work as an agile consultant. I have loved and continue to love working with rally. It is the best job I've ever had in my 30 plus years in the technology community. Well, as the first consultant I help define what we would look like as consultants. One of the big things being we would be highly facilitated. When I moved into the role of agile fellow, the intention was, this is going to sound a little self serving that I would travel less travel less. But now you know something about that. What, what has been so deeply rewarding to be agile fellow is that I actually travel more. And it has to do with the fact that I read a lot more and I blog more. And I work with different levels, higher levels in organizations. And how we came up with the word fellow was we brainstormed and said we don't know what to call this. Let's just call it an agile fellow for now. But it's not an untypical definition. I didn't want to be called an agile thought leader. I thought that was pompous. And yeah, a bit assumptive. But I did want to be someone in the rally community and then in the community at large that where I made an intention of I'm here to share ideas and bring in as we talked about earlier, ideas that aren't even necessarily from agile books.Joe Krebs 31:55 What do you do to relax during boredom? I do try to get a feeling of what is are you scared? Are you ski?Jean Tabaka 32:02 Oh, well, I'm an extremely bad skier. But you ski Yeah. I just went skiing a couple of weeks ago and suffered about five major bruises all over my body and knocked my noggin my head pretty badly. I've broken a leg skiing. I skied into a tree two very badly sprained ankles. And then this two weeks ago, the worst bruises of my life. And I still get out there. It's so beautiful. Wow, I it is so beautiful.Joe Krebs 32:40 You're a skier in training. Claiming like, as we discussed earlier, we still feel like we're in graduate school. Yes, right. And you're stillJean Tabaka 32:50 I'll be in kindergarten as king. And I do love. The other thing about living in Boulder. I chose to live there 12 years ago. It's a beautiful place. There is a lot of entrepreneurship. There's a lot of sense of sustainability, and social impact and giving back to the community. And I've had the deep honor of being engaged with some of the social initiative clubs at the University of Colorado, and also helping with some of the entrepreneur programs. I'm helping set up an agile conference at the University in September. That may not sound like leisure. Okay, let's back off. When when you're passionate about your work, it bleeds back and forth. It really does.Joe Krebs 33:43 You know, it's like, what weekday is it and you will realize how I work on Sundays. But you don't feel it.Jean Tabaka 33:49 And I am trying to move away from so much of my reading, feeding into my passion about work. And actually this summer part of the rally program for having been at the company seven years, I'll be celebrating my anniversary. We get six weeks of sabbatical. So I'm intending to truly take six weeks completely away from my passion around agile.Joe Krebs 34:17 Will that be New York?Jean Tabaka 34:19 It's going to it's going to be in an undisclosed location in France, okay for four weeks of intense language immersion. And I have reasons for doing that which go back to Seth Gordon, and my need to lean in and ship.Joe Krebs 34:39 Awesome. With Thank you, Jean, thank you for your time here. It's been a delight prior to your talk. I just want to highlight that one more time. Tell me why they go in so called Agile we're gonna hear your talk later. At Pace University at our fifth anniversary. It's not a lot. Yay, but it's five years and it's good moment for us to reflect. And we're happy to have an amazing speaker like you onstage. And not only onstage, but also on the ground, actually where we have food, drinks and we can stay for some drinks. That's aJean Tabaka 35:13 hobby. That's food and drinks. Yeah. And music,Joe Krebs 35:17 drinks music, and so we have a good time. Thank you again.Jean Tabaka 35:22 Well, I'll tell you that again. Thank you so much. And thank you for inviting my topic about tell me why that is a passion of mine. I don't think I understood it back when I was an agile neophyte, and learning just how to work within teams. I now look at how passion drives us and should drive the organization. And as Simon Sinek would stay, I would say start with why and that's start with your passion and your vision. That's what I'll be talking about this evening.Joe Krebs 35:55 Thank you, Jean. Thank you so much. Bye bye.

Transcript: Joe Krebs 0:10 Agile FM . Radio for the Agile community. www agile.fm. Welcome to another episode of agile FM today I have Katie Anderson with me. She has a web address not as easy ... Katie Anderson.com No! It's www.KBJAanderson.com. Just want to highlight that if you're starting googling her, she's an internationally recognized leadership coach, consultant, professional speaker, best known for inspiring individuals and organizations to lead with intentions. She has written a book, learning to lead, leading to learn that was published in 2020. We want to talk about some of those topics today. In this episode, we're gonna talk about maybe Australia, Japan, UK, United States, topics like that. But first and foremost, welcome to the podcast, Katie.Katie Anderson 1:07 Thanks, Joe. I'm so really excited to be here and to have this conversation with you.Joe Krebs 1:11 That is awesome. There's, let's let's kick it off with a fun fact. Because I was doing a little research on your website, that is KBJAnderson.com. And I did some research and you started your business in July 23 of 2013. And exactly in that week, the first agile FM podcast came out.Katie Anderson 1:31 Oh, wow. Well, we're, we're fated to talk together with the great beginnings of a podcast andJoe Krebs 1:39 yeah, I would have thought almost 10 years congratulations to that. Oh, thankKatie Anderson 1:44 and who would have thought I had no intentions previously of starting my own business. But looking back, it's not a surprise when I sort of see how the things in my past actually connected it to lead to where I am today.Joe Krebs 1:59 Right. So very diverse background I noticed by two you started working, you know, if I please correct me if I'm wrong here. Planet Hollywood or something like that was? Oh, yeah, it's good. Yeah.Katie Anderson 2:12 I was well, that my I would consider that pre my professional career starting. But yes, in the year and a half after I graduated from university, I moved to London, and was Katie from California, as one of the servers at Planet Hollywood. Now this is back in the late 1990s, when Planet Hollywood was like, you know, the place to go. So it was it was a fun, fun experience and a great kind of bridge between finished graduating from Stanford University. And moving on to my the first part of my career in academia. So, yes, I never thought I was going to be an entrepreneur. So starting as an academic, but it all came together full circle,Joe Krebs 2:53 right. And that was before 2013 way before starting point that we can say, you know, England, London, check for his country already wide covered, you lived in a country and there were other countries on your journey as well, Australia, but Japan had a huge impact too.Unknown Speaker 3:11 So prior, so I've lived in I think I six countries outside of the US. So in high school, and in university, I did exchange student programs in the Dominican Republic and in Spain, then moved to London after university. And I was a winner of a Fulbright scholarship. And that's what took me down to Australia to do my master's degree in public health policy. And I stayed there for four years. And that's when I made one big career shift from academia actually into consulting, still in the healthcare space, and then returned to the US. And that's where I got my introduction to lean and continuous improvement and operations and all of the things that now I've shifted into my my later career and then moving to Japan as well. So...Joe Krebs 3:58 it's all of those things you just touched on speaks for your diversity and it's things we have experienced that obviously have an impact on one of the things you all bring together. Right. I think that's that's what this is why when you're pulling from different kind of areas and life and professional experiences, even better, Japan, I think, had a big impact on you.Katie Anderson 4:20 He has always had, yeah, a big impact but and Japan has had a tremendous impact on me from it was almost eight years ago at the time of this recording that my family moved to Tokyo for my husband's job he actually works in works in IT and we went out there for almost two years, and has just been an incredible part of my personal and professional life since then became the basis for my book "learning to lead, leading to learn" lessons from Toyota leader Isao Yoshino Tino and a lifetime of continuous learning. And the this Japan study tours that I run, leading tape leaders and practitioners from around the world to go learn in Japan on an immersive week long trip. Right? So I'm excited to be going back to Japan and 2023. So we're post pandemic are moving through the pandemic.Joe Krebs 5:14 of course, that obviously had an impact on that as well. Right. helped me build this this connection, obviously is Isao Yoshino if I pronounced that correctly. Well, thank you. Yeah. So he, his part indirectly part of the book, because these are stories, where do you have extracted and learning from, from him, but it's so fascinating about him that you decided I want to write a book about him or about him, but you know, in the context of him from a leadership perspective, learn and extract from him.Katie Anderson 5:48 Yeah, so that mean, he is the subject of my book, we became the what what I thought was a once in a lifetime opportunity to spend the day with a Toyota leader in Japan turned into one of the most profound and connected, you know, adult relationships in my life. And he played some really important behind the scenes roles at Toyota, in the 70s 80s, and 90s, as it was really transitioning to this real learning culture, that was more people centered as well. So leading, and being part of teams that were like almost you consider the internal consulting team, some huge leadership transformation, efforts, re-training, 1000 plus of Toyota senior managers on really what it means to be a leader to create learning in organizations and achieve goals, sort of the foundation of so much of what we know, that might be considered Kata, or a A3 thinking as well. And then part of the joint venture between Toyota and General Motors when Japan was sorry, when Toyota was expanding overseas known as numi, he was in charge of the leadership development program for the training program for the American workers to come out are the American managers to come to Japan to learn the Toyota way. So really prove that you can translate this thinking across cultures, that it's these principles like work, it's just how we embody them, and how we support the development of other people, so and so much more. But I as I dug into my learning from him, and realized how much history there hadn't been captured, and just his wisdom, his own personal journey, I realized this, this needed to be brought to the world. So it's been one of my life's great privileges.Joe Krebs 7:37 Yeah, so we had the opportunity to speak more, spend more time with you. Isao I would assume that not just one one day,Katie Anderson 7:45 oh, my gosh, yes, I so I, we, he I'm recording this in my office, it's also our guestroom he stayed at my house multiple times, we, I would, when I was living in Japan, we would spend, I would jump on the Shinkansen the bullet train, almost every month, every other month, spend the day with him started writing, I was writing a blog at the time, being a lean practitioner living in Japan was a really, you know, unique opportunity, and was writing about our conversations and people were really taken with it. When I moved back to the US. In 2016, we continued our partnership, and just this idea of writing a book came to be and as you know, the concept of a book, a great idea turns into something different and it became a much larger project to once we started with purposeful interviews, but it we've I this book is the culmination of 1000s of hours of conversation, which I'm so grateful to have learned from and having the one on one interaction, but also to be able to synthesize them and put them in a really, hopefully enjoyable read, but a really helpful and useful book for for practitioners lean, agile, you know, just enthusiast about learning and leadership around the world.Joe Krebs 8:59 Right. So I just wanted to make sure right, because you know, and that anybody walks away from this podcast has actually spent a day with no, no, no. Emerging with almost 400 pages.Katie Anderson 9:11 years. And we. So I had, you know, a lot of material from previous years of conversations and writing blog posts and working partnering together. But we when we said yes to like we said, Well, yeah, let's do this book idea together. And it actually wasn't intended to be using all of his stories, it was had a different form and shape. And I talked about that in the introduction how it morphed as you learn. But through the purposeful interviews over the course of a year, it became clear that so much needed to be so much more needed to be shared in a different way.Joe Krebs 9:47 Just curious, I mean, I would assume the conversation was in English.Katie Anderson 9:51 Yes. So Mr. Yoshino spent 14 years of his career in the United States. And actually, as you discover in the book, you know, his lifelong dream was to live in the US Since he studied English from an early age, and this is quite unusual, actually, you know, he was born at around the time of the end of the Second World War. And so, you know, the US and Japan relations were, you know, they're a little different than they are now. So his English is quite fluent, and which has been great that he to through the pandemic, even though we had planned to have all these in person events, he's now able to connect with different leadership teams and help them have conversations and talk about things as well.Joe Krebs 10:30 Do you think like, even though it's not necessarily the mother tongue that something? You know, was it harder to catch something that might have gotten lost in translation, just from like, Japanese culture at Toyota's perspective, translating into English was without any kind of difficulties, just like from a language perspective. I mean, there's always ways to, you know, I say it differently, but it's not the same, necessarily right?Katie Anderson 10:57 So I would say not as much between Mr. Yoshino and myself in terms of the book, as it relates to principles from Toyota. And what we know is lean or the Toyota way didn't, whatever you might want to call it. There have been some lost in translation moments. And particularly, and I highlight this at the end of the book about the internal document that Toyota put together in 2001, to really sort of summarize their culture and what the Toyota way really means. There were two elements that I really consider lost in translation that have really, I think, impacted how people think about what is emerged as lean or agile and a little bit more focused, why we've ended up being more focused on tools perhaps, than the real essence, which is around learning and people. The first is that the Japanese, the way the Japanese words are written, respect for people, we only have one word for respect. And one sort of the one way of looking at the people but the the way the kanji symbols are written in Japan, there's a there's a nuance in those words, and it's respect for humanity or respect for your humaneness, which, to me, has a much more enriched meaning than just respect for people, which you might be able to think of as, like, Oh, I'm respecting you just because of your title. And the second element, which I think is real, a real miss actually on Toyota is part because they were the ones who translated it this way, was that the the way they the pillar of the Toyota way that they translated just as continuous improvement, actually is made up of two Japanese words, one, which is Kaizen, which we know is where we are commonly know as continuous improvement or improvement. There's that was Kaizen and wisdom "chie". And we're totally missing the word wisdom from this concept, and to me, wisdom is like that generational knowledge. It's information that we're putting into place, and it's much richer and so are the missing the word wisdom, to me, really just make sort of continuous improvement. Okay, yeah, we want to make incremental changes and improve all the time. Wisdom has a sense of gravitas, and generations and connectedness that so that that part to me is lost in translation, as it relates to my conversations with Mr. Yoshino? I don't know. I don't think so.Joe Krebs 13:27 Well, so your so your book, what's what's really standing out is in a very short period of time since 2020, when the book came out tons of reviews, and not only reviews, five star reviews. I mean, it's just very, very remarkable have to say, usually, I don't pay so much attention to that I had people on the show here with a few stars, you know, and on an on an Amazon page. But that really stands out, I have to say and what I want to say those those guests were great guests, great topics. It's just like, you know what the public thinks about it. But it's, that's tremendous, in terms of what people would like to learn from you here, and it's let's focus a little bit on the book. Why because it's I think, what's what's in there is about "Learning to lead, Leading to learn". So it's a great wordplay. Well, I love it to add, but it's it's also something where he just mentioned about continuous learning. Right? Well, I would like to go as in terms of leading is some people, at least when I started my career, they were hired, you know, because they brought a certain knowledge to the job description when they were hired to say, like, we need exactly that knowledge to come in. Right? Especially on the leadership side, right? Like, I need that leadership to come in. I need somebody who has that knowledge. So you're basically brought in for what you knew at that time. Your book is all about going forward, right? You're coming in and continue your learning journey. I don't think that you know, that's obviously what we're talking about 20,30 years ago, he might have been different and maybe it was me isolated, but it just felt like that. That didn't beginning you were hired for something because of your knowledge at that time, I think that is a concept. So how do we, you know, how would you tell the listeners here to a listening to this episode here right now, the approach at Toyota, what you have learned and what you experienced over the years since since you wrote the book in the years before?Katie Anderson 15:17 Yeah, absolutely. And this is really what I see as the secret to Toyota and why they've been so successful, and why so many companies and leaders around the world are really trying to emulate what they've done either through applying lean or agile or kata, you know, all of these things that sort of had its genesis through these, through Toyota really be applied in different contexts. The one of the, the framework that I talked about leadership is this comes out of this comment that Mr. Yoshino made one of the first times I met him, and it really summarized to me the simplicity of what leaders need to do. And it's actually inherent in the kata framework as well, or A3 thinking, whatever all the tools you want to talk about from, from Toyota leaders set the direction. So where do we need to go? And you know, what's that challenge the target we need to achieve, then provide support. So that's the coaching the development, the cultivating other people's expertise, and figuring out how to get there. And then the third part is about developing yourself as a leader. And that third element is often missed when we think about leadership. Yeah, okay. Leaders need to set the strategy with the goals, where do we need to go? Okay, yes, they need to provide support to their people, what does that look like? But this realization that we also need to be always developing and improving ourselves, both from our knowledge perspective, but also from our behaviors, and our skills and abilities to be clear on strategy and direction? And then really, what does it mean to provide support? And you highlighted what I think is one of the biggest gaps that I've observed in leaders around the world. And was also, you know, when I, when I realized for myself as a, as a manager and leader within an organization, a challenge as well, is it we have cultivated deep expertise and knowledge, and we are hired often for that technical ability that we have developed. And that's great when we're in individual contributor role, or there's a problem that specifically or strategic initiative that needs to be solved, though, when we have people development responsibility, which usually comes with being a manager or a team leader, or however the structure is, you also need to be stepping away into how do you cultivate that expertise for other people and let them learn and develop those capabilities. And so we have to navigate this leadership continuum between being an expert and developing the expertise or coaching the expertise of others. And that can be a really hard shift for us to make and something that we're like invisible to sometimes. So we're jumping in with all the answers and trying to give people our all our ideas, which is great, because we feel helpful, but it actually is missing out on that secret sauce, which is cultivating learning across the organization.Joe Krebs 18:10 And it's not only the learning for team members or team or a group I work with, it's also my own learning. Right? So that's also, butKatie Anderson 18:20 absolutely, and so you're learning. And I call this this chain of learning, like we're learning through working on a needed gold or also learning through the interaction about how to be more effective and how to do that differently.Joe Krebs 18:35 Yeah, I always think like, if you hire somebody, you know exactly through like a checklist of skills and expertise you're looking for. And let's say you have that perfect match, check, check, check, check, right, and you got more than that person would be bored coming on the job, right? Because it's like that is, you know, what's the learning path here? So you got to provide that, for a person, at least that's how I'm triggered was like, what's, what's next? How can I evolve? What is the to learn and, and that platform, that environment has to be there for somebody to flourish? Right?Katie Anderson 19:03 Absolutely. We, I mean, we know this innately as human beings, right, we always need a little bit of challenge and a little bit of something new or making progress. I mean, that's very rewarding. And when we don't have that we do feel disengaged, or, you know, unsatisfied. And so that's part of the, you know, manager or leaders responsibility, too, is making sure people have enough challenge that's stretching them but enough support that they feel like, you know, they're not like doing it all alone. At that same time, and that's where that learning zone, that sweet spot of the learning zone comes in.Joe Krebs 19:40 I just saw recently like, I think it was a McKinsey statistic it was all about like leadership and the introduction of agile, the impact on leadership, and it was like a significant percentage of people freed up time to actually focus on strategy right in a in an organization because there was so caught up in a day to day activities working like on very tactical items. Because there was so blocked and an agility created a kind of space for them. So...Katie Anderson 20:13 yeah, absolutely. And one of the unintended consequences of us kind of jumping in to participate in problem solving or taking, telling people, all of our ideas is we end up actually taking on the burden of having the responsibility for doing those things. So we don't have time and space to do anything else. And so actually, to be more effective, it's how do we how do we know which are like, our problems to solve? And where is it really our teams and our people? And what does it mean to show up differently to provide that support and that help that's needed without taking over all the all the activity? So that's the great leadership challenge, right?Joe Krebs 20:52 Here we go. That's a good one. It's let's let's explore this a little bit, because obviously, Isao Yoshina is from Toyota. So how would you respond? I'm just curious, put you on the spot here. But how would you respond to somebody who would say like, oh, that's all great. You talked to him, and you wrote a book, and it's about Toyota, and it's maybe lean? But what if, you know, somebody says, I work in a financial institution? We're not building cars or something like that? How would the topic? I feel like I know the answer, but I just want to make from you, how would a topic like this apply to you know, something more generic out there was somebody in a totally different industry might not even for profit, it could be nonprofit? Anything like that? How would you know somebody benefit from this?Katie Anderson 21:40 Well, I first and foremost, I started off in healthcare and working in large hospital and healthcare systems using the same principles to guide improvement. And I now work with industry agnostic, really, you know, I work with IT functions I work with, large, you know, biotech, pharmaceutical companies, I work with knowledge workers, you know, all across the board, what I think is really important is we have focused far too long on sort of the visual artifacts or the process side. Now, it's really important to improve the process, of course of how work is done, and how value is created for any organization's customers. The principles of all of this thinking can be applied to whatever industry. So what is your purpose, your organization's purpose? What is the value that you deliver? Or create either a product or service for your customer? How are you do that doing that in the most effective and high quality way? How are you engaging people's thinking and problem solving at the right level each and every day? How do they know where they need to go set the direction? How are you in creating that active engaged workforce? And how are you improving yourself as well. So I think, if we focus too much on like, Oh, I'm in a different industry, they this can't work, we're actually missing the whole point. Because the the way it will manifest will be different, actually different across any organization, even if you're in the same industry. So this is why Toyota never cared about if people went in and saw their, you know, went to the manufacturing shop floor and observed things because they knew they're missing. The thing that's really the secret, which is underlying everything is that they're creating, learning, looking at how they're developing people, engaging people each and every day, they were just solving the problems they needed to solve. Your problems are going to be different. So that I mean, that's my really my response. And I heard that so much when we were getting started in healthcare to oh, we do we provide health care for people, you know, we're not You're not a manufacturing line? Well, actually, there's a lot of similarity, if you look across, like looking at value and how we create value.Joe Krebs 23:53 Yeah, but it's interesting, right? As you just said, like very transparent on the on the floor, right? Build how we build things and take a look at it. We're very transparent in this. But even with the secret sauce, it's not easy to build that, that that map, like, we can still do that, because now we have the tools, why we can say, we have a better understanding of what's behind it, right. But we're still, we're still struggling to identify opportunities within organizations to try something like this. I mean, I'm just myself, you know, as we talked about before, the Kata is what I'm very passionate about the same thing, as like, you know, is this one comes from Toyota, it's extracted from Toyota with that map or apply to something else, and I see the synergies, but even with the secret sauce, it's not easy.Katie Anderson 24:41 No, I mean, that that's the that's the challenge, right? Like, actually, these concepts are very simple. And they really make a lot of sense if you just take a step back, but it's not easy to put into place. And that challenges all of us to think in a different way. I mean, I think in my own business, as well, like, I'm well into all of these principles, but to apply them in my own work requires me to, like put real effort into that and to like, oh, how am I making the invisible visible? How I how do I have clarity on where we need to go? All of those things? Yes.Joe Krebs 25:16 Yeah. So maybe there's also the answer. I'm just, I'm just gonna ask you because the book itself has the little add on. It's this workbook.Katie Anderson 25:25 Hmm. Yes.Joe Krebs 25:26 It's not a coffee table book.Katie Anderson 25:28 No, it's reflect and learn. I mean, it's beautiful coffee table book. But no, it's for Applied Learning, applied learning.Joe Krebs 25:37 Exactly. So how would you like and obviously, that's why I said coffee table book. It's not a coffee table book. It's a workbook, right? Because we do want to use a copy and we want to work in it. So how would you like the learner work through some of those things you're describing in your book? What's the style with a book? How would you envision that? Is that a start to end read? Is that a chapter by chapter and then possibly exercises? Is that something you go along with as a professional? Is that something you prepare for something? How would you like to see the reader or the professional use that and consume the work?Katie Anderson 26:13 So the book is really, you can choose to use the book however you want? The the way I wrote the book is about Mr. Yoshino's, chronological learning journey. And so it is you could you could go into one of the case studies and just read that what I think is really helpful is it shows like a real human perspective of how like someone starting at the beginning of, you know, actually, there's some backstory of his own person, how he got to starting at Toyota, but as a new college graduate, and, and experiences he had at Toyota about learning what it actually means to lead in this way, what does it mean to be a manager, what it means to be a leader, and then starting to apply them across different assignments that he had at different parts in his career, some which were great successes, and the last, you know, actually, an innovative new, you know, product for Toyota was a huge failure that cost the company $13 million. And he was responsible for that. So, you know, I think it's the human human story. And the feedback I get from those almost 255 star reviews on Amazon, is people really love this. It's a real story. And it's really human anatomy course, you can jump in at any point. And I have reflection questions at the end of each section of the book, to help people think about it. So I wrote the book, the workbook as a companion to really take some more of the concepts that I help leaders and practitioners learn about what does it mean to have intention? Who do you want to be? What are the actions aligned with that? What impact do you really want to have? And then some more some of the questions plus more questions to reflect on some space about that some different exercises to go through to really bring to life some of the stories in the principles that are talked about in the book, but how does that relate to me? You are you rather than the reader, the the learner? And then have what are you what action? Are you going to take on that? So you can use that as an individual, I also bring this into the leadership development programs I do with companies around the world. And as a core part of the learning experience, and if done as part of different cohorts of one, like small group learning I've had as well.Joe Krebs 28:28 Yeah. Well, I used to be a super well connected with the Lean community, as we know, obviously from from your background, you have worked with Agile-lists around the world. What would be your advice for agile leaders, from your experience from your, you know, seeing in workshops, and I'm sure there were some agile leaders that came across your work or read your books or give your feedback? What would you like to tell them in terms of mapping your book to the Agile community and possibly a focus on leadership and learning?Katie Anderson 29:01 Yeah, absolutely. And, you know, I've had different agile leaders and practitioners join me in Japan and have been part of my workshops and learning so people also in the IT space, and in many, many, many knowledge workers as well. And, you know, I gotta go back to what I we were just talking about that the these principles go beyond and actually, do you know, any, you know, I guess, categorization of approach that you've you would you want to call it agile, do you want to call it lean? Do you want to call it you know, continuous improvement, Kaizen, all of these things are built upon these foundational principles about what it means to achieve results, how we get there, how we resolve problems, how we develop people to solve problems and how we improve ourselves as well. And so when we can get back to those fundamentals, we can apply them in any aspect of our work. Regardless of you know what that's looking like and it can help us think differently about our processes. And of course, then we can bring in the different frameworks and approaches and apply this, the, our leadership behaviors to make those more effective. And so I would say, take this, take this step back to really think about what is your purpose in your as a human being first and foremost? And then how does it apply to your role or function and what you're trying to accomplish the impact you want to have? And then thinking about how are you best going to get there? And and how you can align your actions with having that impact that you want? And then how do you take the other frameworks and tools in within your sphere of work and make that happen? So that's, that would be my recommendation. And just sort of, and I'm not trying to take you away from saying, like, we all have different approaches have a great impact applied in the right context. But this is really fundamentally about how you're a real human story. And also, what does it really mean to be a leader and be a humble leader and a humble learner? And in a way, that's not what I appreciated so much about and I continue to appreciate that Mr. Yoshino, he's almost 79, by the way, and we're actually talking later today at the time of this recording, as it he was willing to share not just the success stories, but the challenges and his personal failures, too. And I think that that's really important for us to realize, and to, you know, it's easy to look back and only see the successes, but to hear about people's challenges also validates our own challenges and our own struggle, and that the journey to success is paved with setbacks. And this is, you know, learning is inherent about having, you know, not getting things right, but what are you learning, and I'm obsessed with these dolls called Daruma dolls, I have this huge collection. And I give them out everywhere. In fact, you know, Rich Sheridan has a derma doll for me, in our shared mutual friend, and they represent the Japanese proverb fall down seven times get up eight. So when you have a goal, you fill in the dolls left eye, and it's like a little paper, well, they can be giant too. But it's a paper mache doll that's waited at the bottom. So it's like a weeble wobble and always write itself back up. And to me, this is this great sort of encompassing conte, like visualization of a goal, the reminder of the persistence and patience, we have to have an end, just a reminder to have the inherent struggle, and the setbacks that happened towards achieving the goal. But if we can keep learning, keep getting up and keep moving forward. We'll eventually get there, even if the outcome of our goal looks different than we thought at the beginning.Joe Krebs 32:44 It's also tangible, right? Because you see, and it makes the goal tangible, right? Yeah. To these. Here we go.Katie Anderson 32:57 You can really knock it down, and we'll keep getting back up. So keep going.Joe Krebs 33:01 Yeah, our listeners cannot see this. But that was a Daruma at all. And we can we can put a link into that.Katie Anderson 33:09 Yes, either. Exactly. I'm usually I'm often holding a Dermatol. So you'll see many. And actually I gave Larry Culp, the CEO of General Electric, a larger during muddle when we were on stage together. In October of 2022. We were he loved my book recommended it to all GE employees across the company, which was, you know, amazing. And then I had the opportunity to have a fireside chat in front of 1000 people at the Association for manufacturing excellence. And when we talked about this concept of struggle, and learning and also, you know, the things we have to unlearn as leaders to get there. So I gave him a daruma doll, because I'm sure he has. I know he has some big goals out there. But he said the same thing. He had to unlearn everything that he was trained in business school about what it meant to be a leader. Not maybe everything but we have to get out of do what I call break the telling habit get out of this mindset that we are supposed to have all the answers. We have a lot of good answers. But are they the right answers? And so anyway, it was really, it was really wonderful. And, and awesome to hear directly from Larry and have the chance to talk with him. And really see, you know, I put him like with Rich Sheridan, these leaders who are really embodying these concepts that we're trying to develop in organizations, about what it means to really be an effective leader and an inspirational one toJoe Krebs 34:35 I don't even want to ask you a question. It was such a wonderful, wonderful end you just close it out so nicely, that I don't even want to go and ask you another question. But this is this was really awesome. I want to I want to thank you for your time. We can we can tell from your schedule that you're very busy. I'm happy you spent some time here with the listeners on agile FM that are out there and say that was very interesting. I might be They might pick up book, I might visit your website that is KBJAnderson.com. And there is ways to find you speak ways to engage, ways to find a path to your book or anything like that. And I'm super thrilled you had time to share your story here a little bit with us your story, right? I think that is great.Katie Anderson 35:20 Thank you, Joe. Thanks for inviting me here. And I'd love to hear from your listeners about what's one takeaway that they had from this conversation. And definitely reach out to me on LinkedIn as well. If you're interested in how to break your telling habit, I also have a free downloadable guide on my websites that's KBJAnderson/telling-habit so you can go there. Alright, Thanks, Joe.Joe Krebs 35:48 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.

Summary KeywordsKata, Agile, organisation, teams, agile transformation, step, scrum, people, transformation, agility, building, leadership, goal, vision, tool, starting, experiment.Introduction Welcome to episode 117 of the Enterprise Excellence Podcast. It is such a pleasure to have Mr Joe Krebs on the show with us today. Joe is the founder of INCREMENTOR, an agile consultancy specialized in agile transformations using Scrum, Kanban, Lean and eXtreme Programming. Today we are exploring with Joe Agile Kata, a topic linking two areas of Excellence that Joe is renowned for.  We are proudly sponsored by S A Partners, a world-leading business transformation consultancy.Links Brad is proud to support many Australian businesses. You can find him on LinkedIn here. If you'd like to speak to him about how he can help your business, call him on 0402 448 445 or email bjeavons@iqi.com.au. Our website is www.bradjeavons.com.What's next?Join our membership page to access great resources that we and our guests have made available.Join our community! We would love to see you each month.  www.enterpriseexcellenceacademy.com.Have a look at Joe's white paper and video on Agile Kata: https://www.incrementor.com/agilekataSA Partners To learn more about what we do, visit www.enterpriseexcellenceacademy.com.Thanks for your time, and thanks for helping to create a better future.

This week we have a GREAT interview with Joe Krebs, the innovator behind the Agile Kata.  We review not only the theory but also the application of this easy-to-understand practice which you can use to supercharge your organization!  Enjoy! Agile Kata Website Order your Agile Kata Kit! If you enjoyed this episode, please give us a review, a rating, or leave comments on iTunes, Stitcher or your podcasting platform of choice. It really helps others find us.  Much thanks to the artist Krebs from Machine Man Records who provided us our outro music free-of-charge!  If you like what you heard, check out these links to find more music you might enjoy! If you'd like to join the discussion and share your stories,  please jump into the fray at our Discord Server! We at the Agile Uprising are committed to being totally free.  However, if you'd like to contribute and help us defray hosting and production costs we do have a Patreon.  Who knows, you might even get some surprises in the mail!  

Joe Krebs speaks with Joshua Kerievsky about the Joy of Agility and his upcoming book with the same title. Joshua is a veteran agile community member since the late 1990s and an advocate of eXtreme Programming since then. Joshua will deliver a keynote at the Agile 2022 in Nashville.

Joe Krebs speaks with Joe Justice reconnect about Agile at Tesla. Even though Joe Justice is a Certified Scrum Trainer with the Scrum Alliance he explains why “Scrum is too slow for Tesla” and shares what the electric car maker is doing differently. He also explains why Scrum is still fast for the majority of organizations but that mob programming and Open Space can have a positive impact in agile teams.

Joe Krebs speaks with Tracy Defoe about Kata and the Kata community in general . She explains what makes the Improvement and Coaching Kata (a.k.a. Toyota Kata) so interesting for any kind of improvement. She has actively coached software / IT teams at Volvo and Volkswagen in using Kata and can draw from a wealth of information. Her background however spans across many more industries. She is the organizer of Kata Geek Girls and the Kata School Cascadia, both communities that spread knowledge and experiences among Kata enthusiasts.

Joe Krebs speaks with Clare Sudbery about eXtreme Programming related topics, such as pairing, refactoring and continuous integration. We also talked about professionalism in software development and how quality, coding, design and knowledge sharing are all intertwined to make agile teams successful. Clare has a full stack experience, has always been involved in the complete development lifecycle, and has extensive DevOps experience.

Joe Krebs introduces the Scrummer Quiz 2021

Joe Krebs speaks through the lens of a manager with Johanna Rothman about micro-management, engagement, workspace, psychological safety, 1:1's and feedback loops for managers.Johanna is the author of the “Practical Ways…” books series.

Joe Krebs speaks with Mark Kilby about the experiences of distribution during the pandemic and what we have learned and can use for the future. Mark is the co-author of the book “From Chaos to Successful Distributed Agile Teams: Collaborate to Deliver” released in 2018. Mark also shares some insights on his next book with the working title “Exploring the Open Space Mindset” which will include stories and experiences from practitioners like him about the Open Space Technology.

Joe Krebs speaks with Chris Smith about what dynamic re-teaming did to performance, growth and the leadership team at his company. Chris is sharing real world experiences from the trenches.

Joe Krebs speaks with Christiaan Verwijs and Johannes Schartau about Zombie Scrum, how it can happen, and what can be done against it. We talk about the role of certification, liberating structures and the maturity of Scrum around the world.

Joe Krebs speaks with Jon Kern about quality the creation of software as well as adaptive organization and the future of agile in the business world. Jon is one of the 17 co-authors of the agile manifesto and we are using the 20th Anniversary to reflect on the creation and the time since then.

Joe Krebs speaks with Vasco Duarte about the lack of management support and why this role is so important for the future world of work and if the role “Scrum Master” is still appropriate or if it should be renamed.

Joe Krebs speaks with Heidi Helfand about Dynamic Re-teaming, team names, re-org's and the 5 patterns for adaptive org-design. Heidi was on the original development team that invented GoToMeeting and GoToWebinar and she wrote the book “Dynamic Re-teaming”.

Joe Krebs speaks with Arie Van Bennekum about the creation of the Agile Manifesto but also the time before and after the event on FEB 11-13, 2001 at the snowbird in Utah. Arie is one of the 17 authors of the Agile Manifesto, a pragmatist who accommodates his pragmatism in structure, discipline and common sense. He is not afraid to enter untrained paths and take risks. He has done this since his first days in health care, later in the armed forces, and he continues to do so today. This has led to his special position as co-author of the Agile Manifesto. In the course of his Agile years Arie has become an expert in the field of business transformations towards Agile on the basis of strategic objectives and link this to very concrete objectives. He focuses on delivering value, bringing efficiency and creating support among stakeholders, through role and chain clarity based on the business model and the work packages.

Joe Krebs speaks with Adam Braus about Nemawashi and innovation. Adam is a polymath professional and breakout expert in the fields of leadership, technology, and education. Adam Braus is the author of the book “Leading Change” where he introduces an organic, grass-roots, bottom-up change management that uses the power of a social network.

Joe Krebs speaks with Lee Henson about Scrum and the Scrum Community. Lee had a difficult childhood but he had the willpower to escape the spiral he was in. Years ago, just when he was about to start a 5-day PMP boot camp someone ate his breakfast off his plate and convinced him to join his training. His name: Ken Schwaber. Lee was intrigued and has been infected with empiricism ever since.

Joe Krebs speaks with Gil Broza about challenges non-software teams are facing when they are interested in increasing their agility. We talk about boards, stories, automated testing, an agile mindset, and the role of a product owner. Gil helps organizations increase their agility and team performance with minimal risk and thrashing. Close to 100 companies seeking Agile transformations, makeovers, or improvements have relied on his pragmatic, modern, and respectful support for customizing Agile in their contexts. He is the author of three acclaimed books, “The Agile Mind-Set”, “The Human Side of Agile”, and most recently “Agile for Non-Software Teams”.

Joe Krebs speaks with Dr.Jill Greenbaum about the Bikablo technique and the various use cases for more visual support for agile coaches. She shares tools and techniques and how visual content can be produced on paper or digital. Jill helps leaders across the globe to create responsive environments in corporate, government, nonprofit, and educational settings, by accessing the strengths of their communication styles. She utilizes her expertise in instructional design, training, facilitation, and coaching to deliver stellar offerings that transform participants, their relationships, and their work. She leverages her strengths as a graphic facilitator to support clients in gaining greater clarity, perspective, and depth, about the issues and challenges they are facing, enabling accelerated, richer, and long-lasting results.

Joe Krebs speaks with Daniel Vacanti about the Scrum and Kanban communities and the importance of predictability and what this means in terms of empirical process control. Back in 2007, he helped to develop the Kanban method for knowledge work. He is the author of “When Will It Be Done?” and “Actionable Agile Metrics for Predictability”.

Joe Krebs introduces the Scrummer Quiz 2020

Joe Krebs speaks with Richard Kasperowski about virtual Open Space and how to adjust this liberating structure to make it work in a remote environment.

Joe Krebs speaks with Lauri Apple about agile program management. We talked about the need for a role that is the glue between the teams, within the team and leadership. The glue that keeps things going also from on a personal level. She relates the role to Zombie Scrum, robotic behavior and execution of specific Scrum elements. You will hear Lauri talk about how to cut through the zombie scrum problem, how the program manager deals with metrics and most importantly can drive value. Program management does not have to be conflict with Scrum Mastery, but she sees value in both. Hear topics like culture, agile coaches with technical expertise, bugs, metrics and we close it out with a conversation about Open Source.

Joe Krebs speaks with Joe Justice about the differences between agile in hardware and software and how car manufacturers take advantage of agile processes to their competitive advantage. Joe is dedicated to change the world how cars and living spaces are being built. He is the author of the Scrum in Hardware Guide and offers engineers to use an agile mindset to build the products of the future.

Joe Krebs speaks with Jim Benson about Personal Kanban and Lean Coffee, things Jim created which we use in the agile community on a daily basis. We talk about the importance of collaboration in Personal Kanban and how much of an impact multi-tasking, silo conversation as well professionalism has on the quality of work.

Joe Krebs speaks with Evan Leybourn about the characteristics of business agility versus agile in business and the challenges organizations face aiming for more business agility. He is the founder of the research group and member based organization called “Business Agility Institute” and the organizer of the business agility conference. which shares insights from the research with their members.

Joe Krebs speaks with Rick Dove,who led a government project in 1991 to explore improvements to manufacturing processes at that time. The word "agile" was chosen which influenced the creators of the Agile Manifesto a decade later. Rick published two books “Response Ability” and “Value Proposition” and hundreds of articles that relate to agile. Rick is an early influencer of Agile System Engineering, Business Agility and of course the early days of Agile.

Joe Krebs speaks with Cristina DiGiacomo who wrote “Wise Up! At Work” and created Industrial Philosophy. She describes how philosophy can help agile leaders, coaches and teams in their day to day work. She gave an example through the parable “The Quarrel between the pond the river” which is listed below. Hear how Immanuel Kant fits into agile processes, leadership and coaching.

Joe Krebs speaks with Juriaan Kamer about “Formula X”, a business fable for organizations that strive for more agility. He introduces FASTER an acronym for a list of areas for improvement.