Working as a consultant, I’ve been in quite a few situations involving distributed software development teams. By distributed I mean that a large part of the team members do not work in the same location. I wouldn’t classify one out of five five as a ‘distributed’ team but 2/5 gets there and 3/5 is for sure.
So let me paraphrase that age-old saying about distributed systems:
The first rule of remote software development is don’t do remote software development.
From personal observation, I have learned a few factors that determine the practical success of a distributed team. By practical I mean that the members of the team feel connected and are confident in their ability to move the software forwards.
- If the codebase is 30K+lines and several years old, and developers have been coming and going, a distributed team never works. In this case, developers rely so heavily on personal communication and pair programming to grok what is going on in the system, that a distributed team will get you nowhere, no matter how many conference calls, chat-clients and Skype calls you throw at it.
- If the project is greenfield, a distributed team might work if the team-members know each other very well, both personally and professionally. Knowing each other well at personal level is important because only then is there any hope of the rest of the team picking up the subtle hints that introverted but smart team-member is showing when a poor solution is proposed.
So, save yourself the disappointment of throwing money at a distributed team unless you know exactly what you’re doing. Nothing can substitute for being in the same space together and a sense of team-spirit. And oh, the ‘team’ here includes the main business-delegate, or Product Owner.
I’m curious as to under which circumstances you’ve found a remote team to work well, drop a comment!