Think Test Offshoring Is Automatically Less Expensive? Think Again
I was in the midst of an assessment when the CIO came to me and shut the door.
“I have a serious question for you,” he said. “I’m thinking of offshoring all the testers. What do you think?”
“You can do that," I said. "But if you do, it will take longer to get a release out the door. Considering you brought me in to see why it’s taking you eighteen months to get your nine-month releases out, I’m not sure it’s a wise thing to do. Why are you thinking this?”
“All the other CIOs I know are doing it.”
This was in 2002, just as the offshoring/outsourcing boom was starting. Agile had not yet become an accepted way of working. I had recommended working in feature teams and in timeboxes, with small monthly deliverables and people working on just one project at a time. You can see my thinking in that report.
The CIO's management and the board were exerting tremendous pressure on him to reduce the cost of his projects. At the same time, they were exerting the same pressure to release faster. He was stuck between a rock and hard place.
I’ve seen companies that have developers all over the United States and testers halfway around the world. Every single time I hear the same story: The delays in the project are overwhelming.
Why does senior management split teams like this? Because they do not realize that software is about design and learning, which are collaborative efforts. When senior managers treat software like manufacturing, they miss the essence of software: collaboration.
Success happens when you hire feature teams in one location. There's no rule that you can only hire testers in India—they have developers there, too. And in China, and Vietnam. There are developers all over the world.
Wage cost is not project cost. You need to assess the cost of delay in your project and ask yourself what is driving your project—cost, schedule, features, people, or something else.
You can do that even if everyone is distributed. You need a lot less management, and you need to be very clear about what a team is going to do first, second, and third. If you yank a team around and change their goals all the time, you will get nothing out of that team.
Decide how much management you want. If you are a larger organization and need some hierarchy and you want people to come into work every day, go for feature teams in one location or another. If you are smaller and can get by with less management, go for distributed or dispersed teams, where people work anywhere but are more or less in the same time zone.
The more time zones apart people are, the more difficult it is for people to collaborate. That is why geographically-distributed teams are so difficult to make work—for agile or for any other team.
Of course you can hire people anywhere in the world and make it work. But at what human cost?
