Lately I've been thinking about the facets of Agile that are important to me on a distributed team.

Rich Communication

A major hurdle in working with a distributed team is maintaining as rich communication channel as possible.  A couple of points to consider:

• Your channels must extend past the "standard" agile feedback loops.  Most Agile strategies have several pre-designed feedback mechanisms to keep the process and iteration cycle as tight as possible (i.e. daily standups, sprint reviews, retrospectives, and various other ceremony).  However, when working in a distributed environment your team can miss everything outside of these checkpoints.  Find ways to talk shop, design, and brainstorm.  
  • Occasionally, after the standup... I'll kick the stakeholders off the call and just share ideas and thoughts on the upcoming stories.   Relax the atmosphere and make sure everyone has an opportunity to give input.  This can be especially effective when the team is working in disparate time zones and this is the only opportunity to communicate.  
• The atmosphere is important, even over the phone.  I believe as Cockburn does, the better the amicability the richer the communication.
• Remember how much communication you lose by not being face-to-face, and overcome it.  In one of our teams we installed a cheap webcam and just leave it running between two of the distributed offices using Google Chat.  It goes down all the time, we just kick it and fire it back up.  Despite that, it has been extremely valuable in seeing day to day conversations, being part of the team, and seeing the lights go out in the other office as their day ends.  A great summary by Scott Ambler:
  

Think globally by going local

All development should be local to the workstation. Incredible efficiencies can be gained by not worrying about network bandwidth, development servers, outages during "off hours" and so on.  At any time in the development cycle the developer should be able to unplug their workstation and continue uninterrupted.

Conform to best practices, not "best tools"

We are craftsman in the trade, the tools we use are very personal and a certain level of freedom should be maintained.  Of course still share ideas and tricks to learn and grow.  If the code integrates at the CI server, the tests pass, the code is clean, and productivity maintained.. Who really cares how it got there.

Continuous Integration

This is a must in a distributed team.  All code submissions should be integrated and deployed with every submission.  This allows the developer to work on their local copy and still integrate regularly with the product.  It also provides a direct feedback loop to the stakeholder.  This is a no-brain win.

Virtual Walls for Story Boarding

Story boarding is a fantastic tool for release planning and iterative development.  Try to emulate that "face-to-face whiteboard" experience (above) as much as possible.  There are several free tools that can facilitate this, the tool is irrelevant.  What is important is a real time representation of the fluidity of stories that the developers have access too.  I discourage spreadsheets as this is usually centrally managed, hard to maintain, and restricts the developers access.  This is the developer process, let them have access to it, take ownership, pride, and understand impact.