We find that a distributed team can become Agile and successful by doing a few simple things.
If you have a feature request, or you want a developer or administrator to do something, or you have a comment about design or implementation or architecture, write it down in a ticket. To keep track of these notes in tickets you need a ticketing system (sometimes called an issue manager or bug tracker). You can then arrange the tickets into iterations or milestones with release dates. If you write down the information, everyone on the team can see it. The necessary people will be informed, and will make their contribution, without much effort on your part. It's magic.
On the other hand, you will get into trouble if you communicate requests one-on-one in phone or email or chat conversations. Those receiving the information will have to make an extra effort to forward it to others. The information may be lost, or communicated inaccurately. You may be forced to step in and act as a human hub, forwarding lots of emails to lots of people, and searching through your email threads for individual answers. Don't fall into this trap. Write everything down in a shared ticketing system, and have a good life.
Obstacle: Some people just will not move off email or conference calls. Answer: Stop enabling them. Refuse to forward their requests.
If your team is distributed, you need to make sure that everyone is working on the same thing. That's what makes a blob of people into a team. You can ensure this coordination with a daily build: a version of the software that everyone can look at and test. Or you can go further and run continuous integration, so that you always have a current build that is shared.
Obstacle: You don't have good automated build scripts. Answer: This can be a hard technical problem, but automated build scripts are well worth the investment.
Obstacle: Some people don't want to show their work every day. They want to finish a complicated task, and then present it. They don't commit their code. Answer: Most work can be revealed incrementally. Divide the work into new stages, such as planning, mockup, etc. Use stimulus-response: if a developer waits a long time and commits a big feature, immediately find all of the problems with the feature and complain about them all at once. Then ask for fixes on a daily basis.
We like a lot of things about the Scrum methodology, including the daily stand up meeting where each team member says "What did I do, what will I do, what I need," followed by a short discussion. You can collect this information daily from each of your team members (we have a handy Standup tool in Assembla for this). When your team is forming, you should gather most of your team members together for a 10 minute chat to set priorities and answer "what I need" questions. We use Skype chat or Assembla chat.
Obstacle: Meetings take too much time. Answer: Team members should fill out the online form before starting the chat, so that in the chat people only answer questions and help with needs and obstacles. If this drags on, you can do other work while the chat is running.
Obstacle: Too many time zones. Answer: Pick a time that is survivable for everyone, and stick to it. People adapt to something that is consistent.
Once your team is running smoothly, you can skip the scheduled chat and keep a persistent chat that you use as needed throughout the day.
I have seen Agile experts recommend moving around the time of a daily or weekly meeting or chat so that people in India will have an inconvenient time in one meeting, and people in America will have an inconvenient time in the next meeting. It sounds like a reasonable way to share the pain, but actually it is a very bad idea. The people who recommend this are the same people who complain that managing distributed Agile teams is too hard. They are sabotaging their own projects. You will find that when you move the time, people miss the meeting. If you keep the same time every day or every week, people will adapt to it. They will fit it into their lives, they will attend more reliably, and over time it will become more convenient for them. Meet or chat at the same time every day.
Also, when you discuss or post times, post the 24 hour time (18:00, not 6:00 pm). Also, post the UTC time as well as the time for the majority of team members. Assembla will show an individual's local time, and Google calendar will translate a time to the local time zone.
Our gregarious kids use the Facebook newsfeed: a stream of alerts on the Facebook home page that shows them what their friends are doing. They don't have to be in the same room to feel connected to each other. The same tactic is very important for uniting a distributed team. With the right web tool you can see the work of the team in real time. You should be able to see new tickets, ticket comments, code commits, questions, and build results. We have made the "Stream" a core feature of Assembla. It shows work as it is submitted, collects events from internal tools and external systems, and makes them available by Web, email, and RSS. Your team will be united by a visible activity stream. You will see teamwork, which is much better and easier to manage than task execution by individuals.
Obstacle: Our current tools don't support an activity stream. Answer: Get a tool that provides this visibility.
Good people are the most important ingredient of any successful endeavor. This is especially true in software projects, where the productivity differences can be huge. If you are stuck with a co-located team you might not have much scope to improve individual productivity. However, a distributed team can recruit globally and look for the best and most appropriate people available in the world. Once you figure out how to manage a distributed team, you have no excuse not to recruit ambitiously.
Obstacle: You feel you can't manage remote team members. Answer: Do the first six things in this section of the guide, then come back to this one.
Obstacle: Relationships. You usually find people and outsourcers through recommendations from your friend's cousin. Answer: Try advertising. You might like it. Your friend's cousin doesn't draw from a very big pool of candidates.
Agile teams should get releases out to users on a fixed schedule, frequently, ideally every day. This has a number of benefits. You get regular feedback from users, so you can improve your product rapidly. You fix bugs before each release, so quality stays high. And you establish credibility that you WILL deliver frequent releases, which reduces pressure on the development team and makes it easier to manage user requests.
As you approach your release date, you need to remove features that won't be completed, and stabilize the remaining features. This is very different from an approach that says you will release to users when you have finished the features. Do the release anyway. It builds your credibility. It also builds teamwork. The more frequently you release, the more frequently you bring everyone together to work on the same thing.
When people see these recommendations, they often say "That's a good idea, but..." and then raise obstacles. Let's provide answers to those obstacles.
Obstacle: Some users (or bosses) don't believe that they will get a follow-on release, so they insist on asking for EVERYTHING in the next release. If you let this happen, you will never get the release out. This is a self-reinforcing cycle, because if you don't release on time, they become even more sure that a release is a rare event, and they push even harder for "everything." Answer: Release on time. Users will start to believe they will get more releases, and they will not object if you move features to a follow-on release.
Obstacle: You just don't feel right about releasing unproven features to customers that expect sizzle and reliability. Answer: Do the release, but not to everyone. You can partition your user base into internal testers, beta testers, and risk-averse customers. Then target each release to the correct group.