 So, Sean's session was an excellent lead for my session. I wasn't aware that, that's how it was arranged, or was it sheer coincidence. But whatever it was, it worked very well. Hi, sorry about that. So that was an interesting technological conflict that I never had experience before. So what I'm going to talk about is, is about Teotakata today. And a lot of what I'm talking, going to talk about today is taken directly from Mike Rother's book on Teotakata. There's no, I'm not a great inventor myself. But what I hope to do is to actually make a connection between the principles of Teotakata with, so what I thought was, I'm going to try and make the connection between what Teotakata is all about. And how it connects with lean Kanban thinking, and how the Kanban method from David Anderson helps you actually put a Teotakata culture working practice in your own teams. So that's the, that's the theme of the topic today that I'm going to talk about. So let's set a quick introduction to myself without wasting any more time. I do work for Digite, I head our implementation teams. And on a part-time basis, I do lean agile consulting. I do run the limited web societies in India. So let's set the context and I think with the plethora of all the tools, methodology, frameworks, there are over 30-35 scale frameworks today in the marketplace. The question remains whether management teams are fundamentally happy with the outcome that they've seen with the agile journey of the last 20-25 years. I don't know what's the feedback that you all hear, but in most cases, the feedback that I hear from the senior execs that I talk to, is that they believe it's just a passing fad. And it will go away, there'll be another something in the next ten years. So very clearly, they have not seen the benefits, they have not seen any long-term sustainable benefits. Nothing significant that would definitely challenge their core principles and experiences from where they started their own journeys. So the fact is that despite so much of research about Teotakata and perhaps one of the most open organizations, sharing its best practices, sharing their whatever they have, whatever methods and tools and techniques that they have adopted, there really hasn't been a second Teota, including Japan. The success of Teota is absolutely unparalleled across the industry, across the manufacturing industry, leave aside the software industry even within the Japanese companies. So there's something in the recipe that clicks more than just doing a Jidoka or doing a Kaizen or doing whatever they're doing. There's something in that sauce that people are missing. And one of the quotes that I, that my growth picked up was that Teota deeply values continuous improvement as their key value. They don't have a goal of that, hey, we want to be from 10 billion to 50 billion in the next ten years. That's not their objective. They don't want, they don't have any goal of I want to become the number one and or two in all the market segments that we are in. That's very typically the company goals and objectives that I have seen at the CXO level. But that's not what their objective, stated objectives are. They're very clearly focused that how do I make a continuous improvement culture within the organization sustained at a very grass root level? And that's where our focus is going to be today. Unfortunately, we aren't the best copycats. Time and again, wherever I've landed up in a consulting engagement, the first question that I get asked is, okay, so what template? How do I do my requirements? Give me a template for my status reporting, right? And if you tell them that I don't have any template to start with, I don't know what you're gonna do, I don't know what your challenges are. We'll figure it out. They possibly see it, my God, I got a consultant who's now going to figure out on my dime that what I need to do. Right, so it's looked negatively if you don't come to them with a set of templates and manuals saying, step one, step two, step three, step two dot one, step two dot two, step two dot three. And I think clearly speaking, they miss the point. So we land up copying what is visible, what are the practices and principles we land up copying, but we miss the thinking behind that. Right, Toyota did not start Gimba just from day one out of nowhere. They did not start with an A3 template just out of nowhere. It came out of a sustained journey of trying to figure out what is working, what is not working, and therefore why one pager that fits in A3 is better suited than 10 to do checklist, right? So we're asked to quickly imbibe and say, okay, here's the A3 template. Let me use the A3 template for retrospective. But that was not the objective or what it was meant for. So I think time and again we make this mistake of trying too soon to jump into copying templates. And pardon my saying this, but unfortunately a lot of the new frameworks and the methods are again becoming very template oriented. Do this, this is your first step. This will be your road to success. So continuous improvement essentially means that if you are at point X today and if you have a vision of where you want to be tomorrow, what are the small incremental steps that I need to make along the way? Knowing very well that there is no direct path to go from where I am today to where I want to be. So it is going to be a continuous journey. It is going to be an adaptive journey, it is going to be a learning journey. And it is going to be a small incremental steps. It will not be a massive six month campaign and then that's it. The story ends, I've reached my destination and then again after six months I'll do another campaign to go from X level of productivity to Y level of productivity. So it's a continuous process. It's not something that I would do in batches in steps, right? Relying on periodic retrospectives, whether it's two weeks, four weeks. But relying on retrospectives assumes that the system is static. The same kind of problems that happened a month back, based on a given certain data and a situation. I'm going to do a Pareto analysis on that today and try and figure out those two, three things that I'm going to try and fix. But the system has changed. Just switch off that light. That light is too strong. If you can switch off the light, that person has disappeared, okay? So, kata means a routine. So just as a small, I'm about to finish actually in time. Just as a small side, just cross your hands. Just cross your hands, try just crossing your hands, okay? Bring it back, do it again, bring it back, do it the third time round. Did you do it any other way? Did the order of the hands change? Think about it. No, right? So the brain has been conditioned to doing, responding to a similar to a request, that whenever you are told to do something, you will do it in that order. When you're in a traffic and a person suddenly comes in front of you, you don't think and then respond to that situation. You're conditioned to press the brake. So the trick is, can I reach a state where continuous improvement is a routine? It is not a practice to be told and cajoled and pushed for and planned and incentivized and blah, blah, blah. Can I make continuous improvement a routine? Because if you can, then really speaking, there is no end to that journey. So two key things, one is the improvement kata which we'll talk about. The second is coaching kata, which we'll not talk about today, surely because of time. And if you don't mind, I will eat into the 10 minutes break that we had on the schedule. Is that okay? Thank you. So we'll talk about improvement kata and continue with that and focus only on that one aspect today. So very clearly, even in Kanban system and lean thinking where we focus on value screen, we're typically focusing on handoffs from one stage of the value addition to another stage of the value addition. There is very little work in that literature that is happening within that process itself. So if I'm doing coding and coding is a stage, I'm talking about how to improve the cadence of the coding process. What are the constraints? What are the bottlenecks? But that's where my focus is, is how to improve cadence, how to make sure bottlenecks are taken off things of that nature. What we are trying to look at is just within that process itself. So the key thing that we first start by doing, the first step, is to first define a vision for the team, right? Alventophila says you've got to think about big things while you're doing small things so that the small things all go in the right direction. Another classic problem of retrospectives that you'll see is that different people are doing different things. You'll have, because you've done a Pareto and you've got a feedback, there are two quality items, there are two items from HR, there are two items of the delivery team. It's all over the place. What we want to do is we want to say that, give a vision so that at least the line items that you want to work for in your continuous improvement, they have some background and some context saying, yes, it will help me in this vision. So the first step, define a vision. The second step, that now that you have a vision, you know that you're not going to be able to go there immediately. So use that vision to define your next steps. And you know for sure that you will go through the next steps facing obstacles. There will be technological obstacles, there'll be change management obstacles, there'll be risk obstacles, there'll be obstacles from senior executives, all the way you will get obstacles. So you will have to figure a way out to go from that small step today to the next step, working around with those obstacles. And last but not the least, this I think is the most important thing specifically for the software, people that we are in, is trying to build a pattern in your project execution. Nine out of ten times, my own project teams, we are responding to fire all the time. You have certain set of planned items, you're already planned for 99%, if not 110% utilization. For sure the good guys who are the team leads are planned for 125% utilization. On top of that, there will be a request to do an RFP analysis. There'll be a request for do a critical fix from a previous project. That's the ground reality. So you're working in an extremely ad hoc, unplanned manner. And if you're working in that environment where there is no predictability, you will not be able to assess that if I introduce a change, what is the outcome of the change? So then we are again back to the model where we take five points of improvement, apply them all at the same time. We may or may get some better results, may not. But for sure we can't quantify and saying, or we can't point and saying, this one worked, this one did not work. Or if this one did not work, why did not work? Because I changed five things all at the same time. So the Kanban method helps in continuous improvement. And the key thing that I realized as I've been introducing Kanban, is that by introducing WIP limits, and I'm assuming people are familiar with the Kanban system, is that by introducing WIP limits at the different stages and ensuring, why are we doing that? At the end of the day, a Kanban system's objective is to introduce uniform cadence. We want the rate of throughput of a testing stage to be the same as the throughput from the development stage, to be the same rate of throughput from the design stage. So by having a uniform cadence, I now have a controlled system in place. I have a pattern of work method that I can everyday work to. If tomorrow suddenly five more line items come on my plate, I am controlled by the WIP limit to say, no, I will not do this because my WIP limits will get exceeded. So beyond all the benefits of flow and pull-based execution, which are ultimately all objective is to build in uniform cadence. That uniform cadence helps you to build and establish a pattern in your work. And now if you've got a pattern in your work, you can actually go ahead and implement changes. So you can do, so what do you do? Once you have a system where you have some regularity and you have a rhythm of work, now you can introduce what Toyota calls as single factor experiments. So like Sean said, they're extremely fast changes. They do these changes at rates of 15 minutes. They're not like long planned change management initiatives. They're as short as 15 minutes, 30 minutes, rarely going to something of long duration. But the fact is they're single factor experiments. So that they know that if I introduce this, if it works, great. If it doesn't work, I can take it back, right? I know what was the cause, I know what was the effect. So you establish your work, you establish your work pattern, and then you do single factor experiments to continuously improve. And this is obviously the very standard PDCA picture that everyone might have looked at. The basic point is that you keep doing PDCA and you then define standards so that your maturity of the team doesn't come down. So you kind of keep improving the standard on a continuous basis. You keep doing PDCA with these small single factor experiments so that continuous improvement becomes a rhythm, it becomes a routine in the team. In summary, what do we want to do in improvement quota? We want to define the target condition or the pattern. We want to define where we are today, what are the obstacles? Which ones are you addressing in this step today when you're going from step one to step two? What is your next step? And obviously if you've done a single factor experiment, then at the end of it you'll be able to figure out which one worked and why it didn't work. What was the factors that caused it to fail, right? Let's recap, define a vision, identify the next step. Use something that establishes a work pattern. That's where I have found Kanban system to be extremely helpful, the Kanban method to be extremely helpful. And do quick PDCA's with single factor experiments. Don't try to do large retrospectives, definitely not after three months. In terms of when your overall release is all done and dusted with. That's all I had to share, sorry for eating into your tea time today. But if you have any questions, one question I think that's all I can take otherwise I'll start eating into the next speaker. The single factor experiment means that at one point of time in any control system you change one element, that's all. So you change one element, give it some time to see whether that change has introduced the intended consequence or not. So that's where Sean's point is that the team becomes conditioned to do it, that they will do it themselves when they see there's a problem, right? So team A does it within their team, team B has a different problem, he does it within their team. Nice thing about these things is that because the single factor experiments have a small scope, small impact, in one shot they're never very rarely of a mega impact reaching the whole thing, right? But they incrementally keep adding value and because you're doing them fast, the change is continuously happening fast, okay? So there lies the difference there. And of course if something is very high impact you will go to the next levels and they will be in the picture. The coaching cutter talks about how to actually make people trained to do this but read Mike Rother's book and that will cover explain it. Anything else? Thank you guys.