When you have a team comprised of in-house and remote members, it is very tempting to organize the work so that each group works on separate sections of the project. This helps each group work together effectively, have easy communication, etc. Yet, there is a painful reality to be faced at the end of the project: there are large portions of the project with which the in-house team is insufficiently familiar. That tends to create a dependency on the remote team members beyond the planned end of the project. The goal should be to continue the relationship with remote team members because you were delighted with their work rather than feeling trapped by circumstances.

To avoid this, the project process should ensure that both in-house and remote team members are familiar with all parts of the system at all times. The best way to ensure that is to have both in-house and remote developers working on the same code modules. When a team is co-located, this can cause frequent conflicts; with an Extreme Remote team, however, the non-overlapping work hours allows for a 'relay race' style of development. The developers 'pass the baton' at the beginning/end of each work period.

Here's how it can work:

(WH = Western Hemisphere; EH = Eastern Hemisphere)

WH Day 1 - In-house developer works all day implementing requirements, ensuring that work ends at a well-defined stopping point and changes are committed to the code repository.
EH Day 1 - Remote developer gets latest code, runs automated tests to ensure code is in a good state, and reviews changes from the in-house developer. The remote developer identifies where the in-house developer left off in the list of requirements and works all day implementing additional requirements.
WH Day 2 - In-house developer gets latest code, runs automated tests to ensure code is in a good state, and reviews changes from the remote developer. The in-house developer identifies where the remote developer left off in the list of requirements and works all day implementing additional requirements.
EH Day 2 - (You get the picture....)

With this approach, the in-house developer is intimately familiar with the code at all times. If the remote developer must leave the team for any reason, the rate of progress will suffer, of course; but, it will only reflect the drop in man-power, without an additional learning curve.

To accomplish this style of work, there are specific techniques and processes that can help. I will discuss these next.