Distributed Development (Part 2): 4 to 7By Bruce F. Webster | Posted 2008-07-17 Email Print
Re-Thinking HR: What Every CIO Needs to Know About Tomorrow's Workforce
Bruce F. Webster's advice on how to have the most success in a distributed team environment for IT projects.
4. Provide outstanding and appropriate infrastructure.
If you’re going to distribute your project, make sure the people involved have the hardware and software tools they need—not just for development, but for communications as well. This includes appropriate distributed (and likely Web-based) tools for configuration management and source code control, defect tracking and change management. It also includes tools such as headsets, webcams and desktop sharing software, so that person-to-person conferences can take place with little or no notice and with high bandwidth.
5. Organize the distributed team around the system architecture.
Conway’s Law says that the system design reflects the communication structure of the teams that build it. A distributed development effort is only going to intensify that effect. Henderson noted that at one large military project he was involved with, there was a great deal of effort up front to partition the system into reasonable stand-alone chunks, document the operational concepts and interfaces, and then pass those chunks out to the various distributed groups.
6. Create one-on-one development coordination links.
The natural inclination would be to have as many people talking to one another as possible, but that can actually be counterproductive. Poeltler had the experience of both being the remote developer on one project, and later hiring and managing a remote developer on a completely different project. She noted that in both cases, a critical success factor was that the remote developer had a single point of contact within the overall team. When she was managing a remote developer—located at his home in Hawaii—she worked hard to shape him into her “doppelganger,” so that his independent work would mesh with her overall system architecture. For the last two points together, think “high cohesion, loose coupling.”
7. Focus on software quality assurance.
Too often, SQA is the poor relation of software engineering, an underfunded afterthought and mostly defined just as testing (it’s much, much more than that). SQA is even more critical on distributed projects, because the demands and pitfalls are greater. Henderson noted that there were significant problems with the first integration attempt of the distributed military project mentioned above. The individual modules tested out quite well, but the end-to-end and integrations tests did not. However, the overall lifecycle approach was iterative, so system integration improved each time around.
Some of you are no doubt thinking that most of these suggestions apply to regular, nondistributed development projects as well. For the most part you’re right, although they are quite often neglected there as well. My point is that these suggestions are far more critical with distributed development. That is, your chances of failure are much higher if you neglect them in a distributed project than if you neglect them in a nondistributed one.
© 2008 Bruce F. Webster