CM and ALM for Global Software Development

[article]
Summary:
In his CM: The Next Generation Series, Joe Farah writes that there are many reasons that organizations or government agencies use distributed development. Whatever the reason, a software development team, and indeed the entire product team, needs to do all it can to ensure that development proceeds smoothly.

Put a bunch of developers in an office with a mission to produce a specific software product and it’s only a matter of time before the product starts appearing. Now throw in a new requirement that dictates that development will be done by three or four teams distributed across different cities, countries, or time zones, and the results are no longer so predictable. How are the different teams going to work together to get the job done? Isn’t it better just to put everyone together in the same office?

There are many reasons that organizations or government agencies use distributed development. Maybe it’s a NATO project where multiple countries have been politically mandated to develop the software. Perhaps different subcontractors have different areas of expertise that need to come together. Maybe a series of mergers has left a particular software team spread out over several locations.

Whatever the reason, a software development team, and indeed the entire product team, needs to do all it can to ensure that development proceeds smoothly.

In any event, distributed development will require more effort on your part to encourage team members to communicate. Because the nature of distributed development is that teams are spread out, it’s likely that less communication will take place. To handle this problem you need to remove the barriers to communication. This can be done, for example, by supporting on-line code reviews—stored in the CM repository—or through on-line meetings for design reviews, change control boards, problem review boards, etc.

As your team members can no longer walk down the corridor to chat with peers and find out who is doing what, it’s critical that your CM repository and tools provide a clear communication of the project picture – priorities, assignments and status. The repository or tool that you use must collect data better (automatically when possible) and it must present the information more readily and in a pro-active way. This is to ensure that team members, otherwise unwilling to take the effort to get information, don’t proceed with their job with less information than they might use in a non-distributed environment.

For proper global development, there are three CM repository scenarios I'd like to discuss: distributed data, centralized sites, and synchronized multiple sites.

Divide and Conquer – Distributed Data
The general approach to using distributed development is to divide and conquer. In this approach you  spread the functionality along logical boundaries, such as are naturally defined by devices, system layers or subsystems. This reduces inter-site development conflicts. 

Every so often you bring the teams together with all of the software from each of the sites, so that an effort can be made to integrate them together. This has some merit, but also a few drawbacks.

For one thing, you must ensure that infrequent integration does not cause long delays while you work out the integration issues. This strategy flies in the face of continuous integration practices.

The integration will take some time, since it is done infrequently – so there will be more problems to diagnose and solve.  By the time a successful, consistent integration is attained, development will have moved on and integration work will have to be merged back into each site.

Another issue with this approach is that it takes a considerable effort to partition the software among the various sites.  This is not just an initial partitioning problem, but an ongoing problem as the need for new software components arises, and as the teams and expertise bases shift over time. The strategy of “divide and conquer” works best when it’s only the deliverables (i.e. not the

Pages

About the author

Joe Farah's picture Joe Farah

Joe Farah is the President and CEO of Neuma Technology and is a regular contributor to the CM Journal. Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe at farah@neuma.com

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03