Imagine software development with an entirely remote team.

Using modern technology (IM, IRC, Skype) and 24×7 connectedness, team members can even do remote pairing without sitting side by side. When you think about it, whether developers are 10 cubicles apart, 10 floors apart, 10 blocks apart, or 10 states apart, today’s modern collaboration tools make it almost as easy as sitting next to each other. After all, being 10 cubicles apart for most devs is about the same as 10 states apart.

Admittedly, there could be some efficiencies to being co-located. Sticky notes can be more easily shared on the local wall. Sketches on whiteboards are more collaborative as folks can easily share pens and authorship in real time. And, there are some inefficiencies: you can interrupt your co-worker ad infinitum. you can discuss things around the water cooler, etc.

Conversely, remote teams require more attention to being very open, visible, and sharing. Web-based issue trackers and wikis become invaluable. Doodles often become either camera phone snapshots uploaded to the wiki, or they become collaborative drawings via a wiki graphics plugin, or drawing source file put into version control or otherwise shared. Co-worker interruptions take on a certain hierarchy of importance once you get a few rules of etiquette in place. for example: if an answer can wait, use email (and use an email list!). if you’d like it within the hour, IM. if it is urgent, phone. If it is private use, a back channel — but ensure text “conversations” that should be public are moved into the visible realm. Similarly, it is best to answer things via the wiki or issue tracker, and email links if needed. This avoids the dreaded “management/requirements by email” problem. Keep it visible and shared for all!

So, remote teams that do a real good job of being visible probably spend more time *being* visible and more time creating (mildly) more formal artifacts than a co-located team would require. That could be considered less efficient. However, more artifacts being one side effect of being remote is not all bad and wasted effort. On the contrary. This often leads to greater efficiencies as the team grows. Each new member helps grow and improve the “getting started” wiki page, for example. Or, each new person added to the team helps grow the “FAQ” page.

If only i had plotted the time required for a new team member to get up to speed (and they were almost all remote), it dropped steeply with members #2 and #3, and is now a very flat line at a very low level. I can bring on new contractors and have them doing issues within a day or so.

In some cases, we’d get the teams together every so often — usually when there was at least one “office” of sorts (often the client). But not always.

Having been doing remote work for over a decade, and being on a kick to have shared project knowledge bases for the past 20 years (when early on, the best I could muster was a shared network drive and local web server kind of thing), i am comfortable in my remote ways.

I have also successfully instilled this on other teams that had remote offices and team members.

But it does take effort and commitment. It can easily degrade if members do not feel comfortable being always visible and sharing.

I’d be interested in your trials and tribulations at working remotely.