 That's going to be the agenda. So I was hoping someone from the audience will know a little bit of Japanese and help me interpret it. But I'll tell you why. So the reason I put a little bit of Japanese is because, and I'm going to elaborate. Before some quiz, so I wanted to draw a connection. So from Japan, ultimately, what do we know mainly? Japan has to do with software. Lean, and at the lean is Toyota. A small quiz, do you guys know what that Toyota logo means? So this logo was done to commemorate the 50th year of Toyota. And it almost took them five years to develop. It has three ovals. The first one and second one, you see one represents the company, second one represents the customer, and there's a cross-section which represents that they have a close bonding. And the final oval represents that the world around them. One of the other interesting that you will see is it's also the first two ovals put together, they actually represents a driving wheel, which is a pretty subtle thing in there. Also, you can actually draw Toyota from this. So since we are, sure, right, I will, I will apply, yeah, absolutely. In fact, I actually put the actual English word for each, but then I removed it. So I was hoping because there were a couple of Japanese delegates also. So I was hoping we'll try and pick some of those from them, but yeah, I'm going a little more lean and changing the course. So since we talk about lean, so at the core of lean is the customer value. So I'm going to put out what value are you going to get in next 30 to 40 minutes. What I wanted to draw is not just come up with a ready-made lean software development principles, which I mean, if some of you have read the work of Mary and Tom and a lot of other guys, they've already distilled a lot of those lean and manufacturing concepts and put it, what can you use in software? But my objective would be to go deeper into each of these manufacturing concepts, also give a little bit of more concept or sort of history to how some of these things evolve, because that is what actually I got curious about and I dig more deeper into that. So why TPS? So this is a diagram during the course of reading some of the stuff I came across and that sort of got me curious. If you look at all the things that we talk about today, Scrum, Agile, lean software development, Kanban, I mean, ultimately everything is pointing to Toyota still and it's been almost like 50 years, 60 years and we are still trying to understand what they did and what made them successful and people pick up at some point of time, recent being the lean startup, a lot of those concepts which you actually apply in lean startup are coming from Toyota and lean manufacturing. So that's where I thought instead of doing something on how to do Agile and why, we will dig deeper into why some of these things evolve. I also used something which triggered me, it's called Golden Circle, it's by a guy called Simon Sinek, which does that, it doesn't matter what we do, it matters why we do something, why we do what we do. So ultimately if you look at today, we are doing Agile, we are doing Scrum, a lot of times we get into a sort of social proof that if X company is doing, they are saying some benefit, let me do it. But that's not the point. I mean, the point is that are you facing a problem, what is the problem that you are trying to solve? If you have a problem, you should look around the solution for not just doing Agile and Scrum because someone else is doing and therefore you benefit. So that is what got me triggered into digging deeper into Toyota and I'll present what we have. So if you look at, it's a huge history, I mean, it's like 75 years of what they did and why they did and it's not evolved unlike, let's say, Agile Manifesto which actually people got together in a room for three days in a retreat and came up with the Manifesto. Toyota history is something that they put together in almost like 50 years. So they did not build each of these techniques on one day. They kept on doing at the ground level, at the workplace, found something, is it working, made changes, then established as one of the process. So it's got huge legacy and if you go deeper, then you'll figure out why some of these things will work. So I'm going to take some of these concepts today. I mean, not all but some of them. Anyone knows who said this, since we are going to talk about automobile, Henry Ford. It's actually attributed to Henry Ford, though there's no evidence that he said it. But since we're talking about Henry Ford, I thought that is where we bring. Anyone knows, so who built automobile, what was the first automobile in the world? It was by Daimler, a four wheel thing and at the same time Benz came up with three wheel drive. So one of the things that Ford did, I mean, they did not invent an automobile but they actually, this is called Ford Model T, which was the most popular Ford model. He standardized it to the extent that he could mass produce automobile. That is what changed the course of automobile industry. At that, till that point of time, Toyota was nowhere. They were no in the picture. Ford was selling like hotcakes. They were able to reduce the price more and more, except they had only black color at that point. I'm going to introduce one more guy. So we'll go a little bit now in Japan at that point of time what was happening. So this, anyone knows this gentleman? So he's the founder of Toyota, Sakiji Toyota. And any guess what did he invent? So he was called the king of Japanese inventor. He had almost like 45 patents across eight countries in his name. And what, in what, did he, any guess anyone knows? Textile. So it was not cars. Toyota has actually known to build automatic looms. And one of the breakthrough innovation that he did was he built, you know, a loom and textile manufacturing was a very manual process. They used to have machine and anything thread broke, you know, thread broke in the thing. And then the whole cloth and the yarn becomes, you know, totally based. So he built a mechanism by which you can automatically stop the whole loom, the moment the thread breaks. That actually led, it was a huge change because one person could actually monitor 30 looms at that point of time. So that was a big breakthrough. And, okay, so one more quick quiz. Anyone knows, I mean, so if the founder was Toyota, why did they come up with the Toyota name? So in 1938, they ran a, you know, when they started with automobile, they ran a public contest, you know, so crowdsourcing was there almost like 100 years back, you know, 50 years back. So Toyota is in Japanese is, you know, is through, you know, visual brushing art, it is more luckier. It considered to be a more luckier letter than, you know, doing it with A. So that's why they came up and changed the whole name as Toyota. So this is where I'll come with the first concept of lean, you know. So one of the first breakthrough invention which was the, you know, in automatic loom, if you see, is he came up with the thing that if, if I have to monitor a loom all the time, it's a waste of human, you know, human time. So let machines do the job that machine, you know, are supposed to do and let human do, you know, what I'm good at. And therefore he invented this concept called Jidoka, which means that we should not just build automation, you know, automation typically means that, you know, something can just operate on its own. It means self, you know, he said, it is automation, which is self-working. So let's build more intelligence into the machine so that they can do our job rather than we sitting, you know, on that. And we'll see how this can be applied in software and how, you know, it is actually being applied by, you know, at many other places. But it has roots right there. So, so typical flow that they used to think is, you know, the moment you have a, you found a error, you, you get a defect somewhere in the system, you try and, you know, stop the line, you just stop the work, whatever is happening. Notify, build some notification mechanism so that you know that there is a error. Fix that problem. Identify the root cause, you know, obviously, and fix the problem. And then improve and figure out, put, you know, mechanism in place so that next time that does not happen. And we'll see couple of software examples how you can actually do it in, in, in software. So, the, the second thing, you know, part of the Jiduka is, itself is, once you've identified a problem, you stop the line, which is, they call this, and on. So, if you, I mean, have you, have you guys, anyone have seen, seen a manufacturing, car manufacturing unit? It's a, oh, okay, awesome. Are you from automobile industry? Oh, okay, awesome. So, it's, it's like assembly line, it's a moving assembly line. And there's a rod, you know, a cord going on all across. At any point of time, if a worker, any, at any of the, you know, let's say, division, if he finds a error, he can stop the whole assembly line, whole assembly line, which means that stop, work stops, right? So, that is what, and, you know, that is what they do. So, because they are so, so particular about not introducing a defect, right at the source, that they say, you know, it is better to stop the whole production than actually let it go and we'll fix it later, you know. So, and then they build visual indicators which tell everyone what is going wrong, where are the problems so that they can go and fix, you know, some of these problems. So, that, let me just draw an analogy. So, what do we, what do we learn from some of these techniques? Can they, can they be applied to us? Because we also have quality problems. They, they also just to, you know, make sure that they build better quality. They applied, you know, some of these concepts. So, something, you know, similar can also be applied in software, because we have huge issues with, you know, bugs. I mean, just to tell you, I was just trying to get some stats on bugs, you know. The software bugs itself cost it around $60 billion each year. I mean, that was the statistics of two, you know, 2002, when the software was not that popular. I couldn't find a recent study, but we can imagine how much, you know, it is costing us now. The other issue is, if you, you know, we can always, we have mechanisms to find the bugs, but we fix it later. But the later you fix the bug in a development process, the more expensive it becomes. So, that is what they know, you know, they knew much better, because that is where they, you know, said that the bugs have to be fixed at the source, the whole quality has to be built in at the source. So, I'll just bring back. So, how can we apply this in software? So, there are a whole bunch of mechanisms, and some of you have already gone through some of the workshop. So, the best way is, obviously, pair programming, you know, which comes from XP. But that is a clear way to try and build quality right at the code level, because, you know, you don't want, you know, the bugs to be passed on, you know, before, you can just find out the whole logical error right there before it goes to someone else, because if two guys are working on the same thing, you know, then they have better chances to make sure that things work. The other is, you know, continuous deployment, you know, continuous integration, test automation. There are a whole bunch of techniques. So, I'm not going to go in all of these techniques, but I'm just giving you a pointer to, you know, some of these places, because this is where, you know, all these routes are coming from TPS. So, all these concepts which we, as of now, use in software, you know, and take it for granted, you know, some of those have that roots right there. And some of these techniques you can apply even, you know, without being agile, lean, or, you know, any of those processes. So, if you just decide that, you know, today if I'll start building quality into my software, you can pick up any of these techniques and learn and implement it without doing, you know, the, going the whole nine yard about, you know, agile software development. I just added, I'm a big delivered fan, so, you know, this is what they have to say about, you know, automation, I'll just leave it for a minute, just in case. Do you guys like Dilbert, anyone? So, this might be happening to some of you. Do you get it? Your boss says, you build a tool. I am not going to pay for automation software. Definitely, there are a lot of examples. So, this is a, I'm giving you now software examples. People are already using it. So, this is a company called Target Process. They have built a pretty robust and on board, you know, they call it visual dashboard, but actually it's an on board, which gives them on a daily basis, the quality of their build, where is it failing, how many bugs are failing, in which stage did it fail, and if they just look at this whole thing and they come to know, you know, that something is wrong, let's go and fix the problem right there. There's one more example. So, there's a company called, I mean, it's not a company, it's an open source stuff. It's called Lava Lamp. So, some guys have built it, you know, if your build has gone well in the morning, you will see a Lava Lamp going green. If a build has failed, you'll start seeing red. The later you delay fixing the build, you know, and making sure that the, you know, there are no errors, the Lava will keep on heating up and you'll see all right there. I got even one more interesting examples. So, look at this, what these guys have done. So, they've built a tool in Jenkins and, you know, built some Python code. They tell them the build bug has, you know, build has failed, and let's just see that. Right, so, you know, almost like configure a gun, so that it goes and shoots a sponge ball to that guy. Who broke the build? So, it's, they've built that whole auto, you know, automation into that that, you know, system is going to figure out the builders fail. They will find out, you know, who broke the build and, you know, point that to him, so that you can quickly go and, you know, sort of fix that problem. So, just giving you a context of how Jidoka and Andon can be applied, you know, these are all independent tools, you know, that need not be, you know, depending upon any of these big methodologies for you to implement. The next thing that I believe, and that's one of the key things for their success is, you know, Genji Gembutsu, which they ultimately say, if you have a problem, rather than talking in a conference room, you go at the workplace and then see for yourself how, you know, some of these things are going wrong and why. Probably once you go there, you spot much more, you know, wrong, you know, what could be wrong there than, you know, actually talking about in a meeting room. So, I'm gonna go to one more example, which is again. So, now, once you find a problem, how do you, you know, you've just found a trigger, I mean, you've found that something is wrong, but what they believe is a lot of times, you know, that could be a superficial problem that you are trying to solve, right? I mean, for us, you know, if a, you know, they say, if you have to go to the root cause, you have to apply a five-wave technique, which is a, which is very, very popular and, you know, I think it's very powerful technique. I mean, you should try it. We have tried it at our company, but if a problem comes up, you ask five-wave, just like a little kid, and it will take you to a much deeper problem, you know, which could actually end up being, you know, much simpler to solve rather than, you know, you're trying and doing it. It's a tough thing. So, for example, you know, there's a, I mean, your car is not starting because the battery is dead, you know, or why is battery dead? Because, you know, something else is not working. Why something else is not working? Because something else was not done at the right time. And why it was not then? Because, you know, something else was a problem. So, ultimately, you read down and say, you know what? For example, in this case, just because you don't do your maintenance of a car in a proper time, you will end up getting held up somewhere else. So, in software, this also could be easily applied. I mean, we have our servers crashing most of the time. The moment server crashes, our first response is, let's just bring it back. But a lot of times, after that response, we're just done. I mean, we brought it back. You know, done, we might just do one level of analysis and say, you know what? This was a problem with the service provider. So, we'll leave it at that. But we have to go deeper. We have to figure out why is the problem with the service provider. A lot of times, you will find out that at the end of, you know, each of these problems, there could be some human problem. Probably, there is some guy who's not trained, you know, properly, and hence, you know, he's not able to do some of these jobs, which can be easily fixed. You can just give him a, you know, six hour training and, you know, finish it off. So, that is, so this becomes a pretty powerful technique to, you know, for you to use in any, anywhere. It could be software, it could be, you know, any other domain. The whole team, depth level, the whole team. Whole team. It is collaborative. It is, you have to go, so just apply the previous principle. You have to go to the source, ask the whole team, you know, what went wrong. The only thing we have to avoid is, you know, and there could be, is this. This is what we do most of the time. So, we are trying to find out who did that. I mean, we had, so who has, does not even have to come up, you know, most of the time. You just have to figure out, you know, why is something, you know, failing. And if you're able to figure out the root cause, you know, so that is a big encouragement at Toyota. I mean, if you look at it, they have a zero defect, you know, sort of tolerance, you know, built in. But at the same time, I mean, if you go back to the culture, they have a lifetime employment. They don't fire people just like that. So, people have that security, that, you know, I mean, just because of an error, I'm not gonna get fired. But then, that's why they also come up with the, you know, things that, okay, you know, if there is a problem, let's just fix it. So, if you, you know, so, a typical saving at, you know, saying at Toyota goes that, if you find a problem once, that's okay. If you find it twice, you know, you're not doing your job, you know, right. Someone is not doing his job rightly, and some job is missing, some process is, you know, getting broken. So, let's go and fix it. Any, any question? Have you guys tried, five ways? I mean, anyone? So, do you see a benefit? I mean, anything that you can share, any critical problem that you've solved, you can ask. The company, it has become okay. So, it has been, you know, so, I mean, I've seen two or three other companies, like, you know, the company I work with is Honeywell. They also do it pretty well. So, I think somewhere, the guys who have a manufacturing connection, it's, it's so become natural for them to adapt. So, for example, who is one example? Any other? Sure, so, see some, some of this context, it makes sense. I mean, you know, you could even, you have to do five by analysis, but the outcome, you may not act immediately. I mean, you could always say that there is a, there is a, you know, some percent of chance that can happen, but you can always, you know, keep it under a, you know, close options. For example, what we do is, I mean, we also track it, you know, in just Excel sheets in, in shared in Google Docs. But we say, you know, if one or two, you know, one of incidences happen, that's okay. But we at least, we have gone till the level to find out what could be suspect. So, you know, then you can build at least some more mechanisms to track. For example, if a, if, you know, most of us, if we debug a code, we, we, a lot of time, we don't find the bug. You know, the customer is reported, we don't find the bug. So, what do we do? I mean, we have spent almost like two days to debug. So, what do we do? So, we, at least we can build in more, you know, procedures in the system to, to at least find something more, put more loggers, you know, for example, it could just be one. But more loggers are at least, next time that error comes somewhere closer, you are able to find it much faster and then, you know, one, next time. Let's say my name's Ty from Samsung Supervision, right? So, the server example that I was giving is, is, is clear. I mean, you know, so one of the things which was happening is, I mean, our servers are going down. I mean, first time it went down a production server. We, I mean, we all alarmed and, you know, we're getting it. Second time, I mean, so what we figured out is there was some Windows server which was, you know, suddenly ran, which was unscheduled. And it broke the whole, you know, and suddenly restarted the whole server. And we didn't get to know. So we, so, so we went, you know, deeper into it, and said, you know, why, I mean, was it not checked? So there was some, you know, there was no checklist for someone to check, because the IT guys were new. We said, why is there no checklist? So because, you know, we don't, we don't have as many servers to monitor. I mean, that was one of those case, because then this guy is a newer, newer guy, relatively newer guy. So, so then we put, you know, whole process, some of these cheaper processes in place so that you have a checklist. If you're making a new, you know, building a new server, you have a place. You put some logger so that if it going down, I mean, going down was one thing. I mean, without all of us not knowing about it was another thing. I mean, you know, why do it, you know, had to be reported by someone else, you know, for you to know that this has gone down. So you could always put, you know, more things in place so that you get notified quickly. All right. So one more technique that Toyota, you know, at Toyota that we use very frequently is Pokaioke. It's called mistake proofing. So if you know it's a, it's a, you know, it's a problem which is happening at some of the time. You can always, I mean, as we always spoke, so 5Y is, you dig deeper into 5Ys and figure out what is the root cause. And then you take some corrective measure, you know, to be able to fix that problem. So, and this is actually much simpler. I mean, it's being used in software. I'll show you. Ultimately, this makes that, you know, you should eliminate the defect right there at the source where it is happening and try and build some more, you know, smart mechanisms so that it doesn't happen. So for example, at Toyota, if some, if they figure out that, you know, actually net nuts are the problem, you know, after 5Ys and figure out, you know, some specific net is not working and that is cracking too often. So there could be quality issues. So they, you know, they make sure that they send out a team to check the quality at their partner and figure out, you know, why is something is going wrong till, till that level. And then, you know, in the meantime, have it, you know, replaced on a scheduled interval. A simple example, Google. It's, I mean, you're, you're searching for keywords. You're not getting results. You know, Google, you know, team has, you know, analyzed that, you know, people are not getting it because they are typing something wrong. There is, you know, so the auto-fill mechanism can come in. So it could be as simple as that. It could be even more difficult. I'm going to show you a, I was reading, you know, reading an article on how Amazon does lean. And some of these, it was very interesting. So some of the, so Amazon has a, almost they have been doing it for four years. So they monitor the video, you know, if you pay for a video for, you know, some of the video watching services and if the video, they monitor how it is getting streamed. If it is too slow and you encountered a problem, you've paid for the video, you don't have to reach a customer support. They will monitor it automatically and they'll give you a refund. So some of the customers were like, wow, I mean, you know, I know, you know, two days back, I was watching a video, it was too slow, but I didn't realize they'll get a refund email automatically saying that, you know, you had experienced some difficulties. Here is your money back. So that was an amazing example. So a couple of other, you know, so I'll share this article. It has a whole bunch of other articles that, you know, examples where Amazon is doing lean in various mechanisms. Another example was for a stop the line, the end-on card, they're using end-on card in terms that their customer service team, if you report a problem to Amazon that this product, but you know, particular product that you bought is not right. There's some issue in that. So the service agent has the authority at that level, just a customer support agent that if he has found the problem twice thrice, he can pull off that whole product from the site, you know. So, and then, you know, he'll initiate the channels where someone will go and actually analyze the root cause, talk to the vendor, why is this happening? So that, you know, the quality is taken care right at the source. So some of these things, if you apply without, you know, much of an effort, it could sort of drastically improve the way, you know, we are working on building software. I'll quickly introduce one more guy. I mean, so I'm just giving a little bit, you know, glimpse and sort of perspective of the history so that, you know, you guys know when you talk about lean, you know exactly how the lean has come up. So he's also pretty important guy. So Tai Chi Ono was working, actually passed out from a college and directly recruited by at Toyota, you know, weeding, Toyota looms. He worked there and he saw how Jidoka and on some of these things are applied, and then later he was transferred to the car manufacturing division at Toyota. So he undertook a lot of, you know, improvements. I don't know whether, you know, so when Toyota started with cars, they were actually, they didn't have any technology. So they took body, four chases. They took bends, you know, what he put it together, tried to make some cars and also tried to copy initially, you know, put some of these because there was no demand in Japan. So they had to, they can't price it too much. And if you can't have a demand, you can't mass produce. So they were trying to figure out a whole bunch of ways how they can reduce cost. So that is at the core of, you know, how they became successful because, you know, they can't have 10,000 cars because they don't have a demand. And if they go that way, they can't reduce the cost. So they implemented some of these mechanisms, you know, by which they can improve and bring down the cost and at the same time, you know, produce good quality cars. There's another guy, you know, called Deming. I mean, probably you've heard Deming. So Deming was a, you know, US, you know, he was not as much known in the US, but the moment, you know, as a part of delegation after World War II, he was sent to Japan to, you know, sort of rebuild, help Japan rebuild the economy. And there he got very popular. So some of these, you know, practices that root cause analysis and what you see, a lot of control charts and statistic analysis. He taught them, you know, to them. And they almost like took him as guru and took all the inputs. Okay, so that's where the next thing comes. So now, I mean, if you look at the history, so Japan had very less of a demand. Obviously, they can't mass produce. So they found out that, you know, what if we produce just to the customer demand, you know, because that will keep our inventory costs low. So that is where just in time was, you know, introduced. So, you know, and it happened like, you know, in a bunch of series of experiments that they ran and they figured out, you know, let's just, you know, move this part and see if we can quickly put together something rather than waiting. So because inventory is a huge cost. You don't have money to take the 5,000 nuts and all the spare parts and keep it. So they came up with more innovative ways to do it. So, do you guys know just in time? I mean, it's a pretty known concept. Anyone who doesn't know, I'm gonna skip. So, do we, have you guys seen any examples in software? Yeah, they are actually more visual. I mean, I've just put it because it's a dominant dosage. I mean, by the time you actually order a pizza, you can track it where exactly it is and, you know, it gets served to you. Any software example? You guys know any software example? We go through. In fact, so how it can be applied in software is, I mean, we carry a lot of, a lot of waste or debt, you know, in terms of processes. A lot of time we end up building, doing a very heavy design, even though when, you know, we don't need that software immediately. We end up doing a lot of requirement, gathering, you know, even though things could change pretty rapidly, you know, we could build more and more, you know, tests, you know, test cases, even though the feature is gonna come up much later. So, if you eliminate some of those, you know, you can easily reach a stage where if a customer is asking for a feature and you take it through your value stream and put it up, one more deliberate. I have two more, so, in case you get bored, I'll change it. So, I mean, one of the things that I'm gonna talk about is if someone mentioned that you've implemented Scrumman. So, Scrumman is also, you know, one of the great ways to do, you know, in some way. So, when Toyota started, you know, just in time, it was not that easy because, you know, you can't put everything, you know, there are always delays between the process and it's very hard to figure out, you know, especially if you have 50 different parts going on. So, how do you, you know, try and do that? So, one of the things they said is, you know, obviously they came up with a list of, you know, ways that they produce in the system. There are a lot of unevenness in the process. So, for example, you know, if you have, you know, if you're producing 10-step process and your fourth step is only, you know, it takes much longer time. It has only one guy. Obviously, you will not be able to, you know, make it flow. So, you will create unevenness in the system. So, you have to look out for those and then try and solve those. And then, so, some of the concept here, which is also applied is theory of constraint. That also can be applied. Have you guys read the goal? Anyone? So, some of the, you know, that concept also can be applied. So, I mean, basically it's a theory of constraint. It says that you have to, you know, you don't have to look for local, you know, optimization because local optimization will lead to, you know, sub-optimization at the, you know, overall level. So, you try and, you know, if you, so for example, in a simple term, if you try and solve one bottleneck, somewhere else the bottleneck will come up. So, you have to systematically, you know, fix that problem and so that your overall flow is much smoother. So, you don't look at just improving coding, you know, for example. You know, by putting more and more developers. Putting more developers is not going to help because, you know, next guy, just testers, they may not be there. You know, or example, you know, there's no one in the, in the, in the build to build it. So, you have to look at the overall value stream and then fix, you know, some of these problems and optimize. Just a quick comparison of what are the different waste that they have. So, they have a waste in terms of inventory, emotion, weighting, overproduction. Overproduction is a big base in, in manufacturing, over-processing, defects, obviously, are there. You know, even just the transportation. So, if you have, you know, warehouse is much far off, you're going to take, spend a lot of time in just, you know, getting stuff from, you know, one warehouse to other and, you know, you have the same thing in software. So, in terms of, you know, partially done work, you have, you get one feature. Suddenly, you know, you, you jump on and start building something else and that feature is somewhere hanging. You're just lying there. You have a lot of process overheads. I mean, at least some of the, I mean, you guys have this problem. I, I at least know some of this, you know, even new guy onboarding a laptop will take two weeks to, to come from, from the IT ops. So, you've lost almost two weeks of productivity. A lot of extra features. So, if you guys attended the running lean talk in the morning, features that nobody wants, you know, there's no point in building. So, obviously, I mean, you have to, you have to build to the customer demand. So, if you build it that way, you have much better software and no feature debt. So, one of the ways to find waste, you know, one of the ways to find waste is to put your entire value stream in picture. You know, if you're able to, you know, right from where the customer, you know, request is coming to and, and from where are you delivering the value? If you put this entire thing together in one place and try and visualize, you'll start seeing where can you improve. So, example, you know, if, if this is your entire process, you will see that between each of these steps, you have a lot of wait time. If you're just able to somehow reduce that itself, you will have much faster time to market. So, that is one of the ways that, you know, let us solve the problem. I'm going to skip one or two. And the next is Kanban. So, Kanban was, was also developed because, you know, ultimately to reduce the inventory and also make the whole just in time flow much better. Are you guys aware of Kanban? Anyone, you want me to elaborate a bit? So, it goes along with the, I'll take an example. So, I mean, if you're just able to visualize your entire value stream and implement pull in the system. So, as of now, you are trying and assigning features to your developers and then that guy's working and handing off to someone else. In between, there's a lot of weight that you're, you know, developing, as I was saying, an example. So, by implementing, you know, Kanban and putting, you know, putting restricting a number of features that you can work in, you know, sort of putting, how many things you can work, you know, at one point of time, that will build constraint in the system, which will be visible and then you can, you know, tackle where, you know, you want to optimize, you know, the overall flow. And the last one, Kaizen. So, that's a big culture at Toyota, you know, which lets them, you know, find continuously ways to improve their overall value stream. Now, they find out, you know, each and everything where they can try and improve, you know, the overall process and optimize the flow. I'm just gonna give a quick perspective. There's a whole bunch of things to learn at Toyota. I've just touched, you know, probably 10, 11 odd, you know, techniques, you know, there are things like, you know, 5Ys, there are PDCA, all of those can be, you know, you can always learn, read more about it and try and implement it. All of these can be easily implemented in software and obviously help you get value. Quick recap. So, I mean, you know, you can always build quality at the source, you know, try and, you know, automate more in software. Use visual signals to highlight problems because that will get you the attention very fast and help you resolve things. Try and mistake-proof the system, try and find out whatever errors or mistakes are coming up if you can build mechanism to fix it right at the source. Get to the root cause using 5Ys. Go and see it at the workplace and resolve the problem. Just in time, continuous flow. Try and eliminate waste, you know, in the industry system and try and reduce evenness, over-loading and enable pull in the system and keep learning. That's actually not in Japanese. Thank you. There are a bunch of books, you know, that I'll share the deck and you can refer it. Any questions? Any specific questions on any specific technique? Sure. In the software industry, we should be learning when it is actually not coming from a software industry, but instead of hardware industry. Okay. Okay. So, no, no. Actually, that was my, you know, I was trying to demonstrate some of these techniques that you saw, how they can be applied. I mean, did you feel some of these things can be applied in software? Because, so ultimately, I'll go back to the first diagram. I mean, do we have problems in software that we are not able to solve? But, but, do you, do you, do you, do you, you can have? You can have. Yeah, must have. You guys may also. So, it is also because they are implementing quality, right? The source, which is not need to. Otherwise, we also have. You guys, CR, Tata Nano, burning to fires. There are multiple recalls. Multiple recalls? So, there are bugs, right there. They should not be bugs, because it will kill people. But in software, if there's a bunch of people. Will it not kill people? It is not that big. That's why bugs, probably, I think, won't matter as much as in the hardware industry. So, there are quality of bugs, but that does not stop us to look around for solutions, you know, where, see, if you look at why we're looking, because we have a problem. We are not able to control bugs, no matter what process you go. You move from waterfall to iterative to others. Because, you know, probably we have just built processes which were not optimal, as much, you know, as optimal. If you're looking around, you know, for agile. So, why do I, you know, why are you going agile? Because you could learn what you're building for the customer, collaborate with them, and don't build something which they don't want, right? And if you try and draw, you know, analogy, both have a series of steps. Ultimately, both have a series of steps where you go through, right? I mean, if you're, you know, I could go back to the example. Ultimately, beat a manufacturing or software, you have a series of steps that you perform. You have a whole value stream. We also have a value stream, right? And that is what it is going through. So, there is a lot of similarity. I mean, in terms of end product, it could be different, but there is a lot of similarity between both, right? So, I think it is actually... Yeah, from the lean thing. Sometimes, you discover that you have more number of developers than best number of testers. Because of that, the stories are building, right? But there are not enough testers, you know? There is a wait time. So, there is a waste. Now, if you want to reduce that waste, then you have to convert some developers into testers. Right. And then you can have a flow, you know? Right. So, I think that reduces overall lead time for delivering each of the user's story or different things. So, that we have really seen. Absolutely. I mean, see, that's where it is coming from. So, if you look at... Software and manufacturing, what are we trying to do? We are trying to deliver a value to the customer. That is at the end. I mean, our products are different. The way you build could be, you know, here and there. Obviously, the type of product could be different. But ultimately, you are trying to deliver value. And we are trying to see how you can deliver value better and faster. You had any question? What? Can you find the... So, depending on the context... A lot of times, I mean, actually you don't... You probably may not go till the fifth Y. Maybe you will probably get your answer, which the whole team is satisfied with and say, you know what? Yeah, I think this is what it is, right? So, then you don't need to go even beyond probably three, third Y. But in case you, you know, the team is still not coming up to a conclusion, then there could be some deeper problem. You actually may not even get it in the first go. You may suspect something, work out a solution, and probably you will figure out that there is something, you know, some problem, something else. So, some other thing, I mean... I think that is the... I would have found that problem is a circle. So, it just gives a problem. I mean, it can be an optimal number for the tip. But you can have many notes. I mean, I'll show you. For example, I mean, you can even use fishbone analysis, you know, which is also very popular, where you have Ys at each of these levels, you know, you have one Y, and that is leading to two root causes, and that could go in, in its own chain, and this could go in its own chain. And then you could figure out, probably have uncovered little more than one problem, you know, that you can fix. Anything you wanna add? Anything else? Anything else that... And in software industry? Right, I was just... You know, all the software examples, right? I mean, you know... Things in the end of software or something there to matching, or some context, something matching with our industry, we are going in here, right? We are trying or applying those things, which is successful in a different domain or different industry, we are trying it out here. Right. Like, is there anything like brand new or creating things that happened in software industry itself? Like, we tried out something from our problems itself. Just curious to know, is there anything? Anybody? I'm... From software, we are trying scrum XP, you know, that is what we have come up with, right? Which is not... Yeah. Which is not, you know, in some context, not leading to, you know, it is a lot of... So if you also see that, you know, XP also we are talking about, you know, continuous integration, conceptually, it ultimately, it can even be mapped to Zidoka, which is what they did six years back. Anything else? All right. Thank you. Thank you very much. We'll move on to the keynote, which is right there. Right on the same conference schedule, where you're seeing each of the... There's already placeholder for slides, so we're gonna go in about there. Yeah, so we'll go back, you know, I think at the end of the conference, you'll have it in the tomorrow. Thank you.