Agile and outsourcing, how to make it work

When I was asked first time to start outsourcing, I really had no stomach, nor desire to prove being a big manager by traveling around, asking for reports every single day, sweating in the night from stress and frustration, and blaming all other folks for my problems … There are plenty of horror stories about outsourcing business, and you can probably find the one you like the most on the web and tell it in the bar – but that is not me, I hate whining.
The very reason why I started agile development was to prove that outsourcing model was not working and that dozen people that are talented and motivated can be more productive than hundred people on the other side of the ocean. And now the funny thing, not only that I was asked to start off-shore, but I had to prove to myself that I had been wrong – isn’t that a great challenge?  At first sight, idea of having off-site agile team, and more over from the outsourcing company sounded as a mission impossible – and this is when I first thought of the “plumber’s dilemma“:
Imagine you have a water leak in the bathroom. You call a plumber; he comes and sees that your problem is trivial. If he repairs it quickly and asks for the bill that includes his time to come and leave your place, you will be rather annoyed by the price you had to pay (and probably felt dull at the same time since you failed to do it yourself). If he stays a little bit longer, you would probably not mind paying exactly the same price, thinking that the problem was not that easy to solve. Here is a dilemma that plumber has: it he stays at your place for too long, he will not be able to visit another customer, on the other hand if he stays for a shorter period at your place, he would probably not be able to get a good price and keep the existing customer happy. That is probably the reason that most of the repairs take about 1-2 hours. Not less, not more, unless you really have a big problem or a louzy plumber. What would be great is if you were able to tell him how much you think the value of the repair was, and let him do the job as fast as he can.
In order to achieve this, two things need to happen. First, you need to build the trust between two parties. Secondly, it is essential for both parties to understand business environment in which they both operate.
Although this is not exactly the same problem as you have it in the outsourcing business, and dynamics between the customer and outsourcing partner depends on other aspects such as whether the project is on time and material or fixed price contract, in the end of a day I find it convenient to think of it in the context of “plumber’s dilemma”. That also might explain better why in the previous blog I started with Taleb’s concept of scalable vs. non scalable businesses when introducing this topic.
When I wanted to build the agile off-shore team, I knew that outsourcing partner would feel that this was something that was not fitting their business model (here I talk about 2003-4, things might have change recently) and that lack of will and expertise in agile would fail the project very soon.
So, here is what I did, step by step, you can take it is a recipe and try (but please no shortcuts)

7 Steps: How to create off-shore agile group

  1. Bring 2-3 subcontractors on site for longer period, before you start any off-site activity. Make sure that these guys are excellent. They must be good coders, speak fluent English and have good soft skills. (First two guys that we got on the floor were next week on the flight back to the place of origin. Somehow our partner thought that we were not that serious. To be honest, we also forgot to interview them. Next two guys passed very long interview with 3-4 of our best coders before coming.)
  2. Embed subcontractors in the team; treat them with all respect like any other team member. They would learn better about the product, get to know European culture (we are not shy to say that something sucks when it does) and learn agile. In some cultures, where high respect for authority is expressed in both their customs and their language this can be a challenge. More about this problem you can find in this great blog post
  3. After some period, create the off-site group and bring the first subcontractors back. By now, they should be your ambassadors that will be responsible for creating agile group on another site. At the same time, start building relations with the business partner. Before this phase, you are not that important to them as they only see you burning two of their good resources… Now is the time to go back to them and tell them a big picture – the game you want to play.
  4. Interview every single person that will be part of that team.  This is a tricky one for the outsourcing company, but first time you need to insist on that.
  5. Prepare time and material contract for the off-site team and avoid discussions on metrics. Have one contact person with whom you will be discussing all financial and other aspects of the project. You should connect to this person at least once a month for follow up (this has nothing to do with scrum master or agile, don’t mix these two).
  6. Make hardware and software environment to be exactly the same on all sites and promote accountability and responsibility on all sites – there should be no second class citizens!
  7. Continue with rotation, always having 2 new members from the off-site group at your place – 6 months rotation cycle.
Finally, as every fairy tail that people are proud to put in their blogs, we have built a great product that has become a huge commercial success. During this journey we have created two fantastic agile teams, and I’ve got to know some great people. It was learning experience for all of us. Few years later I used the same approach to start a new test team inside the company in Chennai – and again, it really worked well. The best part of the story is seeing people working together and treating each other with respect.
So, I was proven wrong – agile and outsourcing can work.