#2782

Distributed Development – part 4

Peter Provost blogged on some of his experiences with Simulated Agile Team Rooms, largely at p&p. I’ve added some comments based on my experiences with the distributed/offshore model here and elsewhere…

1) Think about how to simulate the “in the room” experience where you can overhear and participate in conversations going on around you? Team void chat software like Ventrilo, Team Speak or our own Corporate Conference Calling system can work. Can you have an “open mic” in the team room? You also can give up on audio and use team room chat software like IRC. I’ve used them all. There are plusses and minuses to each.

Other tools that come to mind here are Skype. Anything that will give you a cheap always open connection to other team members. We used Windows Live Messenger quite a bit on the WSSF:ME project.

2) Think about the changes you may need to make to development practices. Do you use Pair-Programming and TDD? If so, you may want to take a look at Micro-pairing as a technique for coordinating the TDD/Pair handoffs. (Micro-pairing was actually created in response this exact scenario. I was pairing with another developer who was remote.)

3) In addition to practice changes, think about how to deal with remote desktop sharing. Live Meeting works, but can be a bit heavy. Virtual Server and the standalone Virtual Server client actually let two people connect to the same desktop. I know that VNC, an open source remoting tool, also allows this, but I would recommend you to be cautious with that tool. It has some known security bugs and your network admins may not allow it. Check with them first.

Our biggest challenge here has been finding a good tool to connect remote desktops.

4) Make sure everyone on the team has all the necessary access they need to be a full team member. Access to version control, portals, file shares, email aliases, etc. all must be available.

Not only do they need access to these things but the network bandwidth must be good enough to allow remote team members to use them as though they were in the room. For example, if version control is slow then you’ll see developers batching up work into larger changesets to avoid the overhead of connecting to the remote server.

5) Think carefully about how you do your team meetings. When you have only 1 or 2 people who are remote and the rest of the team is in a room, the person on the far side WILL feel out of the loop unless you run the meeting as if everyone were remote. One thing I’ve heard of is to actually have everyone go into their individual offices and dial-in to the meeting so everyone is on an equal footing.

I’ve heard this too. And seen it on projects where the whole team was co-located with the exception of one person. The odd guy who isn’t in the room soon gets dropped. It actually works better when everyone is in a different location or everyone is in the same location. Asymmetric distribution is the worst case.

6) Drastic time zone differences can make this very very hard on some team members. Ultimately this can be make-or-break for successful disbursed teaming. If people are 8 hours apart, when do you schedule standups and IP meetings? My rule of thumb is that more than 3-4 hours apart will kill you and you should split it into two teams that are closer in time to each other.

Geographical distribution is bad, temporal distribution is worse. You can mitigate larger time zone differences by running multiple standups at the beginning and the end of the day or having an in-room team representative who’s role it is to keep the remote team up to date. This is typically how p&p test teams work. Most of the testing is done in India (8-9 hours time difference from Redmond) and there are one or two testers in the room who sync up with the remote team at the start of their day. This is by no means perfect but it’s an option.

Currently listening to:
Frank Zappa – Sheik Yerbouti