The first step to succeeding with a distributed software team is to accept the fact that your team will be less...
productive than it would be if all team members were co-located. Everyone on the team will expend extra effort to actively communicate and collaborate. People will have to be flexible with their schedules and work to continually improve.
However, you can benefit from some advantages to having team members in multiple locations. Let's look at some key factors that allow a distributed team to deliver high-quality software that brings value to the business.
Teams distributed around the globe have obvious cultural issues to deal with. However, the team culture is even more important. Start by establishing the team's value system. Are you all committed to producing the best possible software quality at frequent intervals? What does that really mean? Are you going to let yourselves get stuck if you run into obstacles such as difficulty coordinating between locations? Once your team has agreed on its goals, it can find ways to achieve them.
Foster a learning culture: build time for experimentation into your planning. Make sure team members know that if they make mistakes, they should simply learn from them and move on – they won't be punished. Create an atmosphere where each person feels safe to raise issues and ask questions. Yes, this is something you should do on co-located teams too, but it's even more critical when time and distance separate software developers.
I'm not sure why, but "face time" is critical for remote team members. I've seen the positive effects of face-to-face communication (real or virtual) over and over on my own teams, and other distributed teams have told me the same thing. If you're starting a new project where whole teams or some team members will be in multiple locations, get everyone in one place for a kick-off meeting. Gather the whole team at regular intervals if possible. If frequent face time isn't possible, send one or a few team members to different offices as often as you can.
I worked on an XP team where developers were located in three different states, including the client's site. Each team member spent one week a month in one of the other locations. We got to know not only each other, but our customers. We also paired on all development and testing tasks, remotely when needed using VNC and telephone.
Back when I worked on that distributed team, video conferencing technology was not where it is today. Now, my team can take advantage of Skype and other video technology. We created a virtual tele-presence device so that remote team members can be virtually in the team room. We put a laptop on a rolling cart and added a good-quality webcam which can be controlled remotely. We also added a high-quality microphone which can pick up even casual conversations in the room, and good speakers.
The developer in India joins the standup meeting each morning on this device, so that we can see him and he can see us. When anyone needs to pair with him, we roll the cart over to the appropriate desk. I myself use this device when I work from home. It's pretty much just like being in the room. My teammates can even hear me type! If I need something, I can just ask, or pan the camera around the room to see who's there. If I hear a discussion going on that's important to me, I can join in, instead of wondering whether people made decisions they forgot to tell me about.
Communicate and collaborate
Using a virtual tele-presence device as the 'eyes and ears' of each remote team member is a giant boost to communication, but it's not enough by itself. Set up a team wiki to encourage collaboration – and make sure it is updated constantly throughout each team's day. Experiment with online task and user story management systems and see if they work for your organization. Put a "face" on your user stories and tasks, too. I know teams who put a photo of the person working on a task right on the virtual task card.
Make sure to try the lower-tech solutions too. My team went back to a physical task board after a couple of years of using an online one. We simply take high-resolution photos of it at least once a day so that remote people know who's working on what, and what tasks are left to do. Our board is pretty large, so we take one photo to show the overall status, then a photo of each half of the board to allow easier reading of the cards. Zooming in on the photo in the browser, the cards are quite easy to read. We also put a photo of the person responsible for each story next to the cards - again, we find a face helps!
I worked remotely on a different team where I maintained my own copy of the task board (in that case, it was a kanban-style board) in my home office. I could simply glance at the board anytime I wanted to be sure what I should be working on. This lower-tech approach only works if the team is disciplined enough to write the cards clearly in large print, using black markers so they're readable, and takes clear photos of it every day. Then again, using an online story tracking solution also requires discipline - each team member must be diligent about updating the cards every day. I know some teams at larger companies that use both a physical board and an online tracking tool. Experiment and see what works best for you.
Whiteboards have been proven to enhance communication, but what good does that do if your team is not co-located? Technology can come to the rescue here too. There are fancy whiteboards that work across multiple locations. There are also online sites that let people in different locations draw diagrams and mind maps, collaborating in real time. Again, my team has found that photos of whiteboards work well enough, but you have to try out various approaches until you find the one that lets your team communicate about design, functionality and other aspects of software.
Each distributed team I've worked on found backchannel chats essential during meetings that included remote people. For example, when my team has a pre-planning meeting to go over user stories for the next iteration, I bring my laptop so I can instant message with our developer in India. I can type in what's being written on the whiteboard, as well as send photos. He can ask me questions that he doesn't want to interrupt the whole meeting with. This can help when there are potential language issues. Chat software such as IRC lets you have multiple channels, which can be useful. I worked on a team that had a channel for testing-related topics, and a 'social' channel where people told jokes and talked about the latest movies or music. This helps build team relationships and made work fun no matter what your location.
If your team has a wide distribution of time zones, make sure everybody has enough work. My team circles back at the end of the day to make sure we've told our teammate in India what we've done and what tasks he can work on. You can turn a wide timezone range to an advantage, checking in new software and running automated builds with tests round the clock.
These are just a few of the key factors for making distributed software teams work well. There are many others we don't have room for here. For example, there are many development practices such as build and test automation that are indispensable. However, if you start with the foundation of a learning culture with good communication, trust and collaboration, your teams will be able to master software craftsmanship over time.