The Devver Blog

A Boulder startup improving the way developers work.

Our Tools & Practices for Remote Collaboration

Last week, we had Avdi, the newest addition to our team, join us in Boulder, CO. It was great to get some face-to-face time, since Avdi will primarily be working from his home in Pennsylvania while Dan and I continue to work in Boulder.

We are excited about the benefits of having a distributed team, but we’re also aware that there are a number of challenges. As a result, one of the things we worked on last week was figuring out the tools and practices we’ll be using to work effectively from across the country. Luckily, both Avdi and Dan have experience working remotely which we can draw upon.

We evaluated a number of options, but settled on the following tools and practices.

Practices

  • Daily Standup. Every day at the same time, we all get on video chat. We cover what we did yesterday, what we’re working on today, and whether or not we’re blocked on anything. The goal is to keep this meeting at 15 min or less.
  • Minimize interruptions. Whenever we need to communicate with each other, we try to do so on the channel that is the least disruptive (and disrupts the fewest team members). Of course, sometimes we need to be disruptive if an issue is pressing, if someone is blocked, or if we need to have high-bandwidth communication (information, especially cues like body language, don’t come across very effectively on channels like email)
  • Keep it simple. We want to use the smallest number of tools and channels that will allow us to work effectively.

Channels and Tools

Less
disruptive
More
disruptive
Channel Tool Properties
Passive Updates Present.ly
  • Asynchronous
  • Not required reading
Email Any email client (in practice, Gmail)
  • Asynchronous
  • Required reading (usually)
  • Sometimes time-sensitive, sometimes not
IM Skype
  • Semi-synchronous (but usually synchronous)
  • Usually time-sensitive
Voice/video chat Skype
  • Synchronous
  • High bandwidth* (especially video chat)
  • Best for meetings

* By “high bandwidth”, I don’t mean that the tool itself requires a lot of TCP/IP traffic (although this is true, it doesn’t really matter). What I mean is that we can communicate a lot of information between team members in a short amount of time.

Other Tools

  • Lighthouse for issue tracking
  • GitHub for source control and our project wiki
  • RealVNC for screen sharing (essential for remote pair programming)

This is our first attempt at finding a good set of tools and practices for remote collaboration. As time goes on, we’ll undoubtedly iterate and improve upon these.

For another perspective (with a slightly different set of tools), here is a presentation from 2008 about virtual teams.

What tools and practices have worked (and which have not worked) for your team?

Written by Ben

April 28, 2009 at 8:57 am

4 Responses

Subscribe to comments with RSS.

  1. Great post Ben! Awesome tips.

    emily_olso40101

    April 28, 2009 at 1:21 pm

  2. Having a VNC server on every machine is one of my favorite development hacks: it reduces the "show me" cost from finding a time & moving bodies to a 3 second "launch a program and watch" experience. Often times as discovery progresses, you'll need to show someone something again, or to demonstrate a new permutation of the issue; after two or three round trips it gets tiring, whereas VNC is eternally a command away.

    rektide

    April 28, 2009 at 4:15 pm

  3. We've used iChat for screen sharing to similar effect. The beauty there is that anyone who has iChat can immediately share their screen with you without setting up any extra software. Of course it helps that we all have macs. For a remote team member, it has made the difference a few times between him being stuck and out of sync to him being chugging along.

    For pair programming, an intriguing up-and-coming hosted tool is bespin, from mozilla labs: https://bespin.mozilla.com

    We can't use it, yet anyway, because it doesn't support git (which will change soon I think). They also seem to be talking specifically about open source, so I'm not sure where (or when) closed source fits in with them.

    Charlie O'Keefe

    April 28, 2009 at 10:48 pm

  4. We utilize very similar practices, but with a couple different tools. We shifted from Lighthouse to Github's 'Issues' — migrating was a pain, but it was worth it to have most development activity within one site. We also use Campfire for chat — we like the logging feature, and our team is on different time schedules so quickly reviewing where the each developer left off and what was important enough to chat about keeps everyone on the same page.

    William Sulinski

    May 7, 2009 at 6:55 am


Comments are closed.

%d bloggers like this: