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.”
I nodded for him to continue. I put aside my papers to show him I was providing him my undivided attention.
“I’m thinking of offshoring all the testers. What do you think?”
“You can do that. If you do, you will take longer to get a release out the door. Since you brought me in to see why it’s taking you 18 months to get your 9-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 this.”
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 working in timeboxes, with small(monthly) deliverables, with people working on just one project at a time. Yes, you can see my current thinking in that report.
That CIO was not alone. His management and his board was exerting tremendous financial 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.
In another assessment, just a few years ago, I encountered the same situation, where senior management had made the decision to hire developers in New York City and testers in Singapore, a 13 hours time difference.
I’ve met people in my teaching who have developers all over the US and testers in the Far East. Every single time I hear the same story: the delays in the project are overwhelming. Read Lessons Learned from Leading Workshops about Geographically Distributed Agile Teams for more information.
Why does senior management do this? Because they do not realize that software is about design and learning. Design and learning are collaboration efforts. When senior managers think software is like manufacturing, they miss the essence of software: collaboration.
What are the successes? When you hire feature teams in one location. What? You think you can only hire testers in India? Ha! They have developers there, too. Or China. Or Vietnam. There are developers all over the world. Do you need to teach them English, or French, or German, or whatever your project language is? Yes.
That is the subject of this month’s management myth: Management Myth 21: It’s Always Cheaper to Hire People Where the Wages Are Less Expensive.
Wage cost is not project cost. You need to assess the cost of delay in your project. You need to ask yourself what is driving your project (cost, schedule, features, people, something else?).
What if everyone is distributed? You can do that, too. You need a lot less management. You need to be very clear on 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 on how much management you want. If you are a larger organization and want/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 manage with less management/hierarchy, go for distributed or dispersed teams, where people work anywhere, but are more or less in the same time zone.
But, 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 any other team.
Can you hire people anywhere in the world and make it work? Of course you can. As I have said before here, you are smart people. You can make anything work. At what human cost?
Read Management Myth 21: It’s Always Cheaper to Hire People Where the Wages Are Less Expensive.
As for test developers vs product developers, only minimal collaboration is required: testers need specifications and the product itself, and nothing more. Bugs in specifications, tests and product are reflected in the bug database. This limited interaction is only for good of product development.