 What a pleasure it is to be here today. My name is Alan Rotson. I come from Chicago area I work for Nokia. I work in the maps division and I have a colleague with me today Sunil Roy from Nokia maps division Mumbai and Both of us are playing the similar role He's from the agile working group. He's managing the agile working group in Chicago I'm doing the same in Mumbai and we are talking about the our journey from waterfall to agile. Yeah So today in 45 minutes We're gonna try to give you the high points as many as we can of a four-plus year journey that we've had in our Transition from waterfall to agile So while we go through this slide there Sunil Thank you. So as we go through the process today Very simply we're gonna give you a little bit about the past What kind of environment were we working in at the time before we made this decision to go to agile? How did we go about doing it? We kind of used the pilot phase. We'll talk a little bit about that When was that moment that we made the decision to do the rollout? How did that go? Where we are today? What's our present state and where we would like to be? in the future So this all started because of the fierce competition in the market where competitors were coming in very fast on us and There was a chance that we could have lost some of the some of our market share to our competitors and we didn't want that to happen so and Previously we were in a comfortable zone where most of our products were aimed towards the automobiles Later on it went to personal devices which made the competition even more difficult or more Fast-changing and more fierce and then it went to mobiles which made it even more fast-changing and even more Fears and that made it all the more difficult for us to stay the way we were so that and One of the reasons we thought that it's it's really time to change from the way we were operating to a new Way is because we had a very long lead time from product inception to product delivery to the customer and it was a very long time that products would finally get delivered to the customer and in the in the frame of things where mobile was driving the business To a large extent it was just not possible to Go go along with the long lead time. Yeah, so that's correct So what we had was changing competitors very aggressive competitors because our market was changing and our executives knew that back one We went too far Okay, sorry go ahead. You're right. So What was it? I'm ahead of myself. Go ahead a slide. Thank you very much. Okay, so how were we organized? Why why was it that we weren't ready to compete with our competitors? Well, our development organization as it is today was in multiple Locations, we're a global organization. We had development staff in Chicago. We had development staff in Mumbai Eastern Europe and Germany That wasn't so much of a problem as it was how we were organized. It was a very matrixed organization We had a team of system analysts or business analysts requirements analysts They went by several names, but they reported it within their organization We had developers and they reported up the line to their organization Same thing with the testers and software project managers That's the area that I came out of as a software project manager and I reported up to a whole different person of those other four organizations What happens when you're set up like this, you know You get silos and the political boundaries and the people fighting for their space It's very difficult to work in that type of environment People working on multiple projects was a given you never really had one person 100% dedicated to a project I can remember going and pleading to development managers for a resource on it what to me Obviously was a very important project It was the one I was responsible for and I was told the person I needed with the right skill set I could have 10% of his time What is 10% of a person's time to work on a project? Basically, it's nothing. What was the environment like in Mumbai? Oh, it was very similar where Where if a problem came up if a defect came up or some Requirement got messed up or some design got messed up Everybody would say this is not my problem. This is their problem The developers would say it's the design issue talk to the architect the testers would say oh the coders didn't do their job Well, the developers would say, I don't know the tester did not understand the requirement Well, probably probably the requirement person did not explain it. Well, so it was all about Who to put put the blame on and it was all about this is not my issue, right? That's that's the past and Does anybody relate to that? Does anybody think about that? Anybody? Yep, so there would be a lot of hands who have either seen that in the past or still face the same issue and It was about developer versus tester mindset Developer versus architect mindset developer versus the analyst mindset and there's no nobody No single team that could be held responsible or felt responsible not what holding responsible But no there was no group which felt responsible towards the product Or there was no single group that thought about the customer in the first place the developer Very rarely had any say in what kind of product should go to the customer He had he never had a role to play in what the customer needs really He just had to take the requirement document Design document implemented not so bad really, but he did not have much say in what the customer should get He never could think about it because he was never given the chance about it The architecture used to be very rigid. It was done up front It was very difficult to make changes later because they never thought of making it flexible because it was not evolutionary in the first So they thought of the perfect architecture up front and therefore it was rigid if there's a late requirement change and everything went boom And that's right because why because we were in a waterfall environment Yep, next slide Now working too well, okay good so very strict waterfall environment, right Sunil? Yep So we had faces we had requirement face ending with a requirement document different types of requirement documents Then we had architecture document high-level architecture document low-level architecture document Then we had implementation where the coders would go and actually Coded they would do unit is then they would pass it to the testing team Which may or may not be in the same center or in the same location It may be somewhere else or it's a separate group or together And then they tested they report the report back the problem it goes right back to the development team These things have been a have been happening over decades right and you know that and we know that everybody knows and then it goes to deployment if They they were lucky enough to solve all the problems Right, so this was the earlier state So this led to the issues that we were having why was our competitors beating us to the market We are an innovative company. We had the same great ideas that they had but they were continually beating us to the market Executive leadership recognized this and they realized there was a do or die type Situation they took it that way and I I think that really helped us be able to move forward And they went to their management and said Their senior leadership said there's some things we need to do and we need to do it right now We need to reduce our cycle time by 50 We need to ensure the quality of our software There was one niche that we had That that we were beating our competitors in it was the quality of the product that we delivered and that could not That could not go back no matter what we did In fact, we need to continue to move that forward. So with speed to market initiative Was initiated at that point and this is late 2009 early 2010 And it wasn't necessarily thought of oh, we got to go agile at this point It was what do we have to do to our processes? product development software development delivery To reduce that cycle time by 50% So management was driving it right from the beginning cco the ceo and senior managers right on down the line And and just to elaborate what he said about the quality the quality that went to the customer was top class But yes within the development organization or within the development group There was some defects found which the testers would catch and we had multiple levels faces of testing because of which the ultimate product that went to the customer was good But there were some defects found defects found in the development stage and we wanted to improve that also. Yep so there was Something happening right around the same time Agile was starting to creep in Not officially We had a couple of unofficial under the table agile projects In fact, we couldn't even say the word agile or scrum It was if you had to say it at all you called it. Well, we're trying an iterative process I was lucky enough to be Leading one of those under the table didn't make a lot of splash Higher up than just my immediate manager But there was a project that I had that never could get off the ground Every time we got into the development phase if we got into the development phase within a month We had to stop and what do we had to do go back to the requirements side I had a consultant working for me. She was knowledgeable in Agile scrum. I had no No prior understanding or readings or anything about it at all I thought let me give this a try. We've tried it the right of the way three times and it failed Convinced the development manager to give me two people full-time unheard of In the testing manager to give me a full-time person Put them in their own room The consultant guided him. She kind of acted as their scrum master I got the requirements analyst on board We picked out the highest Business value that he could define out of the the document that was this this big Restructured it as you should into meaningful stories In nine sprints 18 weeks We delivered something on that project in the previous 18 months. We could not So I knew there was something there. We were getting good results with some of the other under the table projects And we presented that when the speed to market initiative was kicked off My manager and some of the other managers presented it as an alternative something we should look into And the wisdom of the the senior level manager said let's find out more about it brought some consultants in in 2009 heard about Agile There was still You know boy, is this really the right thing to do a lot of people put a lot of time and effort into building our Gated environment our waterfall environment And we were a large organization We did some of the research on our own. We couldn't find many Concrete examples of where agile was used in large organizations Scaling hadn't taken hold yet. So it was you know small small organizations team by team thing but There was something there we could see it We said we'd give it a shot unfortunately this under the table Agile tries or trials could not be done in Mumbai center at that time in those days because The Mumbai center was still in a service organization mode. We were not yet part of their organization That's correct. We were part of a different organization working for naptec or no k maps division Later on we became no k maps. So now we have no k maps employees, but back then we were not Yeah So pilots were the way to go And we presented agile to the larger organization And this is this is the reaction we got you got to be kidding, right? It's going to cause us more issues Then we've got right now There's no structure to it. We're going to go back to the old ways. We spent a lot of time and money Getting us to the process that we had training Resources and now we're going to go back to the cowboy ways And again other things we talked about smaller companies Can't put it in a large company What tools are we going to have we're in multiple locations large teams And why should we be on the bleeding edge of doing this kind of thing? Why don't we just wait to see how it all it may never be anything? To begin with but we address those initial reactions Went forward with the pilots Next slide. Thanks started small three teams in chicago early in 2010 But word of mouth started to get it started to get out there The teams were starting to enjoy what they were doing The stakeholders starting to enjoy coming to sprint reviews We actually had to go to larger rooms because we were getting overflow Overflow crowds into the sprint reviews because they loved hearing what was happening what was progressing Two weeks at a time After two after two months seven projects were now In a pilot phase and we had reached our limit. We had one outside consultant No external coaches and a group of Volunteers we still had our day jobs. I was still a software project manager. That was my daytime job I was working as much time as I could to help support these agile Pilots that we were doing the scrum pilots that we were doing But there was some pilots going on in Mumbai too. Yes, so two pilots started in Mumbai at the same time because now there was More acceptance among the senior management to allow these pilots. So two pilots started in Mumbai also So we the agile evangelists started helping them helping them and grouping them as a Self-sufficient team like there would be developers there would be testers there would be a The analyst would turn up as the would become the product owner the architect would get mapped to the team So we created a few co-located teams to make sure that they are self-sufficient but That was not enough. We had to support them For a few sprints to get them going and That helped us a lot so the pilots were over and the results were fairly positive And senior manager wanted to know what could we do next? What should we do next and we presented the results? And we told them if you want to go forward if you're happy with what you're seeing It's got to be a full-scale rollout. It's got to be through the organization This is not going to be five teams in one program three teams in another and it an organic type of growth. It's going to be a organized rollout at the organization level You're going to have to stop getting part-time people working on this project You're going to have to develop a team of people called the agile working group And they're going to drive what the organization needs. So we form that We're going to need more outside expertise. You can't expect the people we have internally to know everything there needs to know We brought in expert coaches We built our own in-house training Not that we needed to be different than The teachings of agile and scrum, but there were ways that it need to be Implemented in our organization and ways that it worked best in our organization and we realized that and built our own training We brought in more experts more of the Subject matter experts in their field for the certain things that they could bring to our company Dean Luffingwell, Mike Cohen, Esther Derby Mary Papandique and Joanna Rothman It's a thrill today when I come to conferences like this and see These these folks again and again And know that they were in our offices Working with our people training consulting and guiding us And as a matter of fact, I'll tell you a little story at this point We were running the pilots Got started into the rollout and there was one layer of management that was very Still hadn't came full bore into what we wanted to do the executives were on there and obviously the The first line managers, but the vps especially in some of our product management areas and sales areas Weren't on board at all. We were working with dean at the time And there was going to be an off-site retreat for the the vice president So we asked dean for his help and how can we Move this group of people Dean kindly got down in front of the camera gave us a 12 minute video And that that 12 minutes Sold it We still have that video today dean And from time to time we go back and revisit. It's a powerful 12 minutes We brought those group of people on after that and Things move forward much quickly We wanted to always to know how we were doing during the rollout. We used a tool called the Excuse me the comparative agility assessment. This is a Kenny Rubin's organization that does this It's a great tool About a 60 some question survey team by team level and it compares Eight dimensions of agility Against the market against this industry that a large database that he's growing if you haven't heard about it I suggest you go out there and look at it. We've been able to trend how well our teams are doing in all of those dimensions of agility Robert Abernathy was up here talking about bad apples We found those guys But we didn't ignore them We sought them out And we talked to them and many of them converted over There's always a few that's not going to and that's unfortunate They need to go to another place to learn how to do their imply their trade But in the most part people realized that they could work with this environment and Sunil what was some of the uh The processes of the rollout in Mumbai. Yeah, so here's the thing in Mumbai. What happened is after The pilots were hugely successful The talk of the success of the pilots started exciting the other developers developers by by now developers I mean people who code people who test everybody and that was the talk of the Center at that time everybody was discussing at the lunchtime or coffee time as to what exactly are they doing they try to Other people try to understand what what are the challenges? How are they facing it? How are we helping them cope up with those challenges because The agile transformation did have challenges and how are we helping them cope up with it? So those interactions helped them to understand that it is a possible Transformation and agile is possible And then we also started talking to the other teams to find out What what kind of readiness they are in and when the rollout became official Uh The the way we started is we selected few teams from every program Got them into agile and scrum mode Help them become co-located teams and started the same Repeated the same process to repeat the success again and this the second round of success was actually the point where we really took off So what were some of the premises that we took on when we were kicking off teams? well One thing I was obviously they were trained as a team And it was training that we developed in house But there was also a list of criteria that they had to meet before they could go ahead and Make that transformation from waterfall to agile It wasn't a directive that said this team This date you're going to convert. It's when teams were ready and out of every different programs We could move back and forth You had to have a hundred percent dedicated people You had to have a scrum master And you had to have a product owner and you had to have a prioritized list of requirements That can be converted into a product project backlog When a team met all that criteria Then we started their transformation process. We co-located these teams No more this floor and this floor were on opposite ends of the of the same floor They came together and one thing we did As we started to put them together we reconstructed the whole floors and created agile pods An area where eight to ten people could work together Have the tools they need to collaborate and do their work 55-inch monitors whiteboards their own personal space as well as a common space within their working area No more setting up meeting rooms or sending out emails You needed to talk to somebody on your team you turned around and you started a conversation with them this This is part of the environment piece Of a transformation But understand there are three areas that you really have to concentrate on and I think by concentrating on these three areas like we did it helped our success It's the process for sure the culture And then the environment Sunil yeah anything on this yeah in in Mumbai the way we did it is that for kicking off the for kicking off the rollout what we did is we identified the teams that have already started working in the agile mode and we made sure that all all of them are properly trained in agile and scrum and we also identified who the scrum masters would be and got them trained as scrum masters got the Product owners trained as product owners so that they they're able to Work efficiently as product owners they understand what a product on our role roles and responsibilities are the scrum masters are able to resolve the Impediments on on a daily basis and the teams are able to make decisions on a daily basis rather than looking at the manager And thinking that he will give the decision So by this time those pilot teams had started making the decisions on their own which was a big big huge win for the for Rolling out agile on a full scale throughout the organization so I think the The teams being able to make decision on their own that was the biggest biggest difference So yeah, so some of the things that changed sunil just mentioned how the teams started to really make decisions on their own But organizationally we changed too. There was changes that that occurred Coincidentally or because of the changes that we were making in the software development area For example, we have formed verticals Now we call them business groups But the product owners and the product management organization was a different organization than The development organization That changed we reorg completely to where business units now have software development And the product development groups together The pmo had to evolve It had to change as well and now it's become the agile program office I told you about the agile pods instead of cubicles. We tore down the walls We tore down those barriers to communication and collaboration After and this this gets to be really interesting because this was not something We originally planned for but as every team within a program made their transition to scrum And as they became Component at it they reached a certain level of performing We found that we had the opportunity to scale the planning at the program level Not just at the team level And this is where we incorporated release trains Again, dean leffingwell was instrumental in bringing that in you know it now is the uh safe The scaled agile framework, but we knew it as release trains because that was the terminology that we we were interested in And we and we still call it that today The and and as we continued to move forward to our agile maturity growth Um, this was proved out by the scores on the comparative agility assessment What I mentioned to you before that tool before But something very interesting happened just less than two months ago Where the agile community got together and wanted to run their own internal one day conference And it happened On the last day of january this year We held a four track Internal agile conference where the speakers Were people within the organization who came forward and wanted to speak on a topic That they were passionate about and something they wanted to share that took what their peers about And I saw at that point that we reached another level of agile maturity on that maturity curve Right so in mumbai One of the things that happened at this stage was that The agile was now brought into the whole program level The whole program was doing agile planning or the release planning or what he mentioned as release train together So they would be each team would get into a meeting room do their planning and every one hour They would the scum master and product owners would gather and at a common area discuss dependencies Discuss the progress that they make in release planning and then they they would get back to this So this way this way all the teams in the same program were planning together collaborating together for the dependencies sharing How the dependencies can be broken? Sharing how the skill sets can be skill set dependencies could be broken across the team by sharing some Like co-divorated Help from each other so the Previously each team was going agile But now the whole program went agile and they started sharing among themselves Where they would help each other in engineering practices. They would help each other in code reviews They would help each other in Certain areas of the framework or certain areas of the domain and now the program was agile And that was the fun part whether where we actually scale to a new level That that actually made us feel that now we are far better better off than we were earlier because we Still did not know earlier whether we could actually scale up to the program level And once each program started going agile the whole organization went to that's right And and let me tell you a little bit about the collaboration that we got out of the two entities Chicago and mumbai when we Incorporated the release trains. It wasn't site specific It was program specific and we had scrum teams both in chicago and mumbai And they were able to plan together and i give a lot of credit to the folks in mumbai told senile this They sacrificed to be able to be part of this We Are a 10 and a half to 11 and a half hours difference depending on what time of the year it is These folks adjusted their work hours so that they could have that two two and a half hour time slot Where they could collaborate with their peers in chicago talk about and They're planning what they did the night before while we were sleeping and then we would plan But we went home pretty much at a normal time Got in early the next morning and the folks in mumbai were ready to give us their final What they done on their final plans and turned that over to us So they made that work By by making that sacrifice and they still do it today Um, you mentioned to me it's not a it's only this one time every quarter, right? Since it's only once a quarter and indians typically are very flexible you would would all agree So it was not very difficult for us to adjust To this odd time schedules once once in a quarter So we were able to make that overlap happen And that made it easy for us to have a program level Uh Release planning together in chicago and mumbai going together. Yeah, so that that made all the difference And now it really feels like We're one program and that Two locations. Yeah, sure, right So it's no more like chicago is doing this. Mumbai is doing this It is this program taking on this kind of initiative this that program taking that kind of initiative Now everything is program specific not center specific anymore There are no center specific initiatives all the initiatives are program specific now, right? So Everything is now related to a program which again boils up to a customer So a product for a customer. So now The customer is the king whereas previously I think the vendor was the king where vendor would rule as to when he would be able to give the product to the customer So there's a mindset shift Nope, there you go. Sorry. That's all right. So some of the benefits that we see because of this transformation and of course the scaling too Is that the team morale is much higher and Something very interesting which may not be very Obvious, but something that we observed Is that the people turnover rate has gone down? Why because now they are not put under pressure by the managers saying that you have to meet this schedule Or the Planning may have been done may have gone wrong from the project manager side And now he has to protect that plan and now he puts pressure On to the teams that situation went away. Now it's the teams that plan. So they are a happier lot now So now they feel that if they go to another organization, they may not feel the same They may not feel the same empowerment again. Now the teams are empowered. They make the decisions Not that the executives cannot make any decisions They make the higher level decisions the teams make the team level decisions the project level decisions the product level decisions So the teams have their share of decisions The managers have their share of decisions and enable enabling the teams Executives have their share of decisions and strategic decisions So teams are a happier lot. That is one thing the collaboration across the organization is fantastic It's not about developer versus tester that mindset is has vanished Then The product owner drives the priority Whereas previously it was generally the sequential thing that was driving the Priority or rather the component dependency that was depending the prior that was driving the priority now It's not the component dependency that's driving the priority now. It's the business value that drives the priority So there are a lot of shifts now the architecture is evolutionary It's no more that rigid heavy-duty architecture up front that makes changes difficult. It's not that anymore It's more evolutionary But there are new teams that are coming coming on board as agile teams So for them we have to again do the whole process again So there are a lot of lot of changes. There are cultural changes that people are more open to Uh Controlled conflicts. I mean healthy conflicts previously that culture was not there It was a fight between a developer tester all the time But now it's there are healthy conflicts in the team Though we try to coach the teams in a manner that they understand what's a healthy conflict versus personal conflicts We have to coach them regularly Or to improve that aspect Then there is no more like it's not my problem that attitude has gone So there are a lot of cultural changes that has happened Uh in the agile teams the people have changed their mindset has mindset has changed The way the collaborate has changed The the way they make decisions. They are now decision makers rather than following decisions from the manager So they don't follow now They make their own decisions and they go ahead and they commit to the decisions that they make and they make it happen That's the biggest part that they they are making the decisions They are committing to it and they are making it happen that that that has made the culture change possible and another another thing that I see is that The it is very easy to now Start any new practice whether it's a new agile practice or whether it's a new engineering practice It's very easy to start now because now they're thinking in the same direction now. It's a co-located team So if you want to start a new practice for a particular project, you can do it very easily They are not five developers sitting across the floor So everything everything that you want to start any good practice that you want to start it's very easy to start So there are a lot of benefits that we have seen and as a result The speed to market initiative has been realized. We have been able to reduce our Product inception to product delivery by a huge Uh percentage that time gap has reduced. Yeah, actually it was 27 weeks, right Almost eight months that we've been able to take off seven months to take off Just as a result of what we did to change our software development process There were other efforts going on other than the speed to market initiative It wasn't just all put on the sagittal transformation But just the software development process alone we save Or cut off of our life cycle Seven months Yeah, next slide. So I think the speed speed to market initiative was realized and the the quality that takes on the quality that is delivered by each Developer is also better. It's not just the quality that goes to the end customer But also quality at each state quality that is good. So now there is a feeling that everybody owns quality previously The quality team was a quality assurance team I mean rather the testing team was a quality assurance team But now everybody in the team whether it is a product owner the The person who's coding the person who's testing the subject matter experts Everybody now thinks that he owns the quality. So that mindset shift is again a big big win for us So we're done, right? In fact, I had people come up to me and said congratulations. You you did it 66 teams 520 people 22 months The organization is now running as a natural organization at least our software development side And and some some of the other areas of the organization. What are you going to do now? You know, what's your next job? And I was like wow We really communicated the wrong message here, right? We got so involved with the transformation That we didn't think about What what people were thinking afterwards and they were thinking you're done Somebody actually asked me So are you still going to be in need in the agile work group? Are you going to close down agile work group? Are you again going to be the scrum master as you used to be? So that was a shocker to me. I said why do you ask? He said we are agile. So what are you going to do now? Yeah, yeah, you're at we're at job. What do you have to do? Well it turns out sustaining is a pretty big business too And it took a while to get that message across But once you've built it you can't walk away from it and it's been Two years since we were fully done with the transformation. We still have outside coaches We still look for experts to come in And give us guidance. There's always something that we can learn There's always something new out there and we want to become a learning organization as well Our focus is switched Now to where we're nurturing teams and we're trying to increase increase their agile maturity And this whole time in fact Sunil you didn't even mention it this time. But what about engineering practices? We are now positioned quite well to bring in and take advantage of the engineering practices That meld really nicely with an agile environment things like TDD and some of the design practices that come out of xp Now we didn't talk about them because it really wasn't part of the transition But we're certainly moving that way And when jazz humble was up here earlier this morning, he mentioned 22 months To to take on those practices within a regular size organization 22 months That's how long it took us to do an agile transformation So we're in the middle of another transformation right building the maturity of the engineering practices within our organization Just just remember that it doesn't mean that you have to actually wait for the whole transformation or the Or the teams imbibing all the agile practices to start in engineering practices. We didn't wait. It's just that now we are Focusing a lot on that previously the major focus was transformation and the agile practices Now the major focuses engineering practices though engineering practices were still being improved in a lot of teams and another thing that We uh from the agile work group started doing was since the transformation work was over for sustainants We actually improved ourselves as agile coaches and trainers We continuously improved ourselves so that we can train the new teams better We can coach the existing teams better because we have to deliver value continuously We can just say that our work is done So we are improving ourselves on a daily basis by improving ourselves as coaches and trainers And also managing the agile program the agile adoption program So now we get to talk a little bit about the future in the last five minutes here Okay, it's a journey not a destination you've heard it and you'll hear it again. It's kind of overused That's exactly what it is Process wise. I think we're pretty close But we still can improve there's still some things we can do if you're familiar with the scaled agile framework You know, there's a high the the highest level is the portfolio planning. We haven't taken on that challenge yet I'm not even sure Just yet how we're going to do it. We've been dabbling in a few things on how we can make it happen But that that truly is uh Like I said for us a big challenge to take that on And if we don't pay attention to what their teams are doing You know what's going to happen. They're going to revert back To some sloppy practices or the bad habits that we get into We don't want to go backwards. We want to go forward. We want to become a learning organization And so we're going to continually look for things That can improve what we do and how we do it And once again engineering practices We want to raise the maturity level within our organization as well So as I said, we want to be a learning environment right right share ideas So for the future the things that we are trying we are trying to focus on now Is the improving the learning environment itself, which means that There should be more uh Short trainings because the long agile and stump trainings are mostly done for most of the teams But then there are new teams coming up which need to be trained full time But there are short trainings on agile practices which which help them Then there are another thing that we're trying to embrace now is sharing Across the teams which is through the community of practices So we have created a skirmash skirmaster community of practices where the skirmasters gather Once a week and share their ideas and challenges of course There there's a product owner Community of practice there's a testing skill community of practice So any any kind of skill Can actually people of any kind of skill can actually group together and Create a community of practice and we from the agile working group actually make it happen and then we let them Take it on another thing that we always ensure is that We are bringing in engineering practices coaches from outside to kickstart some initiative in some program And then the internal coaches take on after that by learning from them Also and utilizing their own work experience and their knowledge of the code base Another thing is that we try to continuously improve the efficiencies of the process We try to identify ways in the process that that's a continuous Journey it's not it's not that a particular process has improved So the program is is done for no we continuously try to identify ways and try to improve that We also make the skirmasters in interact to discuss the process improvements and We ensure that the training of skills skills say Either the engineering practices or technical skills are taken care of and we interact with other training Departments to make sure that all kinds of training trainings are taken care of So it's a everyday learning experience and we just as you are learning. We are also learning No, well, I just Thank you very much for Letting us share with you. It's been great to Think back over the last four plus years and where we were and where we've come I hope we hit enough of the high points To make to make you understand how we you know why we feel good about what we did and Uh Sunil and I will be here. Yeah, are any any questions right? So any questions you have either now or later Today and tomorrow. I'll be there till tomorrow He is there all the day today So any questions you have about the challenges that you guys are facing towards adoption or scaling or even Starting anything related to agile or scrum or Kanban or anything or any team behavior related issue or Something not being done. You can approach us. We are ready to help Thank you very much