The Unanswered Offshore Question

Student: "But how does agile work with offshore team members?"

Me: "Well, let's start by asking another question - 'Why are you offshoring?'"

Student: "It was a management initiative."

Me: "Why?"

Student: "To save money. The hourly rate is lower."

Me: "But agile depends on high team interaction and collaboration. This change in how work is done might have changed the economics of the decision. How do you measure how productive those offshore teams are? That is, how do you confirm that you are indeed saving money?"

Student: "Ummmm…I don't know."

I've asked this question dozens of times. Always the same answer.

When I am coaching clients, and ask management about this, and most of the replies are essentially "It was the VP's decision, and it's not to be questioned or challenged." Considering that the VP lobbied for it as a good decision, it may not be something most would like to look into and find that they were actually wrong about that $6,000,000 decision (multi-year deal given the resources I've seen). 

The only hard numbers we traditionally had to make a ROI decision on offshoring was the hourly rate, typically somewhere from $40 - $60 for developers, and I've seen as low as $20 for testers. Seems like we're saving money, given the typical $100 - $120 rates I've seen for US developers. But what if those developers don't get as much done due to the fact they can't talk to the subject matter experts and other team members in the U.S. (at least not much of the time, and not without delays, and rarely face to face)? If agile depends on that kind of collaboration, aren't we setting the offshore team member up for frustration and failure? 

Add to this the aging of the decision data. A senior manager in India recently told me, "Those CEO's in the U.S. made the decision to offshore based on very old data." Ten years ago, he told me, you could get a ridiculously brilliant 5 Star engineer in India for 1/10 the cost of the same in the U.S. Many companies rushed into India to take advantage of this - taking all the 5 Star/One Tenth engineers (Such a deal!!), then moving quickly to the 4 Star/Three Tenths engineers (Pretty good business decision). Then large outsourcing shops and system integrators rose up to take advantage of the great staffing and consulting business opportunity. By bundling long term, large team deals, they smoothed out the bumps that they were starting to run into with 3 Star engineers and a moderately lower rate. Now, my friend said, it is very hard to find good to great engineers, so the U.S. is being offered 2 Star (and sometimes even 1 Star!) engineers for a rate that might look like a deal on paper, but these engineers are often not as good as most U.S. company's own developers, AND we using agile. 

A year or two ago, I was coaching a team that was waiting to start their project after they go the resources from the offshore partner. But there weren't any. We waited several weeks before they got one potential to be interviewed. The interviewee didn't pass the technical interview. Not even close. Nor the second, third or fourth. Finally, nearly three months into the original project schedule, the team compromised for fear of either having the reschedule or cancel the project.

If don't get the benefit from the cost/benefit analysis, is this truly best for the company? If we extend the team to realize the value for a project, because it takes 50% - 100% longer due to communication exchanges, the value itself is diminished. And the hidden cost of the quality of resources is certainly higher than the information and stories based on 5 - 10 year old projects. 

And if a company is saying that going agile is a strategic decision, we have to look at the offshoring decision to see if that is best for the teams and therefore the success of agile.

My next post will be on how to objectively, quantitatively and qualitatively evaluate the productivity and cost effectiveness of the offshore teams.