Agile.FM

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 understan

Book “Uncertain - The Wisdom and Wonder of Being Unsure”: Transcript: Agile FM radio for the agile community. [00:00:05] Joe Krebs: Thank you for tuning into another episode of Agile FM. Today I have Maggie Jackson with me. She wrote a book called Uncertain the Wisdom and Wonder of Being Unsure. She also has published a book Distracted you might be very familiar with because it has been published a few years ago. Maggie is an award winning author, journalist.She writes about social events. In particular about technology. She's a contributor to the Boston Globe. She wrote for the New York Times, the Wall Street Journal, and she has been featured on media around the world, including MSNBC, Wire. com, and the Sunday Times. And now she is on Agile FM. So thank you so much for being here and sharing some thoughts on the latest release, Uncertain, with the Agile FM listeners.[00:00:54] Maggie Jackson: My pleasure. Great to be with you. [00:00:56] Joe Krebs: Yeah, that's awesome. You have some really good endorsements and praise here from people like Daniel Pink, Gretchen Rubin and Sherry Turkle on your book. This is it's really amazing. You you have written this book. This was recently released in 2024. So this is a new publication.What drove you to writing this book? Uncertain. What was your motivation of approaching this project, this book? [00:01:24] Maggie Jackson: Yes, sure. Especially because uncertainty seems so foggy and monolithic and negative. And I, after I wrote the book Distracted, which is about, the gains and costs that we have in a split focus world wanting to write a book about thinking, so if you have a moment somewhere, focus, or you have the skill to focus, what do you do with it?And of course, thinking well is our challenge as we move forward in this world, in this day and age. And so the first chapter of the new book was about uncertainty, and it became in a classic way, the whole book, because first of all, because I discovered, veins of or explosions of new research in so many different fields from medicine to business to psychology, a lot of new research about uncertainty.And it hadn't been a very well studied topic, believe it or not before. And by that, Epistemic or psychological uncertainty, which is the human response to the unknown. So I'm really writing about our human response to the unknown and the basically the idea that when you meet something new and unexpected, Your response is to understand that you've reached the limits of your knowledge that you don't know that it could be this way.It could be that way. So that's how I fell into writing the book and I discovered as well that uncertainty is highly misunderstood. It's maligned and yet it's far. It's not weakness. It's not inertia. It's not the negative that we all assume it to be today in this efficiency oriented society.[00:03:03] Joe Krebs: Yeah that's true. We probably have some listeners here at Agile FM that are maybe in the corporate world and they are building products and or executing projects of some sort. And and we see the desire of being certain. We see the desire of running and having a plan, even if the plan is very short and maybe only a few weeks long.Uncertainty is always present, isn't it? [00:03:29] Maggie Jackson: Exactly. And again there are these two kinds of uncertainty. There will always be unpredictability there. Life will always take twists and turns. And we might have the data and the models and the plan. And yet, there's so much we can't know.Despite this incredible probabilistic weather models that we have, you don't know if the snowstorm will dump one or two inches on your backyard next week. So there's so much we can't know. We don't know, but what we can do is control our response to the unknown. We can get skillful at understanding how to manage not knowing or what we don't know and what we want, what we're not sure about.And that's where the, that's where the news is fantastic. There's so much now that relates to how uncertainty basically is very highly connected to. Cognitive skills like curiosity and agility and resilience, which are exactly the kind of cognitive skills we need now on. So I think you're right.And another point I'd make is that we always will need resolution. We always know we'll need an answer. And of course, we want a plan and a kind of security. And yet. By, over predicting or clinging to a plan when it's out of date. That's where we lose the agility. So what I'm talking about is opening up the space between question and answer.Uncertainty is really that middle ground. It's basically. The brain's way of telling itself that there's something to be learned here when you're meeting something new, you have a kind of stress response, which is really, that's where the unease and the discomfort of uncertainty comes from. It's a stress response.But now we're beginning to find out scientifically that unease is actually highly beneficial because, as I mentioned, the brain is, more receptive to new data when you're unsure. Your working memory actually improves when you're don't know when you meet something new and your focus expands.Scientists call this curious eyes. So this is the human response to the unknown. That's really the good stress and wakefulness of uncertainty. And in fact, one study, which I really found very illuminating. is a longitudinal study of executives in Europe. This was around 2009, when the European Union was doubling in size, basically, the markets were expanding, it was the opposite of Brexit, basically, but very controversial.And executives were, really had many different reactions to this proposed change. Two business school professors interviewed 100 CEOs in Europe at the time, and quite a number of them were quite sure of what was going to happen, they airtight kind of predictions. It'll be good for my company.Many said. Oh, it'll be terrible for my company, this new market explosion. But then actually the business school professors were surprised that there was a third group in the mix. They were actually surprised that there were ambivalent CEOs. And a year later, after the expansion, it occurred. Low and behold, it was the ambivalent CEOs who had actually were more resourceful, inventive, and inclusive.They listened to multiple perspectives, and they actually went out and did innovative things, whereas the sure CEOs tended to do, stick to the status quo and basically almost do nothing at all. And that tells you so much about what unsureness does. It opens up the space of possibilities. Very important.[00:07:19] Joe Krebs: Very important. You just mentioned in these stress moments, right? Positive kind of things are happening. How did you, did your research, did you find anything interesting about. Creativity, innovation in the, in those moments of stress, I would be curious because there's focus, right?And, but maybe there's also innovation coming out of those moments of Uncertainty. [00:07:42] Maggie Jackson: Yes. I think that the the uncertainty mindset the good stress of uncertainty first of all helps us attune to our environment. So many studies about learning in dynamic environments find that the people who have this positive.response and positive attitude toward the unknown are the ones that are more accurate, better performers. So it's really helping you pick up on what's going on. If you walk into a meeting thinking, ah, more of the same, blah, blah, blah, then you're not, you, it makes sense. You're not going to be picking up on the mood in the room or in seeing the facial expression.So I think this good stress of uncertainty, Does help us be attuned to what's to the change. And that's the starting point. But as I mentioned, the CEOs in this in the European market expansion, we're highly resourceful. So how does this agility or this uncertainty, this good stress of uncertainty help us be creative?There are many different ways in which first of all, in order to be creative, We have to set step away from the known. So very often the human loves the familiar and the routine. And we actually operate in life using something called predictive processing, which is using your mental models and the heuristics that you've built up based on your experience in the past to expect and assume, the doctor hears chest pains and then thinks heart attacks or, a certain kind of client will evoke an assumption or expectation when they walk into the meeting about what their demands are going to be. We expect so much, but we operate so much into the routine That it's really important that we break from this routine in order to be creative.That's what innovation is. It's working at the edge. And so that's also what uncertainty helps you do. It makes, it helps you. Studies of divergent thinkers are highly creative with idea generation. Show that they have a kind of cognitive flexibility that they're more able to remain, make unusual connections in their life.These are the type of people who are, again, more able to operate within the space of uncertainty. And in fact, divergent thinking is actually highly related. It's based on the same brain networks as daydreaming which is a form of, daydreams. What if questionings that they actually remove us from the here and now and they allow us to operate in what one scientist called transcendent thinking mode.That's basically just asking what if questions and daydreams are actually 50 percent of daydreams are future oriented. So I'd say one of the ways in which we can Manage uncertainty. Is to step back from that need to be productive in a very narrow way and allow ourselves time to muse just for a minute or two.I interviewed one phenomenal genius scientist who's He's extremely innovative. A MacArthur winner. He's, he's been done. He's, he just, his laboratory just found the first new antibiotic in 35 years. He's, and he spends at least an hour a day daydreaming and it a coherent thought experiment.But this is not what we. us

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 work

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

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

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 again for tuning into another episode of Agile FM. This is the Agile Kata series. And today we're going to explore Kata from a leadership's perspective. And I have here with me Mark Rosenthal who is with Novayama that is his company. He's out of the West coast, United States, and we're going to explore a little bit together, leadership in conjunction with Kata, which is Series all about.We're gonna explore that angle a little bit. Welcome to the show, mark. [00:00:40] Mark Rosenthal: Thank you very much. It's looking forward to the opportunity. [00:00:43] Joe Krebs: Yeah, this is awesome. I wanna go back in time with you and talk a little bit about an employment you had where you worked from home. [00:00:52] Mark Rosenthal: Oh, yeah. . [00:00:53] Joe Krebs: You didn't get a lot of phone calls until you got one.[00:00:56] Mark Rosenthal: Yeah. [00:00:57] Joe Krebs: And that was the one you got terminated. [00:01:00] Mark Rosenthal: Yeah. Bu Yeah. [00:01:01] Joe Krebs: But the interesting thing is you in your reflection, you had a, let's say a moment of realizing a lack of leadership skills. [00:01:14] Mark Rosenthal: Yes. And yeah, and really that was, and this is even better because this is really the kind of leadership that most conduct practitioners have to engage in, which is influence.You don't have formal authority you rather, you've got to, you have to find a way to influence the lead, the line leaders in the organization to be effective. And this is true for lots of cases. It's true whenever I'm bringing groups of people together that I can't tell what to do. And actually it's more true that you think even in the military, which is where I learned leadership.And it really was that. We tend to do, we practitioners tend to engage with the technical artifacts, and we put in the tools, we put in the mechanics, and we don't, and then we complain when the line leadership doesn't embrace the changes. And that is on us because if you look at a traditional Kaizen event approach, for example, in the world of, you know, of CI, but this would be equally true for somebody trying to get scrum in place or somebody trying to cause any change in the way the organization does business.I can describe the mechanics of the daily standup perfectly. I can describe, I can get all the scheduling. I can get the artifacts into place.If there isn't a engagement of the conversation about how we do it on a daily basis too, then it's going to fall apart as soon as that that, that goes away in the situation you're describing. I mean, it was even worse in a way, just because of the nature. It was an international organization and it didn't really matter where I worked, so I didn't work anywhere.Although I got a lot of frequent flyer miles. You know, going to Europe once a month, going all kinds of places. But what I was doing was making technical recommendations. And then, you know, they weren't getting picked up. And frankly, I wasn't earning my money. Yeah. And the key here for a change agent.Is it's not about the tools you're putting into place, the tools are there to create the kinds of conversations that need to happen in the organization between the leaders and between people, between groups of people. And once I understood that, then the paradigm changes completely because the experiments I run are testing whether or not I'm effective at moving the needle.About how these conversations are taking place. And that's kind of what I was talking about in the, you know, in the story that you're alluding to. [00:04:20] Joe Krebs: Yeah. So this is a life changing event for you, but also in your career, right? You had a lot of learnings coming out of this. [00:04:27] Mark Rosenthal: A lot of them, and they came later on.You know, I had, I was familiar with Toyota Kata at the time. But I was still in the position of trying to make people do it, and I can't do that. What I have to do is look at the dynamics in the organization and think in terms of it's not the mechanics of standing up a storyboard and getting them to go through the starter kata of grasping the current condition and all of that.It's about what actions what small experiment can I run? That I think that I hypothesize will nudge the conversation into, for example, talking about something a little more concrete than we had a good day or a bad day, which moves them toward measuring how they're doing, you know, in that example, that particular organization really had disdain for numbers because they made people look bad.So they didn't talk about them. I mean, they had them on displays, but nobody ever talked about them and the numbers they had on displays were lagging indicators. Yeah. It's interesting because you said like the words, if I remember correctly, like you said, like moving the needle, and I think that's also important from a leadership perspective, are we just in the operations mode of tools and features and keeping those alive or are we disrupting them?Yeah. Absolutely. Certain ways of working within the organization as a leader. Yeah, and you're going to be disrupting, you know, that's the whole point in a way. So when I want to begin to shift things I want to do is engage in the smallest change I can that's going to move things. And I'm going to try to do is to incorporate that change into something they're already doing.So in this example, there was already a daily production meeting. So rather than saying, we're going to have another meeting about improvement, rather than saying, you got to stop doing that way and start doing it this way, I can hook part of my agenda into the existing structure. So as a change agent, I want to look at what are they already doing?And can I grab any of that and just modify it in a way? That moves the conversation in the direction it needs to go. [00:06:58] Joe Krebs: Yeah, This is interesting, right? There's two things I would like to talk about, and I'm not sure which one should be first or not. I'll just take one and get started.Maybe it's the wrong order, but. We just went through a, or just two years ago, we somewhat ended the pandemic and we started going back to work. And your experience obviously from work from home was prior to to the pandemic. Now you had some learnings in terms of leadership and we see a lot of companies that are bringing the people back to work sometimes mandatory.And sometimes it's the leadership team that just feels like very strongly about that. So I want to just include that in terms of, it's very impressive right now. There's a lot of companies still work in that kind of dual mode or came back full time back on premises. What advice do you have based on your learning for leaders when you work this way?I don't know if you'd have any, but I'll just put you on the spot.[00:07:58] Mark Rosenthal: You know, that's a good one. You know, you're going to encounter resistance, but you know, this is a quote from Ron Heifetz out of Harvard, who Talks about this thing called adaptive leadership, which really is applying PDCA to leadership. And that's why I like it so much, because it follows the Kata pattern of grasp the current condition, make a, you know, make a judgment where you want to go next and run experiments to try to get there.And he said, and I love this, people don't resist change. People resist loss. Nobody gives back a winning lottery ticket. And so the people who are. are used to working with the cat on their lap and having be able to respond to their kids and all the awesome things that come from the ability to work from home are losing that connection that they have developed with their family.So that's what they're resisting. Typically, you know, I can't speak for everybody, but what's, you know, the flip side is what's the boss, what did the company lose when the people didn't come to the office? And that was the informal interaction that drives the actual conversation that gets stuff done.Yeah. And so that's what I didn't have, right? You know, we didn't have, I don't even think we didn't have video. We didn't, you know, I mean, this was a while ago. I think, you know, Skype was cutting edge stuff, right? [00:09:31] Joe Krebs: Hard to imagine, right? [00:09:32] Mark Rosenthal: Yeah yeah. You know, if I were to go back to the same situation, I would be having a lot more scheduled online sessions.With not just individuals, but with groups of people sharing their experiences with, in my case, with continuous improvement and what they're doing so that I didn't need to be there all the time, but I could work on keeping the conversation and the buzz going and get a better read for the organization.[00:10:09] Joe Krebs: Yeah. You mentioned that I've heard you say things like that leadership is a typical leadership. Yeah. What is authority. And then sometimes you do see that when you go back to, to work in, you know, in work environments where you're being asked and forced to come back to work versus adaptive leaderships, taking a different approach to something like that.But another quote you said, and maybe that's the other angle I wanted to ask you. . Is I heard you say a phrase that leadership is an activity, not a role. [00:10:40] Mark Rosenthal: And that's again, I want to make credit where credit is due. That's right out of, you know, Ron Heifetz work and a lot of it is taught at a place called the Kansas Leadership Center in Wichita.And so I want to make sure I'm giving credit where credit is due. . So in, there are, you know, there are cases where authority is a good thing. There are cases where you have to get something done fast. The building is on fire, evacuate immediately, not, hey, what do you think we should do?But even when there is formal authority, it's far more eff

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 in the Agile Kata Series here. Today I have two authors. I have an author on the call and I have a character. I have two characters from a book and a comic illustration, which is called Engaging the Team at Zingerman's Mail Order. That is Betty Gratopp and Jeffrey Liker.Thank you for joining me here today. [00:00:34] Betty Gratopp: Thank you for having me. [00:00:37] Joe Krebs: All right. So this is a book, the it's a comic. And this book was published in 2023. And it's really a book that illustrates the journey from, in, in terms of Kata up at Zingerman's mail order. And before we talk a little bit about the lean journey, What is Zingerman?Zingerman, I have visited Zingerman in Ann Arbor myself. It's a mail order business of a a company that is shipping the most wonderful cheeses and breads. I can smell it in the in the warehouse. And but there's much, much more to it. Betty, what is the size? What's the scope of Zingerman's?What do listeners have to picture? Not familiar necessarily with the service? What do you guys do and how big is the operation? [00:01:20] Betty Gratopp: Oh, excellent. That's a great question. We are a warehouse and a call center. The warehouse employs approximately 55 people year round, and then we grow to a peak of about 400.Warehouse staff people during our Christmas holiday at the service center. I would say is about 20,25 people and they have, they experienced the same growth during that peak season. [00:01:45] Joe Krebs: Yeah, excellent. In the comic, you are a warehouse manager. [00:01:49] Betty Gratopp: Yes, I am one of three warehouse managers that manage the warehouse and have been the three warehouse managers that have taken us through our lean journey and our transformation to trying to be better scientific thinkers.[00:02:05] Joe Krebs: And as a character, you were visualized by the illustrator, Jasmine Morales, who is visualized this entire comic, the book, and she did a really good job knowing you obviously listeners cannot see you right now, but this picture is really nice. So is. Jeffrey as a character also drawn in the in the comic [00:02:24] Jeffrey Liker: and Skinnier and better looking in the comic.[00:02:28] Joe Krebs: And Jeffrey, I do have to mention the other two authors on the book. That's Eduardo Lander and Tom Root, which are not on the podcast today. But we are talking about this book, the three of us. More importantly than the book itself, obviously describes a story that describes a bumpy story of introducing lean and Kata within a Zingermanwhen did your journey start? What was the situation like that led to it? And obviously the origin of the book, that's where everything started, basically. [00:03:03] Betty Gratopp: Yes. I think back to 2003 when our business was growing in double digits. So we were a bunch of. Intended foodies who started this business and then had to get better at process because we weren't doing very well.We were not schooled or learned in anything that had to do with process. That was the environment. So we didn't know how many people to hire. We didn't know how much space we needed. We didn't know how many sales we could take. Really basic things about our business were not clear to us. [00:03:40] Joe Krebs: Sounds like a startup kind of environment.Like everybody who has worked or seen startups, it sounds very typical. Doesn't it? [00:03:47] Betty Gratopp: Oh yeah. Everybody did everything. Yeah. [00:03:51] Joe Krebs: Yeah. And you guys had some form of a warehouse. Is it the same warehouse as it is, or did you guys relocate it over the years? Was there also like growth or. [00:04:00] Betty Gratopp: One of the major motivations to moving to a more, more scientific thinking and lean lean process was the fact that we were moving our operation every two years.So I was hired in 97. I think we moved twice in four years. And then that fifth year or so is about when we started to think about, we had to find a different way. It was too costly. Ten months of the year, our building was way too large for what we needed it to be. Two months of the year, it was way too small for what we wanted it to be.And so we had to make a commitment to stay in the building that we were, and we had to figure out how that was going to happen. At that time. My boss, one of the managing partners here was going to the University of Michigan and met a gentleman who you already mentioned, Eduardo Landers, one of the authors of the book, and they were going to U of M together, and that's how that connection was made.I don't remember actually whether we met Jeff first or Eduardo. [00:04:57] Jeffrey Liker: I don't remember either, but I did get contacted by Tom Root, and he explained that there were Kept on growing out of their quarters and they understood that lean would help you save space and use space more efficiently. And he said, you know, do you think that it might help us in our journey?And at the same time, Eduardo was my doctoral student and he was trying to define a dissertation topic. And his interest was in lean and a high variability business, but he couldn't find any that. I had implemented lean as a case study. So this came along and I said Eduardo Maybe you're not gonna be able to find a case study to study and maybe you're gonna have to create your own and become like a consultant and advisor to Zingerman's mail order.And that's what ended up happening. It was just kind of a coincidence marriage his need and their need. And I was watching the whole thing unfold. And when he first came, and I visited the warehouse and he visited, it was clear to both of us that we talk in the Toyota production system about the seven wastes.And there was seven ways every place you looked, it was just a complete disaster from our point of view. So in other words, it would be a target rich environment for improvement. You could practically, you could probably throw a lean tool any place and. something. But his, he had been, I've been teaching them that in the Toyota Way of leading, which is asking questions and guiding them step by step, taking the whole enchilada, the whole big problem and boiling it down to small pieces.And then starting with a first step and then guiding them and getting them to do the thinking and the work. And that's the approach he took, which turns out to be very consistent with Kata. We didn't know about Kata at the time, but it was very consistent with that approach. , [00:06:54] Joe Krebs: I just want to go back to that quick is I think this is an important comment you just made is the initial approach was more focused on lean rather than Kata because it was quite a while ago, like, when did this all start? [00:07:07] Jeffrey Liker: 2003 so 2003 he walked through and then he started going there like several times every week.And again, what he did was what he could have done is he could have said, here's the Toyota production system. I'm going to lecture you about standard work. I'm going to lecture about Kanban. I'm going to lecture. He didn't do any of that. He just went with them to the floor and say, what's your biggest problem.Let's start there. And then he would ask questions and, you know, example, why do you have to build up a whole, why do you have to build all your gift boxes overnight? So that they're ready when the shift starts. Why can't you build them as the customers are ordering them? And they said things like, because this is a Star Trek and we can't just beam stuff to where we want to instantly.[00:07:57] Betty Gratopp: I think my exact words were, because we're going to fail. [00:08:01] Jeffrey Liker: Yeah, exactly. So they didn't believe, you know, what he was suggesting was possible. So he would say, I understand. Is there something we can try right now? And they would say I guess, you know, and then pretty soon they were generating ideas instead of pushing back and they were trying it.And then they also found their own analogies, like in the book, the original book, lean and high variability of business. We have a case where one of the, one of Betty's colleagues said, I guess it's kind of like subway. Where they make the sandwiches to order, but they have a certain number of sandwiches in a case in a cooled case that you could pull off the shelf and maybe we could develop both kinds of situations.And so that's the way it got started. Again, there was no lectures about except for very brief introductions. There was not. Here's 15 tools. I'll teach you all the tools go apply them. It was here's a problem. Let's test some ideas and let's do it right now. And then what do we learn from this?And then most of the ideas came from the group, like Betty, not from Eduardo. Is that true? Betty. [00:09:16] Betty Gratopp: Yeah, what I remember when he was first teaching us, he was very he didn't give us a whole lot of, he didn't give us a whole set of tools at one time. The first thing we learned was pull, the second thing we learned was kanban, the third thing we learned was timed routes, because now you have kanban, so it's At the time, I had no idea that these skills or tools were layered and connected and making a whole system.Had he come at us with all of that. I mean, even just coming with us with one thing and saying, Hey, we're going to make gift boxes just in time. What do you guys think? That was enough to make our brains explode and us want to stick our feet in the mud. But once we got over that, once we tried it, once we said, yes, we'll at least give it a shot and we saw the value of that, that set the stage for the rest of our growth because we had a problem that we thought we couldn't do.We learned that we could do it, we did it, and it made us stronger for the next problem that

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 coachin

Joe has a book “Agile Kata” in the making, if you like to be the first to know when it launches, please visit www.agilekatabook.com.Transcript: Agile F M radio for the agile community. [00:00:05] Joe Krebs: Thank you for tuning into another episode of Agile FM. Today, I have Dr. Jeffrey Liker with me. You probably know from a, I would say, famous book with the title The Toyota Way. That is a book we want to talk about today a little bit, but there's so much, much more about Jeff, he is a professor of industrial and operations engineering at the University of Michigan.He's president of Liker Lean Advisors, and as I said, he wrote not only the Toyota Way, but he also wrote, if I did the count right, nine other books. That relate to Toyota, and there are two books that more recently were published and we'll have a chance in a different episode to talk about those.One was in June, 2023, Giving Wings to her team with Tilo Schwartz, and we have Engaging the Team at Zingerman's Mail Order and that's more like a comic if you want to see it this way, and he co authored that with Eduardo Lander and Tim Root, so that is the The list of books if I haven't missed anything, but we want to talk a little bit about the Toyota way before we do that.Welcome to the show though, Jeff. [00:01:13] Jeffrey Liker: Thank you. Joe. [00:01:16] Joe Krebs: Awesome. So the Toyota way initially released, I believe 2000, somewhere three, two, somewhere that this book we're talking about is the Toyota way. Second edition. This is also very important. We're talking about the second edition of which, which was released somewhere in the year 2021. Timeframe. [00:01:34] Jeffrey Liker: Yes. Three, about two years old. [00:01:36] Joe Krebs: Yeah. And but there is something that happened in that book that is fundamentally different in, in terms of I, I don't know all the change log and everything, but there's one fundamental change, and that is the inclusion of scientific thinking.[00:01:52] Jeffrey Liker: Right, right. A little over five years ago, Mike Rother than I jointly gave a presentation and the book hit my book Toyota Way was 20 years old. So the 20 year anniversary, and his book to Toyota Kata was, I believe, 10 years old, and. We started talking about the relationship between the two.Mike was one of my students and he had practiced lean transformation for many years and was very familiar with the Toyota way and all the concepts of Toyota and studied Toyota. And then he came up with this thing called Toyota Kata. And I had to kind of struggle to sort of figure out what it was and what he was trying to add to what we know about Toyota.And. What he really did was to reverse engineer what Toyota, we call him Toyota Sensei. Sensei is like a master teacher. So what the Toyota Sensei, who are experts on the Toyota production system, do when they work with a new client outside of Toyota, how do they teach it? And they always teach by doing.And he had a chance to see a lot of companies that these different Toyota masters worked with and their masterpieces. And. Asked the question, What do they have in common? And they're all very successful, like they almost won't even bother working on a project unless they can at least double productivity.And that just happens almost automatically. And so he knew that they got great results. But the question is, what are they doing. And in fact, each of these masters. It has a bit of an ego, and they think that they're doing it the right way and the best way, and nobody else can do it that way, the way they do, but he found an underlying pattern, which he called scientific thinking, and what he noticed is the first thing they do is they grasp, they call it grasp the situation in Toyota, they go in, they see what's going on, they talk to the top leaders, and they ask, what is it that they're trying to accomplish?What is their goal? What is their purpose? What are their goals? Why do they want to learn about lean management? What is their vision for what happened? If they were successful, then they go to the Gemba where the activity is, and it could be a factory that they work. They've worked with where they gave you injections for COVID 19.They've worked with where they made ventilators for COVID 19. They've worked with software houses where they develop software. They don't really care when they will go to the Gemba and they'll see the process and understand the current conditions. So then they'll go back, they'll grasp the situation generally, and then they'll go back and they'll say, here's where you're at.Here's the challenge for you. Yeah. And the challenge is always big, you know, like we will double productivity or we will reduce costs by 30 percent or something pretty big based on the needs of the company may have runaway late deliveries and there's paying a ton for a premium freight.And we'll say we will eliminate all shipping and then they will go back to the Gemba with a team of people from the company. And they will teach them how to see, how to understand the process as it is. And Mike calls this the current condition. And then the people in the company will basically wait and expect answers, solutions from the masters.So what do we do? And the masters will say, that's my question to you. What are you going to do? You see where you are, you see where you want to be. You see all sorts of opportunities. What do you think you should be working on first? And then based on what they say the students say, they they may ask them to go back and look some more.Or they may say, why don't we try it? Usually what these people come in the company, come up with, because it's a big challenge, they come up with a fairly big thing and they, it might be, for example, in a manufacturing facility, moving equipment around and laying it out as a cell and They said a personal last one.Can you do this? And they'll say something like, well, we have to talk to engineering and we have to make sure customers okay with this. We have to line up the maintenance people move the equipment. So, I think we really stretch it. Maybe we could do it in a week. And then the trade master will say, good, I'll be back tomorrow and that like starts the process. Now, of course they can't do it in a day what they might have to do it. They can't get all the approvals. So what the person is trying to get them to do is. You don't have to do a hundred percent in one step. Let's try something that's doable and then see what happens.And then we can learn from it. And then we can think about based on that, what our next step is. Usually what happens is the, like, for example, if they lay out a cell. It'll be a disaster. You'll move the equipment together and they'll realize that the equipment has maintenance issues and it's breaking down and everything stops because they don't have inventory anymore.And usually they can't, they barely make product and the you know, the mentors say, that's okay. Let's start working on the problems down now that we see what the problems are. You were hiding them before. Now let's start working on the problems one by one. So Mike saw that, and he saw it enough times, that he realized that what the, these Master thinkers were doing.We're not teaching tools and methods like most of the Westerners were doing with lean. They were teaching a way of thinking. Yeah. And it was actually very scientific. What's your goal? What's your current condition? Right. You know, fairly precisely with measurements and direct observation. And then let's not try to in one step get to the challenge.Let's break down the problem. And all we really need to understand is our first step. And then after that, our second step, our third step, and each of these steps were structured like experiments. They might ask them, what do you think will happen if we make the cell? And then, you know, the people will say, Oh, well, our productivity will go up or quality will go up.Let's see what happens. Yeah. It's a disaster. Yeah. So what did we learn from that? We learned that we have a lot of problems that we've been hiding. And now we can see the problems we have to solve them. So, and also they're trying to teach the value of running the experiment, learning from it, which then gives you the next step and gives you the next step.So that became the basis for what. Mike call Toyota kata. The other part of it was in the meantime, he was studying about neuroscience and cognitive psychology and how we learn and there's a lot of literature that suggests that none of us are natural scientific thinkers, right? We're driven more by biases and the desire to know things, whether we do or not.So we want a lot of certainty. And we want to be right. We're going to, in fact, fudge the data to make it appear that we're right. That's called confirmation bias, which is really strong in humans. So he realized that to change people, to start to think and act scientifically requires fundamental behavior change.That's right. Yeah. It means changing our habits. And then he asked the question, how do you change habits? And the literature on, on, on cognitive psychology and neuroscience, as well as Practical experience, for example, with coaching sports teams, it all says the same thing, which we have to practice repeatedly with feedback.And it's very common enough times it becomes a new habit. So then he said, asked, how do you, how can we practice scientific thinking? And he said, first, we need a model, which we have, which is challenge current condition, first short term target condition, then experiment, then second target condition and experiment.Then third target condition and experiment. And. Then he said, how can we teach this? And each of those steps has some associated ways of thinking and tools and think practice routines, things to practice. So he laid that out in what he calls the Toyota Kata practice guide, which is pictures and step by step instruction, like, Like a

Joe has a book “Agile Kata” in the making, if you like to be the first to know when it launches, please visit www.agilekatabook.com.Transcript: Agile.FM radio for the agile community. [00:00:05] Joe Krebs: Hi everyone, I'm back with another episode in the Agile Kata series. We're going to explore the topic of cultural and learning and how that relates to color and scientific thinking. And today I have Katie Anderson with me, who wrote the book, learning to lead, leading to learn lessons from Toyota leader Isao Yoshino on a lifetime of continuous learning.And there's a lot of words in it that are relating straight with Kata. Katie, you have been on this podcast before we talked more in depth about the book. This is a little bit more in depth about Kata and how it relates to your book that doesn't mention the word Kata, but there are so many connections and synergies.We got to explore that area a little bit, but first and foremost, welcome. [00:00:53] Katie Anderson: Thanks, Joe. It's great to be back and dive into this conversation with you. I'm so passionate about how, as individuals, leaders, we create learning in our organizations and the patterns and routines about how we do problem solving and coach for problem solving is just so fundamental to that.[00:01:09] Joe Krebs: Absolutely. Now, I have to admit, I listened to your book recently the audio version of it. And in the, so I was listening and in all aspects of life, but then it all came together in the last chapter when you summarized the learnings from the book and summarized, and the word kata wasn't mentioned in the book.But it just screamed cut up everywhere. And I was like, I have to have Katie on the show again, and we need to talk about this because it is about continuous learning. It is about failure. It is about what is it failing or falling seven times and getting up eight times. Why? And things like that.So all of those characteristics you're mentioning in the book are important. Did Isao ever mention the word cut out in your conversations? [00:01:52] Katie Anderson: So no, and actually when Mike Rother's book came out and, it was a little before I met Mr. Yoshino, but we as caught the term Toyota Kata and the word Kata, actually means something in Japanese.It's the routines and practices that, support something usually used in martial arts. And the way Mike Rother used it was around how do we create learn habits of learning the patterns that we go through for problem solving and coaching for problem solving. And in the English language, that's now become ubiquitous with, with Kata means that around problem solving.Mr. Yoshino though, there isn't something called Toyota Kata it's what Mike Rother and other researchers, when they went to Toyota to observe what was happening, trying to undercover that, uncover that secret sauce. They, he observed this pattern of how leaders and managers were showing up.To help people go through a problem solving process. And he said, there is this unspoken or undocumented routine that people are doing. And if you read my book, you will see from Mr. Yoshino's 40 years at working at Toyota. So we cover from the late sixties to the early two thousands, all of his experiences about, how to learn how to problem solve and then how to coach other people through problem solving. Go through this same format. How are you asking really effective questions? How are you guiding people through a learning process and not coming up with the answers? How are you setting the direction, providing the support, and then also continuing to develop yourself as a coach and a leader as well?So the reason I didn't use the word Kata or Toyota Kata in the book was because it didn't exist at the time. There wasn't that label that we now have at the time that Mr. Yoshino was in Japan, or at Toyota. [00:03:35] Joe Krebs: And the book itself was called Toyota Kata because of publishing, not necessarily something that is Like a tool that was developed from [00:03:43] Katie Anderson: no, absolutely.So I take people to Japan on my executive Japan study trips and I'll have people in the past. I've had different participants say, are we going to see Toyota boards up at Toyota? I'm like, no, you won't because this was a framework that was developed to help us outside of Toyota. To learn the pattern to practice the kata, the routines that support this.And so then there, there are a variety of tools that can help us do that, but they don't, that's not what exists at Toyota, but that pattern of the mindset and the behaviors exist, but there, Toyota leaders are not walking around with the five question card and going through this. That's a tool to help us learn that pattern that is inherent.I opened the book, you'll remember this Joe of a quote from Mr. Yoshino from early days when I was interviewing him, half a decade ago, he said the only secret to Toyota is its attitude towards learning. And that's exactly what Mike Rother was documenting and Jeff Liker and others and Jim Womack and so many people, they were documenting and seeing this attitude towards learning, but it's really hard to describe that, right?It's easier to see the tools and the outputs of it. [00:04:52] Joe Krebs: Yeah. So this is very interesting, right? Because you actually in that chapter, right? In, in that final chapter of your book, you do mention words like setting the direction, a challenge. Personally or for the organization or as a team is important experimentation is important.Now, within the book, there is I don't want to take the entire book away. There's a ton of things to be explored, but there is an example of a failed experiment, a very costly failed experiment from Mr Yoshino. And that is from a Kata perspective. Obviously an experiment that failed that's at a large scale, right?And a big learning, I would assume would come out of this exploring new business ideas within an organization, even on smaller scales, I'm sure there were tons of experiments going on in his life and what you have observed, obviously working with the organization and with him directly. How important is that from a learning perspective, that experimentation piece?[00:05:51] Katie Anderson: It's fundamental, right? The reason we don't know the answer is because we don't have the answer yet. And so we need to know directionally where are we trying to get to and then learn our way forward. And so a lot of, if you take away the, the terminology, so much that you've learned through reading this book and from my conversations in the series, are those same patterns?Like, how do you set a target? But doesn't don't worry about it being too precise. You'll learn your way forward as you start doing the experiments. It's about how do you ask those questions? How are you go through the process of learning? You'll remember there's a story where Mr Yoshino was asked to Put together a report and a document and his boss who had asked him to do this.When he went forward to present, he said, what was the process that you took to prepare this report? And he knew he should have gone out and actually done interviews, gone to that quote unquote Gemba and said he went to the library because he didn't feel like he had time. And the boss said, no, that's not the right process for the learning.And so it's that same model in the Kata Kata world or Kata framework that. You want to coach people through the process of learning and not necessarily giving them the answer, but giving them the framework and the structure to be learning their way forward to that answer as well, or to a new answer that you don't even have, right?Oftentimes we're in these complex environments. We're not just giving people assignments for learning their way to us, a set predetermined answer. It's about learning our way forward to innovation and to continuous improvement. [00:07:16] Joe Krebs: I remember that that scene in the book.And it was also, it was interesting for me coming from an agile and from a cutters perspective. One thing was in, in that particular dialogue, I remember it crystal clear now that after you said it is probably not enough research was done on the existing current condition, right? So like, where are we right now in, in terms of the process?It was just not enough to read about it and go to the library. So one of those learnings, right? And that is the scientific thinking of Kata to say step back, slow down, go through where you are in, even in your learning journey. Now that's a key aspect of this one. [00:07:54] Katie Anderson: Absolutely. And I want to emphasize too, that like Kata, as we, that using that term Kata, it's nothing new.Absolutely. Different. So it's not separate from like how we approach continuous improvement, how we approach the scientific method. It is the routines and practices that help us get there. And there's people in the lean world or the agile world. And honestly, it doesn't what we label it.Those are like the tools and the processes. But Fundamental thinking and human behavior aspects are all interrelated there too. And so again, Kata is just those routines and practices that help enable us to be better problem solvers and better coaches of problem solving. [00:08:33] Joe Krebs: I always refer to it as a universal pattern rather than a tool.It could be described as a tool, but sometimes people feel like a tool is like a, like an actual thing, a tangible thing. It's a thing. It's a thinking pattern, in my opinion, most likely gets you through scientific thinking. And if we can agree on that scientific thinking is a good idea it's a good idea.[00:08:53] Katie Anderson: Yes, absolutely. And so there are tools that support that you can have a kata storyboard or a question card that helps you practice, but it's the same thing with anything like learning a sport or something. You have tools that help you practice that pattern in that routine. So it becomes habitual.[00:09:08] Joe Krebs: By in a second

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 a

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 elimin

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

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

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.

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

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 th

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

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

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 s