News

Tips for virtual teams

• By Mike Gunderloy
• April 27, 2004

Recently, I've been working on a fairly small development project, with three of us splitting design and development chores. The challenge, though, is one that's on the increase in these days of the Internet: we're spread around the map, sometimes being in three different states at the same time. It is possible to develop software this way, but there are certainly pitfalls. I like to think I've learned a thing or two that's worth sharing, so here's a small selection of things to consider if you find yourself in a similar situation.

Have a continuing customer presence. Unless your customer is very forgiving or very up-to-date, they're likely to find the notion of a virtual team at best disconcerting and at worst scary. The easiest way I know to pull the customer back into their comfort zone is to make sure that they see one face from the team on a steady basis. This allows your point man to build up some face-to-face relationships and to keep an eye out for those signs of danger that are hard to sense from far away.

Have a shared knowledge repository. With a team that's spread across timezones, and no office hours to pull them together, it's not unusual for people to be on completely different schedules. The more this happens, the more critical it is to have a place to store documents that everyone can get to, no matter the hour. We're using a Windows SharePoint Services site on the project I'm working on, and it's serving that function just fine. By checking out documents, we can make sure that we don't overwrite one another's changes, which is another plus.

Instant messages are your friend. Our entire team spends pretty much their whole working day online and signed into an instant messaging application. This makes it easy to tell who's available at any given time, and easy to pass information back and forth without the interruption of a phone call. Use an IM client that can log all the messages, and you'll have another knowledge repository that you can search in the future.

Sync up frequently. When you can't poke your head over the cubicle wall, or listen to the growls of debugging displeasure, it's a lot harder to know what co-workers are up to. It's worth a daily phone call or IM conference (or more than one) to make sure everyone still thinks things are moving along in the same direction.

Use e-mail as a last resort. Yes, e-mail is a convenient default way to pass things around. But e-mail clients tend to leave everything as a disorganized heap, and make searching for things tough (Outlook's search is especially abysmal). With SharePoint, TCP/IP-enabled source code control, Web-based bug tracking, and so on, you can move most of your project's information into much more organized repositories than an e-mail client.

All in all, I find distributed offsite development to be challenging, but certainly not impossible. The key is to keep open lines of communication with the rest of your team - and to have a team that feels the same way.