Can everyone hear us? Great. Good afternoon. I hope all of you enjoyed your lunch. And I hope all of you don't sleep through the session. Anyway, so my name is Vinod. I work with ThoughtWorks as a project manager. And this is Praveen. Praveen, do you want to introduce? Hi, I'm Praveen. I work with a company called Trainline.com, which is primarily a UK-based company. And we work with ThoughtWorks to develop our product. I'm offshore head of development. So before we start, just wanted a raise of hands. How many of you have been part of Knowledge Transfer? Great. Excellent. So hopefully we have a good set of folks who will understand the context of what we are talking about. And this is probably quite novel that we have the customer and the vendor here making this presentation together because we have actually undertaken this journey together. And Knowledge Transfer is typically an exercise which has a lot of undercurrents. There are many shades of undercurrents. Some folks may feel insecure, some folks would know that it's probably loss of business, loss of jobs, loss of many other things. So it's not necessarily an easy experience. Just a good rest on the agenda. Brief on the CTP, CTP is the exercise that we did between ThoughtWorks and Trainline. It's a short form for capacity transformation program. Just specific to what in this context it is, you will need to understand what those details are with the specific to this program. The learnings that we took from the program, something on the methodology itself, can this be applied? So before we start about this, I would like to tell a bit more about the Trainline.com. We are essentially an online train retailing website. We are the largest train ticket seller in the U.K. in online presence. Probably 80 percent of the online tickets are provided for 20 of their websites are Trainline.com white-level websites. So we pretty much capture the U.K. the real industry in terms of online presence. We also have various other types of customers like, for example, travel management companies, big corporates, and hence we provide a website with gateways as well through which you can go in and book the train ticket. So just one more point. Just in terms of the size and scale, the Trainline.com probably does more than 3 billion euros worth of business on their website. And that really is the sole and substance of the company. The company's engine is the Trainline.com website itself. So what we had created and what we had to maintain is what the company is all about. So what happened during the last many years, approximately 7 to 8 years, since Trainline is working with ThoughtWorks is, we have together developed a big platform, a pretty complex platform, a real industry in U.K. is pretty complex, and hence the software that we create is pretty complex. Primarily the software was developed by ThoughtWorks in India. Last year, and during this period, of course in U.K., which is primarily London, we have grown up our development team as well from tiny to significant size. Last year there was a business drive to transfer the ownership of the software which is being developed in India, primarily to the U.K., to do in housing essentially. The reason was pretty simple. One was decreased capital expenditure because the challenge was that a big team, which is here in India, has to reduce to a significantly smaller team in the U.K. Another one was in sourcing and a team together. How we needed to do it? It was not just transferring the software from one location to another or transfer a few resources from here to there. It was, as I said, a 7-year-old program running in Bangalore. Lots of infrastructure developed during that time frame. Lots of complex software developed during that time frame and many more. So when he had told that we had to do this exercise, we didn't know where to start. As Praveen was saying, this is like something that we had built over 7 years. And what we built over 7 years is not just a business of functionality. What you built over this period could also be some of the processes involved, created roles, created an entire infrastructure around it, multiple things were there. And we didn't know where to start. This is not like a normal project. There's a normal project, there's a functionality. You start talking about requirements and then you can start writing stuff. Typically, all the leaders and the managers start at talking. And everybody had their points of view. The release manager brought in things about the processes. The lead VA talked about features, channels and things like that. The architects spoke about code base. Several folks spoke about many things. We had a brainstorm a lot. And then when words started going out, the developers came and said, hey, don't we talk about working code? Shouldn't that be the essence of what we're trying to transfer? And we thought, yeah, that makes sense. So we said, there is all this complexity, but what has to be the primary element around which everything, everything revolves could be working code. We made sure that the things that we can call it that of this program would be working code. Everything else would be ancillaries that would revolve around it. Be it process, be it structure, be it infrastructure, be it anything else, would revolve around making sure that this working code gets transferred appropriately, securely and in an optimal fashion. Then the next one was, how do you actually transfer? I'm sure, Gosopi Omen, part of knowledge transfer exercises would know, the first thing you would do is get some documentation, send through sessions, try and understand what the application is doing and all of that. Photos and train lines have been working further for a long time, so we were extremely, extremely settled on working using agile patterns. And we were pretty low about documentation or even workshops. We've been using bad programming for a long while. So for us, this was the least effective for us, the most effective is if someone had to pair with us and actually deliver functional code. And that's where you build context. That's where you get a sense of confidence that you can actually take this forward. Any other kind of learning is just going to be passive learning. You may have learnt it, you may be able to write an exam, but if somebody were to ask you to build something with what you've just listened in a classroom, the confidence would not be there. So we were all very clear that the most effective is that we will pair when we are executing projects, and that's how we are going to transfer this. And if there were no projects that may actually fit into that module or that component that we wanted to, then the next best thing would be we will pair when, you know, working on, let's say there are some regression defects or any small items that may come up and all that. So we may have to, in some cases, force fit those, if those kinds of projects did not come up. So we were very clear that this is knowledge transfer, it's actually more than that's ownership transfer, and the way we're going to transfer is by pairing and actually working on functionally relevant projects. So once again, as I said, rail industry in UK is very, very complex, so is our software. We literally looked into our, by the way, this does, has just a replica of it for all the sensitivity purpose. We have just named our services as 1, 2, 3, but there is very in-depth behind it. So what essentially we did is we sat down with our architects and we tried to find out what is the core of our system, what really we need to transfer and how do we need to transfer, which, how the team composition is going to look like. It is not that we are going to send 20 people from here and sitting over there with the guys over there. So, and in addition to that, what all projects are running while we are doing this knowledge transfer and which projects are the candidate for the knowledge transfer. Things like that. Plus, there will be lots of things which is not technical, like process. So how would we go through each one of them and how would we put work around so that once the ThoughtWorks team is not there or once the ThoughtWorks team is with a minimum size, our production system doesn't fall apart because that's most important to us. We don't want to lose our production systems. And just to put a bit more on it, for the last two years, we rarely had any priority one issues in our system. So we did not really want it to be in a state where as soon as the knowledge transfer finishes, there are thousands of P1s coming up. So that was a big challenge. So what we did is we sat down together, we looked into each of the pieces that we have and we started putting them one at a time on the timelines. So we have given a little bit of money compared to how much we have built in last many years and 10 months time that during next 10 to 11 months you will have to transfer everything. And while you are transferring everything, you are ramping down in India. So what we essentially did is we went through each of these items and put them on the timeline. So there was a plan put in place and that's obviously important. The plan is a different matter. We will talk about it. But yeah, there was a plan. It has to be there. At least we knew that there were about 17 units that needed to get transferred. And what you saw in the previous picture was sort of a visual depiction of how they all interact and what they mean and all of that. And then we actually got into the execution and that's where we started using a lot of agile methodologies. We never called it let's use agile because we were always in nature. When we step back and looked at it, we realized there are so many elements of agile that we've actually utilized this whole process. Obviously it's distributed agile themes. So I'll come to that. So that's going to be part of how we actually distributed agile themes. It would have been great if all the 40 or 50 members from London had come over to Bangalore or it would have been great if all the 100 people from Bangalore had gone over to London. We didn't get that kind of budget. We couldn't do that. So we had to pretty much work in a distributed fashion. And we will get into depth on what that meant, how we did that. Continuous delivery. We are using that in a slightly different context from what Jess was mentioning. There were critical projects. Functional projects had to keep going. While we were doing this program, you could not stop what the business required. So, you know, we had releases that were going out every five weeks. Complete platform releases that were going out every five weeks. So that needed to keep going while we were delivering this as well. And then, of course, ownership transfer. As I had mentioned, knowing is not enough. Owning is far more than that. And so we really had to define what that ownership means. It could mean change to processes. It could mean there were different teams. As I said, there were 100 members here. There were 100 members in London. So we were not all one team. We had, you know, specific teams who were doing specific things, you know, themes. What, how does that work? Where does infrastructure go? We had about 650 virtual machines in Bangalore. What happens to all that? Is London going to recreate all of it? So, multiple things. All of that conjoins to, you know, what we are talking about in terms of ownership. And, of course, metrics. I mean, what does good look like? I mean, how do you even measure something like this?  Nobody can come and pick and say, yeah, we are done. And then if production breaks to quarter, then you would realize that you are not done. So how do you actually measure and figure out if you are going in the right direction, if you are going in the right phase? Things of that nature. So these are all the different elements that we try to address while we are going through this exercise. So from a distributed team perspective, the first thing that we did was we decided if you are picking a certain functional component, we had mapped it to a project that was running at that point. And we knew that this project required a lot of changes to happen in that component. So we created a team, which was a mix of Bangalore and London members. What did that mean? We had two members from London who were pairing with the Bangalore folks. We made sure that there was one dev manager. So we used to call that as a dev manager, scrum master either way. We had one dev manager and one business analyst who was giving requirement. So both folks on either side got the same set of requirements, were following the same process, were part of the same standards, and all have one goal of delivering the project. The knowledge transfer was sort of, you know, it was there, but they were all, the team was focused on delivering that functionality. The fact that they were gaining knowledge was slightly secondary. So we sort of took that whole focus from having to think of knowledge transfer to actually delivering this. But what we did was in each of those, we'll come to that in the metric stage. In each of those iterations that we had, we had one story around knowledge transfer where at the end of the iteration, we'll check with the team members on what have they learned, what is the level of confidence and things like that. So there was something that was happening on an iteration basis in terms of how much we are making progress. One more thing I would like to add here is London made a pretty good effort in that, London developers particularly. Given the 5.5 hours time lag, it would have been pretty difficult had they been stubborn. I'll come to office only at 9. So what they did is they started waking up early. Since they started waking up early, sometimes 5 o'clock in the morning and started pairing with us. What happened essentially is our velocity increased because the guys sitting in Bangalore were causes of this fact that the guys in London are waking up early from 5. And the surrounding team members were very causes because they were with the headphones. So essentially what happened they were getting 6 to 7 hours of uninterrupted time where they walked literally together. And that literally increased our velocity quite a lot. That's what we had spoken about here. We can probably move on. I was also told that we have got another 5 minutes to go. So you probably need to rush. Okay. Alras then. So metrics as we know already mentioned it is not pure science. It's just a few boxes and you are done. What we knew is we have limited budget, limited timeline and there should not be any P1. So essentially what we started looking into is what the regression issues were looking earlier before we go to production and how the regression issues are looking after. And that's the only thing that we literally tracked during this period. Yeah. So regression. Obviously we were clear that we are not going to compromise and get a P1 on our production system. So that was a no-no. The other best way to actually check was are we getting more regression defects now than previously? Okay. Quickly on the ownership transfer what we did was, as I said, we had a distributed team. So let's say there is this project that's running on for two releases. We could run for, let's say, six prints. Six iterations. Bangalore took the responsibility. We had two members from London who paired with the Bangalore folks. So the dev manager from Bangalore were responsible for it. The BA from Bangalore. And in the next three iterations the project shifted over to London with two members from Bangalore. So what you have is earlier you had two members from London. Now they have context. You've got two more members from Bangalore. So these four folks would now pair with folks from London. So you've got a larger set of folks in London who would work on this. So over about six prints that functionality is delivered and the component also gets transferred over to London. Going forward, the London team takes care of supporting, maintaining all of those anything and everything that comes from the component. We have already mentioned this. This was a project whereby we were not supposed to halt our production system and improvements. So this was literally, we analysed at that point like changing the pilot while you are flying. In our top management they took it as building the aeroplanes while you are sifting the manufacturing plant. So this was pretty good exercise that we did running out of time. I'll just skip through. A couple of things on the risks. It was a very risky proposition. So we initially spent quite a lot of time in analysing each of the risks that could happen and if that happens what the mitigation would be. And we went through in a great detail. All right, so there are a lot more things to be covered on this. In fact, I'm actually writing a book on this in terms of the learnings, the methodologies, to extract this and really apply this across. But a quick sense in terms of how we think we should approach something of this nature is first understand the real scope. So first understand the real scope. The real scope almost always is not knowledge. That is only a subset of what you are trying to transfer. You've got things like processes. When a new team takes over they will change how they are doing things. You've got things around engineering. We are doing continuous integration in Bangalore. Could be different in terms of how it's being done in London. What TDD means in Bangalore could be slightly different in terms of what TDD means in London. Multiple things around that. Infrastructure as I said we had about 650 virtual machines. Does London procure more? Do you transfer from Bangalore to London? That can become a project in itself. And of course the team structured itself. We had a functional team running in Bangalore. London had more product centric teams. When you transfer over what does that mean for the team structure? Multiple things. Create a framework. We were initially grappling a lot with how do you even address it. Code is at the centre. That always has to be the case. And documentation will not suffice. Automation scripts are also code. You can actually transfer a lot of knowledge just by working on the automation script because you get to know the functionality that much more. The plan evolved. We had that big plan. Not all of it actually eventually happened. But the most important thing is don't try to do this in one month or two months. Knowledge transfer cannot happen in one or two months. You could probably ramp up one team member and that too not completely. But you can't do it in one or two months. For us this took us 10 months. And that too after we had been working together for about five or six years. A new team coming in trying to take over in a month or two just doesn't happen. Practical reality we all need to appreciate. The last one is obviously execute. There are going to be a lot of issues. Things that we don't talk about, the elephant of the room, typically are all the undercurrents that are going on, people feeling insecure, people not wanting to part with knowledge, people wondering what's going to happen to their jobs and things like that. You've got to face it. I mean if this is happening it's a reality. And actually just work through that and then take it forward. Okay, where is it applicable? As we mentioned all systems and all situations where there are two groups. It could be within the organization, development to a maintenance team. It could be between two organizations. It could be vendor to customer, vendor to a client, client to a vendor. Or it could be two vendors and a client in between as well. In any which case it could. And anything that has things around process, around change of engineering structure or infrastructure. This is something that we feel can be applied. All right, that's all we had time for. Any questions? So how are we feeling that? Because as you said in the instrument or the ad, we just follow one project. There's no more separate projects. So how was the team working on moving itself? So as I mentioned, we did not keep this separate and say that this is a different project. We had underlaid the process of knowledge transfer within existing projects. So we changed the team as I had mentioned. So we had people from Bangalore and London pairing on this. So in that process folks in London started getting more context of the course. Yeah, we had one story which accounted for the velocity, the budgeting and the effort that would get spent. In every iteration we had one story to track for that. But velocity actually increased. So that is a bonus for us. What about this process of knowledge transfer? So I think that's a very, very good question. The way we look at it is what principles and elements of agile that we have adopted. For example, things that we did not touch around. We had those 17 knowledge transfer units that we had to. We did an MEP around it. We actually only transferred about 13 of those. We prioritized and decided these are the ones. And we didn't decide it first when we started off. So that was the first thing. The whole concept of using pairing and using remote pairing to actually transfer this process was something that from an agile perspective we had adopted. And how we had utilized the distributed team through this whole process. So those were certain elements of agile that we had absolutely utilized through this process. Almost every agile practices was to pair with only two people, saw how it works and adopted to it and then increased the size. So can we take other questions off? Yeah, sure. Thank you very much.