Getting a different team to take over the development of an application brings in challenges from multiple perspectives. There will be differences around processes, engineering, as well as culture. Larger transfers would also involve changes to infrastructure. For long, the industry has done a disservice to this field by calling it “Knowledge Transfer”. Knowledge transfer is but a subset of the scope of activities involved in this exercise. It would be more befitting to call it as “Ownership Transfer”.
We put this process into practice on one of our customer’s projects. After more than 5 years of supporting the platform, Thoughtworks worked with the customer teams to transfer knowledge and context back to the customer. A few specifics about the application:
- More than 80% of all online ticket sales are done through this application
- More than 400,000 visits a day
- Close to 5 billion USD of ticket sales
- More than 70 VMs supporting the production application
- Upwards of 300 VMs supporting other development and testing environments
A few highlights on the Ownership Transfer program,
- More than 150 IT members involved in the program
- A ramp-down was part of the process to get the final numbers to about 60
- The transfer had to occur from Bangalore back to London
- Infrastructure had to re-optimised from Bangalore over to London
- Two organisations were involved viz. Thoughtworks and the customer
Since the teams in both Bangalore and London were following agile practices, they decided to utilise core agile concepts to affect the transfer. This was especially helpful, as business required critical features to be delivered on a continuous basis.
We started off by creating a fairly context-agnostic methodology that would support a healthy, sustainable and mature way to transfer ownership. The transition itself lasted about a year, and involved practices such as remote pairing, program MVP and above all, continuous delivery and non-disruption to business through the process.
In this video, we walk through the framework that can be applied to most Ownership Transfer situations. In particular, this will be of interest to groups who are looking to transfer ownership from one team to another - from a development team to a support team, or from one vendor to another as well, or across distributed teams. Summing up and also paraphrasing Jim Highsmith, it's important to note that companies, while implementing their digital business strategies, are adjusting their approach to outsourcing, in part, by re-insourcing systems critical to their new technology-driven strategies. And interestingly, my book Software Ownership Transfer, drawing deeply from my experiences on the field, provides practical information on transferring application systems knowledge and ownership from one organization to another.
