 So, hey everyone, I'm Avinash Rao, I work with Cognizant, I'm here to present a case study, we call it the double helix model for lean agile. It's what we're doing with large projects, 70 people, where we're moving from waterfall to agile lean model. And basically what I want to cover is, we'll start off with a few war stories. And then some of these war stories really will give you a sense of the thinking that has gone behind what we are trying to accomplish in the project, the perspective that we're coming in with. Then we talk a little bit about how we've implemented lean agile and then we look at the double helix model and the results and the reflections that have come as a result of this model. Okay, so those who were in Scrum Bangalore two weeks ago have heard this story. So apologies, but I think it really makes the point that I want to. So I'm at Taekwondo Greenbelt and I started learning three years ago and in London I went in into my Taekwondo class for the first time and there were two of us who were the real oldies in the group, meaning we were over 30 because everyone else was in college or in high school. And so my sparring partner on day one was a motorcycle mechanic. He had this guy's black hair, but he looked a little bit like that, but he had blonde hair, blonde ponytail and he was this much taller, biceps, tattoos all over. And so the Taekwondo instructor comes in and says, Avinash, now throw Ian on the floor. Ian is going to try and choke you. What you need to do is extricate yourself and throw Ian on the floor. Simple, right? You have 15 minutes. And so I spent the next 15 minutes like this and I couldn't move him. He was clearly heavier, he was clearly stronger than I was and there's just no way that I could extricate myself for get through this guy on the floor, right? So 15 minutes later the instructor decides that I've had enough and he comes over and he says, You know what you need to do? There aren't any muscles here. So everybody, what you need to do is he has your hands here, pinch, twist, trip and he'll fall down. And 30 minutes later that's exactly what I was doing. So the point I'm trying to make here is that some of the challenges that face us are hard work problems. We can work very hard and we can, you know, go to the gym for two years and hopefully after that we might be able to move this problem. But a much better way to solve these problems are using techniques. And techniques give us results which are much better, much faster for a certain type of problem. And I think too much of what we are doing with agile, with lean in India, we try to, we try, we take everything as a hard work problem. Our guys work really hard. We're committed. The team's spending 20 hours a day in office. You know what, you can't beat this guy, working harder. So we need techniques. So I was managing a large program out of London in the last few years. And one of the things that I often saw was that when we were working with teams offshore, there's always this pattern to the iteration. In the beginning of the iteration, the team comes in, they're fresh. They'll take a look at, you know, the LLD, we need to start working. We do a bit of analysis. Then everybody knows that the end is going to be a slog. The last few days when all the code comes in from the 12 teams, then it's going to be a crisis. They're not going to go home for three days. So the middle of the iteration is when people compare notes. They say, you know what, Meenakshi Mall, Vanargata Road, Wednesday evening, 100 rupees ticket. So take your wife. My test lead actually used to say that. He says, week one of the two-week iteration on Wednesday. I'm taking my wife to the movie because she's not going to see me from Friday to Sunday at the end of the iteration. And you do that over 24 months and people seriously start to burn out. This isn't sustainable. What it does is that it creates a constant pressure long-term on key people. And this is where one theme that's going to recur constantly through my presentation, which is that the team that we have here in the offshore typically services industry isn't uniform. You have some people whom we designate as heroes. And the heroes are the ones who are getting the releases out, iteration after iteration. And on top of that, the managers are focused on pyramids, velocity that's in the contract, the guys we've gotten in from campus. We tell them, 80%, you don't pass your exams. We don't complete your probation. You can't join us. And us can be cognizant. Infos, I mean, I don't think there's too much of a difference considering I've worked in most of these places. What we also do is, 18 months, this guy is now, he's more valuable in a different project. So why don't we pull him out? Because we constantly want to replace our most more experienced people with freshers. But what do you do on longer term product development projects, which are the kind of projects that I typically look at? So these are projects which have anything between 70 to 150 people. These run for a minimum of two years. Their vendor spends are about $15 to $20 million. And it's really hard to do those projects given all these. So we need to do things differently. Now, this is some of the perspective. I'm going to change tack. We no longer talking about the current project. But I was in a Nissan factory in Japan where they were doing automotive components. And then Andon went off. I hope most people know what an Andon is. It's a red amber green light that's typically used in Japanese production floors. And if there's a problem, they stop the line with a red light. And it doesn't happen very often. But it just happened that the red light went on when I was visiting. I said, great, right? This is what we've always read about in books, that the team gets together. Everybody looks at the problem. We put something in place that will prevent it from recurring. And what happened was nobody moved. Andon went off. And then everybody just stood there. And then four people came quickly walking by. And they started doing some things. And I asked my interpreter, because nobody spoke English there, said, what are these guys doing? Why isn't everybody getting together, looking at the fault, trying to come up with a solution, right? Which is what we do in retrospectives. We get everybody together, look at the problem, see what the issue is. And the gentleman who was taking our tour, he said, why would we do that? That is such a foolish, romantic notion that you've got these people whose job it is to do the robotic equivalent of six turns on a monkey wrench, and you want to get them together to solve a fairly complicated production line? Yeah. OK. It's back. OK, so essentially he said, why do you think it's OK for people to come in and solve that? Because we have specialists who are trained in the modalities of solving these issues. In analysis, they know the history. They have the data. Won't they have a much better chance of identifying what went wrong and putting in procedures to fix the issues than get in a group of people and hope that they come up with a solution? It also gave me a very data view into process improvement in a tightly scripted environment. Now, what happens in a lot of early agile projects was you had a very, very high-skilled team. But as we've moved it to the mainstream, often our teams are uneven. We have all the issues that we've looked at in the previous slides. And also, you have hard and soft scripts. In India, what typically happens if you compare it to the teams in the UK is that people tend to defer to authority a lot more than you do in other places. You know that everyone's equal in a scrum team, but you also know, if you look up the designation in Outlook, that this person's a senior manager or this person's a whatever, and he or she is getting paid and is designated at a different level. And that's always in people's minds in India, more than in other places. And there are also hard scripts. Organizations, I used to work for a company that constantly rewarded people who logged in the office, FaceTime. So people made sure that they were required in the office because that's how you get promoted, right? And that's a script inside an environment, in an office environment. And that comes into view when we're talking about some of these dynamics. So finally, one final story, and then we'll get into the project, which is that I was hosting a different Japanese company's corporate strategy manager and hosting him in electronic city. And he wanted to make a call to Japan. And so I took him to the reception. And the receptionist didn't know what the Japanese country code was. And then you need to put in a zero. She didn't know how to handle that. And this gentleman turns and looks at me. And he says, Avinash, this is the future of your country. What do you mean, this is the future of your country? And he basically says, I thought Japanese were polite people, right? Clearly not. But essentially what he said was the same thing happened in Japan in the 60s and the 70s. The economy grew so fast, there were so many opportunities that there weren't time to train people, which would happen in a slower growing economy. What happens is that if we didn't need so many receptionists in Bangalore, you'd have everybody could qualify from, I don't know, there was a school when I was growing up that taught people country codes. So you'd have to certify as a receptionist. And then you'd get a job. And you'd know the Japan country code right off. But he said, any economy that grows really, really fast, like IT is growing in India, forces people to weigh beyond their level of capability, their level of training, much faster than in a slow growing economy. So if somebody would be a scrum master in the UK, we'd give them a lead agile coach in Bangalore position, which has nothing to do with their skills or their ability. It has to do with demand and supply, that they just happen to be so much better than the other people, plus there's just so many positions open that we have to fill. Otherwise we can't build our customers. And so he says, one of the things that he said that has stayed with me, and this was nearly four or five years ago, is that he says, therefore what you must do is that you must have a system which compensates for the capability of your people, which means that in this particular case, if you had to dial Japan, that would be a world map. You hit the Japan country icon, or you search by J, which needs a much lower level of skill. And the country code is populated. You put it in and the system recognizes that the leading zero, take it off, dial the number. Which is where you need systems and processes that compensates for some of the unevenness in the people. So full disclosure, I think too many agile teams offshore. I mean, water falling, we fill too many iterations with one big rock. And then we say, that's what we're going to deliver in this iteration. And I have a background. I was a business process re-engineering consultant much before BPR became a bad word in the US. And I look for data everywhere. My wife says, you're not spending enough time with me. I say, what's the benchmark? For a reasonably successful guy who has a flourishing career, how much time am I expected to spend with you? What's the benchmark? And then I Google, how do you spend more time with me? So I look for data everywhere. OK, so lean agile. One of the things that's happening in lean and agile is that there are companies. And I was very stuck by a presentation that the NDS guys, now part of Cisco, that they made. One of the things that they very fundamentally said was our business is so fast that we must be agile to succeed. And that, I think, is a very, very key driver of why they've done really well and why they've succeeded. Often what happens is a lot of the customers we work with contract through the procurement teams. Still, there's a lot of IT contracting that happens with a very procurement mentality, which basically says lean is a synonym for save me money. And agile is, so it's not perfect, but make it happen. There's just too much thinking around lean and agile that's become polluted with contracting, with notions of velocity, and how much we will deliver. But that's just a background thing to keep in mind. But the lens with which I approached this particular project was, we know all this, right? Everything that we've said up to now is a given. But we play with the teams we have. Doni doesn't, unless something's changed in the last three overs, doesn't seem to have a bowling attack which can contain Australia to less than 350. But we play with the team we have, and under imperfect conditions or under imperfect contracts. Now, what can we achieve given these realities, especially given that offshore is now expected to be efficient and effective? Now, there are many people in the audience who have more experience than me. But when I talk to my team, a lot of my peers remember a time when offshoring was easy, because all we were expected to be was cheap, right? I actually remember one sales conversation. This was about 15 years ago, where the person said, yes. And person offshore delivers about 50%, 60% of what you'd expect a person on site to do. But you get it for 20% to 30% of the cost. So there's value. But those days are gone. Nobody now is saying, you give me less. They're saying, how can you give me the same thing for lesser than the price, because we have a 10-year relationship. You need to do continuous improvement, et cetera. And this whole procurement mentality of constantly decreasing costs. So how can we be effective in a world where people demand effectiveness but want to pay for efficiency, where we want to contract based on velocity and measurements? And a few years ago, I remember there was a big discussion around Gen Y, how Gen Y is going to enter the marketplace, and all our worlds will change. Because apparently it was to be the first generation that's grown up with economic prosperity, plus out of the shadow of the British Raj and no shadow of colonization and all that. So they were supposed to be this really confident, self-driven people who will come in and change India. I don't see it, to be honest. The people who are coming in behave exactly the same as the way people behave 10 years ago. I've been recruiting off campus for the last 13 years. And while there's been some change, but not that much. We still have people who expect to be told what to do. And that becomes a huge problem when we want to move to real agile and team. And an added consideration is that too many agile teams on large-scale, long-term product development are burning out. They are delivering value, but at the same time we don't want people to burn out. And that's something that we want to accomplish as well. I love the sound of my own voice, so I'm gonna find it hard to finish my childhood. Let's see. Right, so our, so the double helix came out of a discussion I had with another agile coach who also works in Cognizant. And I work on a program where we're building a large reservation and inventory system for the hospitality industry, it's a multi-year program. It failed completely the first time and they tried to do what they thought was pure agile. Right, they hired agile coaches. People came in, spent a lot of money, spent a lot of time and the program was scrapped completely. So this is iteration two. So there is a very strong need to be effective because failure is not an option. Doing this in waterfall in my professional opinion as a agile coach is a recipe for failure. So that really wasn't a complete option there. Also the effective, there's another program where which the other agile coach manages and what they do is that they've been delivering using agile for the last two years and they've been doing it very, very successfully. Now what is happening now is that the customers coming back and saying, okay, your agile, great. Now how much money are you gonna save me this year? Okay, so they're under pressure to increase velocity, reduce cost, et cetera, from their customer which in turn is disturbing some of the agile practices and the teams that they have put in play. What we wanted to do was use techniques to achieve success in these imperfect conditions. So the first step that I did and when I came in, the team was entirely in waterfall mode, pick up something, absolutely no visibility and then they were used to working in silos. And so I said, we need to do visualization, we're going to do scrum, we weren't truly agile because the customer side, we didn't have the product owners, a lot of that in place. So we said, at least let's do iterative development at the first step, but let's do visualization. Let's look at where the work is and essentially this is what happened. So I was standing there in front of the teams every day saying, this is visualization, this is how it will help your life, this is how it will add value to your careers and everybody stood like that. So it didn't work very well at all, honestly. So what we wanted to accomplish was to get some deep improvements in addition to the shallow improvements that we were seeing from a lot of the retrospectives. So the retrospectives were giving us limited improvements and they were based on field rather than data, meaning that people would come in at the end of the iteration and they'd say, what went wrong? And they would say, the VPN went down, right? And that was a huge problem. What can we do about it, et cetera? And we also wanted to recast our heroes and give managers something else to do other than pushing people using the hard work mentality. You've got a big problem, work harder. Why don't you come in during the weekend? I'll give you a comp off next month on the day of the India-Australia match, but you would believe how many of my team members are sick today. Yes, I will go into that in more detail. So if you think about... So one point I wanted to mention before I got to this point, was that one of the things that I heard in the Nissan factory, if we go back to that example, was that the fundamental changes to the product, a lot to the production line, a lot of the improvements come, which I'm calling deep improvements, which fundamentally change what the process accomplishes, come out of a small group of people who are professionally and deeply trained in many of those techniques. But it just doesn't come out from a random collection of people. So what we did was that we structured two teams. One, we call it planning and execution teams, but the planning team focuses on the deep improvements and the execution team focuses on the more shallow improvements. But in... And one way we sold it to the team was that, you know what, Spotify, have you read that article on Hendrix blog? You know, they have guilds. So why don't we think of it as a guild that looks at deep improvements and a guild that looks at shallow or ongoing improvements? And we spent a lot of time training the team. We started with Lean. We used the Shingo Lean Bronze certification material in order to train the team on Lean. And Kanban, we used Kanban tool to visualization for each and every activity, including setup, as well as any development task. And we also trained the team on Six Sigma because we wanted to move away from people making statements based on what they felt or what they perceived to statements of fact. And we also did a lot of work on mind mapping, all communication and information flow from my past work as a BPR consultant, right? So we looked at the whole thing, looked at what the bottlenecks are, et cetera. So this was done with the planning team, which is a small group of people who have not been picked because of their designations. It's been picked because either they volunteered, most of them are developers or leads. Interestingly, none of the architects volunteered, none of the managers volunteered. So I lead this group, so I meant. But we also looked at what's value from the perspective of the customer, meaning what's value add, what's non-value add from the customer. The work that we're doing on a daily basis, everybody's spending 10 hours a day in office, right? So that's completely different from spending 10 hours on tasks, which add value to the customer. And we wanted to understand and identify what each of those tasks were, right? Okay, so why do we call it double headaches? And that seems to have thrown a lot of people off because this morning there's somebody who said, shamelessly went up and I said, are you attending my session? And he said double helix sounds scary. I don't want to be a part of double helix. And I don't see that person here. So clearly my sales technique, oh, he is here. Oh, thank you so much. Come here, okay. All right, I hope we didn't have the opposite problem with you that you thought of something else. So what I want to do, because I'm very keen to spend some time on question and answers, is that I have a few slides here that show the output that we achieved with both deep improvements as well as with shallow improvements. So I'm going to go through these in the next about five, seven minutes. And then hopefully that will leave us about 10 minutes for question and answers. So one of the things that, once it picked up, a lot of people who were trained in Kanban said, why can't I use that as part of my scrum team? So what we did was, and I spoke about this in more detail as a full session at Scrum Bangalore two weeks ago, is that we looked at the output of a scrum team versus the output of a scrum barn team. So once you visualize all the activities and you start picking up items, if you do that on a constant basis, how much does your throughput improve? So it's zero one by 16%. We consistently seeing a 16% improvement in throughput if we do scrum barn. We also measure flow and value added and non value added. The blue lines in both iterations show what is the amount of core activity that the team performs in different iterations. So if you look at that one, it's not that the team's going home much earlier towards the end of the iteration than in the beginning of the iteration. It's just that the core tasks that they've worked on really finish somewhere around here. And after that there's a lot of non value add tasks, many of which we've looked at removing. In the second one, this is our famous VPN outage which led to a drop in the core activities on that particular day. But then that's from the scrum barn team and you'll see that right till the last day they focus a lot more on the core activities. So we use charts like this and we review it with the team twice a day. We stand in front of the board morning and evening and we look at these charts and we say, what happened here? How do we bend the curve? How do we focus more on activities of the core, non core? And it's a process. We look at it and what we define as core or necessary or non core will change as you work through this with the team. But what it does is that it gives an excellent way for, for all of us to speak the same language. So what we do is that we have a common vocabulary and people use that in discussing these charts. What the team also did is that they said, we need TRD because we're wasting too much time on defects. We write code, then we fix issues on that code. Then we put it in for integration or J units, then system level testing and this defects everywhere. And we identified that as a huge problem in our context. And so what they did was they wrote a development or they wrote a tool really. What they came in and they did was they offered me a deal. And this is the problem with empowering teams, right? Because once they feel empowered, they really feel empowered and after that the managers irrelevant. So they said, here's the deal, Avinash. We're going to change the way we've allocated work. We're going to free up one architect and two people who are going to form a small tiger team. And we're going to write a tool which will auto generate our J units for us before we do a line of development. And they did that. And the point I'm making is none of these are my ideas. None of these are the ideas of one person in the team. But it's just that when we put these processes in place and start these discussions, a lot of great ideas come out and the team decides how to implement it and that's what I think drives a very big difference in the way the team is structured, in the way the team thinks. One of the largest changes I've observed is in the people who become part of these tiger teams because they're really developing small products by themselves with an architect. And suddenly when they come back into the development stream, they're different people. Not only are their technical skills much better, but now they're thinking in terms of, this is a product, this is how I finish it. These are defects. And so they're just more complete agile people at that point. So coming to shallow changes of what we think of as things that we do on a day-to-day basis is that we have three problems which we've encapsulated here and we all say these are things that we won't do. And if anyone's familiar with the school boy problem from Supply Chain, to give you an example, my daughter gets summer holidays for 60 days, right? And she has holiday homework which takes five days, right? So on day 55, she decides to start doing her homework. And then I don't have my pencil, I've lost my notebook, my friend has something else, et cetera. So that takes it into day 56 and she finishes on day 61. And the teacher says, I gave you a task for five days and you had 60 days to do it and still you were a day late. And believe it or not, it's very common in supply chains and it's called the school boy problem. So the school boy problem is an important part of how we address a lot of our day-to-day improvements, right? And once people get this into their heads, I've seen team members call out saying, don't be a school boy, start this task. And that's a huge improvement. The other thing that used to happen is that people come in at 11 and they start working on something, they get blocked. So they go for lunch. Then they come back and they Google some stuff which doesn't work, then it's 4 p.m. Then they ask the lead, the lead's busy until six. And so essentially a day of productivity is lost because people haven't followed the one hour rule that if you're blocked for more than an hour, ask for help. And that's something that we're doing a lot more with our boards, with the visualization because two times a day we're looking at what have we done since last, last time we did a checkpoint. Also, and I think this is a critical piece is that a lot of our estimation depends on averaging. We believe that some of our items will finish sooner than anticipated. Some of them will finish later than anticipated. And therefore we say here's our overall estimate for the project. Now, if something is sized at seven days and take eight days, it affects the project buffer. But if something takes seven days but finishes in five days, what happens? Nobody gives us back those two days because the developer knows that he or she has seven days to finish this task. And therefore they just give it on time on day seven. So if you have a scenario where your average is defined when your estimates, you feel the pinch of late completes but do not capture early completes, then the probability that your project is going to be late is pretty close to 100%, right? And this was a huge problem for us and it's not a very obvious thing that we saw in the beginning. But as we went through, this was a huge reason why I think people are looking at this and they see value in this whole process. And once we quantified the VPN outage, we realized that it was about 4% to 6% of the overall time that was being wasted. So it wasn't as big a deal as many people felt it was. Now one final slide. So why I think this has worked really well for us is that the product view for developers and tiger teams, scrum masters are now recognized as real roles because in the beginning everybody thought of them as overhead and that I think is a big transformation. This team ownership, now when we pick up a large development activity, the lead automatically creates a board for visualization and emails me the link and he or she says, look, you can just verify what we're doing or you can take a look at what we're doing. Things that I worry about is that I think there may be scope for beta errors in identifying people for the various process improvement tracks, which means that an alpha error would be, we picked somebody for process improvement and they couldn't do process improvement. But that becomes obvious very soon. We haven't made too many alpha errors, but the beta error here is that there is somebody who's actually really good who can contribute but we haven't involved him or her in any of these activities that we're doing. What the board also does is that it very ruthlessly exposes people who aren't as good or as committed in a very social setting because everybody can look at the board twice a day and they know exactly what's happening. So that was my presentation on the double helix model. So I've managed to keep it with 10 minutes left for question and answers. So I'm happy to take any questions. It's a tool called Lean Kit. So Lean Kit is a Kanban board essentially and we put all our tasks, including setup, construction, everything into, so elaborate on that a little more. Okay, so if you look at the issues we have with the schoolboy problem, the one hour rules and the capture early completes, we see many of these as shallow improvements because they are ways of work that can be changed within the team, right? The team can change this without needing support from anyone else outside the ecosystem. And the deep improvements we look at as something that fundamentally changes the process which needs approvals or investments. So in order to create a tool which has started us down this path of TDD, that needed us going to the director making a case saying we won't affect the volume of work that's happening but at the same time we want to do these three people to go away in a corner, complete the tool for three weeks and then come back. Now that is not something a lead and the team can decide to do by themselves. That needs some buy-in from the larger ecosystem and those are the ones that we fundamentally called deeper improvements because that must be done in the ecosystem rather than in the project. That's a fundamental decision. So a lot of the work that we, I didn't put the number up there because you'd think my team was totally incompetent but it's actually not very uncommon for people to have 50% to 60% of their time being spent on wait times, idle time or on non-value activities. So when we did our analysis, we found that almost 50 to 60% of the team's time was being spent in non-core activities, right? So once we cut down a lot of those, we were able to free up a lot of time as well as focus the team more on activities that actually give us throughput. So you'll be surprised but through this entire process, the team went home at 7.30 where they were going home much, much later and 7.30, you need to keep in mind that they come in about 10. So a lot of them were on waiting for the lead, for example, was a huge problem because everything that came in when we did our whole process flow, we found that a lot of people and items in the ecosystem were waiting on the leads. So the leads were a bottleneck. Anything that would come in from outside or for the customer would come to the lead and queue up. And the developers would be waiting for technical clarifications, they'd be waiting for work assignments, they'd be working, waiting for hardware requests or anything like that on the lead. And the lead was a bottleneck which lost our developers and are here for 45 minutes here. It wasn't that they wasted the whole day but it's just that their days weren't as productive as they could be because of all these delays. So the delay is one thing. The other thing is that the rework is non-core, meaning that you could have done something right first time which is the huge thing with TDD, that it eliminates a lot of the rework in the process. And so that's non-core, it's a big part. What we did was we assigned each of the, so if I may, it's too much in the corner, but essentially what we did was that we de-bottlenecked the lead by assigning two people to play the role of task assignment, clarifications, et cetera. So essentially we doubled the capacity there and we said that nine out of the 10 teams that currently stand with the lead don't actually need the lead to work on it. The other person can do it. And this person was a senior developer whom we identified in each team and tagged along with the lead. So one of the things that my manager asked me was that by taking away one developer, aren't you actually reducing the teams through port, right? Because you've taken away a developer who's no longer spending 100% of his or her time on development or on testing. And that didn't happen, our productivity is through because we were simply wasting so much time on the queue items. And it'll be different for different projects. My bottleneck won't be your bottleneck, won't be somebody else's bottleneck. But I think the process by which we apply this and then we start the discussions around the bottleneck, I think that's where the van goes. Okay, what I meant by that was when we began the process, we said that, so this person, whoever it was, is a scrum master. Everybody said, why do we need a scrum master, right? Can't we have somebody doing it part time? Is it a real role? The scrum master has no technical skills, so therefore what's the value? And all those questions have gone away because people understand what the scrum master does and the value that the scrum master brings in combating many of these. Agile actually works really well because inherent to agile, some of these problems are addressed. In Waterfall, you can avoid problems for months and in Agile, you're forced to confront them at least once every two weeks. I think a lot of what Lean and Kanban do is that they bring that down from the two weeks into even smaller time periods so you actually waste less time. Does that make sense? So that's an artifact of where we were. We were in Agile, sorry, Waterfall methodology where the team expected the team lead to assigned tasks. So I'm not saying that's a good thing, it was just how we evolved, that is how it was and we slowly brought it to a more, that the team can look at what work is there, pick up the work and then decide what they could tell you. Is your Kanban board helping you identify your current bottlenecks and if yes, how? So the Kanban board, we use the Kanban board to enforce the WIP of one. So we enforced a WIP of one from day one and we said that if you pick up a task, you complete it, move it to complete production ready and then you pick up the next task. And the bottleneck we were able to identify when we did the, the bottleneck was very obvious to be honest. I think the challenge will be once we have done this exercise, it'll be interesting to see what happens in the next six months because then the secondary bottlenecks will emerge which won't be as obvious as the ones that we've sorted out. So we'll keep looking for those. Any other questions? Why did we have it twice a day? It's to bring people into following the one hour rule. Essentially what was happening was that we had the stand up and then we would discover problems in next day stand up. So we effectively lost a longer period of time which we, it's a trade off between how quickly do you poll people so that you identify where you can help them to the time lost if you increase the time period. So we found that once a day wasn't enough because it enables us to catch problems twice a day instead of once. A lot of, and this may be a service company phenomena, a lot of managers have grown up from being developers to leads to being managers where they see a task as being coding. They see coding as a task. So even after they become managers, they tend to look at, okay, so here's the thing. Is it coded? Is it tested? Rather than what's the process? There are very few of them and we're trying to change that with the next set of promotion because over time if you promote people who drive people and get work done, you will get the hard work managers in your ecosystem. If you promote people who can change processes to achieve outcomes, you'll create a different culture and that's the shift that we're trying to do. Today I think too many people have come into management by the hard work approach. I think that's the best I can put it. They're just used to working really hard, let's work weekends, they're too eager to work weekends and that's a problem. For me that's a problem, if that makes sense, yeah. How did you manage the motivation for the team in following all these processes over a period of time? I think it just dives down the motivation level generally. I take your point, but the way it's played out is different from the way you've asked the question. I don't think people die down in interest or people who tend to be interested in process, improvements, et cetera become a part of such initiatives. The projector light is very bright, sorry. But what happens is that the risk here I think is in creating a class of people who are winners and a class of people who are losers. The winners who are, I mean, part of these teams and the losers who are not part of these teams. That I think is the real risk. The risk isn't that people are losing interest. We haven't seen that. To be honest, if you use many of these teams, you can easily finish it with a 20% to 30% faster than if you use waterfall. And I think we're using that as one as buffer and two as capacity to do our improvements. So we're not giving it back. We're using the same old methodology. We finish faster. Therefore, we take out some of that to do improvements. We use the, honestly, I don't know. I don't know, that's okay to use it. I know quite a few projects use it, but I don't know what to do. So I think, so the question is, why didn't we take Scrum Masters who had technical knowledge than non-technical knowledge? I think Scrum Master, and this is my view as a coach, the Scrum Master role needs people who have a competency that's different from is a brilliant Java programmer or she is a brilliant Java programmer. Brilliant Java programmers tend to be very focused on helping the team complete the task as opposed to how can we make the team successful? And I think it's a slightly different orientation. And I think people are very good who are very good at one particular area. It's not common for them to have very good people skills or team skills. So that's just an observation. It's maybe the kind of people. Otherwise, we're on time. It is 12.30 and yes, I did have, this is our double helix. We've very heavily brought in items from both Scrum and Lean. This isn't a classic agile implementation. We don't have a customer PO who sits with the team on a daily basis. We don't have that yet. We want to get there, but we are not there yet, but we've brought in a great deal of stuff from Lean. And at that time, it felt like a good idea to call it back now. All right, everybody, thank you very much.