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.

Software outsourcing dilemma

For people who have read “World is Flat” it looks obvious that in the world of internet and crowd sourcing, starting software business in the so called “low cost” countries is a logical step forward. Since intelligence, expertise and ambition in people is not bound by race or political border, there should be no reason to believe that there is anything tricky about it. More over, as waterfall has let us believe, good upfront analysis, detailed documentation, proper planning, quality control and right process (CCMI, 6 sigma and similar) should secure our projects from failure. So far so good, and in the end of a day, this philosophy is what has made the call centers in India a great success.

In order to get to the problem, let me start with another book: “Black Swan”. In this book, Taleb not only talked about – well obviously black swans and how much he hates Gaussian and sees fractals all over the place, but he also explained very important concept of scalable and non-scalable jobs:

{next paragraph from novelist Karen Hancock blog}

Non-scalable professions are defined as those with a built-in cap on how much one can earn in pursuing them. A dentist’s recompense is directly related to the number of people he can see in a day, and that number is limited. A watch repairman’s income is likewise related to the number of watches he can repair in a day. Both examples require the worker to be physically present to perform the services they provide. Obviously this category includes all “regular” jobs that pay hourly or salaried wages. When you agree to the hourly rate or the salary, you are in essence capping the amount of income you will receive. Revenue depends on your continuous efforts in the job. This kind of work is largely predictable and, according to Taleb, not Black- Swan driven. They belong to a place he calls “Mediocristan.”

Scalable professions, on the other hand, are those which have no such cap, where you do the same amount of work for one person as you do for one million. Like, say, writing a novel. (grin) Other professions in this category would be entrepreneurial activities, scientific research, venture capitalists, stock traders, etc. The quality of your decisions is more important then the continuity of your efforts. These sorts of professions belong in the land of “Extremistan.”

“A scalable profession,” says Taleb, “is good only if you succeed.”

{end of paragraph}

So, you may wonder what these thing has to do with outsourcing in software business? Here is the funny thing, software business is by definition scalable business while outsourcing business is NOT!

On one hand outsourcing companies are looking to make money by having as many as possible people on the project, while people who owned the project are not only interested in the cost of the project (hopefully), but as well as in potential revenue that they can generate from their customers.

In general, there are two types of software projects, the ones in which the end customer is company that did the outsourcing (retail, governmental organization, banking industry)  – and they are called CDE’s (customer driven projects), and projects in which the end product is a software that the customer resells to the other party. Although it makes sense to go for fixed prices contracts in case of CDE’s, if you want to succeed in the scalable business – you need to be the best in the market, and next to good product strategy and good marketing, you also need to have great software developers.

Most of the big outsourcing companies in India create so called triangle model. At the top would be 1-5% of developers with 5-10 years of experience and they are paid rather well (actually these days their salaries are comparable with salaries in western countries). They are followed by up to 10% of less experienced developers followed by about 90% of junior developers. Salaries at the bottom of the pyramid are sometimes order of magnitude less than of the ones at the top. What customer of the outsourcing company would charge you is the average salary per head. So, one thing is very important to remember, the primary incentive of outsourcing company in this model is to add as many as possible developers to your project, since this is the only way they make money. Another very important feature of this model is that this model breaks if the best developers in outsourcing company work only on one project. As companies in India start feeling the pressure from countries like Vietnam, where costs are even lower, they would probably need to find a new outsourcing model in the future. In my opinion, one of directions that Indian outsourcing companies can take is to work on quality and go up in the food chain, which will eventually bring the prices up and have them compete with smaller agile groups in Europe and US.

Just check what Alistair Cockburn has to say about agile contracts on this link to see what is the dilemma that every subcontracting company has when it comes to software projects (and BTW if you have time read all his books and blogs, guy is just awesome).

In my next blog post, I will talk about my experience with Wipro – our outsourcing partner, and how we started probably the first outsourcing agile group back in 2003. This hard work turned into a great success for both of us and it is something that we are all proud of.