This Month’s Pattern *

80 Offshore Follies

Dazzled by lower labor rates, the executives launch an offshore development scheme that increases the complexity of communication among development sites.

One of the most reliable ways to elicit a debate among software managers is to bring up the topic of offshore development. Over the past fifteen years, the use of offshore software development and support teams has gone from fringe fad to industry staple, while remaining controversial. Some managers see offshore development as the inevitable path forward, while others see it as a desperate move by clueless cost-cutters. Still others see it as a potentially useful tool that brings with it significant but surmountable challenges. What just about everyone can agree on is that there are many ways for offshore development to go horribly wrong.

Here are a few of our favorite executive epiphanies that doomed the offshore adventures that followed:

  • “From now on, when attrition occurs onshore, you will have to hire the replacement person in Franz Josef Land.”
  • “It looks like we underestimated the amount of work required to complete the portlet component. I hear that there are three developers in Andorra who are not busy for the next two months. Let’s have them help the team here with that.”
  • “Wow, the schedule for the next release looks really tight. The only way we can get enough developers on it is by going offshore. That will help us finish sooner.”

These statements reveal a lack of appreciation for the high cost of inter-site communication and inter-site iteration. Allocating work to sites almost randomly (as attrition occurs, for example) greatly increases the minimum required bandwidth between the sites. Similarly, if the manager from whom a first-line employee receives task assignments and feedback is at another site, the frequency and intensity of communication required between the sites are substantially increased.

The underlying principle here is nothing new. To control the complexity of a system, we have long been taught to partition the system, to minimize the complexity of interfaces among its major subcomponents. The same concept applies to the design of work flow in a development team. If the team includes groups of people who are in multiple locations—especially if some are in distant time zones—the stakes are raised considerably. We want to reduce the requirement for frequent, high-bandwidth communication and iteration across oceans. We want to avoid this:

How will you know if you’ve fallen into an offshore folly? Look for symptoms like these:

  • Daily meetings at 6:00 A.M. (or 8:00 P.M.) throughout the development cycle so developers in both locations can sync up with each other.
  • Three people onshore trying to manage the work of two developers offshore.
  • First-line employees whose direct manager is more than four time zones away.
  • An offshore site that does feature development work for six products, but ships nothing itself.

Having said all this, we do not want to discourage you from making use of offshore development resources. We have had success with offshore partners since the early 1990s. To make the most of their potential, consider this advice from the grizzled:

    1. Iterate locally. Whenever possible, assign to a single site— either onshore or offshore—phases of the work that require rapid iteration.
    2. Recognize that your first few uses of the offshore development model will take longer than they would have if you had done them onshore. Teams need time to develop the new muscles on which successful offshore development relies.
    3. Realize that your offshore teams are not different from your onshore teams, in most ways. They want challenging, meaningful work to do. The labor markets in most offshore centers have become extremely competitive. Top software engineers in these markets have choices. They gravitate toward exciting work that gives them an opportunity to advance their skills. They flee from maintenance-only sweatshops.
    4. Foster the purpose of each site. Sites need souls. While there are lots of factors that separate healthy sites from unhealthy ones, vibrant sites are usually characterized by a specific mission. They build a specific product or system, or a significant, nameable part of a larger product or system. Conversely, sites that contain many miscellaneous development and support teams with no specific shared purpose often exhibit low energy and low morale. When chartering an offshore development site, think first of how your teams will identify with the site’s mission.

These steps, especially the last, can help you avoid onshore follies as well.

* Each month we plan to publish here one of the patterns from our Jolt Award book, Adrenaline Junkies and Template Zombies — Understanding Patterns of Project Behavior. (Watch this space for a mere 86 months and you'll have read the whole thing.) The book is published by Dorset House Publishing, in the US and Hanser Verlag in Germany. It is available at Amazon and also as a Kindle book.


Brussels, Mastering the Requirements Process
13-Jun-2017 to 15-Jun-2017

James Robertson teaches Mastering the Requirements Process. Please contact I.T.Works for details. 

Hilversum, Mastering the Requirements Process
13-Jun-2017 to 15-Jun-2017

James Archer presents Mastering the Requirements Process for Adept Events. Details and registration: English - Dutch.

Oslo, Mastering the Requirements Process
12-Sep-2017 to 14-Sep-2017

Mastering the Requirements Process with Suzanne Robertson. Contact Den Norske Dataforeignen for details. 

Brussels, Mastering Business Analysis
13-Sep-2017 to 14-Sep-2017

James Archer teaches Mastering Business Analysis. Contact IT Works for details of this course.  

Stockholm, Mastering the Requirements Process
26-Sep-2017 to 28-Sep-2017

Brussels, Mastering the Requirements Process
10-Oct-2017 to 12-Oct-2017

James Robertson teaches Mastering the Requirements Process. Please contact I.T.Works for details.  

Brussels, MRP part 2
11-Oct-2017 to 12-Oct-2017

Rome, Mastering the Requirements Process
16-Oct-2017 to 18-Oct-2017

Rome, Mastering Business Analysis
19-Oct-2017 to 20-Oct-2017

James Robertson teaches Mastering Business Analysis. Contact Technology Transfer for details of this course.  

Oslo, Mastering the Requirements Process
6-Nov-2017 to 8-Nov-2017

Mastering the Requirements Process with Suzanne Robertson. Contact Den Norske Dataforeignen for details. 

Hilversum, Mastering the Requirements Process
7-Nov-2017 to 9-Nov-2017

James Archer teaches Mastering the Requirements Process. For details please contact Adept Events. Dutch description, or in English.

Oslo, Mastering the Requirements Process part 2
9-Nov-2017 to 10-Nov-2017

Suzanne Robertson teaches Mastering the Requirements Process part 2. Details for this advanced class at Den Norske Dataforeningen.

London, Mastering the Requirements Process
14-Nov-2017 to 16-Nov-2017

James Archer teaches Mastering the Requirements Process. For details and registration, please contact IRM UK.

in depth

Business analysis is often seen as a technical skill. But the business analyst has another set of responsibilities -- to dig into what the stakeholder's mind and uncover what is really needed, and not just what they say they want. 

A Ruby Beam of Light, Book I of Tom DeMarco's Andronescu's Paradox saga is now available in English in paperback and ebook, from Double Dragon Publishing.

"This war isn't going to blow anything up, only turn everything off."

Suzanne and James Robertson's "Requirements: The Masterclass LiveLessons-Traditional, Agile, Outsourcing". 15+ Hours of Video Instruction. 

Als auf der Welt das Licht Ausging, the German edition of Tom DeMarco's science fiction epic, Andronescu's Paradox, has now been published by Hanser Verlag in Munich.  Translation by Andreas Brandhorst.

James Robertson’s webinar for Software Education explains how agile stories are best used to ensure the right solution. Writing the Right Agile Stories on YouTube. Download the webinar slides.