Your distributed team will need communication tools and techniques to replace the in-person chatter of a co-located team.
Do not try to manage your distributed project with daily conference calls. People hate it. Think about a project where you participated in a lot of long conference calls. Did you enjoy it? Was it a satisfying, successful project? I have asked hundreds of people this question and they have never recalled a case of a good project with a lot of conference call time. I find that conference calls are a good indicator of failing projects. They make the boss feel better by allowing him or her to share his or her problems. They don't solve problems for team members. They eat time that could be used to fix problems. They come at awkward times of the day. I laugh when I hear about how the boss has to get up in the middle of the night to inflict a conference call on his Asian team. Calls demand attention, and attention is a very scarce commodity.
"Synchronous" communications happen between two or more people at the same time. Face-to-face conversations are synchronous. Telephone calls are synchronous. In "asynchronous" communications, people can respond at different times, at their convenience. Emails and text messages are asynchronous communications.
A naive manager will try to replace his co-located conversations with equivalent, high-bandwidth, synchronous communications. This leads to a lot of conference calls, some of them late at night. It also leads to a vision of the future where everyone is in front of a camera, video-conferencing with colleagues as if they were at the next desk or in front of the proverbial water cooler.
However, many hard-working people prefer asynchronous communication. Even if they are sitting at the next desk, you will see that they often email each other and respond at leisure. This trend is particularly strong among young people who prefer to receive text messages rather than voice calls.
Why do they prefer short and seemingly unsatisfying text messages over real conversations with friends and colleagues? There are two reasons. First, they don't want to be interrupted. They want to pay attention to the thing in front of them, which is often computerized. Second, they are multitasking, having many different conversations at one time. At the same time that you are trying to talk to them about a weekly plan (bla bla bla) they are discussing an engineering point they care about, and arranging for beers with friends.
As we become more productive, and as the competition for our attention intensifies, we come to prefer asynchronous communications. Also, we get annoyed by people who demand our attention for synchronous meetings.
Write your ideas, requests, bug reports, and comments in an online ticket system. They will be visible to the entire team, and you have a running, long-term record of contributions.
If you are writing feature requests, learn to present complete "stories." That makes the implementation work easier, and you will get better results. We describe the elements of a good story in the Product Management chapter.
Your team will have a default view of the Work in Progress tasks which shows the status of each task, and shows who is working on it, or where it is waiting. Agile teams call this an "information radiator." You can always go to this view to find something to work on.
A good online ticketing system with comments and attachments is a requirement for a distributed team.
I live on email. I type thousands of words per day in email. However, it's a dangerous addiction. You should avoid using email for team communications. Information in an email thread is invisible for other team members. This creates work for you when you have to relay the information. When people email you details that are not important, they waste your time. When they email you information that is important, you need to repost it for the team, which wastes your time. Avoid becoming a human router. I recommend using email only if you are asking a personal question. If people send you information by email that they should be sharing, just ignore the information until they post it properly.
Every distributed team should have a chat running. People like chat because it can be synchronous when they want to have a real conversation, and asynchronous when they want to come back to it later. You want a persistent chat that team members can come back to at any time. You probably also want a searchable history so that you can find that URL someone posted last week. We use Skype. You can now get chat systems designed for programming teams.
You will want to post your documentation and instructions on a Wiki. If you are inviting new people to join the project, you should take some time to document the setup and other instructions. Later you will want to document test, build, and deploy procedures.
You will want to post status reports, meeting summaries, and major questions on a message board. These tools aren't absolutely required, but they are helpful and they help move communication out of email and into more visible formats.
Other useful communication and collaboration tools include:
Online standup reports. Your team can post "What I did" and "What I will do today" and "What I need" on a form. We built this form into Assembla. It only takes about one minute to post a daily report this way, so it saves a lot of time compared with other types of reporting. After that you can get on the team chat to discuss any questions or needs. It's very useful to read the "What I will do today" reports, because you will often see that people are working on things that are not very important. By asking them to work on higher priority items, you can blast through project obstacles.
@mentions. In some ticketing and collaboration systems, you can @mention teammates to draw their attention to your comment or question. They will get a link on their dashboard that goes directly to the discussion. This is a great way to collaborate and build a visible discussion.
An effective distributed programming team communicates with code. In fact, many of the most successful distributed projects are open source projects that communicate almost entirely through the exchange and review of code.
Distributed teams should have either a daily build or a continuous build of code. This shared build communicates a lot about the state of the project, and it gives everyone, even non-programmers, a way to see current code and comment about it. If you want your distributed group to work together as a team, then you want everyone to be working on the same thing - the shared build.
Programming teams exchange code through their version control systems. Code management workflows can facilitate many types of communication:
An important function of a project manager is to improve communications between team members. If your team communicates mostly with code, then a non-technical project manager will not be able to participate. That is why modern continuous projects use tech leads who can understand code.
I like to do big full-team calls to kick off a project. This ensures that everyone on the team hears the same plan and the same goals. Your team will form around the goal. After that, I do calls that include only the correct people, the people that need to be on the call. They will appreciate the call if it is for them.
Some teams are getting good results with Google Hangouts, which is a sort of informal, low-fidelity group video conferencing tool. It works better than a formal videoconference that requires a lot of setup and synchronous attention.