‘Software quality issues due to variable level of skills between locations’ was one of the most interesting findings which came out of an survey, which was performed by The Reg reader poll in September 2008. The survey was conducted with 369 respondents, of whom, 80% had direct experience with distributed software development. The geographic split being 44% UK, 36% USA and 20% elsewhere.
Though, communication and collaboration was still the dominant challenge in distributed development with more than 85% respondents mentioning it, the surprise second, as per the survey, was software quality issues arising from too much variation in skill sets between sites. Another closely related concern was the difference in quality of practices and processes. These challenges remained true irrespective of the type of organization and management approaches followed. Three main approaches, used by the respondents, in distributed development were
- Hub and Spoke – Core development function surrounded by geographically distributed teams
- Peer to Peer – All activities divided between teams of equal status
- Ad-Hoc – No consistent policy and a mix of various approaches
The survey revealed that the challenges of distributed development are amplified when an Ad-Hoc approach is followed, however, the order of challenges was similar across the approaches. The top 5 challenges reported across approaches were
- General communication and collaboration challenges
- Software quality issues due to variable level of skills between locations
- Political issues with the way organization is structured
- Quality concerns due to difference in processes/practices
- Project management issues caused by complexities of distributed development
The primary motivation behind distributed development came out to be resource flexibility and strategic value as compared to cost. This might lead to an observation that just focusing on cost does not help because cheap remote resources might translate to inadequate experience and skill.
Another interesting observation was the result of the activities, which can be distributed. Respondents, who followed Hub and spoke approach, preferred distributing coding and testing activities more than some critical activities like specification definition and analysis and design. Those following peer to peer approach were relatively less reluctant to distribute these critical activities.
In a similar analysis, Scott Ambler summarized the results from the Dr. Dobb's 2008 Agile Adoption Survey, which showed that the success rate of the project is inversely proportional to the geographic distance. Following were the success rates for Agile teams,
- Collocated – 83%
- Near located – 72%
- Far located – 60%
According to Scott, the key enablers of distributed development, which help both communication and skill development are
- Getting the whole team together at the start of the project
- Some initial upfront modeling to build comparable skills
- High-level planning to identify their major dependencies and milestone dates
- Organization of team structure around the architecture, so as to reduce the communication required between various sub-teams
- Better tooling than collocated teams because index cards, cork-boards, and white-boards don't work well from a distance.
- Have ambassadors and boundary spanners.
There are other success stories like Offshore Development by Martin Fowler and Reaching Hyper-Productivity with Outsourced Development Teams by Jeff Sutherland which talk about good practices for successful distributed development.
Though, distributed development has its own set of challenges but it is a reality in today’s world. The key lies in effective tooling and better collaboration practices which would help in facilitating communication and building skills across geographies.