1. If you are remote then it is your burden to make the rest of the team not notice. Simple things like picking up the phone and talking to team members on a daily basis, and not just in the daily standup, worked great for me and the team. Being on both sides of the situation, nothing is more frustrating than not being able to get in touch with the ‘remote guy.’ The worst thing you can do is go dark when you are remote.

2. Keep the team small. Our project had three developers, a Scrum Master and a Product Owner making communication much simpler. This wasn’t necessarily by design but in hindsight, and compared to larger teams with more remote employees, this was a contributor to our success.

3. Travel on a regular basis. We worked with four-week sprints for awhile and I would travel once a month to be at planning sessions in person. When we decided to go with two-week sprints we would do as much planning as made sense and made adjustments over the phone if I was not there for the next iteration.

What’s your view on integrating the formal collaboration and workflow of software development, vs. the messy stuff like idea generation, brainstorming, finding historical bug knowledge ”stuck in somebody’s head”, etc?

Like folks here, I’m personally a big proponent of real-time, group-based chat. Not IM, but chat. One-to-one IMs are lousy for group collaboration, and the collective learning that should result. With group chat, you can pose questions to a whole group of folks at once (and everyone learns the answer the same time as you!).

How do others view that? (truth in advertising – I just blogged on this very subject)

Cheers,

Eric, http://blog.imroadmap.com

Four other tools / tricks to add to your list:

* Mimio (http://www.mimio.com). It’s basically a $500-$1000 gadget you attach to any existing whiteboard. It tracks the whiteboard markers in real-time, drawing on the whiteboard on your screen. Use this in combination with VNC or Webex and you can “broadcast” your whiteboarding session to anyone you want. It’s uni-directional, but better than nothing. I suggest finding one on eBay. The old serial ones (work just as well as the new USB ones, and are alot cheaper used.

* Digital camera. Snap pictures of whiteboard doodles, upload them to your wiki or email them to other folks remotely. Nobody likes taking down the notes, and this lets you cheat. Great poor-man’s alternative to mimio, or good if you forgot to turn on the mimio.

* Digital voice recorders. Use this instead of or addition to below. Record your meetings, and agree an audio marker/annotation format, so that you can share the voice notes with folks via mp3 and quickly zoom to a given recording section that you care about (“…. the argument over JDK versions half-way through the meeting…”)

* Hire/use a minutes-taker. Great for formal meetings and will save you LOADS of time, confusion and debate down the road.

Tools we are currently using / evaluating that I like:

1. IRC for real-time chat. Most IRC clients keep a history of conversations. Skype.com and FreeConference.com used for voice chats.

2. Just started evaluating Rally (www.rallydev.com) and am quite impressed with it so far, the first agile tool that has me excited. The free version allows up to 10 users on one project.

3. Google docs, great for accessing / sharing and collaborating on.

4. Project mailing lists for easier email conversations and archiving.

I’m looking forward to trying out Mind Meister and Planning Poker. :)

In reply to Eric’s question on chat integrated into the IDE. I would do whatever my team wants. If they ask for it, I will find a way to provide it. However from a personal point of view I’m not sure what benefit it would provide – I’ve not even found the benefit in Eclipse’s new task tab. So I wouldn’t be inclined to take away precious IDE pixels from my code.

My group chat client resides on my second monitor with my email and browser.

Cheers
Mark

Very good developers perform well on their own. Less skilled people need others around in order to request their help. If you have a team of rock stars then you can let them work anywhere they want to and it will turn out well. But if you have junior or medium level people, you need much more guidance, a team room, pairing and all the other helpful tools and techniques. An experienced trainer/consultant some days of the week would be great help as well. The available tools for software development can be overwhelming at times and having a guide makes a huge difference.

VNC’s security is terrible unless it is tunneled through SSH, at which point the performance drops to ugly. FreeNX/NoMachineNX has better compression algorithm support and a better security profile than VNC.

@ Stephan

> Isn’t all the open source developed at a distance?

Not all; more to the point, there are lots of great open source projects out there that have wonderful functionality and really ugly code. The open source projects that really are flagship operations are apache and firefox, and they may be open source projects but they’re not exactly open communities.

> the skill level of developers makes the difference

Change “skill” to “discipline” and I’ll agree with this statement. There are lots of coders out there that are brilliant but undisciplined – having a bunch of really talented but ad-hoc programmers trying to operate while in a distance environment is going to give you a cruddy final product. I’ve met more than a few people who have had the “rock star” label hung on them, and while they may be able to tear apart and rebuild code amazingly fast and remarkably bug-free, there is a very small percentage of them that can do so while producing code that anyone can read. I’m not a programmer myself, admittedly, but in the systems administration business “what happens if Joe gets hit by a truck” is one of the first questions a good sysadmin asks. That should hold true in programming projects as well.