Even in offshore development, there is some portion of the team that works nearshore.  This gives the development team access to the business. Typically the nearshore team consists of project management, business analysts, and senior technical staff, while the offshore team consists largely of developers.  As the team is distributed, getting both groups to function as a single team is the first priority.

To do that, the members of the team must first understand how they will work together.  Because there is not a single definition of an Agile process, taking an "Agile approach" can mean different things to different people.  The practices adopted - requirements gathering, continuous integration, test-driven design, project tracking, and reporting - are performed in different ways by different teams.   Having different ideas about how work is to be done will result in people working at cross purposes.  For example, while both nearshore and offshore teams may agree that requirements will be expressed as Agile "stories," they may make different assumptions about what that means. The nearshore team may only to provide single sentences that describe each requirement, expecting to work out the details with the developers as code is produced.  The offshore team might expect detailed narratives with each requirement.  This inconsistency will create dysfunction.

Before beginning development, the team must agree how Agile practices will be executed.  Over the course of the project, it must hold retrospective meetings that specifically focus on practice disconnect.  In so doing, the team gets its house in order, and will be consistent in how it solves the business problem.

What Is It We're Trying To Do?
The second priority is to facilitate a common understanding of the business problem at hand.  Agile development isn't "order taking" with developers working from voluminous specifications.  Instead, it is a process of discovery, with people coming to a greater understanding of a problem by iterating development of a solution.  This requires fluid, engaged communication.

The obvious problem in an offshore context is that distance strains communications.  Being physically separated means the development team won't be exposed to the "ambient noise" of the business.  Working in different time zones introduces latency in how quickly questions can be asked and answered.  Facilitating collaboration on the business problem is a top priority. This is done through a combination of practice, tools, and training.

Collaboration requires that everybody speak the same language.  In Agile development, it means that people communicate in the language of the business.  If developers are to do more than simply work from specifications, they must understand the business problem they're trying to solve.  That means an investment in training the team so that developers can communicate in a business context, and not just a technical context.

From a requirements perspective, this often means that the distributed team creates more detailed requirements narratives than are typically used in a co-located team.  But reliance on extensive artifact production can create false confidence.  For a distributed team to work on a problem collectively requires communication tools that allow knowledge to be captured as it evolves. This is possible with integrated, development-oriented collaboration tools.  They facilitate complex communication including rich media and artifact association such as requirements, code, bugs, tasks, documents, and discussions. They allow knowledge to be shared, organized and searched, and made accessible over the duration of the project.

Collaborating with the business is particularly challenging in offshore Agile.  The business participates in development on either side of coding, specifically in articulating requirements and by executing the software. The same collaboration platform used by the development team should also be usable by the business.  By expressing requirements as independent statements of need and associating discussion threads, presentations, documents, spreadsheets, and other artifacts with them, the business is able to provide context more completely to developers. At the other end, frequent releases of the software to a test environment - possibly automated as a final step of the continuous integration process - gives the business access to the most up-to-date version of the software. This will allow for continuous feedback on the software as it is developed.

Of course, all of the collaboration infrastructure in the world won't overcome a disengaged customer. It's one thing to have a full suite of collaboration tools, the project in a state of continuous build and frequently released for test.  It's another for someone to actively participate. That means an active and engaged business partner, regularly reviewing the software and providing feedback to nearshore and offshore members of the team.  Strong project sponsorship makes this happen.

Furthermore, for a team to "work a business problem" collectively requires more than just tools and training.  Role replication - having people in identical roles in each location - creates consistency and continuity of execution.  Having "global pairs" of key roles also institutionalizes team collaboration.  For example, for a development team to get questions answered in a timely fashion requires access to business knowledge when it needs it.  Having a business analyst in both offshore and nearshore locations makes this possible.  Similarly, to track team progress and resolve team obstacles, there should be project management in both locations.  The same can be said for senior technical roles.  Because personal relationships overcome communications problems more effectively than technology, it is important that each "global pair" be co-located with the other for brief periods.

Finally, there needs to be frequent, focused team communications. Agile development calls for a daily "stand-up" meeting where each team member states what he has worked on, what he is doing next, and anything interfering with his progress.  Agile also makes use of retrospective and planning meetings with each iteration (e.g. one to three weeks) and each release (e.g. one to three months).  These are highly focused events that communicate priorities and expose risks. By consistently executing them, the team increases its communications "bandwidth" and minimizes "noise."