Want to build a lean, mean, code churning machine? In our own projects, and in work with clients, we find that a distributed team can become agile and successful by doing six things. These simple tactics will not load you down with the jargon of name-brand methodologies. And, they will help you bypass the many "experts" who claim that you shouldn't try to run an agile process with a distributed team. Most software teams are distributed. So, let's get to work and churn out some software.
1) Release on a fixed schedule
An agile methodology relies on getting releases out to users, on fixed dates, hopefully frequently. This has a number of benefits. You get feedback from users, and your product improves. You fix bugs before each release, so quality stays high. And, you establish credibility that you WILL deliver, 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
When people see these recommendations, they often say "That's a good idea, but..." and then raise some objections and obstacles. Let's answer those objections and get around those obstacles.
Common 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.
Common obstacle: You just don't feeel right about releasing unproven features to customers that expect sizzle or reliability. Answer: You should do the release, but you should decide WHO to release it to. You can partition your user base into internal testers, beta testers, and risk-averse customers. Then, you can target each release to the correct group.
2) Share a daily or continuous build
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 effect 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.
Common obstacle: You don't have good automated build scripts. Answer: This can be a hard technical problem, but it is well worth the investment. Assembla is trying to address this challenge by providing virtual servers with pre-packaged build environments.
Common 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: I think this is a bad idea, and 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, find all of the problems immediately and complain about them. Then ask for fixes on a daily basis.
3) Write it down in tickets
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/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, if you communicate the request one-on-one in phone or email or chat conversations, you will get into trouble. Those receiving the information will have to make an extra effort to forward it to others. They information may be lost, or communicated inaccurately. You may step in and act as a human hub, forwarding lots of emails to lots of people, and searching through your email threads for individual answer. Don't fall into this trap. Write it down in a shared ticketing system, and have a good life.
Common obstacle: Some people just will not move off email or conference calls. Answer: Stop enabling them by forwarding their requests.
4) Daily report and chat
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", and there is a short discussion. You should collect this information, daily, from each of your team members (we have a handy Scrum tool in Assembla for this). You should also try to get most of your team members together for a 15 minute chat to set priorities and answer "what I need" questions. We use Skype chat or Assembla chat.
Common obstacle: Meetings take too much time. Answer: You can chat while you do other work.
Common obstacle: Too many time zones. Answer: Pick a time that is approximately survivable for everyone, and stick to it. People adapt to something that is consistent.
5) Watch a team activity stream
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 their friends. The same tactic is very important for uniting a distributed team. With the right web tools, 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 get teamwork, which is much better than individual task execution, and easier to manage.
Common obstacle: Tools don't support it. Answer: You will feel a lot better when you get tools that provide this visibility.
6) Recruit good people
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 appopriate person available in the world. Once you figure out how to manage a distributed team, you have no excuse not to recruit ambitiously.
Common obstacle: You feel you can't manage the remote team members. Answer: do the first five things and then come back.
Common obstacle: Relationships. You find people and outsourcers by recommendation from your friend's cousin, etc. Answer: Try advertising. You might like it. Your friend's cousin doesn't draw from a very big pool of candidates.
If you do these things, it is very likely that you will succeed in delivering good software quickly. The reverse is also true. If you aren't doing one or more of these things, you will often have problems.