 for about seven years now as a business analyst. I work in the Pune office. I've traveled here for the Agile India conference. So we're gonna talk about Lean today. Just before we start, can you guys hear me? Okay? Okay. So we're going to not be sitting. We're gonna come and play a game. So I'm hoping all of y'all, as many of y'all that we can accommodate in this production line. So we're gonna try and be part of this production line as many of you guys can make it. Other than that, we're gonna play a game which hopefully is fun. Can, yeah, just settle down. We'll come and join the production line soon. Okay, so just a quick check. What, how much do you guys know about Lean? Have you practiced it in your organizations? Have you read about it, learned it? Mike did he, Jenna? I feel out of it. Okay. Thanks. Huh, yeah. Okay, okay, okay. Do you wanna talk about a little, what do you understand by Lean? You're not much, not much. Okay. I'm just interested. Okay, okay. Anyone else wanna just give a couple of words on what they understand? How does Lean help? What is Lean? How is it different from Agile? Is it different at all? Okay, okay. Okay, that's good. Okay, okay. Simplifying things as much as you can. Eliminate waste, yeah, similar to what he said. So, there is a lot to do with Agile. Okay. Nice report. All right, so let's get to it. Can you guys come over? So, I'd like to have at least four or five people per table. So, what we're gonna do is we're gonna simulate a production line in, very similar to how they do it in the manufacturing industries. Each table is a workstation. So, we need five people at each workstation. And yeah, sorry, no sitting. So, yeah, but yeah, we're just doing one. So, the rest of you all will need to observe for today. Yes, please. Actually, six is also okay. If it's getting a little crowded, we could just push the tables here a little bit. We just need a little bit of space in the middle of each. This is fine, all right. Okay, let's get to it then. Okay, really quickly talking about why we're here. Like I already said, we're gonna try and cover a couple of lean concepts, which you'll see as we go through the workshop. The idea is to use this production line, play a game, and then try and grasp what the real principles of lean are. While we're doing that, I'm also gonna try and draw a parallel between how lean helps in the manufacturing industry and how it actually will help in our software world as well. So, that's another goal that I try to achieve at the end of this session. Okay, so really quickly, this is Tai Chi. Oh no, he's called the father of the Toyota production line. And the most important thing that he really taught is that waste is the most important idea that you need to understand when you're trying to adapt lean. Anything that does not add value to the customer is waste. So, what we're gonna try to do today is, A, understand what are the seven types of waste that the TPS of the Toyota production tries and tells us. Inventory, extra processing of a production, transportation, weighting, motion defects. These are all the seven types of waste that are taught in the lean manufacturing study. But what we are gonna try and do is, first of all, identify waste and then see how to eliminate that, right? Okay, so let's get to it then. Here's the workshop that we're gonna do. Really simply, there'll be a hands-on activity for a couple of minutes. We'll retrospect what happened, what went well, what didn't. And then we'll learn from that and we'll go to the next iteration. So, we're gonna literally do three iterations. Like I said, we're gonna try and simulate a production line. So, each of you are workstations. If you see on your table, there's team one, two, three, four. If you see, if team one can see on their very, what is this, left, right, sorry. This is your inventory. So, each table also has an inventory that you need to work with. Okay, so let me just talk through that a little bit. So, team one, you will pick up your inventory from inventory A, bring it on your workstation. There is a paper on your table which we'll turn around in a second which has specific instructions that only you need to follow. And then, after you've built what you've asked to be built, you will keep it on inventory B, ready for team two to pick up. So, team two, you will pick up the inventory from B, bring it over, work, put it on C. Does that make sense? Same way for you guys. Team three picks up from C, builds, puts it on D. And you guys, again, picks it from D, put work on your station and give it to E. But what's important at E is that we'll have a customer standing there, okay? So, at the end of the day, what are we trying to build? We're trying to build something for the customer, right? So, you'll have a customer standing there who's going to accept or reject the houses that you've built. Fair enough? Everything okay till now? You'll know in a second. You'll know in a second. Okay? So, like I said, we're gonna build a Lego house. Just talk through how the process of the game is going to proceed. Really quickly, let's try and see. Yes. As soon as you flip your sheets over, which I see most of you all have, you will know exactly what you need to be done. Very quickly, trying and seeing the house cost, right? So, we're trying to build houses in Bangalore because, like we see, they're extremely expensive. So, our company is trying to build a lot of houses in Bangalore. A really quick cost, each Lego brick. So, each brick for the house costs about 10 rupees. Each house that we build will be sold for 1000 rupees, right? So, if everything goes perfectly well, we actually have a scope to make a profit of 900 rupees, which is excellent, right? Okay, cool. At the end of each iteration, we're gonna measure success because that's extremely important again. We're going to see how much cost we have incurred to build how many houses, how many houses actually got accepted and hence sold and what's the profit we made. Okay? Okay, enough talk. Each team, can you quickly check if team A has a bucket of Lego? Yes, team B has a bunch of bricks. Everyone okay with that? All right, so, does everyone understand what they need to do? I'll give you just a couple of seconds to turn around your sheets and go through it really quickly. B, about two minutes. Ready? Any questions? Yes, please. The instructions are written like the things from B. Yes. Yes, so these are your instructions only. This is for this team, your team four and the customer is gonna stand there, right? So you're the final team that's actually building the house and those three teams are gonna help you with the inventory required to build the house, which is why you have the whole set of instructions. You have the exact specifications to build the house. Yeah. Yeah, okay, I'm gonna start now if there are any more questions. Okay, another rule of thumb. You guys are working in a typical, typical manufacturing firm, so each department doesn't talk to the other. Period. No. I'm the flow manager, so you ask me or him. Yeah, so this workstation does not talk to that, right? Okay, any final questions before we start? All right. Ready to go, guys? How about ready to go? So do we need to pay for them to do something or if we can start over? You, okay, each workstation needs to be done, needs to do exactly what you're told to do. Nothing else. No, you do exactly what you're told to do. You don't look anywhere else. Okay, I've given you all enough time. Ready to go? All right, iteration starts now. Start building. You're not talking to other departments. Perhaps not, so he could come to us, right? Just leave a little gap here. Yeah, yeah, it's the same. It was just for you guys. Okay. Yeah, if you don't need it. Listen, where is our alarm? Alarm. Sorry about your fight. Sorry about your fight. Sia, hello. Where is your house? That is not my house. Okay, okay, so, sorry, you don't have a house, sorry. Okay? Anymore? No houses, no houses sold at all. Zero houses. Excellent. Okay, let's give five minutes to see what happened. All right? Yes, we did it. Yeah, let's do cost first. So each table, just a rough number of bricks that you have on the table currently. Very rough estimate. 75. How about team two? How many? Approximately. Okay? Two, I don't know, you do the math. 200. I'll set 300 combining. Okay? Okay, nine. 30. 30. In the, on the production line right now on each workstation, okay? So that's about 360 into 10 bricks, 10 rupees, one brick. Okay? And number of houses sold? Zero. Okay? The profit is negative. Excellent. Good job, guys. No, clap. Okay. All right, quick. What are you the guys? How do you think it went guys and girls? Good. Okay? Let's talk about it. What do we need to do? Only they know what they need to build. Uh-huh. And they're not going to work. Just grab it, just keep it here. And just pick it whatever they want. Right. So they're not picking it, they can't pick what they need to do. Right. So it didn't go well then? Definitely. Okay. Okay, okay. But what do you think? Okay. So what does this number mean? What do you think it means to have? How do we set the production line down the way? And we're basically bringing a lot of waste here. Yeah. Or do we fix laying around in the room? Yeah. Yeah. So there's a lot of waste which is, and what kind of waste do you think it is? Definitely. There's a lot of work in progress. Right. What does bricks mean? Bricks mean that you were trying to build something with those bricks, but it actually never went all the way through to make a house. So it was all work in progress. Does that make sense? Yeah. So how many unused Lego bricks? A lot of them versus how the soul were absolutely zero. So like you guys rightly said, that's one kind of waste that you want to look out for. Let's put in a little bit more thought into how this process happened. Right. We predicted market demand. Did any one of you all know what the market, what the customer wanted? Right. At the very end, I came and told you that I need a yellow house, which is when you started looking for yellow. Otherwise you were building a red house if I wasn't wrong. Right. So what happened there is they started building for the first one and a half minute and then I went and said as a customer, hey, you know what, I want a yellow house. So we didn't know, none of us knew what the market demand was. We just predicted that, yeah, probably someone requires a yellow house so we started building a yellow house. You guys didn't even think about the color, right? You just took whatever that you saw, you started building using the specifications. Mass production. Again, we didn't know how many houses like you rightly pointed out. Nobody knew how many houses the market actually wanted. And we achieved economies of scale. We just continued to build and build whatever we thought we predicted and we started pushing it over to the next workstation. Yeah, but that's typically what will happen in a manufacturing production line. So this is called a push system where you're predicting what the customer wants and you're pushing your demand to the customer without actually understanding what they want. Back in Henry Ford's time, this was a very classic sort of statement that was used. Henry Ford used to say, yeah, yeah, make it any color as long as it's black because Henry believed that the market required only black colored cars. Now the reason it worked in his time at least is because he had monopoly, right? There weren't a lot of Hyundai's and I don't know, Honda's out there. So it worked in his time, but would it work today? Let's try and relate this to our world, to software. How many companies do you know that have assumed what the customer wanted and pushed products out there and miserably failed, right? Orkut is a really good example here as well. They did really well, but they'd never actually tried to learn what the customer wanted afterwards and hence failed eventually. Okay, so now we're gonna try and change what we did in the first iteration. What we're gonna try and do is a pull system. We'll sort of try and reverse the trend here, right? So we'll first try and understand what the customer wants. We'll build only as much as required by the market and we'll adapt what that requirement is and only then will we build, right? Like I said, this is called the pull system. Make only what is needed, only when it is needed and only in the amount that is needed. But why would we do this? Like you guys have already pointed out, right? We don't build more than is required. Again, trying and relating that to software is extra features, right? When we're building software so many times, we just think that, yeah, yeah, this is gonna be brilliant for the market, but we don't really actually go and do market service to see if those features are required and hence we keep pushing out features. And to avoid wasted inventory, which is partially done work or work in progress. Sure, yeah, yeah, let's do that. Like someone else said just before we started, the push system, what we did before is just in case production, which is just in case someone needs it, I'm just gonna build it and put it out there. But as opposed to the pull system is just in time production, right? I'm gonna build it only when it's required. One way of achieving this is using Kanban. Anyone knows what Kanban is or used Kanban? Yeah? Anyone? Mm-hmm. During the flow of production. Right. And you try and eliminate the bottlenecks in that particular phase. Yeah. You shuffle the sources and you concentrate on that particular phase where your work in progress limit is broken. Right, right, fair enough. It's a bad word. Exactly, Kanban is nothing but some way to identify something. So it's literally in Japanese, I think. It just means a signal of some sorts. Right, Starbucks coffees. Have you guys noticed that the coffee mug actually has some kind of identifiers on them? To do exactly that. So if you go back to Starbucks or even McDonald's, when you're at the cashier, you tell him you want a cafe latte. It's not like a cafe latte is already made. He takes it, he takes your order, ticks it, pushes it back into the kitchen. The kitchen then makes it and then gives it back to you, right? So it's very similar in that sense. Again, same thing, decaf or any other. So now what you're gonna do is you're gonna try and implement Kanban in this production line now. If you see on your tables each inventory, there are four color cards. Okay, we're gonna use those cards to indicate Kanban, to indicate if I should work or what should I work on? Okay. And we're gonna implement the pull system using Kanban. The way we're gonna do this is, first we're gonna try and understand the market demand. Only when team four pulls something from inventory C, right? D. From inventory D, will you guys start working on something? For example, if they pull in a yellow, if your yellow card becomes empty, only then that's an indicator for you to know that, okay, I need to refill that yellow card. That's when you'll start building. That's when you'll pull yellow from next, bring it here. And that goes back to you guys as well. You know that your yellow card is empty, I need to refill it. So you will go pull yellow from your previous inventory. Does that make sense? So it's really simple. We're gonna use the color card to indicate whether I should work and what I should work on. Fair enough? Okay. Inventory check done? Yeah, everyone has enough bricks on their table. That's the customer. I'll give it to you. All right, ready to go? You guys don't seem excited at all. Ready to go, yay, we're building houses. All right, iteration two, start. Read your instructions, follow the same set of things. Yes, thank you. All right, good. Again, you can't talk. No, no, no, no, no, no, you can't talk, no, no. You cannot still talk to you, thank you. Okay, okay, good, good, okay. Yeah. Okay. Stop, stop, stop, stop. Okay. Inventory check. How many bricks on the table, unused? Oh, even you guys gave stuff back, isn't it? Ridiculous. I should remember to put that as a rule next time, because it's never happened, someone threw it back. Yeah, totally. How many? 45, and here? Total? Okay. So 220. How many houses sold, actually, yeah. It's not sold yet, I didn't buy it yet. I know I'm the customer, all right, that looks okay. Does that look the same? Customer is God, I can do anything I want. Are they different color yellows? No, the same color. No, this is lemon and... It's the inventory we got, it's not our... I don't care. Sorry. Defect. 2000, I guess, huh. All right, how do you think that went? Much better, why do you think it's much better? Sorry. Okay, okay, you were saying something? Less cost, more profit. Less work in progress. Yeah, so hence less cost. Okay, what else? What did you guys think? We didn't have people... Okay. That's not very organized, just put a little bit of change in it. Okay, but did you guys have it? Did you think you were working a lot? Okay, how about you guys? How was your work, right, right? And then pushing back also. But other than that, but just within your work cell, did you think there was a lot of work? Yeah, much better. Okay, what I noticed at least was that most of you were waiting like that for some time, right? Yeah, but everything was not utilized. Even one as well, is that fair? Yeah, so I get that there was less cost. We actually sold more houses. But what my observation was is that they were extremely worked out, like they were working a lot as opposed to these three teams were not so much, right? So this is again something that even in our projects we need to think about, right? It's not only about your role. You need to think about the system as whole. And I think that's a little broken at the moment, right? So while one team was working a lot, a few of us were sitting idle. What do you think that is? Yeah, absolutely. So the resources are not getting utilized as efficiently as you'd want them to be, right? So this is something called Mura, which technically means unevenness in work, right? So the teams waited for, you guys waited for them to tell you what to do and only then you started working, right? So what are some of the things that you think we could do to make that better? One, one, one, sorry. How do you think that'll help? We could do that. We think the resources, the resources knows what to do. Okay, fair enough, okay? What else do you think we could do? There should be this. There, what should be? The exact, okay. Right, okay. Merge the team so that few sectors spread across there. Okay, fine. So that will help how? It will help in earlier in the life cycle. Right. So by the time you are towards the end, you'll have sort of semi-finished product, which you can just assemble to finish. Right, so that's a good point, right? Because at this point of time in the production frame, each of you are doing only the four instructions that you're given, not knowing what the end goal is, not knowing how the house even needs to look, right? So again, going back to what I'm sure we see in our lives as well, is it's at least my view is that it's better to be a generalist in what you're doing, rather than just being a specialist. I mean, again, it can go both ways, but what helps is what this gentleman already suggested, right? That if we are, each of us have enough information of all the tasks so that we are well informed and hence we can help out in whichever way we can in that given set of, to build the product. Does that make sense? You will know in a second. Okay, again, trying to come back to software and our world. How many of you all know what this is? Yeah? Scrum board, agile board. Yeah, this is a typical physical wall that most agile scrum teams will use. Again, what stuff, some tasks that are ready for dev, something that's in development, something that's in QA, right? What typically we've seen, I'm not sure if you guys would agree with me, but the QA wall is generally, the pipeline is generally overfilled, right? QA is always lagging back a couple of iterations. I'm sure you guys have heard this quite a lot, right? So one way what we could help with is adding a work in, WIP line, right? So if there are more than, limit the work in progress, which is what one of the things that we did, right? If there are two cards in QA, we will not take any more, accept any more cards into the QA lane. What that means for dev is that either they stop working or they could actually help out QA as well, right? Does that make sense? So this is again going back to being a generalist versus a specialist, right? If the dev is able to help out in another role, you're going to be able to reduce MURA, which is uneven workload. Fair? Right, another important and I think one of my favorite concepts in lean is SkyZen, which is continuous improvement. So the coolest part about this was that it's not that the floor managers, someone mentioned floor managers before we started. In the Toyota production system, the floor managers or the managers in general were not, they were not the only people who were responsible for a successful delivery of something. The employees, the workforce were enabled so that within their tasks that they're given, they were almost pushed to see how much, how they can improve it every single day. So it wasn't the manager only responsible to say, okay, you know what, you sit that way or you do this that way better. Each work employee was enabled, was empowered to think of ways to make their work efficient, bring it up and hence try and improve what they currently do. So I think this is also very, very important for us to try and implement in our software IT world as well. I've tried this a couple of times in my project teams and it really helps because the manager really does not need to micromanage as such, right? Because the manager will need to see at the top level. But it's really the developers, the QAs, the BAs who are doing the real work, they're really on the floor, right? They are best placed to be able to see what are the small tweaks I can do to be able to make my delivery of software better or delivery of the iteration of the scrum better. So I strongly suggest that each of you all, when you go back to your project teams, try and include this in your stand-ups or in your retrospectives. If there's, if each of you can think of ways to improve what you're doing in your workspace every single day and try to bring that up to improve your life cycles. Okay, we have a little time left. What we're going to do is we're going to reduce all of you all within three workstations and each workstation will be given inventory to build houses, okay? And I think you've already suggested one way to get the specialty that these guys have of actually knowing what to build is we'll integrate them within the three teams. Does that make sense? So that they will know what are the specifications each one of you had and you will know what the end result was, right? But question though, how would team one know what team two and three was doing? Yeah, does that make sense? Because even if each of them go into one and three, you would, they would never know what you did. You would never know what they did, right? So one way and here again, right? We've sort of used Kaizen to just quickly tweak that. This is not typically how I would run the session. I would just make these people go in and then give you guys sheets to read and know what to do. Blank faces. Does that make sense? Okay, so what we're suggesting is self-organized, right? Four teams come together, manage yourselves in a way that each team should have at least one member of each workstation. Cool. We can do four teams, we can do three teams. Whatever you guys want. Take about two minutes as a group to manage that. Take a minute or two to see what you need to be done and need to do. You need, hey, where are the, and you are from here. So you guys have someone from each team. You guys are good? Okay. You guys are good? Okay. You guys are good. I'll tell you. Let's start iteration three, guys. And girls. Yes, I will tell you the market demand. Where is my market demand? Okay, I'll tell you the, all right, start. Yellow house. You need to wait, hold on. Hold on. This is your inventory. What about this team? Sorry, here is your inventory. Take. This is your inventory. What is the market demand? Yellow. Yellow. Yellow. Yellow. What have you done? But you have a person from team four to help you understand what's needs to be built. That's what we decided, right? You can take. No, no, no, forget it. Just use any yellow, don't worry. I'm just giving you more inventory. Did you already build? I'm supposed to be building the houses? Yes, start. Red. So which color? What do you think we should do? We're trying and implementing Kaizang. You tell me what we should do. You decide. You need to tell which color you want. Red. Red. Okay. Red. Red. Okay. Okay. Okay. Okay. Okay. But you're from team four. Blue. Blue houses. Blue is the new red. I know. Your cramps are over here. This one didn't go that well. Own production line. No passing on. Here. You need more inventory. Just pull from here. Sorry, can I just take some? Two. One. I'd like to see you do. What about team three? You do know that none of them are complete, right? This is complete. No. No. No. Final picture. Go down. No. No. That's your final picture. This is step nine. Needs to look like that. That's your final picture. Fail. Fail. Fail. Zero houses built. Oh. What about you? Two green, one yellow and one blue. Awesome. Good job, guys. Yeah. Five, six, seven. Box. That's the whole box that you pulled out. And you team four. I'm serious. I really need to come back to your company and see. Okay. Okay. They're confused of what to do. Mm-hmm. They say go on. Okay. Yeah. Okay. Okay. That's a very good thing. The person who was on team four. Okay. Yeah. What else? I think you guys did the best. What do you think helped? Yeah. So team four. Uh-huh. Contribute the both in terms of the idea and vision of the final product. Okay. And that really helps the team. Did you guys talk about organizing yourselves in a specific way? Yeah. At least the teamwork. Okay. How, can you talk about that? Yeah, I have this idea based on the previous presentation. Okay. We will do this, we will do this. We will do this. Okay. We will do it based on the steps given in the paper. Okay. Okay. So you use the steps to actually make it easier. And everyone was involved. And everyone was involved. Okay. So you almost had a mini production line. I know. But all of you were talking, there was a lot of collaboration, right? Okay. There was a lot of collaboration, right? So I think you guys didn't do very well. You said there was chaos. Why do you think there was chaos though? OK. But you still had folks from this team. I think you and I. So but you must have seen it on that. Yeah, no, this was not there. Understood. Sorry, I'm just saying that I get that the specification wasn't there. But one of the things that we decided as a group to do is if each group should have one member of the workforce, right? What that means is that whoever was on team four, they actually knew the specification for two iterations until now. So I get that you didn't have the paper, but the point was that you had people who, expertise, right? You had expertise from that group in your group to help maintain that. I guess does that make sense? OK, OK. So that sort of brings us to the very end. Very quickly, doing a recap, we saw what the seven types of ways in production are. We sort of touched upon extra processing, overproduction, waiting, inventory, right? Drawing a parallel to software. We spoke about partially done work, right? You want to push something into production? Yeah. But even in software, right? You want to push something into production, but you can't right now because you have half of a free ship build. QA is not ready to sign it off, things like that. Gold plating, extra processing, like we were saying earlier, right? All the bells and whistles that maybe the customer doesn't even need. Extra features, waiting for someone else to, some other process to come through before you take things to the next stage. So this is sort of drawing a parallel of, and I'm sure you guys have read, Lean Software Development by Mary Pavande. I think it's a great book that helps, gives you small tips that you could use on your everyday projects. Yeah, that's pretty much it. There are a few more concepts that I typically cover as well, which include things like, what happens if there's a defect in your production line? What are some of the things, yeah, like the defect there, right? So what would you typically do in that case? How best can you build quality into your production system as opposed to have QA at the very end, right? So there are some of those things. There are lots of Lean principles that it's good to read upon because it's not only specific to manufacturing. There's a lot that we can learn from it and use in software as well. So yeah, that's me. I hope you guys had fun. I know it was a little, thank you very much. Take care.