Thoughts on Offshoring, Part IV

This is the fourth and final installment I'm going to write about offshoring. I've already written about the two implementations of offshoring I've been part of, what I thought worked, and what didn't.

Let me recap the different approachs and my thoughts about what worked and what didn't.

The first approach:

• Use Scrum with teams spanning geographical boundaries. Each onshore team was augmented with a few offshore resources.
• The offshore location was chosen so as to minimize the time difference. Using resources basedin Costa Rica reduced this difference to 3 hours, even with us being on the West coast
• Offshore resources were screened so as to try and ensure competency and language fluency.
• Direction for these offshore resources came from onshore leads and all management of the project was done onshore.
  

The problems:

• Offshore team members did not feel like "full-fledged team members", frequently waiting for onshore leads to tell them what to do, despite our attempts to involve them in Sprint Planning and retrospectives.
• Because the offshore developers did not take ownership, it fell to the onshore devs to "assign" them work. Often the onshore devs did not feel confident in giving the offshore resources critical work items, and so they ended up being assigned low-priority work that did not contribute significantly to the business value of our project
• Even with our daily Scrum being held via conference call, due to communication difficulties, cultural differences, or something else frequently the offshore resources wouldn't give much context to what they were doing and so these Scrums were of relatively low value
  

When we finally made this approach worked well:

• We rolled-off all the offshore developers who had been seen as contributing marginal value, keeping only the best resources
• We reduced the team sizes, so the offshore resources were not "extra capacity" but were absolutely essential to the team's ability to deliver on its commitments.We started using online collaborative tools (namely the Wiki) to ensure the offshore team members knew exactly what their priorities were and so that onshore leads/managers could effectively communicate the highest priority work items to them.
• We removed the members of the onshore management team who had failed to give clear direction to the offshore team members and consolidated the management of the project in the hands of a few senior team members

The second approach:

• More traditional Waterfall development schedule
• Onsite architects and leads largely flesh out the initial design and implementation for new features, which are then handed off to largely self-contained offshore teams
• The offshore company provides "embedded" team members who are onsite. This includes technical program managers as well as development staff. There are also managers who are co-located with the offshore developers
• Onshore developers serve largely as giving direction to the offshore developers and reviewing the work they have done

The problems we currently face:

• The offshore developers were not directly screened. Instead, we choose the leads who were allowed to choose their developers. In practice, who knows if they screened them. I suspect they were simply "given" resources by their offshoring company. This meant that the quality of the offshore resources was somewhat inconsistent at times.
• Projects estimated to require a single dev for a few days, are assigned to multiple offshore developers since there is so much capacity offshore. This ends up negating the cost saving of using offshore in hte first place.
• Related to the previous point, there are no tools to easily know what the offshore members are working on.
• Given the ebb and flow of project work and the massive size of hte offshore team (almost 30 developers), we often end up with a bunch of developers with nothing to do. We are rate limited in our ability to farm work out to them, because it tends to need analysis by onsite leads which is rate limited.

What is working and current improvements we are attempting to make:

• Some of the offshore developers are extremely competent.
• The onsite technical PMs are also extremely competent and better than many of our FTE managers as they have technical backgrounds. It should be noted there are only a few and they are over 10-15K per month per head, so the cost savings are debatable.
• Having onsite technical PMs and resource managers also helps to overcome the pain associated to a significant time difference between locations. Of course, it only "transfers" the pain to the onsite representatives.
  

Concluding thoughts:

I have done something of an about-face with regard to offshore. I'm now convinced that there is some great talent out there. I still, however, have yet to be shown that there is anything better than a motivated staff of full-time, onsite developers, both in terms of the quality of what they produce, but also the cost at which they can produce it. The communication overhead and the low visibility onsite members have into what offshore team members are doing are severe impediments.

These impediments can be overcome by using onsite representative to "bridge the gap", but the cost of these people is significant and negates much of the value proposition of offshoring.

If *I* was the CEO, the way I would use offshoring would be:

• Recruit offshore developers using even the same criteria as used for an FTE. In fact, they have to be *better* than an equivalent onshore developer as they have signficiant geographical and language barriers to overcome.
• Build your offshore talent pool slowly, add one or two here and there, augmenting existing staff. Just as you could not expect to build a great programming staff by hiring 30 people all at once, don't expect that your going to end up with a "great" team by replacing all of your staff with offshore devs.
• Ensure you have the tools/communication vectors in place to communicate work to your offshore devs. it can be as simple as a Wiki. But you absolutely need to know *what* the offshore resources are doing on any given day.
• Prefer resources located in a timezone as close to your own as possible. Costa Rica has some great talent.
• Ensure your onsite program management team is top notch. Having mediocre PGMs can be worked through wtih onsite people picking up the slack. If you're using offshore, it ends up being a disaster.
• Continue to recruit onshore developers and do the majority of your work via these resources. Use offshore only as an augmentation to this staff rather than a replacement.

I'm not sure that totally captures my thoughts, but it will have to do for now.