A geographically distributed software development team (“distributed team”, for short) is simply one where developers don’t work in close physical proximity (within a few hundred feet). In such a time you interact mostly via electronic means.
To some readers a distributed team will sound like an obviously ridiculous idea, while to others it will sound quite normal. A great many companies are distributed nowadays, as are essentially all open source projects, including the largest and most successful such projects. (Does open source seem like a toy to you? Not “real”? Consider this: in your real project you need large amounts of money to get everyone to work together to build something. Open source projects somehow accomplish this without the carrot and stick of money. Which is more impressive?)
Distributed teams appear to be most common in small firms, but certainly aren’t rare elsewhere. At some large firms, there are teams that work at the same campus or even in the same building, yet are inconveniently spread out enough that they are borderline distributed.
At Oasis Digital we operate mostly as a geographically distributed team, or rather as a set of teams (for various projects). We are scattered around our city, our country, and in a few cases, globally. We’ve learned a lot about how to succeed this way, summarized as 14 tools for a productive distributed team:
(1) Online meeting / telephone. Effective online meeting tools are available inexpensively or sometimes free; telephone calls, including mobile, long distance, and conference calls are free or inexpensive. Either way, don’t hesitate to spend time together and live discussion, with at least voice and ideally video. Especially the early stages of a project, this is by far the closest match to in-person interaction, of all the tools in this list. At Oasis Digital, we typically use a regular weekly discussions as a baseline, with more discussions of all kinds as needed. (Frequently at the beginning of a project, less frequently over tim.)
(2) Instant Messaging. Beware that your time is valuable though; don’t type out a long conversation, when it gets complex talk live instead. The key value in IM is as a substitute for the awareness of who is available and working, that would be obvious in the same office.
(3) Email is especially helpful to create a thread, a trail of key decisions. I suggest summarizing key decisions, especially when they span between different teams, in a (hopefully concise) email – even if the decision was reached by meeting, phone, IM, in-person, etc. As above, beware that email can consume unlimited amount of time, and don’t hesitate to switch to live discussion if it gets complex.
(4) Airplane / Car / Train. The most powerful tool to help a distributed team work well is occasional in-person interaction.
(5) Documents. Communicate a complex idea, especially one that will need to be explained again and again, clearly in a document. (An aside on “template” documents: I’ve found them to be of limited value, though we use them when needed to meet customer requirements.)
(6) Screen Sharing. Using Remote Desktop, VNC, and other tools, it’s possible to do “pair programming” from half a world away. In our projects we do a only a little of this, but a few hours of pair programming on a tricky area can work wonders. Screen sharing is also extremely useful for demonstrating new features, reproducing bugs, working with customers, and much more.
(7) Screencasts are video/audio recordings of the computer screen and a person talking; they are very useful for explaining a feature or module to another developer. Recording then viewing a screencast is not as effective as sitting alongside someone explaining in real-time, but it has the tremendous advantage of re-playability. A series of (high quality) screencasts explaining important parts of a system will get new team members up to speed quickly.
(8) Audio recordings. Record an audio explanation of a feature or bug, while walking around or driving, on an inexpensive hand-held digital voice recorder. Then send it to another developer as is, or have it transcribed. Again, it’s not quite as effective or high-fidelity (of either the audio or the ideas) as an in-person explanation, but can be replayed, sent to multiple recipients, etc. A caveat here is that people read much faster than they listen, so if you have something long-winded (or long-lived, important) to say, have it transcribed then edit it. You may find, as I have, that it’s far easier to compose a long detailed explanation this way, than via direct typing.
(9) Screen Shots. Don’t just tell; show. Show another developer on your team what you mean by taking a screenshot them marking it up. Unlike a screen recording, it’s easy to go through a set of screenshots and update just one of them in the middle if things change.
(10) Mockups. A distributed team leaves more room for misunderstanding of desired results. Counteract this by building a mockup (paper, Excel, etc.) of what you want.
(11) Issue / Bug Tracking. If you don’t have an issue tracker for your team, stop reading this now and go get one: Mantis, Trac, Jira, there are hundreds to choose from. (Go ahead. I’ll wait.) A common approach for collocated teams is to use a tracking system loosely, updating it occasionally. In this usage model, tracker items act mostly as high level token for more detailed information exchanged in conversations. This approach can be made to work on a distributed team, but in my experience it is unwise. Instead, get every issue in to your tracker and keep it up to date aggressively. Don’t let the sun go down with your issue tracker mismatching reality. Assume that others on your team will check the issue tracker then make important decisions relying on the data therein. If they see something that was fixed 3 days ago, but still marked as broken, bad decisions can easily result. Anyone on the team should be able to see the essential status of every current issue in the tracker, not by a time consuming process of asking someone about each item.
(12) Source Control. You’re already using this, of course. For the future, consider a distributed source control tool (bzr, git, svk, Mercurial, etc.) for your distributed team – if you’ve only used centralized tools (CVS, SVN, ClearCase, etc.) you’ll be surprised how helpful it is to have the project version history available locally, among other benefits. (See Linus explain distributed source control.)
(13) Code Review. Some collocated teams enjoy social camaraderie, but squander the benefits of proximity by working in technical isolation. Your distributed team can outperform them easily: avoid technical isolation. Read each other’s code, comment on it, learn from each other.
(14) Automated Builds. Surely there is hardly anyone left by 2007 who isn’t using an automated, continuous build process on a server somewhere. The value of this is amplified in a distributed team, because the stream of successful builds (we fire off a build after each commit) helps keep everyone in sync.
A related but separate question is where distributed team members work: in their homes, in offices outside their homes, in public spaces, etc. I believe the best answer is a blend of these; I mentioned hiding in a cafe to get some work done before, and I’ll write more about the Where question in a later post.
Another related question is whether any of this is even a good idea; stayed tuned to read more on this as well.
I moved to a remote team about a year ago and just recently became a remote member working at home, so I have been acutely aware of learning how to work in this new way. I’m using pretty much all the techniques above and it’s definitely taken a little adjustment, but I’m pretty comfortable working remotely now. I feel like I actually get more work done remotely (especially with a time zone difference) as there are longer periods that are interruption free.
One I would add that we use at Terracotta is IRC. We keep an open irc room and typically someone is always logged in there, so you can usually track someone down or bounce ideas off someone there. Also, they have a bot that tracks and archives all discussion there, which in some ways makes it better than IM (but not as good as email) for recording.
You also failed to mention wikis, which are great for certain kinds of information (product / project docs for example), like stuff that is not too dynamic (issue tracking) or requires discussion.
I think I would also possibly mention blogs, although that has to be a central part of your culture. There is a bit of internal project blogging at Terracotta and I can imagine it being something important to a team, but I haven’t witnessed that personally.
I find email to be very frustrating because people mail their little circle of “buddies” to resolve problems, but only people in the CC list are included in the conversation. You mention that email leaves a “trail”, but only for the few lucky enough to be included. Other people do the opposite, spamming the whole company with every trivial issue. When new people are hired, they don’t have access to this so-called “trail” you mention. I try my best to advocate discussion forum software so conversations and decisions are truly archived for all to see.
+1 on screencasting. I use that quite a bit for little training videos. It really frees up my time when I can give people a simple URL to a video that shows them the answer to their question.
My firm gets by quite nicely with a source control tool by Accurev. It has a GUI called the StreamBrowser that provides a flexible, stream-based dynamic view of the development process that not only allows us to work in this view, but also provides developers, release engineers, managers, etc. a view into who is working on what, where, and how everyone fits into the process. The drag and drop features to move releases and people around, etc. is neat and any merge conflicts are resolved easily and efficiently. It may also allow you to not require so many collaboration tools, or at least greatly enhance them.
Good luck!
Josh
Echo Alex Miller’s comment about Wiki’s. You might also find that automated testing coupled with your source code control system is a good way of flagging interoperability problems early. For example, if you are using subversion coupled with TRAC, you can run a your test suite every night if there has been any changes during the previous 24hr. Couple the results with a dashboard that graphically reflects the test results and you have an “at a glance” status of the development.
I use nose/python/(subversion/bazaar/git)/trac as a platform and it seems to work pretty well for distributed development.
Our company is going to provide remote technical support to our customers.
We need to have a reliable and cost-effective remote support tool to satisfy our clients’ needs and not to go bankrupt because of the high cost of the tool.
We wouldn’t like to have something to be installed either on our or customer’s side. We’ve come across a web-based tool by the name of (redacted) Does anybody have anything to say about it?
Can you suggest something more appropriate?
Regarding remote control tools: Yes, I recommend VNC (especially UltraVNC). It is free, and works well for remote support. Further, you can easily make a customized VNC download, by following directions on the UltraVNC site, to make it extremely easy for your customer to set up a VNC connection.