Last time, I talked about all the challenges that surface when you attempt distributed software development, that is, having an IT project team being spread out over a wide geographical area. Simply put, it’s tough to do well, if at all, for a variety of reasons, including problems with communications among developers, maintaining conceptual unity of the system itself and managing a dispersed team.
Nevertheless, you may have strong reasons to do distributed development; in some circumstances, you may have no other choice economically, politically or otherwise. So if you’re doing to do it, how can you increase your chances of success and quality?
Besides my own experience on several projects with distributed development, ranging from a software startup to the global Iridium satellite telephone project, I solicited feedback from two long-time colleagues—Bruce Henderson and Deirdre Poeltler—and also got comments on the same subject on one of my Web sites. Here’s a summary of the key factors for achieving success in distributed development.
1. Use your best IT engineers for remote development.
I have written elsewhere about the attributes that make up an outstanding IT engineer: talent; education; professionalism; experience; and skill (“TEPES”). If you have individuals or small teams that are working remotely, you want to be sure these are your best people. Note from the list of attributes that “best” doesn’t necessarily mean “brightest” – it means most disciplined, trustworthy and self-motivated. You want people who can get the job done with a minimum of supervision and management, and who have a desire to do well and look good.
2. Small is beautiful.
As a commenter on my Web site noted, overall project staffing size is a key factor in success: The fewer people involved, the more likely the project will succeed. Of course, the irony is that the smaller the team, the more feasible it would be to relocate them to all work under one roof in the first place, but still, keep the size factor in mind.
3. Bring the team(s) together as often as needed.
Building a cohesive development team is difficult enough when all the members are under the same roof; it’s that much harder when there’s significant physical separation. Set a regular schedule to gather everyone at one location, and make sure that there’s time for socialization; you want your team members to like and trust one another as much as possible. If the project is too large to truly bring everyone together, then make sure you bring key personnel from each team together. Note that in the relatively short period—less than six months—that I worked on the worldwide Iridium project, I attended two such meetings: one in Phoenix for representatives of all North American teams and one in Hong Kong for representatives of the entire global effort.
Feeling stuck in self-doubt?
Stop trying to fix yourself and start embracing who you are. Join the free 7-day self-discovery challenge and learn how to transform negative emotions into personal growth.
