Making Agile Offshore Teams Work

Agile processes stress communication and colocation. Splitting a team into on and offshore resources inhibits the first and prevents the second. Teams struggle to resolve this apparent conflict of interest. Applying best practices (for any team) to address these challenges makes it possible. Martin Fowler provides us with great guidance based on years of experience with his company.

Agile and Offshore

To be agile means more than just having an incremental delivery process. Agility is built on communication – ideally face to face communication. Technology has all but eliminated the communication barriers of geographically distributed teams. But technology can’t solve the problem of temporal displacement that comes with teams operating in different time zones.

Communication starts with requirements and moves through development and testing. In an incremental delivery process, this is a continuous, cyclical process with small elements of functionality being processed in each cycle. Offshore teams – and most outsourced teams, regardless of location, prefer a more contract-based relationship. These supplier-consumer type relationships are traditionally managed through delivery against a specification. Martin calls this a plan-driven process in his article.

To be offshore and agile, we have to avoid the extremes and follow the best of both approaches. We have to recognize a couple immutable truths about the operating theater of splitting a team across the planet:

• Communication is not real-time. While there is some overlap, we must account for asynchronous communication between team members.
• Cultural barriers are just that – barriers. We can surmount them, but only after first acknowledging them.

Martin’s Guidance

Martin provides a fantastic (and long) article about how his company has made it work. Here are some of the key points from Martin’s article, along with our commentary.

• Use Continuous Integration. Martin points out how effective this is (for any team) at preventing the integration problems that come up in any large or complex software project. Those integration problems, when not prevented, are solved through collaboration and communication. Since the teams are seperated temporally as well as geographically, these interchanges become very inefficient. The key is to prevent the problems, in order to avoid the inefficiencies of solving them without colocated collaborators.
• Cross-Pollinate the Teams. Don’t just send some people over to the “secondary” location to get things started. Rotate key contributors through month+ stays at the remote site to establish an ongoing rapport and relationship. Martin also suggests having recurring visits from other team members both to initiate and cultivate relationships. It is these relationships that build the foundation for informal and effective communication.
• Organize by Feature, not Function. Avoid the traditional offshoring approach of doing analysis onshore, construction offshore, and then testing onshore. This “waterfall model” serves to create political barriers between the teams, as hand-offs and responsibilities lend themselves to finger-pointing when things go wrong. Martin suggests that we try and distribute work so that each team can own as much of the process as possible for each given feature. Splitting the work this way improves the efficiency of communication within each cycle.

There is a lot more in Martin’s article. Check it out!