• Skip to main content
  • Skip to after header navigation
  • Skip to site footer

Shaping Software

Enduring Ideas in the Realm of Software

  • About
  • Topics
  • Best Software Books
  • Archives
  • JD Meier.com

Insourcing

Aug 18, 2008 by JD

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.

Category: Project-ManagementTag: Project-Management, Teamwork

About JD

Previous Post:Give Up Explicit Preparation for Change
Next Post:Fixed Price in XP Development

Sidebar

Recent Posts

  • What is ChatGPT?
  • Agile Performance Engineering
  • What is Cybersecurity?
  • Software Security Threats: A Comprehensive Guide
  • What is Software Security?

Popular Posts

Best Software Books of All Time
Best Practices for Project Management
Best Practices for Software Development
Customer-Connected Engineering
How To Frame Problems Better
How To Pitch Business Ideas Better
How To Structure Vision Scope Presentations
Intro to Lean Software Development
Lean Principles for Software Development
The Enterprise of the Future