Offshoring seems contrary to Agile principles. Can it work?

Posted on June 14, 2016.


Rapid iterations. Short cycles. Feedback from the market. Real-time conversations. Fast course corrections.

These are some of the many promises of Agile software development. It’s tough enough to make these concepts work well in a company where the development teams are colocated. It’s a completely different challenge making Agile work with offshore teams — especially third party vendors. The obstacles to agile collaboration with offshore vendors are many:

  • Vendor procurement is often based on fixed time and scope initiatives
  • Vendor business models dictate success as “works as spec’ed” not “met customer needs”
  • Time zone differences make real-time conversation challenging
  • Cultural differences give the illusion of conflict resolution or no conflicts at all
  • Incentive structures for the in-house teams differ from the vendor’s
  • …and many more
Can Agile software development work this way? The answer is “sort of.”

In what is now nearly a 10 year old piece on making Agile and offshore development teams work together, Martin Fowler of Thoughtworks recounts several tactics that worked for their teams. They include:

  • Have each side send ambassadors to the other sites to ensure there is representations for each team at each location.
  • Don’t underestimate the culture change required to implement Agile. The freedom to question your managers’ directions is not universal. Ensure this is discussed.
  • Separate teams by functionality (e.g., features, workflows) not activity (e.g., development, QA, etc). In other words, build self-sufficient teams at each site (or as close to that as possible) so that cross-ocean dependencies are reduced.
  • Expect to need more documents. There’s no way around it. Reduced real-time communication means a greater reliance on written communication. These can be digital documents held in wikis and other collaboration tools but the teams will rely much more heavily on them than in colocated situations.
However, it’s worth noting that while these tactics can certainly ease the pain of cross-globe collaboration, Fowler’s teams — both on and offshore — worked for Thoughtworks. At the very least this allowed them to share incentive structures, infrastructure, and communication tools. When your offshore partner is not part of your organization many of these elements have to be agreed to up front.

One of the most effective ways I’ve seen this done is with a team working agreement. This simple document, hammered out in a project kickoff meeting, lists in painstaking detail exactly how the various teams involved in an initiative will work together. How long are iterations? When will we have standups? Retros? What tools will we use? How do we resolve issues? What constitutes success? Where will people sit? How often will we visit each other? Etc.

The time spent creating this upfront alignment is worth its weight in gold downstream as conflicts arise during the initiative. As with all agile practices, the team working agreement is an initial set of assumptions that will be proven out, or not, over the course of working together. As new, better ways emerge to collaborating, the agreement gets updated along with the teams’ practices.

What have you found to work with your agile offshore teams?