Tips for virtual teams
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
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
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.
Mike Gunderloy has been developing software for a quarter-century now, and writing about it for nearly as long. He walked away from a .NET development career in 2006 and has been a happy Rails user ever since. Mike blogs at A Fresh Cup.