 So, there has been a lot of, you know, talking and conversations about IEL, you know, really cool stuff. There has been quite a bit about Lean as well. There's a lot of confusion as to what is Lean, where, what are the boundaries, where Lean ends and where IEL begins and so on. This talk is actually, I hope, I'm hopefully not disappointing you guys. This talk is not necessarily about that. I am not going to dig into the essence of Lean. What I'm actually going to be talking about is something new, okay? Something different that has to do with Lean. So, I am calling it Lean Value Innovation. Hopefully, as I go through explaining this to you, you know, you will get an idea. It's a very broad concept. It encapsulates a lot of things. So, what I'm going to give you guys here is just a gentle introduction. Okay? So, at any moment, if any of you has a question, just go ahead, press your hand and I'll ignore you. So, okay? So, you can ask questions and we'll go through the conversation, okay? So, let's see. So, if we think for a moment, and this is just as a matter of metaphor, I don't need to emphasize on automobiles or manufacture, okay? So, don't take this literally. So, there is a point in time in which automobiles are being produced. You know, we all know about the Model T. And basically, the idea was, how can we produce a lot of these nice toys for people to enjoy so that they are affordable? As time passed by, then we started getting more production of cars. They said, becoming more attractive. There was a point in time in which the coolest thing was to have a car, right? So, you would remember those golden years, right? A lot of fun, really cool, really great. However, what happened? Well, I remember when I was a little boy, going out on vacation with my family and I just remember driving and seeing on the side of the road, just car after car that was on the side of the road broken. The engine was steaming and so on. So, there were lots of problems. So, even though it was cool to have a car, it was actually kind of a pain, right? If we look at software development, then we have had a similar path. So, there was a point in time in which we started getting programming languages, they started becoming popular, people started writing code. But there was nothing behind them to tell us how to do it. Basically, here's a set of instructions and good luck, right? So, we have the famous spaghetti code, you know? Hopefully, everybody knows what the spaghetti code is. I think some people will have a big question mark. It's like, what is that? Okay, Wikipedia is your best friend. You can find it there. But it's just basically, you just write code in whichever way, you know? And basically, you end up making a mess. And then as time passed by, there was the intention of, let's try to do this better. So, along came the structure programming and then came object oriented programming. However, there were still issues. And there were very serious issues. So, we have, for example, you know, the point with the third act 25, which was a system, you know, software that was to control a machine that will give radiation treatment to cancer patients. And because of this subtle problem with the software, people were getting overdosed. So, some people actually died as a result of this. So, it's not really that much fun, right? So, we have to be very careful on what to do and how we do it. So, things have evolved. So, in the case of, you know, the automobile industry, now we have lean manufacture, which, you know, has brought a very nice amount of improvement primarily, you know, to the eyes of the consumer quality. And in the case of software, what we have is, well, we have the IO movement. We have the lean movement. And we're doing things better. We are finding out a few things, ways to do things better. But what's next? I mean, is that the end of the story? You know, what's coming after that? So, what's missing? And if we think carefully about this, we are focusing a little too much in just how to create software better. But not necessarily on the end, the purpose, why are we actually writing all this software for, okay? So, if we look at a project, the way we really want a project to take place, it's just like a river that flows continuously. So, just imagine a river that is just flowing very nicely, not too fast, not too slow. There's no boulders in the middle of the river that deviate the flow. There's no dams. There's no waterfalls. There's nothing there to change that nice flow. So, that's what we would like to happen with our projects. And we continuously ask ourselves, how do we do it? How can I achieve a very nice flow on my project so that it just happens seamlessly and everybody's happy? And that's a good question. However, there's a more fundamental question we should be asking ourselves. And that's why, okay? So, where do we want to do it? Where do we want to achieve this nice flow? And we can find different answers. But let's look at history for a moment. So, back during the Renaissance, the Medici family was actually the main contributor to the period of the Renaissance. And basically what they will do, for example, Leonardo de' Medici will go to Michelangelo and say, hey, can you just like paint these walls? They're kind of boring like that. So, can you just like do something there? And I'll pay you, and I'll give you this much money. All right, that's cool, right? So then Michelangelo will go about painting. Leonardo didn't worry about, hey, Michael, when is it gonna get done, right? And didn't start putting pressure as to, hey, you're not done, are you there yet? Come on, you know, it's taking too long. What's going on? So, of course, that doesn't mean that Michelangelo will take forever to do it. But at the same time, there was a clear understanding that Michelangelo is creating art. He's doing art. And you cannot easily and necessarily put a deadline to that. So, the emphasis was on money. But there was an understanding, there was an implicit understanding that there was something more valuable than money, right? Then came Taylorism, Fordism. And then the emphasis was not only on money, but it was also on time. The less time it takes me to do this, the more money I save. So, time and money are important. But to consumers, what was important wasn't really the time and the money, it was something else. Then came lean production. And Toyota is the milestone to that. And they say, well, yes, we have to pay attention to money, we have to pay attention to time, but we have to pay even more attention to quality. It's very important to do that. And actually, the driver of what we do, which has to do with time and money, has to be quality, that has to be the driver. And then came Agile, then came lean for interest, lean for software development. And we started talking about value. And we talk about value often. So basically, we are acknowledging that there is something else, something that is more important. Now the question is, if we are aware of this, why do we still keep on running our projects based on time and schedule, sorry, schedule, budget and characteristics, right? The famous iron triangle. Why do we keep on doing that? I mean, we are already aware of these other elements. Nonetheless, we keep on doing things the other way. So there's something funny going on. And I think that what we need to do is to start getting a better understanding on what these other elements are and how we can play with them. So to do that, I'm going to run an experiment with you guys. You are not the first ones, but you're part of the experiment, okay? So let's say that we have two companies. These two companies are entirely new. We know absolutely nothing about them. And that means that the company name means absolutely nothing, okay? There's no marketing behind it. There's nothing about distribution channels, nothing. The only thing we know about these companies is the product they created. And these two products actually compete. So we go to a trade show and then we see this booth with these company's names, which obviously are meaningless to us. And they are showcasing their products at the same booth. So we grab both products. We look at them. And what we learn is that they offer the exact same characteristics. All the features are the same. All the things that one of the products does, the other one does as well, okay? Is there's no difference. And both of them have the same level of quality. And let's say, you know, just to have a way to measure these, let's say that by quality, we mean both products are going to stop functioning after exactly the same number of days after you purchase them, okay? So same quality and same features. Which one would you buy? I'm sorry? The less pricey. So the one that has a lower cost. Something else? I'm sorry? Design, so the one you like best. The one you like best, right? Okay, so the one you like best, the one that's less expensive, what else? I'm sorry? I can't carry. We have nothing else than the products themselves. So we don't know about that. So I can only evaluate based on the products. Usability, both of them give you the same usability. Okay, so this is fine. All the people I have talked about this give me those answers. Sometimes they come with some other that are interesting, but these two always happen. Always, always, always. So this is interesting. So now let's see. Let's say, you know, those of you who thought I will go for the cheapest one. Not the one that I like best. So let's say that the one I like best is not the cheapest one. How many of you will be willing to sacrifice money for looks? That is, the one that I like best is a little bit more expensive. And I don't have enough money to buy it right now. So I am not buying the cheapest one. I'm just gonna say I'm gonna wait probably two, three paychecks or so to save enough money to then buy the one that I like best. How many of you will do that? All right, so there's a pretty nice number of people. Now let's say some people say no, no, no, no, no. I am very cost conscious. So no matter what, I'm buying the cheapest one. I don't care, I'm just buying the cheapest one. And that's okay. The question is, I bought the cheapest one is not the one that I like best. How many of those people will have something in the back of your mind saying, oh, wow, it would have been nice to purchase it. Nice one anyway, right? How many of you will have that kind of sensation even if you purchase the cheapest one? Oh, not that many people, okay. I'm in a different context today. So typically, what I see is that the vast majority of people have the tendency to go towards looks. Even if the cheapest one, if the cheapest one wasn't the one that I like and I purchased it, I'm using it. And I'm okay with using the cheapest one. But I'm like, oh man, but that one was so cool and I would have liked to use it and so on. So basically a smaller percentage of the population sticks to the I don't care and I won't have any second thoughts about the fact that I purchased the cheapest one. So what this suggests is that if one of these two companies actually dedicated resources to innovate towards the value to the customer towards how attractive the product is, there is no 100% guarantee but it's a higher chance that it's going to have a competitive advantage because more people will buy that product, okay. So if I do innovation towards value to the customer, there's a chance that I might get more business, okay. So let's see, go to the next part of the exercise. Again, two new companies and telling you new products. Again, we know nothing about them, about the companies, about the products. We only evaluate based on the products themselves. And these two products give us same quality just as before, same features. But in addition, same price and they are equally attractive. You look at both and like, I don't know. So which one would you buy? It doesn't matter, flip a coin. Yeah, I mean so basically if it's the same then I'll just go for any of them, right. So let's say that for the first time in the history of consumer products, these two companies sold exactly the same number of units. No one more, no one less, okay. However, one of these two companies went about doing innovation towards the way they designed it, they assembled it, they transported it, et cetera. Then there's the possibility that their costs were lower. And what does that mean? So even thought to the eyes of the outsiders, it was the same amount of money that came into the company, I was a more successful business because I got more profit, right. So my point is innovation is actually a good thing that can give us a competitive advantage and can make us more successful as businesses. So this line of thought brought me to propose the linear prism. If you look at the right hand side of that prism, that triangle is actually the ideal triangle, the one that was proposed by Jim Heismith, where he talks about constraints, quality, and value. So Jim Heismith said constraints are budget, time, and features, okay, the iron triangle. But you don't go about managing your project based on those parameters. You take those parameters as constraints to consider to then manage your project. What you have to actually pay attention to is quality, meaning you have to achieve the minimum level of quality expected by the user. And from the lean perspective, I will say you want to exceed it at least a little bit. So you exceed customer expectations. But also you want to make sure that you provide the customer with the right value. And we could talk a lot about value. I am not going to do that. I'm going to dig just a little bit from the perspective of this presentation. But value is something very important. What I'm adding to this equation is if we do innovation towards value to the customer and value to the enterprise, then we can get a much better competitive advantage. What is important to note here is that value to the enterprise is subject to the value to the customer. So if we don't do that, if we give more value to the enterprise than to the customer, then we might start cutting corners. And that sooner or later is going to stab us on the back. So we have to be careful about that. So again, value to the organization, value to customer, very, very important. Now, to understand innovation within the perspective of lean value innovation, first we have to have a better understanding of what value is and what quality is. So I'm going to talk a little bit about that. So we have a pile of leaves here. What value does a pile of leaves have? Not much, none? Okay, so let's say we have this pile of leaves and usually we will just throw them away, right? Well, so fall season comes. I have all these leaves falling off the tree. My garden is full with all these leaves all over. The road is also full with these and it becomes annoying. So I hire somebody to go and take care of them. I am pointing there instead of here. So to this person, there's actually value in those leaves because I am paying him to do the work. So this guy is actually making a living out of that. If there were no leaves, then I wouldn't pay him to do the job. Therefore, the person cannot make a living. So there is value to this person from the fact that there's these leaves. Now, let's say that there's a person who does amateur gardening. So to this person, there's also value in those leaves. You can take those leaves and use them to create compost, which will be cheaper than buying it. But we can look at value in a different way. So of course, the amateur gardener is not being paid to do this, but there's value that he's getting from this. What about something like this? What if we have a kid who just goes and plays with that pile? Is there value to it? Definitely yes. So what we have to understand is that value doesn't necessarily have to do with money. It's something richer than that. So the kid is having fun and that's good. And if we want to look at it in terms of money, we could say, well, I could have taken the kid to the amusement park, which would have cost me, versus having him play with the leaves. So even at that level. But now let's look at this. If the person I paid to collect the leaves, he hadn't done that, then maybe the kid wouldn't have played with the leaves. It's unlikely that the kid would have collected the leaves to make the pile and then play with them. So there was a benefit, the kid got from the other person. And then as the kid plays with the leaves, they break down into smaller pieces, which benefit the amateur gardener because then the compost gets ready more quickly. So value can come from anywhere, in any direction, where we least expect it. So the point is, why is it that we are so arrogant to say that we know what the customer wants, that we determine what that value is? Or how can we just limit ourselves to say, hey customer, tell me what the value is and I'll just do it? The customer doesn't know what he wants and the customer is not always right. The customer has just an idea of what he wants. There's this something that I figure that will be nice to create. And then we force the person to create those requirements and he has no clue, I just have an idea. So it's our responsibility to help them identify what that value is. So it has to be a joint effort. So the end value is the gain of tangible or intangible benefit. The customer is happy that's part of that gain of benefit. So it's something valuable. Now, what's quality? Well, I say that quality is the successful delivery of the expected value. So if we understand what the value is and we have a successful way to deliver it, then the product has quality. An important work here in this definition is successful. What does successful mean? Successful means that it provides a positive economic impact. If there is no positive economic impact, then there is no quality, okay? Which means we can quantify it, right? Okay, so that's it. There's go about innovation. So if we look at innovation, the modern definition of innovation is innovation is the creation of something new that has economic success. And this is actually a very important definition because oftentimes I have people come to me and say, hey, Masa, when is something an innovation and when is something an invention, right? Well, it's not really that difficult to figure that out. I create something new, I invented it. It won't become an innovation until it becomes economically or successful on the market. For example, let's look at the famous posted notes. Who doesn't know what a posted note is in this environment? Okay, shame on those who would have raised their hands, right? Okay, so we have posted, right? Many years ago, somebody at 3M came up with this chemical formula for a glue that was more sticky on one side than the other of the polymer. And they had no clue what to do with it. So they invented this glue and they have no clue what to do. Sometime later, and by sometime later, I mean several years later, somebody came up with the idea of applying this to paper. They started playing with it, using it, they started bringing it to some customers for them to play with this paper with glue. And after a couple of years, they asked the customers, if we must produce this and sell it, will you buy it? And they say, yeah. So then they started mass producing it and selling it. And now postage is what we know it is. So it was not until the postage came to be and it was being sold on the shelves and people started buying it, that it became an invention. Okay, so that's the difference. And this is something important to consider. So to get into what is lean value innovation, now we have to consider another element. So I know that I'm talking about foundation, but I think it's important because very often I get people confused. So that's why I'm spending time talking about this, okay? So hopefully I'm not getting that many of you bored. Okay, so if we go about using systems, thinking that is instead of just focusing on doing analysis to find grain, to break into small pieces what we want to do, like oh, we have this system, the customer wants, right? And we start thinking about what are the components and how we break it into modules and then we start coming to the small details of implementation and how to test it and all that. If we do the opposite, that means instead of going in to the details, we just move outwards to understand why it is that we need that to begin with then we're gonna be more successful because then we can create the right solution that the customer is looking for. So systems thinking is actually very powerful because not only allows us to create a better solution, it also allows us to solve harder problems more easily. So that is it helps a lot to identify the root cause of the problems. So okay, so let's say now we can get into topic. So what is limb value innovation? Limb value innovation is to introduce in a successful manner. So again, successful means economic benefit. Something that is new anywhere in the organization the product or the service which has value to the customer and all the organization. And this is very important because basically what I am saying is innovation is not necessarily having to come up with a new iPad or with a new iPhone or something like that, big flashy because a lot of people will say, you know what Masa, innovation is not for me. My organization doesn't do that. We're just a small software shop or we just work on financial systems. So how much innovation can I do? Well, you can do the hell of a lot of innovation actually. So it's something that happens anywhere in the organization. Okay, something that happens anywhere within the product or service that we are creating. And this is very powerful. There is four elements and it's just coincidence that we have the linear prism and we have the linear value innovation prism. It's either that or I don't know how to count beyond four. I don't know, it's one of those. So there's four elements to this. The foundation is innovation fostering environment, methods and tools that are not only innovative but actually promote innovation and value innovation thinking. The pinnacle of the structure is the human factor. So I'm going to dig into each one of these and I'm going to give a couple of examples. I cannot go deeper because it's actually a lot of material but what I want is for you guys to have an idea of what this is, okay? So, value innovation oriented thinking. What does that have to do? Okay, basically is we have to make sure that we bring into the organization and at all the stakeholder level, including the customer, a different new way of seeing what we're doing and why we're doing it. Not to replace what we already have but to add to what we already have, okay? And that has to do with what is shown here on this slide is some of the elements. It's not the entire list because it's pretty large but it's some of the elements and as you can see there are aspects that don't necessarily sound quite familiar. We were used to seeing when we're talking about agile or when we're talking about lean as we know it so far. So I'm bringing aspects of economy, for example. I'm bringing levels of innovation, context-free, freedom, et cetera. So let's look at some of them. So what is this economic ecosystem? Well, so I mentioned value to the customer and value to the enterprise, right? So we have their customer enterprise and then I have an addition here. Why do I have that? Well, because I think that it's our responsibility to make sure that what we are doing is something that is in agreement with the benefit of the planet, okay? If we are bringing solutions that are going to have a negative effect somewhere else, we might want to think twice and think a little bit harder to see if we can come up with a solution that doesn't do that. That is basically minimize the collateral damage that we could generate with our solution. It's very important. We have to think about future generations and not just about ourselves. Dare to think different, okay? Don't just do your work, okay? Question what you're doing. Think about is there a better way to do it? Is there an alternative? Actually, why am I doing it? Do I have to do it at all? Maybe I just have to stop doing it, right? So we have to be careful to make sure that we figure out a way to make improvements anywhere and everywhere. And we have to be, we have to have the courage to challenge. Now to challenge our leaders, to challenge our team, to challenge ourselves. And at the same time, we have to be humble to recognize when we are grown and that we can do something in a different way. It's extremely important to do that. There's also three levels of innovation and here is where the concept of limb value innovation has is different from the original idea of what innovation is. So basically what I am proposing here is that in limb value innovation, we have three levels of innovation. One of them is improvements. And what would that be? Okay, so let's think about a keyboard for example. Okay, so we have a keyboard and we say, you know what, maybe we can do this a little bit more ergonomic, you know. We use this key more than others. So maybe we can make it more easily accessible. So we just start thinking about a small improvements and we do that. And you'll say, well, a small improvement is not necessarily an innovation. Well, in the original sense of the word, it isn't. But again, if we didn't leave, what we want to do is optimize the whole. We want to improve everything we're doing. You know, it very well fits within the definition of, you know, this is an improvement that is going to have an economic impact. Then why not? Why should we be elitists to say this is and this isn't? You know, it's perfectly valid to do that. You know, we have small improvements and that's acceptable within limb value innovation. Then we have solutions. And solutions is the typical kind of innovation that we know of, right? Oh, you know what? Instead of having this physical, you know, keyboard, let's have them logical. So now we have this on-screen keyboard. Oh, that's pretty cool and that helps. And that's a nice, you know, solution to the fact that, you know, a mechanical keyboard has certain inconveniences. Okay, and this is much more familiar with what we are used to with innovation. But we can also have made a solutions. And what a major solution tells us is instead of looking for a very nice solution to the problem, what if we look for a solution that avoids having the need for the initial solution to begin with. So we just avoid the need for the solution entirely. What would be an example of this? Well, instead of using keyboards, we just don't use keyboards anymore. We have an alternative that works much better. So we can have, you know, voice-operated machines. So it would be nice if it comes the day when we just, you know, keyboards are history. We don't use them anymore. And then they're just voice-activated. And who knows, maybe, you know, the next steps are gonna be just through thinking. You know, I can control everything just through thoughts. You know, I had like a Bluetooth device that is driven by brain waves and I can control a bunch of things, right? So we just have to think about a solution that eliminates the need for the original solution. That would be a meta solution. Then we have innovation fostering environment. This is very important. It has to do not only with the physical environment, but also with, you know, the intangible environment. So it has to do with communication. It has to do with the way we collaborate, et cetera. And it has some very important aspects. So one of them is, for example, leadership. Leadership has to stop being the carrot and the stick. You know, leaders have to focus on enabling the team to be able to deliver value, to create and deliver value. They have to motivate the team. They have to help the team be successful. They have to also be hands-on, not from the standpoint that, hey, you know, I'm a leader and I need to know how to write code in Ruby or Java, but from the standpoint that I am actually involved with the team doing things and not just sitting at a desk with my hands on, you know, sitting on my hands or, you know, or doing things that don't really add value. And being involved with the team obviously includes spending more time with the customer to understand the features better. So, and then we have simplicity. There is this definition of simplicity by Koichi Kawana that I really, really like. And this is important. Everything that we do, we should figure out the way to do it as simple as possible. Simplicity is golden. It's your best friend. At the same time, we have to be careful not to make it much more simple than that, okay? So I put here as an example, you know, the Apple remote, you know, you can do quite a few things with this very simple looking device. Google search, amazingly simple. The phone on the right is a photo of a, one of the meeting rooms at Cerox PARC. And this is a very, very old photo. And I put that on purpose because, you know, I could have taken a photo from Google, the Google campus and everybody goes, wow, yeah, that's Google and the Google culture. And that's not really true. And most of what we call the Google culture is a standard practices in most companies in Silicon Valley. So what is so enough on Google is very little. And we don't need to be Google to be able to do it. So basically, we have to make sure that we can provide an environment that makes it easy for people to interact, collaborate and create. We talk about a lot about build quality in, right? I mean, if we know about agile, we know about building quality in and that's nice. But I would like to add something else to this and is let's bring artistry in. Let's make sure that the solutions that we provide, the products that we create, have some artistry to it. And by that, what I mean, well, if you bring artistry, artistry helps bring simplicity, bring elegance. It doesn't matter what kind of solution it is. You know, even a simple task that you just have a screen with something that looks like a spreadsheet, you can bring artistry into it and you can make it more attractive. So what happens? The users are more happy using that product. And an increase of happiness means that the user is going to actually be more willing to play with it. He's going to feel this tire, et cetera. And that has also benefits. So we have to look at the benefit also at the intangible level. Ubiquitous innovation. So it's not a matter of saying, we have an innovation team or we have an innovation department. I think that's wrong. We could have them, but we shouldn't limit innovation to use those people. We should allow innovation to happen anywhere and everywhere. Anybody in the organization, even the person whose first day was this morning can come up with a brilliant idea on something that is going to be very useful. And I'm going to take advantage of these to also say you should think the same way about quality. Okay, quality is not a cellophane grapper that we put around the code. It's not something that happens after the fact. It's not just testing things. So we talk about building quality in. That means that it implicit is an intrinsic characteristic of what we are creating. So we should do the same with innovation. So both quality and innovation have to have those characteristics. We have methods and tools that facilitate innovation. This might be a little bit more of a familiar territory to some of you. So examples of it are obviously lean methods, ion methods, the concept of auto-nomation. How many of you are familiar with that concept? Another image. Okay, not that many people. So I think it's worth mentioning it. So auto-nomation is a term that came from Mr. Toyota, the founder of Toyota. And basically what this means is what you want to do is you want to automate as much as you can. And even though since you think you can automate, you automate them for two purposes. One of them is the more you automate, the less people you have busy with those repetitive tasks. And what that allows is that that gives people more time to do activities that have to do with actually, human valuable activities. So to be more creative, figure out improvements, et cetera. And that formation itself should allow me to more easily identify where and when things go wrong so that again, I can figure out how to improve the system. Okay, one of the translation of this term is automation with a human touch. I don't like it that much myself, but that's what it is. And in this case, we also have simplicity. So we have to make sure that what we do, our environment, the tools that we use are very simple, simple to use. And I think a good example is, for example, Scrum, Kanban are very simple. And the simplicity actually allows for the power they have. So while I mentioned Scrum and Kanban, having metrics that are significant, we shouldn't measure just for the sake of measuring. What we should do is identify the right way to measure something. And if those measurements are actually very simple and very powerful, then we're much better off. So one example is in the case of Kanban, we have what we call the control chart. And that control chart, even though it looks a little bit complex there, is very easy to generate. It's very simple, however, it is very powerful because it allows us to understand what's going on with what we're doing. It allows us to more easily identify the root cause of problems or things that are taking too long in this case. So what we could do here is analyze why some tasks are taking too long to get finished. And if they could take too long, because it's just what it takes. But it could be because there were certain circumstances that created delays. And the better we understand that, the better off we are, okay? And that brings into mind the following. So we talk a lot about knowledge work. No, I think somebody doesn't know the term knowledge work, haven't heard of it? Perfect. Okay, so if analytical thinking provides knowledge and systems thinking provides understanding, what if instead of just saying we're knowledge workers and we focus on knowledge work, we say we're understanding workers and we do understanding work? I think that it sounds very subtle, but it's very powerful because what that means is that instead of building teams and organization that focus on analysis, on knowing things, we're going to build organizations that focus on systems thinking, therefore they focus on understanding what's going on and then they can create better solutions. Okay, so I know maybe a few years from now we're talking a lot more about understanding work. And then we have tools like continuous integration and so on. Another element that is very important is serious gaming. It's very powerful, so serious gaming has to do with using techniques that are very much game alike and who doesn't like games. Advantage of gaming is that it makes people, gets people more involved and we get better solutions as a result of that. And we can use them in very different ways. I think that the most well known serious games nowadays are those created by Luke Homan, but that's not all there is. Okay, there's a lot more around it. But for example, I have here the tree they mentioned on your left side of the screen is a modification of one of the games from Luke Homan. And basically I use this as one of the first activities that I conduct with customers to understand the state of the organization. And basically what this is telling me is if the semantics of this tree is what is at the very top is like Nirvana, just fabulous, is great. It's the most incredible thing in the universe. And what is at the very bottom is this is the worst nightmare ever. And then we just take that range. So fabulous, incredible, really good, good, not so good, bad, it's horrible and it's just terrible. And then we populate that tree with aspects that have to do either with the project or with the organization or with the team. They very quickly and very easily we can get a snapshot of how that organization is doing. And that can be a really good guidance to get started with improvements. So for example, in the case of this customer, the tree was populated by all the stakeholders. And this is not the initial version. This is the second pass. The first pass had way more post-its. And basically what we did was eliminate redundancies and so on. Anyway, so here is populated with aspects that have to do with anything from salaries to leadership, infrastructure, quality, you name it. What was very interesting with this customer and it has happened to me several other times was because everybody's involved into this, when evaluating where in the tree that aspect falls into, there were times in which a portion of the stakeholders will say it actually belongs to this part of the tree and then another group will say it actually belongs somewhere else. So what I did was I duplicated the post-it and then I put a link to those. And basically what I thought the customer was, okay, of all the improvements you had to make, you had to begin with those ones because that means that you're not even on the same page on those things. So that will probably be a very good starting point. When the CTO came and looked at this without me explaining to him what it was, he just saw it and said, this is us. This is exactly us. So that helps, so we have different elements that allows us to start improving the organization. And what is important about this is that we understand much more easily that the success or failure of the project has to do not just with the fact that either we don't have enough people or we don't have the right tools or not, it is a combination of everything. The health of the organization is gonna have a direct impact on the success or failure of the project. And on the right hand side, well, there's another kind of game going on to help people understand concepts. And then we have the human factor. And this is very important. This is something that everybody, not only leaders, have to pay attention to. And some of the points that I have there are actually not commonly included when we talk about projects. So we have things like psychology, emotional intelligence, and so on. It is unfortunate how very little attention is paid to this. Because actually this is the most important aspect. If we want a project to be successful, if we want an organization to be successful, and if we want a team to be successful, we have to pay attention to this more than anything else. So what does that mean? Well, what that means is that we have to get to know our people better as people. So if we as leaders know our team as human beings, and if the team members know each other as people, they're going to be able to interact much better. They're going to be more comfortable working with each other. They're going to be able to make better decisions, et cetera. Now being honest is also incredibly important. And we have the responsibility. There's a person, his name is Christopher Avery. He actually came up with a structure that has to do with responsibility. And it shows how we operate at different levels of responsibility where out of all those levels, actually only one is responsibility. The other ones are ways to avoid the responsibility. And in the measure in which we understand that, then we're going to be able to do things in a better way. We have leadership training. Training has to be not only at the level of technical training. It is actually much more important when we do training that changes behavior and not necessarily knowledge. If we change behavior, then we're going to be able to be more successful. And actually the training at knowledge level, like technical, becomes a lot more easy. And then we have motivation and mastery. If we don't motivate people, then we're not going to be able to do much. So we had to come about, finding out ways to motivate our teams. An example is video games. Why do video games have such an amazing good quality? Well, on the one hand, we have a very, very demanding customer base. I mean, the worst thing that we can do is spend millions and millions and a couple of years developing a video game. We put it out there and half an hour later, starts crashing, right? Forget it, that's the end of it, right? So we have very demanding customers and that motivates us to do better. There's a lot of money involved, but also developing games is fun. So people have fun doing it. So all those aspects contribute to motivation. So we have to figure out a way in which we can do this to be able to create better products, okay? So I know that this sounds a little bit high level and it's on purpose and there's just too much to dig in. And, but it's very important. I mean, we are so used, particularly in this industry, to focusing on just the technical aspects or just focusing on the magic formula. Marisa, don't come to me with all this stuff. No, just tell me exactly what to do. Just give me the magic formula. Just tell me what the actual process is or what the method is. Well, this is it, you know? I mean, there's a lot of things that you have to figure out because we're dealing with human beings and human beings are non-deterministic, right? And the kind of work that we're doing is knowledge work which involves understanding. You cannot have, you know, a magic formula to deal with this. So there's a lot of involvement and a lot of understanding that needs to happen here. Anyway, so, okay, it sounds nice, but do you have proof, right? So I have applied this with several customers. I'm going to show you a couple of cases and I'm going to play with them a little bit in parallel. So one customer was working on an application for the healthcare industry and the other customer was developing a software, sorry, they developed the infrastructure and the content for online education at undergraduate and high school level. And they had several problems, as you can see there. The company that was doing the healthcare application, they were at almost level four of CMMI, which is not bad. Nonetheless, they were not doing too well. In the case of the healthcare application, my customer was the company that was actually developing the product and their customer was a company that designed the product and then there was the end user. So we have all these layers, right? And my customer absolutely didn't want me to have communication with their customer. And their customer didn't want my customer to have any direct contact with the end user. Sounds great, huh? Recipe for failure. Anyway, so what happened? Well, what happened was that if I had taken the standard approach of I am an agile coach or I am a lean coach and I'm gonna come here to help you save the project, the first thing that I would have done was, you know what, you guys have a bunch of problems that you have to fix first before I can come and help you. You guys are entirely dysfunctional, take care of yourselves and once you're ready you call me and I can come and bring agile to you or lean whatever, you know, XP, TDD, Kanban, Scrum, whatever. It simply won't work. The adoption will fail because they are not ready for it. And that's part of the story that it is just so easy to just avoid that problem because it's actually much harder. But instead of doing that, it's okay, let's do it. So let's apply lean value innovation. So what happened? Well, the first thing that I did was I identified that for example, this organization, they were extremely hierarchical. So the communication between one layer and the next organization was extremely broken. Project leads don't do any actual work, they just get orders from above and they pass them on to the individual contributors and you guys do the work and then I don't do anything. And then I am a director of one part of the organization and there's another director and you don't touch my turf, okay? There's this line that you are not crossing no matter what, right? So I defend my territory, you defend yours and just chaos, right? And it was very easy for me to identify that because I was there early, which is, you know, I usually do that, today was the exception. I didn't get here late, but I didn't get too early. Well, basically, when I got there, the area was empty and people stayed walking into the room and as they were stepping in, I observed the way they were coming in, who was talking with whom, how they were sitting and it became immediately obvious the way they operate. So what I did, they were expecting me to start talking about IO or whatever and of course I didn't do that. So the first thing I did was actually start doing a set of dynamics exercises that had nothing to do with IO or LYN. And basically what I focused was on helping them break that structure. There is no leaders, there is no teams, there's no individual, we're just a group and we all together are going to solve this problem. And it took me just about half an hour to create the change. By the end of the half an hour, people were talking to each other in a much different way and they were interacting in a much different way. What I did next was I started working, again, taking advantage of this, you know, keep on digging into that aspect, but at the same time I started bringing, in this case, LYN and Kanban into the organization and as we went about saying to learn about this, about the Kanban system and method and about LYN, I was also fixing them as a group of, you know, as a team. So this actually worked wonderfully because as you can see there in those photos, on the first one, they're actually creating those trees that I mentioned at the beginning and this was the first activity that had to do with the actual adoption after I had them working. If I had just asked them to do it independently, each one of these groups would have been one team from, you know, the same team working together and in this case, that isn't happening. All of those small groups are combined from all the other teams. In the exercise down here, what I am doing is I am making sure that all the stakeholders are actually contributing at the same level in all the decisions that need to be taken. So that's taking an amazing change in the way they work. So what we can see here is what I told you, I have these trees, this is the organization that was about, the project was about to be canceled and we can see if what is at the bottom is terrible and where some top is pretty good, then this already lets you know that obviously the project is failing because they are just entirely dysfunctional. So how can we fix the project if we don't fix the organization, right? So anyway, so we wrote about doing some work such as generating a value stream map and this value stream map wasn't created by teams, it was created by everybody. So basically what you end up having is that every single stakeholder in the organization understood the entire process for the first time in the history of the organization. And this is great because they were able to help each other solve problems, they were able to help each other improve the process. Even if I am at the end of the process and all I do is the final testing or I just do some configuration stuff, IT for release to production, I am actually now working with the design guys trying to figure out how to improve what's going on at that level and so on. So improvement is happening very rapidly. And then at leadership level, same thing. There was a small team that was going to work on a dedicated effort and the leader came up with this structure when she said, oh, well I'm gonna have everybody working on this. And what I realized was two things, one of them is not a good approach to put all your eggs in one basket, but also what we have here is, each one of these three letters are initial, so it's a person. The people on the left are leaders, the people on the right are individual contributors. So we have occasions in which we have one leader and one individual contributor. And the leader will tell the individual contributor what to do and then that person will do nothing. Well the other one was doing the work. So how efficient is that, right? So we started changing that structure and basically what we did was start having a very distribution where everybody's involved and everybody's doing value added work. And that started having a different, creating a different synergy within the team. This is a little later, so eventually it just went back to most people doing certain part of the work. However, the work was being done with much better quality. Contrary to what my customer asked me to do, I went ahead and had contact with their customer. The contact between my customer and their customer was terrible, to say the least. It goes to the point where they were going personal, just to give you an idea. So I started helping my customer's customer work on how they were creating requirements. And we actually achieve the generation of requirements in one-fifth of the time with the best quality they have ever achieved. And that's good, but what is even more important was that thanks to those changes that I brought, my customer and their customer were now actually interacting. Before I go there, it was only one person from my customer and one person from their customer talking to each other. And now we have stakeholders from all the teams being involved. In the case of the company that created the online education content, they have three groups through which every single project had to go through. And the point was they didn't communicate. So there's a customer, he asked for something. One group starts working. They have no clue what the other group is doing. There's accumulation of work everywhere. There's bottlenecks everywhere. And they were just delivering, not only with good, with poor quality, but late. So after I went about, again, unifying the organization, they decided, in this case, on their Kanban to create a common baseline for all the groups. What happened next was, okay, now each one of us go about doing our own Kanban because in Kanban, actually, the Kanban boards evolve over time, so they become unique. There's no two alike. But what we ensured by doing this was that everybody had not only the same minimum knowledge, level of knowledge on Kanban, but also that everybody was making sure that the common aspects of this common board was being respected all the time. And that made the flow of the project become amazingly smooth. So what we can see from this initial Kanban board is that now we have all sorts of different Kanban boards of different shapes and sizes. And they were working very efficiently. So basically what we did was the entire ecosystem improved without having to invest any more money on the projects. And what were the results? Well, for the healthcare project, employees were working an average of 72 hours per week. By the end of month one, they were working 45 hours, which is still a lot, we would like it to be less, but in one month to come to that change is actually pretty significant. Generational requirements significantly reduced with much better quality, communication, huge improvement. Their claim was the best communication we have had in eight years of our relationship. Improvements, 20 times improvement, we had a lot of automation established and very important, zero layoffs. I mean, usually you have an organization that we come up with this magic number. So amazingly important. So what ended up happening with this project was not only the project was rescued with a lane of people without buying new equipment or anything, so no extra expenses. The project was rescued, multi-million dollar project. It was implemented at three hospital and one doctor's office by the end of 2010. 2011, it was implemented at six more hospitals, and so there were improvements there. There were new things being brought into game, but it was actually a meta solution that came as a result of all this. And basically what happened was my customer's customer, so the enterprise that designed this product, they were so happy with the level of improvement, and actually this guy was making so much money out of this, that he bought the entire team from my customer. He just bought the entire team, okay, here come all these guys, and he created a new company. And thanks to the way he saw that this works and taking also into consideration principles of Kanban, because that's what we used in this case, he came up with a new solution for the healthcare industry that actually covers from the moment a patient makes an appointment to go through all the treatment, it keeps track of the treatment itself in real time, which allows to accumulate real data on how patients are, how they're improving or not health-wise, and that data can be used by pharmaceuticals to be able to have an extra parameter to determine how good their drugs are. But at the same time, it reduces in very good measure the possibility of human error at the hospitals, or having the nurse forget how to, and you know, when to administer the medication, when medication to administer, and so on. And basically what the CEO did was he took ideas from Kanban, some lean concepts, and from the way airports work. And he came up with this really cool idea, I cannot dig into detail because I am not allowed, but he presented this at an event in Boston and a very large hospital chain in the US got interested about this project. So it looks like this guy is going to be doing pretty well fairly soon. For the other project, oh, there is, what we have was the comparability became 100%. Now there were no miscommunications, the projects were flowing smoothly across all three groups. The internal communication had an improvement between three to eight. I couldn't have direct contact with their customers, so I couldn't have an intervention. And the only improvements of communication was what they were able to achieve. Nonetheless, it went from three to five. But the project delivery, when they were having over 170 simultaneous projects, they were having from 19% delivery on time to 82% delivery on time in just four months. And at maintenance level, they were able, they say, we're 100%, I said, no, I don't think you're 100%, let's put 99. Okay, but they were saying, the claim was that they were at 100%. Everything that comes is being done on time. And those kind of improvements, we can say, well, yes, you apply IO, you apply lean, and you can get amazing improvements. But I am convinced that if I hadn't done all this extra work on making all these other changes in the way people think on how the environment works, then bringing the change would have been extremely difficult. And I don't think these level of success would have been achieved. I have wrote, you know, Kanban solutions and Scrum solutions to other customers without applying these. And the level of success doesn't quite match even when the problems were not as challenging as these ones. So anyway, so this is what I wanted to bring. You know, I am alone for a good amount of time. To go through a dialogue, you know, you can ask questions and we can discuss this. So, you know, the presentation is just this long, so for a product. What I did was take the idea of using this to understand how an organization is doing or how a project is doing. And the steps that I go through is, well, after doing some previous work, if the teams are not communicating well, but let's see that already happened. So the first thing I do is I just draw a big tree and I ask, I give post-its to everybody and I tell them just don't think too much about this. Just the first thing that pops into your mind, I want you to write everything that has to do with the project or the organization in any context. So you can put things about quality, about the project, about deliverables, about the leadership, about, you know, human resources, salaries, whatever you want. You know, just let your mind just go, you know, run freely and write one concept per post-it. And then you come and put it on the tree where you think it belongs, you know, given that semantics. Once everybody comes and does that and we have this huge tree with a lot of post-its, what I do is I pretty much line up the, you know, the organization in front of me, in this case it could be you guys sitting there, we have this big tree over here and I draw another tree. And then I start taking one post-it at a time. So this can take a good couple of hours, okay? So I got a post-it, I read it aloud and if it's not clear, then the person who wrote it then explains it. So obviously I ask people to write it clearly so it can be read but also that can be easily understood, you know, the concept behind it to avoid that because some people don't like being exposed. And then on the new tree, I just put the post-it on top, assuming that it's the most wonderful thing in the universe and I start scanning the post-it downwards. And what I ask people to do is once the post-it is where you think it belongs, you raise your hand. And as I go scanning the post-it where you think that it's no longer within that range then you lower your hand. So what is gonna happen is that there's a certain range within which most people raise their hands. Then I say, well then this post-it belongs more or less here, right? There might be some isolated cases that are, you know, some outliers but that's okay. So I do that. And then, of course, if there's some redundancies, then we start eliminating redundancies. So basically at the end of the exercise, we migrated all these post-its here where now there's a consensus as to where those concepts belong. So that's step number two, right? Now the next step is now I take advantage of this tree again that is now empty and what I did people is now you are going to color code this. So you guys are going to come here. You're going to look at all these and respecting the semantics of, you know, the vertical semantics of the tree, what you're going to do is one color per area. So everything that is blue is human resources. Everything that is yellow has to do with your technical aspects and so on. And you made your own classification and put it here. So now you have the tree in order of importance in terms of how good or how bad it is, but now you have it by areas. And what happens? Well, now we have an understanding of how we're doing, what's okay, what is not okay and so on. Now we have a starting point to start figuring out how to make improvements. And we have to decide what to start with. I don't force them to begin with anything, only there's something that is identified as we go with the adoption and say, hey, we should probably start working on this. But other than that, it's just then be able to little by little start moving. Well, now that we're here, start moving the post-its upward, right? We fix this problem. We were really horrible about this. We made an improvement and now we're over here or we're just, we made it all the way to the top. So what we want to do is to make sure that all those post-its are going to start bubbling up as the organization improves. Well, so you have the entire spectrum, right? From fabulous to nightmarish. So quality in the organization could be bad. So that means they put it in the bottom. So we went into well and quality on what exactly and so on, identify it. Like defects, a lot of defects in the code that is out there, there's a lot of technical debt. Okay, so let's say we decide that TDD is going to help us and we decide that continuous integration is going to help us. Okay, let's start working on it and as that helps us improve the quality and people say the quality is getting better and we actually have a way to prove it, we can start bubbling it up. Okay, and we don't necessarily want discrete solutions that we go from here to here. It's gradual and these are different fronts at a time. Okay, thanks. So, sorry, there was a person behind. So I just talked about like from the list we identified these are the fabulous stuff, these are okay, these are the bad and then out of these root cause bad things we pick two or three to focus and we work on it. Then what I am getting is we are having that restructure somewhere in the remoderation where it's always accessible and monthly we are then revisiting that, okay, based on the parameters. Now, when these two or three things we stand here, are you okay to move it up? Is that the way we move or it's, because we cannot do it immediately that we have fixed the problem and we can move it here. Well, I mean, there has to be the consensus in which and even more so if you are quantifying the progress that you start bubbling it up. Yeah, sorry, here. I had a couple of questions on the metrics, a couple of slides that you showed. Okay. Yeah, probably, yeah, okay, this is fine. How did you calculate communication that? Okay, so some aspects are measured in a quantitative manner and some of them are qualitative. So you want to talk to the stakeholders, you talk to the end users, you talk to the customer, and so on. So I actually was talking to everybody. And how do you feel this is going? But let me give you an example. I mean, in this case, there were some very interesting things that happened with this project. But on the second day that I stayed working with this customer, I had the opportunity to kind of witness a meeting they were having. It was behind closed doors, but I could hear the swearing and the going personnel. I said, well, how can a pretty go right when people are not focusing on what matters and they're just attacking each other, right? I mean, it was horrible. It was really, really bad. I stayed working with them and by the fourth day I found a way to approach their customer and that actually helped to improve in things. And then I did a technique that has to do a lot with clinic with psychology to be able to get close to the leader from that group. But to me, the long story short, what ended up happening was that whereas they were telling me this guy, don't get close to him because he's the most horrendous ogre in the world. One day after I say interacting with him and I realized that he wasn't an ogre at all, actually a really cool guy, very smart guy, type A personality, one day I got to the company a little late, like two and a half hours late because I was given a presentation at another place. As soon as I arrived, some of the engineers say, hey, Mas, you're not gonna believe what this guy just did. And I'm like, okay, here comes the bad news, right? And they say, for the first, we have had a relationship with this customer for eight years. For the first time, this guy came here in the morning, he gathered all the stakeholders, so all of us, for an old hands meeting, and he explained to us the vision for the entire project. Now we have an idea of what the hell it is that we're doing. So I mean, an improvement of that level, I mean, for them themselves, from this guy being the most horrendous ogre in the world, saying, wow, this is really cool, this is amazing, right? So that starts giving you an idea of how things are. And then when I ask them, and I give them some sheets to fill in when I say on a scale from one to 10, where do you think you are in terms of these parameters? And they say, wow, this is amazing. So really, really cool things. You know, one other thing that happened in terms of communication was they were two intermediate deliveries before the final one. The first one, we finished a week late. The second one, we finished a day earlier. The final delivery, we finished four days late, okay? And of course, so they make it out, you wanna say, okay, what happened? It looks like you were doing better, and it just collapsed, but not really. Because what happened was that between that second deadline and the final deadline, finally they understood and realized how important it was to get the end user feedback. So we got the project, the system, to a stable enough state to bring in end users, bring nurses and doctors and hospital staff to look at the system and their feedback on what to improve. So of course, it took us time to bring it up to speed, and that caused the delay. But anyway, all of them were happy about waiting a little longer to get something that was really going to work for them, instead of getting something on time that they were not going to use, okay? That helps. How about continuous integration? How did you, what's the, is that a formula that you use to arrive at the percentage? The continuous integration, did you use a formula? A formula? Yeah. No, I mean, just infrastructure. They were working with Java and Ruby on Rails, and. Oh, this is aggregation of all the projects that used integration, that used continuous integration. Yes, continuous integration infrastructure, and that helped obviously improve the quality quite a bit. I'm sorry, eliminating, reducing the technical debt. Okay, and can you flip to the previous? Okay, nobody else has questions? Okay. You're still in the show. There was one more metric related. Okay. Yeah. I think the same thing on communication, that's fine. Thank you so much. That helps. Okay, some other question? Yeah. Well, first of all, thanks for the excellent presentation. The question I had was, so, when you're working with teams, which are, which believe they're doing reasonably well. Okay. Okay. But we are really looking for opportunities, whether from a velocity or innovation, other areas. How is the engagement different? The reason I ask that is, when you look at the game, the preliminary game, you may end up with a lot of things, pretty much at the top, because everybody's happy with the way things are going. So, can you share some thoughts on that, please? Okay, so, okay. First of all, this is not a recipe. It's not like you have to do all these things. It depends on the customer and what you do and the approach is different. So, for example, I mean, before I specifically answer your question, I was in Spain last week working with a customer and it was my second round of coaching. And for the first time, the first round was just with leaders. The second round finally was the opportunity to start working with teams. And what I realized very rapidly was that there was this very strong sense of, because I am an individual contributor, I am not allowed to make decisions. So they feel they are doing really well because there's a little bit of command and control that leads them and that things are happening in the picture of the quality of things, right? But they say, well, we're actually working well. We're getting things done. The customer is happy, right? I ran a game that has to do with people standing up and having a pen on the fingertip where two people are keeping that pen in balance that in less than 30 seconds made it possible for me to identify which people are the ones who do nothing unless they are told to, which ones are the ones who are trained to dominate the organization and so on, right? And how poorly they were solving the challenge of the game. And once I pointed out to them how they were operating and I thought, okay, let's begin the game again. Now just be aware of this observation. They came up with a solution very rapidly. The funny thing was the solution came out from three people who were the most quiet guys. So it was a way to let them know that it can come from anywhere and if you don't pay attention to the great talent that you had then it's not gonna happen. Now coming in more directly into your question, you might not have to necessarily go through doing some previous games or stuff to assess how things are going. But what can happen is if you start bringing a high level of visibility of your work into the organization and then you apply systems thinking to the organization, then you are going to realize that even if you think you're doing really well, you can do much better. So to give you an example, a telecom company in Panama, I say working with them, they were doing Kanban and there were two things that we identified. One of them, some employees were actually very unhappy. So they were being productive but they were unhappy and therefore they didn't contribute much to the improvement. They were just sitting doing their work doing it well but that's all they were doing. And then we also realized that it was an aspect in the Kanban board where we had a constraint. And what we identified was that in good measure that constraint had to do with the fact that they had work that depended on providers. And they were underperforming because their providers were underperforming. However, they were not showing that. So we could just see that there was a bottleneck but know why it was happening. So we started digging into detail and we realized that if we brought down in a way that we had a detailed visibility of those operations, then we were able to not only understand how each provider was performing but what the weak point was so that that would allow us to go back to the provider and help them out improve themselves so that we could do better. Doing this analysis was bringing everybody in. And I purposely invited those people who were unhappy to help out with the solution. And then I asked them to actually follow up into the solution because they were directly involved with those providers. Well, like magic without doing anything else. In a matter of weeks, these guys were the main, were much better contributors than the rest of the team. They were not only contributing in terms of productivity and helping the providers do better within the team itself. Now they were talking and bringing people in and calling into doing analysis and figuring out solutions and so on. So basically they just needed a little push for them to start walking. And what you have to do is figure out how you can do that, right? So basically you can do things in a very subtle manner. You can be very gentle in figuring out ways in which you can make people get motivated. And let me tell you, most of the times the most quiet guys, the ones who are not contributing and so on, have the most amazing contributions to make. It's just incredible. So bringing that balance is important, okay? And also this guy, he was actually, one of them he was having even family problems, family issues, and even his personal life started getting better. Just that subtle change. So again, as I say, there's a lot of psychology involved in today. So I use quite a bit of neuro-linguistic programming and other things when I'm working with customers. Last question. Thank you, Nasa. Though the model itself was very insightful in terms of the human factors, the environmental factors, right? Thinking, the tools and methods, you know? Now, when you get into engaging with a team, first of all, how do you assess that team against this model, right? And secondly, how do you decide on the leverage? Where exactly you would be leveraging, whether it's human factors, whether it is environment or a combination of these, how do you go about that? Okay, so it is always a combination. Always, always, always, okay? That's point number one. Point number two, it always has to do with leadership. No matter how good or how bad it's going, it always has to do with leadership. So whatever you want to change to improve in the system, there's going to be an aspect of leadership involved because in the end, the way the organization is working is a reflection of the leadership. So that's the aspect. So basically, if we want to kind of put this into a method, now that we want to kind of give you some sort of steps to follow, there is, I will say there's two of them. One of them is getting other leaders. So I always go top-down approach. I never go bottom-up. So top-down approach. And the other one is customers who allow it, the very first activity that I do is a company assessment or a team assessment or whatever the scope is, in which I actually talk to different people and different groups. And I play a little bit of trick of, I'm going to learn about the organization or the project from that tangible aspect. But as I go through the conversation, I start getting into the intangibles. And that's the most important part. That's when I realize what's going on, okay? And I have a template that I use, but I don't follow it verbatim. Basically, I have these questions and areas to explore. But what I do is I start going through the evaluation and I allow the conversation to go whichever way it goes. Because I don't know how you're doing, but you guys do. So if we start talking about an area and people very rapidly get into an aspect, there might be others, but this is probably the most important one. So I start digging deep into that to understand what's going on there. And then I go to another team and then I start putting two and two together, okay? So I think that's it. We run out of time. Thank you guys. I appreciate it. And by the way, thanks. I'm writing the book on this. I haven't finished, but hopefully it will be ready soon, okay?