 My name is Srinath and this is an experience report that we did on a project which was actually following a traditional methodology and we applied some agile practices to that. So basically me and Balaji work with a group called the Agile Center of Excellence and we are acting as consultants to different projects and we work across different projects. So if they have issues, they would probably come to our group and based on our experience and learning, we will try and help them to resolve the issues or give them some more insights into what's happening. Typically about our organization, for example, we are from HCL Technologies and a lot of our projects are one through bidding, which means that right at the beginning of the project, there are some commitment made to the client in terms of maybe some free bees, maybe some over commitments in terms of what will the delivery team do. So that's one challenge. The second thing was that we are already carrying a lot of baggage in terms of the processes, in terms of CMMI, in terms of the way the teams are structured, the hierarchy, all that thing that should not be really agile. So we are carrying a lot of that baggage and we are still doing projects which are doing agile. And of course, a lot of change really happens when we get a jolt from the customer. So suddenly there's an escalation, everybody sends out mails, the top shot receives mails and then the delivery teams have to start working on fixing those issues. So that is the background and with that as a background, this is the specific to this project. So it was a project which was typically in the maintenance and enhancements phase, so it's already. So anyway, let me continue till the slide comes up. It was a project in the insurance domain, so the project or the software was actually collecting data from various sources and putting them, creating the indices for the project. Some technical problem. Data from various sources and create an index. So it's basically for using at the London Stock Exchange and various other, it's working out. So the indices used to be calculated as a part of the project. Any issues in the production used to have a lot of issues, I mean the fire used to be raised and there were a lot of issues with the project. And of course, from a team size perspective, we started off with a team size of 15 people, but due to issues in terms of contracts and downsizing by the customer, it came down to three in the beginning of 2012. They realized that there was some issue and the team could not function correctly and then they went up to nine, but the challenge was that a lot of knowledge was lost because they came down from 15 to three and the people who came in after ramping up was the people who had not worked on the project. So there was a lot of issues with the knowledge that was lost and subsequently after we started implementing the practices, the team size went on to 20. In terms of the other challenges, the typical challenges that we have, so on time delivery was the main issue. We used to go to the customers or the stakeholders, ask them questions, but we would never get the answers in time, but yet we were supposed to deliver it on time, so that was a challenge. And sometimes there were so many dependencies that we used to ask a certain question, they never used to get back to us with the correct answers. So one part of it was that they were never there, the other part was that we used to get the answer after a long time, so we never could get the right answer. They were ad hoc delivery requests, so special delivery requests, so suddenly there was an issue and we had to really plan for it and do the delivery. Multitasking was very common and as a result a lot of bugs were raised, the high severity bugs and the issue was that, I mean that was escalated. We reached a state where we were actually banging our head against the wall and all the time we were supposed to ensure that there is good customer satisfaction and the customers at the end of the, on the other side were quite happy with whatever we had delivered. So these are some of the challenges that we had when we went under the project and this is the typical way of working, so the business used to create the JIRA, they used to create the tickets, we used to discuss it with the business users. As a contractual obligation we had to do a high level estimation, the estimation was approved, then it used to go through the detailed analysis, estimation, coding, testing, et cetera and then sometimes we used to get feedback, so it used to go back to the business, let's say the estimate and they would come back to us saying that this is too high, you have to reduce it, so it would come back to the whole loop, go all over again and then we used to lose a lot of time in this process itself and at the same time we had to ensure that there were SLAs were being met and the contractual obligations were being met and we were also supposed to deliver a good quality software at the end of it. So that was the background to the project and then we got into it and I think Balaji will take over in terms of how we went in, what was the retrospections that we did and the challenges that we were able to resolve to some extent. Yeah, due to the customer satisfaction, depletion and a lot of escalation from the customer, they were trying to pull out the project from us and then this is where we, as a center of excellence, we got into the project and then as a part of doing a transformation to the project, we started with one of the agile practices called retrospections to understand what's happening in the project. So we found that the requirement changes were very frequent and any changes to the requirements needed to a scheduled deviation, but still we were all blamed for the scheduled deviation. So that was one issue and Gap in understanding the application and dependencies on the client dev team was one more bigger issue because we were working on the back end software and the dev team was working on the front end or a framework which computes the logic for calculating the indices and the team used to be stressed out, work late hours and then weekends to fulfill the commitments and there was the biggest problem in dealing, getting the response. So we thought, how can we solve this problem? So we, to start with, we thought that the principles and the practices from the lean and Kanban and to achieve a flow could help the project. So we started with the two small practices called visualization and the daily hurdles. So basically the team will gather around the visualization board and then they discussed the issues and the escalations and where they need the clarification and what kind of work has to come. So that was one thing. So initially what we did is like to understand what's happening in the project. We set up the board into four parts rather than one part of to understand what's happening. We wanted to know that what kind of requirements are coming and then since the contractual applications were there, we want to have a better control over this place so that we will take the work only after customer is signed off and acceptance criteria is defined. Then second was the delivery cadence. We want to have a full control over the delivery and since we had a very good knowledge on the application, we thought like we will have a good control and the whatever the tickets which were scheduled to happen were tracked separately and then waiting for clarification and these are the continuous improvement part. We wanted to reduce the pain points over a period of time slowly. So these are the first step we did it. So as a way of working change, we told that every CR should be tracked or the change request should be tracked from this board. We thought this we cannot take any other new requirement. To see where exactly what is happening, we also put this approval pending from the customer side to say that these are the tickets which are pending from your side for approval and we also attacked the variability. There were complex indexes which were broken into small and then we know that what is the complexity of the ticket. Then so this would address one of the retrospection points on the requirements changes frequently in gap and understanding. Until we have a full defined acceptance criteria, we are not going to take the work. That is the one rule which we have set and team didn't or the project manager didn't have any clarity on who is doing what. So we thought that we will have the delivery cadence to with the names assigned on the postage and to see what are all the impediments which the project team is having. So this would help in identifying what are all the CRs which are dependent on the client teams and to address the team stress. That's what it and the blockers. So wherever we are going to slip this schedule, the senior management got into it and then tried to solve the problem. So this is on the continuous improvement part which I will explain later. So what did we find out in the initially was like there were super heroes in the team. They were if a person takes a work, he will be running from one end to the other end of the full life cycle. Too many dependence with the client team, too much of context sitting because of the adopt requirements. And if you see most of the tickets were estimated but not scheduled for development. This was a waste for the customer. We almost found that our resource was spending estimation only two days in a week. So that was a biggest waste. So we try to attack it. So 50 percent of the work was not taken and so that's what one of the things and yeah. So after we understood what is happening in the project, so we wanted since we didn't have much control over this place. So we thought like we will set the improvement on the delivery cadence part. So after that we redesigned the board to have ready for development column so that based on the capacity available. We will push in the records here or this years here to get a clarity on with whom the tickets are pending. We created the client and the HCL and whichever is having a complex complex here. We broke down and then we had an integration column and then the review column and the UIT column the other person started working on it. And later we also realized that lot of work which we have completed was not consumed also. So this was also a waste and if the date misses on deployment date misses then it comes as a rework. So this is more on the solution. And then we also created the ways of working of definition of that. We wanted to establish a full mechanism so that we created at what situation the CRs can be pushed here. Then to measure how long it takes cycle time and lead time. So we measured we had this posted template. So when it started and to find when it ended. So this was the other small thing which we implemented and to identify the blockers and with whom it is lying with whether it is business technical or internally. So we classified the blockers and over a period of time we saw that there was a major improvement in the customer satisfaction also because customers were evaluating the project on these parameters. So initially when we went in escalation management was very bad and then quality of output also was very bad and delivered right first time and non-time delivery. After we had this practice implemented you can see within three months a course went up. Basically it is more of your transparency and then the transparency within the team and you see the throughput also was going up. We were able to finish lot of tickets and then we were able to initial measurement was my cycle time was 8 days and then lead time was 13 days. So that was our initial baseline value and this is the post implementation. If you see over a period of time we were with the project for a year and then we saw that we were able to give the or give the product to the customer 50% earlier than whatever we have to do. So for customer to see the project it was taking 21 days for this year. So now it takes only 12 days and we are able to finish from 13 days to 4.1 days. So that is a drastic improvement from our side and even the time to create the index so the knowledge got improved from 75 days to 15 days and this is the value stream which we did and saw that there was a significant improvement on this time. We managed to reduce this time and then here also we managed to reduce the time. So these are the significant improvements and after the success of this project we saw that this is a very useful method for even the traditional project and we are implemented these practices into a traditional project process so that we have now 9 platinum accounts plus 85 projects and 1400 team members who are having this board. So this was our mantra. So we told specifically the project not to start any work before finishing it. Even though it creates a slack it's okay. So we told that this is very important. So with this any questions we can go back. We tried it but see what happened was if you observe total team has 9 people but we are not able to fit into that total capacity. Means like the team was or the customer was giving more work we are not able to align into the number. So still it is there but customer started sensing it and then he also started using this board. So we're applying we've limit. We need to have what is an agreement from the customer also so that we can plan accordingly. So that's what the so that's what our experience. Provements that you have shown. Yeah it increased in truth. But there was no slack in the team in the beginning. Right? There was no slack in the team. They were slogging. But now if you see the retrospection. These are the retrospection after three months. So these are all the what went well and then we were able to see in the initially three months itself. So this was the achievement where exactly the customer started to see the change was basically the throughput and the these parameters. Monthly governance call where we will tell customer that this is the monthly performance from our team and we'll ask the customer to evaluate the team on this basis. So on this basis how are we doing? Tell me. So if you see there was seven out of seven was of this core. We were almost there. The biggest thing was like after few months people didn't have work here. We were able to finish more work and customer was struggling to give more work. So this this was a good thing in our organization with work well. We wanted to try to run green opera but we don't have that. So Excel only was used. Excel was used to calculate the cycle time. Calculate the cycle time. Even the CFP is also used to generate using the Excel and now they were extending the same Excel. So the people the onset team was in London and we were in India. So we used to give the status of the offshore in this status report and they will update and send it back. So they work late and then they share this. Spanning correct. The workers spending for five days to 20 days not more than that. Very complex was 20 days not more than that. Thank you.