Keeping a dislocated team on track

Question

Being a part of a small development team that is geographically dislocated, I keep running into constant problems with keeping the projects on track and the team productive.

Aside from project collaboration software and regular communication, there seems to be little to do to improve team synergy.

I would really appreciate any tips, tricks and techniques you might have successfully applied to your teams with good results.

Answer 1

A few things that I've found helpful in a similar situation:

• Regular scheduled project-planning meetings where responsibilities are discussed, and team members make commitments and discuss the issues they had if they've not delivered on one. We found that an hour-long meeting once a week, involving a spreadsheet tasklist, seemed to be helpful.
• Easy availability for quick Q&A - AIM worked well for us.
• If you can choose your team, opt for experience. There are too many little things that are hard for somebody younger to pick up remotely. One of the biggest problems I've found is that inexperienced programmers don't know when to stop spinning their wheels and just ask for help.
• Wall off project tasks as best you can. It doesn't matter that people are somewhat isolated if they are not doing interdependent work.
• If you are the team leader, schedule time to track & follow up what the others are doing. Management takes time, and one can't be a full-time programmer and still expect to do a decent job coordinating what everyone else is doing.

Answer 2

I'm not one to automatically assume that the latest trend in software development will solve all problems, but I found that SCRUM works very well for managing geographically separated teams.

I used it very successfully on both small and large projects involving teams in India and China (while being based in the USA).

The notion of a short sprint that delivers working software combined with daily standup meetings create transparency and accountability remarkably well.

Answer 3

Two things are essential for keeping a small-ish development team on track and in sync: a bug/issue tracker and a continuous integration tool. I here assume that you are already using a SCM. Couple the bug tracker and the code with crossreferences and use a continuous integration tool that is aware of both the bug tracker as well as the SCM repository (with regards to diffs as well as tagging builds).

Good tools include cruise control, hudson and bugzilla

Once these things are in place you can start considering what the meeting frequency and style should be (it can be hard to do good meetings across many timezones), if you should have code reviews, and what kind of conferencing software you should use. The code and the environment surrounding the code is the most important thing to get right.

There are similar post here at SO.

Although I really like Martellis suggestions, it requires a large-ish budget but most importantly some 'star' programmers. When you're looking at getting a small gig done with a fixed architecture (as fixed as they come, anyway) and you can only afford one get-together a year, in my opinion, you'll want to have a rock solid foundation. Think the processes through and pick your tools. Martelli is right in saying that no tools in themselves will make a difference, but they never do - not even in a team that shares breathing.

Answer 4

Do as many sprints as you can possibly afford on your travel budget -- they're a HUGE positive on team productivity. The only company I know that's able to make distributed teams consistently productive, Mark Shuttleworth's Canonical, as far I can see has two basic "secrets" to it: first, they mostly hire open source superstars, partly because they're totally focused on open source, but also because people who have proven to be very productive in big open source projects have thereby also proven they have whatever "secret sauce" it takes to work on a distributed team; second, they sprint a lot, flying people in from all over the world to meet at a variety of locations and just hack, hack, hack away -- just like open source projects have in recent years discovered is a GREAT approach.

Disclaimer: I happen to know a lot of Canonical's employees -- I guess that this is not surprising given their focus on open source, and Python in particular -- and particularly admire Shuttleworth for his vision and management skills (and his taste in books, ever since he asked me to sign his copy of "Python in a Nutshell";-). But despite this bias I think the above evaluation is objectively defensible.

In my on-and-off-again capacity as a manager (I seem to switch between managing and individually-contributing every few years, just as I seem to keep switching between Europe and the US;-), I've often been asked to deliver SW with a distributed team, but I do NOT consider my achievements on that especially difficult goal to be anywhere close to being successful; I've convinced myself that, personally, I may be great at leading and/or managing a co-located team, but I can't hack it at managing and/or leading a distributed team. But then, I've never been given a rich travel budget to play with, or reports who were selected for being especially good at distributed-team work; maybe I could do better in the future if I were.

I have witnessed people (good and otherwise sensible ones, mind you;-) make grandiose claims as to how distributed-team work SO well under their own management, typically thanks to the latest and greatest silver bullets in methodology, communication technology (video conferencing and the like), programming technique, whatever. Every time I've been able to observe concrete details, I've seen such claims disproven. When I find myself doing distributed work, I observe my productivity AT LEAST doubles on those sprint-like occasion where the team just happens to be in the same room for a while, hacking away... so, with rare but important exceptions, my current working hypothesis is that it just can't be done WELL -- except with great preliminary selection of teammates and lots and lots of sprints, like Canonical does!