Lessons learned by participants of distributed software development

& Research Article

Lessons Learned by Participants ofDistributed Software Development

Seija Komi-Sirvio* and Maarit Tihinen

Technical Research Centre of Finland, VTT Electronics, Oulu, Finland

The maturation of the technical infrastructure has enabled the emergence and growth of dis-tributed software development. This has created tempting opportunities for companies to dis-tribute their software development, for example, to economically favourable countries so as togain needed expertise or to get closer to customers. Nonetheless, such distribution potentiallycreates problems that need to be understood and addressed in order to make possible the gainsoffered. To clarify and understand the most difficult problems and their nature, a survey ofindividuals engaged in distributed software development was conducted. The purpose ofthis survey was to gather and share lessons learned in order to better understand the natureof the software development process when operating in a distributed software developmentenvironment and the problems that may be associated with such distributed processes.Through a clear appreciation of the risks associated with distributed development it becomespossible to develop approaches for the mitigation of these risks. This paper presents the resultsof the survey, focusing on the most serious problems raised by the respondents. Some practicalguidelines that have been developed by industry to overcome these problems are also brieflysummarized. Copyright # 2005 John Wiley & Sons, Ltd.

INTRODUCTION

Distributed software development enables soft-ware production to take place independently ofthe geographical location of the individuals/orga-nizations concerned. Software subcontracting, part-nership-based development and global businessventures are all different business strategiesexploiting the advantages that such distributed isexpected to bring. Unfortunately, distributed soft-ware development projects have inherited thesame problems that single-site software projectshave been struggling with. Thus, distributed pro-jects suffer equally from quality, schedule andcost related problems—the distribution only makesthese harder to handle. In addition, distributionitself may create time slippage problems. A recent

study shows that the physical distance betweendevelopment sites alone is likely to create delaysin work (Herbsleb et al., 2001). Problems in taskcoordination, project management and communi-cation have also been reported (Hersleb andMoitra, 2001). Over and above this, distribution hasalso introduced new specific problems (De Souzaet al., 2002).

Despite the challenges entailed in distribution,distributed software development is a develop-ment strategy that is in increasing favour with theindustry (Herbsleb et al., 2001; Battin et al., 2001;Ebert and De Neve, 2001). The expected benefits,such as the possibility for high-speed developmentthrough the use of individuals/teams in differenttime zones (Hersleb and Moitra, 2001; Gorton andMotwani, 1996; Mockus and Herbsleb, 2001), theemployment of more skilful staff, the lower devel-opment costs (Hersleb and Moitra, 2001; Press,1993) and the ability to respond to local customers’needs, are expected to outweigh the risks involved.

Knowledge and Process Management Volume 12 Number 2 pp 108–122 (2005)

Published online in Wiley InterScience (www.interscience.wiley.com). DOI: 10.1002/kpm.225

Copyright # 2005 John Wiley & Sons, Ltd.

*Correspondence to: Seija Komi-Sirvio, Technical Research Cen-tre of Finland, VTT Electronics, P.O. Box 1100, FIN-90571 Oulu,Finland. Email: [email protected]

In prior research a number of unique topics havebeen studied by researchers that relate to distribu-ted software engineering, for example, require-ments engineering (Lloyd et al., 2002), projectmanagement (Lam and Maheshwari, 2001; Gaetaand Pierluigi, 2002; Aversano et al., 2003) and con-figuration management (Van der Hoeak et al.,1996). However, the viewpoints of these studiesare biased towards the use of software develop-ment tools. For example, solutions are offeredby different researchers in the form of a softwareconfiguration management tool (Surjaputra andMaheswari, 1999), a process support system(Gianpalo and Ghezzi, 1999) or a virtual corpora-tion negotiation approach (Kotting and Maurer,1999). More recently, some interesting industrialexperiences of distributed software developmenthave been published (e.g. Herbsleb et al., 2001; Bat-tin et al., 2001; Ebert and De Neve, 2001; Karlssonet al., 2000). In all, however, a thorough under-standing of the complex of problems connectedwith distributed software development has notbeen developed.

The aim of this research is to gain a better under-standing of the problems faced when softwaredevelopment projects are distributed over multiplesites in different geographical locations. The pur-pose of the survey was to enable ranking ofproblem areas according to their frequency ofoccurrence and to gather practical knowledge andexamples of the problems experienced along withthe potential solutions that have been developedand tested by developers. Being more aware of pos-sible pitfalls and potential risks, those involvedwith the development of distributed software pro-jects should therefore be in a better position to suc-cessfully plan and execute these projects.

As we have noted above, there may be severalreasons for organizations to distribute their soft-ware development. One of the potential reasons isthe possibility of using the fact that individuals/groups reside in different time zones to enablerapid development, for example distributing devel-opment and test sites across different time zones,and then synchronizing them to a continuous24-hour product development and testing cycle(Gorton and Motwani, 1996). However, thishypothesis was not verified by the results of thissurvey as there were no indications that this waseither attempted or even desired. Primarily, themotivation for distribution was ‘peopleware’ related:the needed knowledge was distributed, there wasno local expertise to solve a development problem,or the local demand for software development wasinsufficient. The survey also sought to identify fac-tors that would support project distribution. It

turned out that the duration and total effort asso-ciated with the project were not as significant asthe size of the project measured in terms of thenumber of people involved.

This paper is organized as follows. In the nextsection the background information of the surveyis presented. In the third section the results of thesurvey are introduced and the improvementapproaches raised are analysed. In addition, basedon those results and issues, observations of distrib-uted software development process will be dis-cussed. The final section presents the conclusionsof the survey.

SURVEY BACKGROUND

Knowledge acquisition was carried out in the formof a questionnaire. The semi-structured question-naire, containing a large set of open and closedquestions relating to distributed software develop-ment, was sent by mail and e-mail to the recipients(it was also accessible via the Internet). The ques-tionnaire covered the following topic areas:

� characterization of the organization;� characterization of the distributed projects;� utilization rate of various communication tools;� problems and the solutions developed to over-

come them;� advantages of distribution; and� overall satisfaction.

The survey was conducted during the summer of2002. The questionnaire was posted to 44 organiza-tions in Finland and it was also e-mailed to over200 organizations around the world. The total num-ber of responses was 31, representing 21 differentorganizations. The regular mail proved to be thebest way of reaching the respondents: out ofretrieved 31 replies 24 were received by post. Con-versely, e-mail turned out to be a very inefficientway to reach respondents; only seven replies wereretrieved using e-mail. The replies came mainlyfrom Finland, but some also from the Netherlandsand the USA. Four replies were eliminated fromthe analysis due to the fact that they were receivedfrom organizations not carrying out distributedsoftware development. It turned out that theseorganizations were distributed globally. Thus, inthe final analysis there were 27 responses includedin the survey.

In this paper, we concentrate on analyzing pro-blems relating to distributed software develop-ment. Most of the responses to the survey camefrom the telecommunication or wireless telecom-munication industries (see Figure 1).

Knowledge and Process Management RESEARCH ARTICLE

Lessons Learned in Distributed Software Development 109

Within the survey sample software developmentdistribution was very extensive and also global. Inonly four cases (14.8%) did respondents reportinvolvement in software development distributionwithin one country. Ten responses (37.0%) referredto software projects which were distributed withinone continent, and 13 responses (48.1%) reportedthat software development projects had beenundertaken which were distributed over two orseveral continents. Figure 2 illustrates the positionsof those who responded to the survey. Analysingthese positions we can conclude that to a largeextent they are characterized by extensive experi-ence in software development.

Table 1 separates the responses by viewpoint(organizational or project viewpoint) and further-more by the extent to which distribution wasimplemented. The survey was carried out withinthe Finnish research programme; thus theresponses are mainly from Finland. The number

of software development projects involving team-work between continents—namely Europe andthe USA and Europe and Asia (13 responses,48.1%)—was essentially equal to the number ofprojects involving cooperation within Europe (14responses, 51.9%).

Figure 3 shows a geographical distribution ofsoftware development represented by the surveyrespondents. The arrows in Figure 3 illustrate thedirection (to a country or a continent) in which arespondent reported that their software develop-ment had been distributed. If the respondent hadnamed a city, a bullet is used as an identifier ofthat place. Each line starts from a city correspond-ing to the home address of the respondent. Further-more, some lines have been drawn in bold,indicating various responses reporting distributionto the same city, country or continent. Two anon-ymous responses have not been included in the fig-ure since their home office is not known. One

Figure 1 Business scope of organizations

Figure 2 Positions of respondents

RESEARCH ARTICLE Knowledge and Process Management

110 S. Komi-Sirvio and M. Tihinen

anonymous answer reported that their softwaredevelopment had been distributed between twocontinents, and another reported developmentbeing distributed between three continents.

SURVEY RESULTS

In this section the results of the survey are pre-sented. First, the characteristics of the organizationsand projects of those taking part in the survey areoutlined. Second, the problems introduced by thedistribution of software development are discussedalong with the solutions to overcome these pro-blems as described by respondents. Lastly, basedon analysis of the preceding data, potential successfactors are identified.

Characteristics of the organizationsand the projects

Our survey results indicate that software develop-ment distribution is carried out not only by large

organizations but also by small and medium-sizedenterprises: 47% of the respondents were employedby companies having fewer than 500 employees intotal. Figure 4 depicts the distribution of responsesby organization size (measured in terms of the totalnumber of employees).

Most companies taking part in the survey wereoperating in the area of embedded software. Com-monly, the distributed development concerned aproprietary product of a company, but there were

Table 1 Characteristics of responses

Response viewpoint Extent of software development distribution

Within Within one Between two Between three orone country continent continents more continents

Organization 2 5 5 3Project 2 5 3 2

Total number of answers 4 10 8 5

Figure 3 Geographical distribution of projects

# of employeesin an organization:

12 %

53 %

0 %

20 %

40 %

60 %

80 %

100 %

% of responses

> 500

50 - 500

< 50

35 %

Figure 4 Distribution of responses by organization size



also some responses that reported on companiesdeveloping software components for clients. Thebusiness governance strategies adopted in distribu-tion may take various forms, such as partnering,subcontracting or the use of sister sites. The extentof distribution, denoted by the distance betweencooperating development offices, vary from thosedistributed over a single town to those distributedbetween several continents. However, it is appro-priate to observe that the results presented in thispaper primarily concern issues typical of organiza-tions distributing their software developmentactivities both extensively and globally. Over halfof the responses (52%) had distributed develop-ment activities to different continents, and morethan two-thirds of them (74%) to different coun-tries. While subcontractors were used extensively,the extent of distribution in this case was slightlysmaller: less than one-third (30%) had subcontrac-tors in different continents and 41% had them indifferent countries. In all, a total of 85% of therespondents had used subcontracting as anapproach to software development.

The characteristics of the distributed projectswere determined in terms of duration, project sizein person years and the size of the developmentteam. It turned out that the duration of a distribu-ted project was rarely longer than 2 years; 78% ofthe projects were shorter than that and, of these,one-third were of less than 1 year. Furthermore,the size of the project measured in person yearsturned out to be either rather large—almost halfof the projects were over 20 person years insize—or rather small, half of the projects beingunder 10 person years in size. Only 11% of the pro-jects studied fell in the category between 10 and 20

years. The size of the development team showedthe least variation: in most cases (56%) the teamwas smaller than 20 software developers. Theresults suggest that globally distributed projectstend to be rather large measured in terms of personyears, while the development team was often keptquite small.

A closer look at the number of software develo-pers in the organizations represented by therespondents reveals that the majority of answers(67%) were provided by respondents from compa-nies having more than 100 software developers,and one-third (33%) of the responses were receivedfrom individuals employed by organizations withunder 100 software developers. These two groupsof organization were studied to detect possible dif-ferences in their characteristics, and a noteworthydifference was identified concerning the size of dis-tributed projects in person years (see Figure 5).

Figure 5 shows that when the number of soft-ware developers in an organization is under 100the size of distributed projects is most often (67%)smaller than 10 person years.

Problems in distributed software development

In the survey, respondents were given the choice ofidentifying eight different problem areas. Theseproblem areas were identified on the basis of thedescriptions found in the literature (Herbsleb et al.,2001; Mockus and Herbsleb, 2001; Karlsson et al.,2000; Niederman et al., 1993; Zoran et al., 1995).Respondents were asked to check all the problemsthey had experienced in their projects and todescribe each of the problems identified in moredetail. Respondents were also provided with an

Figure 5 Size of distributed projects and number of software developers



opportunity to identify problems that were notlisted. This ‘other’ category was used by only tworespondents, which gives some confidence thatthe proposed classification of problems adequatelycovered the key issues associated with the projectsidentified by the respondents. In addition to pro-blem descriptions, respondents were also asked todescribe the solutions they had developed to over-come the problems encountered and to evaluate thesuccess of these solutions. The overall distributionof answers among problem areas is presented inFigure 6.

Development tools and environment

While the existing technical infrastructure seems toprovide adequate support for distributed softwaredevelopment, respondents indicated that the devel-opment environment is not yet mature. Projects aremost often undermined by poor software develop-ment environments and tools. Thus, tool-relatedissues were most commonly experienced as a pro-blem area, with a selection rate of 81%. The pro-blems identified were diverse, though two mainproblem streams could be clearly extracted, namelythose concerning network connections and thecompatibility of the tools used.

In the case of issues relating to network connec-tions the specific issues that were identified relatedto the reliability and usability of the network beingunsatisfactory. For example, the network connec-tion was deemed to be too slow, with its reliabilityfurther impaired by occasional server failures. Con-nections that were too slow were considered to benot only a source of frustration due to increased

waiting time, but were also reported to causeusability problems with development tools. Onerespondent described the problem as follows:‘development tools are based on the assumptionthat the network is extremely fast’.

The solutions that were adopted to address net-work problems were varied; one solution was toincrease the bandwidth between the sites, which,however, failed to have the desired effect on speed.In this case the problem may not have been theavailable bandwidth but rather latency in responsetimes. In several projects the slowness and unrelia-bility of the network were successfully reducedto an acceptable minimum level by changingthe development strategy from a synchronousapproach to an asynchronous one. That is, insteadof having one central database for the project, eachdevelopment site had its own local database, andreplication and reconciliation were done once aday. This time-synchronized resolution may be agood solution if real-time development is not obli-gatory. Whether a time-synchronized solution isfavoured or not, the distributed developmentenvironment emphasizes the need for having prop-er configuration management tools and processesin place.

Establishing a uniform software developmentenvironment is a challenging task. Not only werea diverse set of tools reported to cause problemsbut also the different versions of a single toolpotentially caused problems as well. As it turnedout respondents are relatively well aware of the cri-ticality of establishing a compatible environment;the problem is how such an environment can beestablished successfully. Respondents indicated

Figure 6 Problem areas



that their readiness to change development toolswas quite low; development sites were reportedto be reluctant to change the development toolsthey were already familiar with. In one companyit was considered a highly sensitive question whichsite had the dominant role in defining which toolswere to be used. Forcing the sites to use identicaltools appeared to make the problem even worse.The respondents did not have any easy or assuredsolutions to offer to solve this issue. Some respon-dents described how they had had to visit the sitesthemselves to be able to clarify what tools wereused, what they were capable of and how the inter-operability with the various tools and their differ-ent versions could be achieved without changingthe existing tool configuration.

The respondents also thought about the reasonsfor the problems concerning development toolsand the development environment. The obvioustechnology-based problem appeared to be aggra-vated by distance and various human factors. Cul-tural differences between countries andorganizations were pointed out as a potential pro-blem factor, along with the lack of communicationand missing face-to-face-meetings; these are likelyto cause information and knowledge deficiencies,further provoked by the different time zones. Con-figuration and document management tools, testenvironment, and replication and synchronizationof artifacts are critical for distributed softwaredevelopment and therefore need to be carefullystudied and planned case by case. Obviously, themost effective stage to address these tool-relatedissues is when the distributed software develop-ment project is set up.

In summary, the solutions disclosed by responde-nts to overcome slow and unreliable network were:

� changing the development strategy from syn-chronous to asynchronous and replicating oncea day; and

� increasing the bandwidth between the sites toimprove speed.

In addition to the solutions above, the respon-dents gave the following practical advice for con-trolling the tool environment:

� define and document acceptable tools and ver-sions for the whole project life cycle;

� define configuration and version managementtools and practices;

� get official, explicit approval for the plan from allparties involved; and

� arrange for the main developer site to take thelead and responsibility for the tool environmentand for organizing identical tools for all sites.

Communication and contacts

The area ‘communication and contacts’ wasselected as a source of problems for distributedprojects by the majority (74%) of the respondents.The result itself was not a great surprise but thereasons stated by respondents for this selectionwere interesting. There were two factors repeatedlymentioned as causing problems with respect tocommunications and contacts: cultural differences(including language skills) and physical distance.

Cultural differences may give rise to misunder-standings and exacerbate problems in oralcommunication. The respondents described thatsometimes the level of language skills alone wasoften so low that fluent conversation becameimpossible, most particularly telephone confer-ences. The problems that cultural differences arelikely to generate are introduced in more detaillater in this article.

The survey clarified how the frequency of face-to-face meetings changed with increasing distance.It turned out that when the development was doneat a single site, but in different buildings, 88% ofthe projects involved having face-to-face meetingsone to three times per week or even every day.When there were several sites involved either in asingle city or in different cities, the frequency of theface-to-face meetings dropped, with only 4% hav-ing weekly meetings. When the sites were situatedin different countries, the most active projects interms of communication still had face-to-face meet-ings, one to three times per a month (48%), but therest of the projects had then only one to three timesper year (see Figure 7). This result supports therespondents’ view that physical distance causesmiscommunication and that face-to-face meetingsreally are the best means of communication.

Time zones play a role in globally distributedprojects. Especially when development is distribu-ted over continents with extensive time differences,this structure creates challenges and causes practi-cal problems for projects. The survey results verifythat increase in physical distance increases pro-blems as well (Herbsleb et al., 2001; Battin et al.,2001). The time difference being the effective work-ing days in different time zones reduces both thewillingness—and opportunities—to have meet-ings. The reduction in the number of project meet-ings, along with language barriers and culturaldifferences (county or company related), causes anumber of problematic situations. Lack of knowl-edge and misunderstandings are reported byrespondents to have led to redundant work or nowork at all due to mistaken assumptions concerningwho is in charge of different stages in the project



being developed. Respondents also mentioned thatdistance is likely to makes it easier to hide possibleproblems and to withdraw from decision making.

Respondents use various strategies intended tosubstitute for the missing face-to-face communica-tion. The most common solutions applied are tele-or videoconferences and e-mail. However, evenvideoconference is regarded as problematic dueto the connection difficulties that are often experi-enced. Despite this, communication problemswere not very often linked to the tools used; only30% of respondents regarded communication toolsas a problem (see Figure 6). It may thus be specu-lated that if communication tools are experiencedas good enough and communication is still a pro-blem, better communication tools are not likely tosolve the underlying communication problem.

The foundations for effective communication arelaid at the beginning of the project. Informal team-building sessions are identified by respondents asone of the main means of building trust and feel-ings of togetherness. Becoming thus acquaintedwith each other, face-to-face substitutes, such ase-mail, NetMeeting and tele- and videoconferences,become ways of improving communication. Somerespondents suggest that project members shouldknow each other so well that the barrier to contactbecomes non-existent.

Another common and recommended means ofminimizing communication-related problems is todecrease communication needs and contact pointsto a minimum by splitting the project into smaller,independent units managed by a local manager. Ifno local project manager can be appointed, at leasta contact person should be named for answeringquestions and acting as a contact point.

In summary, the following strategies are consid-ered successful in improving communication inpractice:

� informal team-building sessions and face-to-facemeetings, especially at the beginning of the pro-ject;

� decreasing the need for contacting other teammembers by splitting projects into smaller, inde-pendent and more manageable units; and

� appointing a contact person from each site.

Design knowledge

Design knowledge was the third most frequentlyselected problem area by all respondents (67%).The problem descriptions relating to this issue cov-ered the following design mediating-related issues:‘Interpretation of specification, understanding of designrationale’ and ‘Difficult to transfer knowledge’. Forexample, if architecture design is done at a site dif-ferent from where the implementation takes place,efforts must be made to ensure that the designrationales are understood and communicatedacross the sites, so as to verify that they are under-stood correctly. Only a few respondents report pro-blems originating from partner site incompetenceor insufficient ability to carry out their develop-ment tasks. The problem descriptions indicatemainly problems relating to knowledge transferand communication. They also noted that knowl-edge is typically distributed asymmetrically.

Knowledge transfer and sharing was recognizedas a bottleneck especially when the chief architectand software engineers were working at differentsites, as was often the case. Here again, the role of

Figure 7 Frequency of face-to-face meetings



face-to-face meetings was highlighted and regardedas the fastest way to solve a design problem or toobtain an answer to a specific question. Knowledgetransfer solely via design documents was regardedas a slow and laborious process. This observationaddresses the need for having a design documentwith clear and adequate structure, content and levelof detail to answer the requirements of the distrib-uted software development.

The strategies used to overcome designknowledge-related problems do not differ signifi-cantly from the solutions already discussed. Onceagain, face-to-face meetings are regarded as essen-tial to build a common understanding of terminol-ogy, approaches and the application area. Kick-offmeetings at the beginning of the project and techni-cal meetings in the design phase are highly recom-mended. To attenuate the communication needs, itis recommended that the project be split into smal-ler parts and that the responsibility for the parts isdistributed among sites. Moreover, practical guide-lines for using common databases, tools, and ver-sion and configuration management were listed ashelpful. In addition, training material available forall in an electronic format made it easier for engi-neers to acquire and use available knowledge.

As a summary, the following factors are consid-ered to be important for improving a design phase:

� face-to-face kick-off and technical meetings todiscuss design rationale, terminology and appli-cation area issues;

� division of work and responsibility into smallerunits;

� practical guidelines for developing design docu-ments and using development tools; and

� training material provided in electronic form.

Project management

Project management is identified as a source of pro-blems by 59% of respondents, making it the fourthbiggest problem area. Project managementchallenges are harder to solve in a distributed envir-onment than in a centralized development environ-ment. It is noted that in distributed developmentsignificantly more effort is required for up-frontplanning and follow-up activities in order to beable to manage a project successfully. Furthermore,if this need is not recognized at the beginning of theproject, uncertainty, misunderstandings and man-agement problems are most likely to appear later.The manager of a globally distributed project hasto have varied abilities and knowledge, such as cul-tural knowledge and communication skills in addi-tion to technical competence and particularly good

project management capabilities. One respondentgave the following example: ‘In centralized projectmanagement, a project manager may be far awayfrom development groups, which creates a visibilityproblem, and makes it easier to hide possible pro-blems.’ In other words distribution, for example,makes time slippage more difficult to estimateand control due to the decreased visibility. Timeslippage and budget growth are listed as a problemarea in 52% of all responses, which is, naturally, anissue relating to project management in general.Generally speaking the budget can be adjusted totake into account the higher costs involved due todistribution, for example additional planning activ-ities, communication, and lead to extra travellingand meeting costs. However, if the project managerdoes not know the software engineers involved inthe development at the other site(s), it becomes dif-ficult for him or her to assess whether given esti-mates are realistic or not. In addition to unrealisticestimates, the project manager may suffer from pro-blem hiding, which is more likely to take place in adistributed environment for a longer period of timethan in single-site development. Eventually, thismay cause serious problems in keeping to the sche-dule and achieving project development goals. Onerespondent captures his experience in the followingdown-to-earth heuristic: ‘The farther the subcon-tractor the bigger the delays in the schedule.’

Several other problems are mentioned as well,such as failure to inform other sites of decisionsor changes that have been made. Difficulties in get-ting the information as requested were alsobrought up, e.g. delays in getting status reports.Again, the issues refer mainly to knowledge man-agement and communication-related problems.

Respondents have good experience of solid pro-ject management practices with strict control assolutions to the types of project management pro-blems discussed above. Breaking down projecttasks into weekly delivery results is reported tobe an efficient way to track the progress of develop-ment projects. Another proven strategy is to plandevelopment blocks so that they can be indepen-dently developed by different sites. If this solutionis adopted, a local project manager can take oversome planning and follow-up activities from themain project manager. In addition, clearly estab-lished rules, definitions of responsibilities, resultsand timetables along with regular meetings andthe management and control of process arereported to be highly important in a distributedsoftware development environment.

In summary, the following actions have helpedin the management of distributed software devel-opment:



� detailed up-front planning and strict controlactivities; and

� splitting the project into sub-projects with localproject managers.

Cultural differences

Cultural differences are mentioned as a proble-matic issue in 52% of all responses. Table 2 depictshow cultural and also communication problemsgrow while software project distribution extendsover one or several continents.

Different and divergent values and perceptionsmay cause misunderstandings and even dissatis-faction within the project. Depending on the cultur-al differences, be they related to company cultureor the culture of a country, the same action canhave different interpretations. Cultural differencescreate possibilities for misinterpretation, especiallywhen these cultural differences are not appre-ciated, let alone understood. One respondent gavean example of different viewpoints to problemreporting: at one site it was a regular action origi-nating from a basic development procedure; atanother site such reporting was understood as aninsult. It is also important to pay attention to howthings are expressed; when communicating in aforeign language, it is easy to send unintentionalmessages. In addition, terms and concepts mayvary between different countries and even withinone country. Commitment to decisions and timeta-ble is also claimed to vary between countries andcontinents.

To alleviate cultural differences, and to reconcileconceptions, approaches and terminology in use, itis recommended that actions be taken to enhancecommunication inside the project. Face-to-facecommunication appears to be an effective meansof lowering thresholds caused by cultural differ-ences. Training and common sense are also consid-ered to have an important role in tackling the

cultural differences in distributed projects. Asnoted above, kick-off meetings at the beginning ofthe project and technical meetings during thedesign phase are highly recommended.

To summarize, the following factors are reportedto be important for improving the culture-relatedproblems associated with distributed developmentprojects:

� enhanced communication throughout the projectin order to build understanding between thesites;

� defining and using predefined terminology; and� improving language skills and developing and

sharing knowledge concerning cultural issuesand customs.

Requirements engineering: the mainsoftware error source

Requirements engineering-related issues werestressed when respondents were asked to deter-mine the main sources of software error. The pre-defined alternatives included various errorsources ranging from design, coding, interfaces,environment problems and security vulnerabilitiesto requirements engineering issues. We anticipatedrequirements engineering to be one of the principalproblems (Damian, 2002) and therefore we dividedit into three categories. There was also one openchoice (Other, describe) in the questionnaire, whichwas, however, not selected by anyone. The mostsignificant problem source was marked ‘1’ andthe least significant ‘8’.

Figure 8 illustrates how requirements engineer-ing is ranked for software errors. ‘Misinterpretationof requirements’ was ranked to be the most signifi-cant error source, with 74% of answers ranking it as1, 2 or 3. Problems also arise from insufficient com-munication, poor quality of requirement docu-ments and the requirements engineering process

Table 2 Extent of software development distribution and reported problems

Selected problem areas Extent of software development distribution

Within one Within one continent Between Between three orcountrya (10 replies two continents more continents

(4 replies in total) in total) (8 replies in total) (5 replies in total)

Communication—contacts 3 7 5 4Communication—tool 1 2 4 1Cultural differences 1 3 7 4

aAlthough four replied that their project distribution was carried out within one country, two of them had subcontractors in a differentcountry or countries.



itself. Detailed documentation can reduce misun-derstanding, but it is also considered a slow andcumbersome way of transferring information.‘Changing requirements’ was ranked as the secondmost significant error source by 70% of the respon-dents. While changes in requirements are likely tolead to errors in software development in general,in distributed software development these changesare even more difficult to manage and communi-cate due to, for example, the number of stake-holders and the distance involved. Problemsoriginating from ‘missing requirements’, whichwas ranked third (59%), can be successfully pre-vented by careful planning and execution of therequirements engineering process.

The importance of organization size

When further analysing the survey results, differ-ences were detected between large organizations(over 500 employees) and small and medium-sizeorganizations (under 500 employees). Due to therelatively limited number of answers from smallorganizations, it was decided to analyse themtogether with medium-size organizations.

When analysing the answers originating fromlarge organizations, tools and environment-relatedissues turned out to be even more emphasized,by 94% of all answers, as the most damaging fac-tors likely to undermine the success of distributedsoftware development projects. Communication-related problems were still in second position

with 76% of the responses. Issues related to culturaldifferences were considered equally important asproject management issues, making up 65% of theresponses. The reasons for these problems were thesame as explained earlier in this paper.

The views of small and medium-size organizationswere slightly different, resulting in a change inthe ranking of the most damaging factors. Thearea of design knowledge was assessed as causingthe most trouble by 80% of the respondents. Inter-estingly enough, in smaller organizations, pro-blems related to cultural differences werementioned by only 30% of the respondents. Thereason for this may be explained by the character-istics of the related distributed projects: the extentof distribution was not as great as that of largeorganizations. When operating in Europe, culturaldifferences were not recognized as a major factor,as one respondent referred to this issue as follows:‘Cultural differences are directly proportional togeographical distance of sites. Inside Europe theseissues are much easier than between different con-tinents.’

Issues contributing to satisfaction

The survey included a question focusing on theoverall satisfaction with the distributed softwaredevelopment that had taken place at the respond-ents’ own company. The following scale was usedto make assessment: completely satisfied, some-what satisfied, somewhat dissatisfied, dissatisfied

Figure 8 Major sources of software errors



and not applicable. The results yielded by thisquestion were very interesting: none of the respon-dents were completely satisfied, while only 7%were dissatisfied. The majority of respondents(63%) were somewhat satisfied, most of themrepresenting large organizations with over 500employees. The overall satisfaction rate of respon-dents from small and medium-size organizationswas slightly lower and evenly scattered from some-what satisfied to dissatisfied. However, the resultsshow that despite the risks and the problems dis-cussed above, the respondents still perceive distri-bution to be appropriate and, as such, an importantand fruitful development strategy.

The overall satisfaction and the issues behindsatisfaction or dissatisfaction deserve a moredetailed investigation. To clarify possible reasonsfor this result, the group who expressed themselvesto be somewhat satisfied was selected for furtheranalysis. First, the selected answers were comparedwith the related project duration (by calendaryears) and size by person months. However, noclear relationship could be distinguished, althougha clear relationship between satisfaction and size ofproject by the number of persons involved wasdetected. Figure 9 depicts this relationship. Themost satisfied (59%) respondents were involvedwith projects that employed fewer than 20 persons,while the satisfaction diminishes to 12% as thenumber of developers rises to over 50. Figure 9also shows a similar outcome for the categoriessomewhat dissatisfied and dissatisfied (both classesgrouped into the ‘Dissatisfied’ class in Figure 9:

57% of dissatisfied responses originate from pro-jects involving over 50 persons.

The analysis suggests that the number of personsinvolved in the project is a significant determinantfor the success of distributed software develop-ment. Another implication is that since communi-cation-related issues are an important factordetermining overall satisfaction then, if the numberof persons involved in the project is under 20, thisis likely to provide better teamwork-based thinkingand practices during the course of the distributedsoftware project. This outcome is worth consider-ing when planning distributed project develop-ment, e.g. when making decisions about splittingand conducting project tasks into independentand rational parts at each distributed site.

Limitations of the results

The moderate sample size of 27 allows only limitedanalysis and study of interdependencies betweenvariables. The possibilities for a more fine-grainedanalysis are inevitably to some degree limited.The best response rate was achieved when usingregular mail (the questionnaire was also sent outusing e-mail). The questionnaire was sent to compa-nies that were either known or assumed to have dis-tributed their software development. The mailedquestionnaire was received by 101 recipients in 44companies and of these recipients 24 completedthe survey. In total 31 replies were retrieved, ofwhich four were withdrawn from the sample sizedue to the fact that these respondents were not

Figure 9 Overall satisfaction versus size of a project



involved with distributed software developmentand had no experience of it. Despite the fact thatthe size of the sample is rather small the samplingitself is relevant in the context of this study.

While observing the software development dis-tribution (refer to Table 1 and Figure 3), it is notablethat replies were almost equally divided betweenthose that addressed concerns relating to the devel-opment of software in a distributed European set-ting (51.9% of responses) and those that involveddistribution between different continents (Europeand the USA and Europe and Asia), the latter con-tributing 48.1% of responses. However, it has to beacknowledged that replies represent Finnishexperience of software distribution to a largeextent. This being the case it is reasonable to pon-der to what extent the results are generalizable.Recently, Prikladnicki et al. (2003) analysed 22interviews from one Brazilian and one US-basedcompany which had engaged in distributed soft-ware development both locally and globally. Intheir study the conclusions of the relevant proble-matic issues are consistent with the problem state-ments of this survey. They name language barriers,communication, cultural differences, context shar-ing, trust acquisition between teams, requirementsengineering, software development process, soft-ware configuration, and knowledge managementin general, as problem areas in which projects aresuffering.

CONCLUSIONS

The challenges of distributed software develop-ment must be recognized when aiming at diminish-ing the risk of development failure and maximizingthe possibilities for success. The results of this sur-vey put forward and clarify the target areas forimprovement regarding distributed softwaredevelopment processes and suggest appropriatework practices that have been tested in industrialenvironment.

Software development is very knowledge-inten-sive field of engineering. In each developmentphase efficient knowledge creation, knowledgetransfer, knowledge storing and/or and knowl-edge-sharing activities are vital. The results of thissurvey point out that previously complex softwaredevelopment processes are further complicated bythe distribution of the development process overmultiple sites. Diverse software development andmanagement knowledge needs and knowledge-capturing and transfer-related problems were iden-tified as being important. In the survey, misunder-standings, ignorance and uncertainty are examples

of common words respondents use to describe ori-gins for problems related to requirements engineer-ing, development tools and environment, designknowledge or project management.

Survey results show that the most problematicarea is related to software development tools andenvironment, and more specifically the incompat-ibility of tools and versions used by the differentdevelopment sites. This problem is most empha-sized by large organizations employing more than500 persons. Communication problems appear tobe extremely common within all organizations; inall, this problem area was ranked as the secondtoughest. However, a closer analysis of theresponses shows that the role of communicationis even greater than it appears at first sight. Whenstudying the reasons behind other problems, thelack or poor quality of communication was oftenmentioned as a root cause. When requesting thethree areas where respondents would need supportin distributed software development one respon-dent condensed his answer to the following:‘communication, communication, communication’.When the efficient knowledge-capturing and shar-ing mechanism (in the form of a face-to-face meet-ing and personal contacts) is hampered by distanceand time differences supportive and substitutesolutions are self-evidently vital. Results of theplanning phase of a distributed development pro-ject are decisive what comes to transferring knowl-edge between sites. Because knowledge transfer isproblematic attempts should be made to minimizeit. When the project is divided into independentlydeveloped and managed units whose interfaces areclearly defined the needs, for example, for transfer-ring design knowledge during developmentshould decrease.

When knowledge transfer has to take place,appointing a contact person at each site is a meansof controlling communication both between sitesand within site(s). Numerous communicationpoints at each site raise the risk that knowledgetransfer becomes chaotic and uneven.

Requirements engineering and managementappeared highly problematic for distributeddevelopment projects, causing many errors.Requirements engineering is a large and multidis-ciplinary process and traditionally is performed atthe beginning of the system development life cycle(Royce, 1970). However, in the development oflarge complex systems it has been realized that itis impossible to define an accurate set of require-ments that are likely to remain stable throughoutthe months or years of development (Dorfman,1990). Requirements engineering thus becomes anincremental and iterative process, performed in



parallel with other system development activities,such as designing and implementing, which iswhy misinterpreted, changing and missing require-ments are likely to be the main sources for softwareerrors according to the industry feedback.

Based on the analysis described in this article,there is no doubt about the message of the study:successful distributed software developmentrequires both structured—and disciplined—soft-ware engineering and knowledge managementsolutions embodying, most particularly, communi-cation management and the utilization of effectivesubstitutes for face-to-face communication. A care-ful execution of project start-up activities—includ-ing planning (splitting tasks, schedule, delivers),exact determination of common rules, responsibil-ities, tools used and kick-off sessions—can greatlycontribute to a successful implementation. Byunderstanding the nature and demands of distrib-uted software development in depth, softwareorganizations are able to reduce the risk of failureand to make their operations successful.

ACKNOWLEDGEMENTS

This article is based on a survey conducted as a partof the Knots-Q-program (Knowledge-CenteredTools and Methods for Software Production Qual-ity; see Knots-Q Project, 2004), which is funded bythe Finnish Academy and VTT, the TechnicalResearch Centre of Finland. The authors are grate-ful for the voluntary help provided by the repre-sentatives of the various organizations involvedin this study.

REFERENCES

Aversano L, De Lucia A, Gaeta M, Ritrovato P. 2003.Genesis, 2003: a flexible and distributed environmentfor cooperative software engineering. In Proceedings ofthe Fifteenth International Conference on Software Engi-neering and Knowledge Engineering (SEKE), 497–502.

Battin RD, Crocker R, Kreidler J, Subramanian K. 2001.Leveraging resources in global software development.IEEE Software March/April: 70–77.

Damian D. 2002. The study of requirements engineeringin global software development: as challenging asimportant. In Proceedings of Global Software Develop-ment, Workshop #9, organized in the International Con-ference on Software Engineering (ICSE) 2002, Orlando,FL.

De Souza CRB, Basaveswara SD, Redmiles DF. 2002. Sup-porting global software development with event notifi-cation servers. In Proceedings of Global SoftwareDevelopment, Workshop #9, organized in the Interna-

tional Conference on Software Engineering (ICSE)2002, Orlando, FL.

Dorfman M. 1990. System and software requirementsengineering. In IEEE System and Software RequirementsEngineering, Thayer RH, Dorfman M (eds). Tutorial.IEEE Software Computer Society Press: Los Alamos,CA.

Ebert C, De Neve P. 2001. Surviving global softwaredevelopment. IEEE Software 18(2): 62–69.

Gaeta M, Pierluigi R. 2002. Generalised environment forprocess management in cooperative software engineer-ing. In Proceedings of the 26th Annual International Com-puter Software and Applications Conference (COMPSAC),2002. Oxford, UK; 1049–1053.

Gianpalo C, Ghezzi C. 1999. Design and implementationof PROSYT: a distributed process support system. InIEEE Proceedings of the 8th International Workshops onEnabling Technologies: Infrastructure for CollaborativeEnterprises, Stanford, CA; 32–39.

Gorton I, Motwani S. 1996. Issues in co-operative soft-ware engineering using globally distributed teams.Information and Software Technology 38: 647–655.

Herbsleb J, Moitra D. 2001. Global software develop-ment. IEEE Software 18(2): 16–20.

Herbsleb JD, Mockus A, Finholt TA, Grinter RE. 2001. Anempirical study of global software development: dis-tance and speed. In Proceedings of the 23rd InternationalConference on Software Engineering (ICSE), Toronto;81–90.

Karlsson E-A, Andersson L-G, Leion P. 2000. Daily buildand feature development in large distributed projects.In Proceedings of the International Conference on SoftwareEngineering (ICSE). ACM Press: Limerick, Ireland; 649–658.

Knots-Q Project. 2004. VTT Electronics. http://www.vtt.fi/ele/research/soh/projects/knots-q/index.htm [23 February 2005].

Kotting B, Maurer FA. 1999. Concept for supporting theformation of virtual corporations through negotiation.In IEEE Proceedings of the 8th International Workshops onEnabling Technologies: Infrastructure for CollaborativeEnterprises, Stanford, CA; 40–47.

Lam HE, Maheshwari P. 2001. Task and team manage-ment in the distributed software project managementtool. In Proceedings of the 25th Annual International Com-puter Software and Applications Conference (COMPSAC),Chicago, IL, 401–408.

Lloyd WJ, Rosson MB, Arthur JD. 2002. Effectiveness ofelicitation techniques in distributed requirements engi-neering. In Proceedings of the IEEE Joint InternationalConference on Requirements Engineering (RE’02). 311–318.

Mockus A, Herbsleb J. 2001. Challenges of globalsoftware development. In Proceedings of the 7th IEEEInternational Software Metrics Symposium (METRICS2001), 4–6 April, London. IEEE Computer Society;182–184.

Niederman F, Beise CM, Beranek PM. 1993. Facilitationissues in distributed group support systems. In Pro-ceedings of Conference on Computer Personnel Research.ACM Press: New York; 299–312.

Press L. 1993. Software export from developing nations.IEEE Computer December: 62–67.

Prikladnicki R, Audy JLN, Evaristo R. 2003. Globalsoftware development in practice lessons learned.Journal of Software Process Improvement and Practice8(4): 267–279.



Royce WW. 1970. Managing the development of largesoftware systems. Proceedings of IEEE Wescon. Rep-rinted in Proceedings of the 9th International Conferenceon Software Engineering (1987), Los Alamitos, CA.IEEE Computer Society Press; 328–338.

Surjaputra R, Maheswari P. 1999. A distributed softwareproject management tool. In IEEE Proceedings of the 8thInternational Workshops on Enabling Technologies: Infra-structure for Collaborative Enterprises, USA.

Van der Hoeak A, Heimbigner D, Wolf AL. 1996.Peer- to-peer repository for distributed configurationmanagement. In Proceedings of the 18th InternationalConference on Software Engineering (ICSE ’96), Berlin;308–317.

Zoran M, Berry A, Bond A, Raymond K. 1995. Support-ing business contracts in open distributed systems. InProceedings of SDNE ’95. IEEE Computer Society Press:Whistler, Canada.



Lessons learned by participants of distributed software development

Documents

Transcript of Lessons learned by participants of distributed software development