You talk about the cost of large offshore teams. Did you ever work in a successful environment with distributed teams? Do you know of any strategies that work for this setup, which are not as wasteful?
No is the short answer, if success means predictably delivering the right thing for the budgeted amount of money or less, with quality software that has a low total cost of ownership. It comes down to lead-time and the cost of delays. When people are spread out it takes longer to go from customer request into the customer’s hands; transaction and coordination costs are higher. Sure, a distributed team can be made to work – look at 37signals. It comes down to having a simple setup and having people with passion and capability on the team, wherever they may be, rather than just fungible resources who tick the boxes on a skills matrix.
The decision to offshore is usually driven by cost. Labor costs get expensive when projects get big. The thing is a lot of projects are bigger than they need to be because they get overcomplicated unnecessarily. I remember hearing a CTO talk about having 400 developers working offshore, as well as 100 onshore. At the risk of assuming the back-end of their e-commerce site is simpler than it actually is, that still seems like an awfully lot of developers. Size matters! It is an issue. I don’t believe a big project with a big offshore team and the usual politics mixed in is a setup for success. Then I see companies building it into their KPIs, like mandating 40% of capital expenditure must be offshore. I don’t consider this to be a good sign. “Do the simplest thing” doesn’t just apply to software. There are just simpler more cost-effective ways to get things done.
If you haven’t already, please go read my No Bull paper. It sparked a conversation about offshoring in the Agile group over on LinkedIn, with people citing real examples of unexpected issues and hidden costs.