Distributed Agile Test Teams -- Making It Work

I just returned from a trip to Krakow, Poland where I visited with members of my test team.  Our test team is split between two offices.  In one office, we have programmers and testers, and in the other office, we have testers and no programmers.  Because of this, it is not possible for all the scrum teams to be colocated.  This creates some challenges, but so far, everything has been a solveable problem.  In some ways, using distributed agile test teams is not idea, and in other ways, it is a big strategic advantage.

Here are some things we do to make distributed agile testing work:

• Make the best use of the overlap hours.  In our case, we have at least three overlap hours between Poland and the eastern US.  These hours are precious.  During this time, we have stand-up scrum meetings and we work on test team projects.  
• Invest in the right tools.  This means buying or building tools that enable everyone on all teams to have the same advantages.  For example, we migrated to Quality Center when we opened the Poland office.  QC is just about as responsive in Poland as it is in the US.
• Communicate!  We use video conferencing, collaboration software, and instant messaging everyday.  Cheap tools can erase the miles and bring your teams together.  We have started using Adobe Connect for video conference and collaboration.  One cool feature of this is the ability to record meetings.  This gives the abilty for programmers to pass along a quick recorded demo of the day's work to the tester on the other side.  User acceptance test sessions can be recorded -- in fact, a UAT performed during off hours can be reviewed later in another office.
• Travel between sites.  New hires in our Poland office spend several months in the US working the development and testing teams.  A big success factor is building strong relationships.  It is difficult to really get to know and to trust someone if you only talk on the phone or communicate through email.  The benefits to people traveling and to the people being visited outweight the costs of traveling.
• Find the right projects.  Regression test analysis and many test automation-related projects are easily done in Poland.  Most new functionality projects are more easily done in the other office where there is better access to programmers and business users.  
• Hire the right people.  This is always important, but it is really important when you have to rely on trust and communication with people that you don't see on a regular basis.

What I have found so far is that the issues related to distributed agile testing are common with distributed agile development.  If you are looking for more information on distributed agile development, here is a great resource:
http://download.microsoft.com/download/4/4/a/44a2cebd-63fb-4379-898d-9cf24822c6cc/distributed_agile_development_at_microsoft_patterns_and_practices.pdf