How do you gradually shift responsibility for a system to the customer? How do you reduce the risk of a customer inheriting a system they can’t sustain? Rather than outsourcing, you can consider “insourcing.” In Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series), Kent Beck writes that insourcing is where you gradually replace the members of the team with technical folks from the customer.
Gradually Replace Team Members with the Customer
Beck writes:
The “big thump” delivery of outsourcing violates the incremental change principle. There is a slight twist on outsourcing that XP can deliver. What if you gradually replaced the members of the team with technical folks from the customer? I call this “insourcing.”
Gradually Shift Responsibility for the System
Beck writes:
It has many of the advantages of outsourcing. For example, it lets the supplier give the customer the benefit of detailed technical knowledge. By gradually shifting responsibility for the system, insourcing doesn’t give the customer the risk that they will inherit a program they can’t sustain.
Example Insourcing Arrangement
Beck writes:
Let’s look at a sample insourcing arrangement provided by the supplier of a 10-person team. The contract is for 12 months. Initial development lasts three months, followed by deliveries once a month for 9 months. The customer supplies one technical person for the initial development. Thereafter, every other month the customer brings in one new person, and the supplier takes off one person. At the end of the contract, half the team are customer employees, ready to support the program and continue development, albeit at a slower pace.
Adjust How Much You Commit To
Beck writes:
XP supports insourcing by having the team constantly measure their speed. As team members shift around, the team as a whole is bound to go faster and slower. By constantly measuring achieved productivity, the team can adjust how much they commit to get done in the iteration of the Planning Game. As experts leave and less experienced people replace them, the team can reestimate the remaining stories.
Key Take Aways
Here’s my key take aways:
- To insource, gradually swap out the development team with technical members from the customer.
- Insourcing helps reduce the risk of a customer inheriting a system they can’t sustain.
- Consider insourcing to reduce the risk of shifting responsibility of the system to the customer.
- Using XP, you can adjust how much you commit to get done as you shift team members around.
In patterns & practices, we’ve used a process similar to “insourcing” but we called it co-development. The customer would provide heads and/or budget. in return, they would learn hands on and help shape the deliverable.