Software Teams and Their Knowledge Networks in Large-Scale Software Development

ContentslistsavailableatScienceDirect

Information and Software Technology

journalhomepage:www.elsevier.com/locate/infsof

Software teams and their knowledge networks in large-scale software development

Darja Šmite

, Nils Brede Moe

, Aivars Š ¯ablis

, Claes Wohlin

aBlekinge Institute of Technology, Karlskrona, Sweden

bSINTEF ICT, Trondheim, Norway

a rt i c l e i n f o

Article history:

Received 4 May 2016 Revised 10 January 2017 Accepted 11 January 2017 Available online 19 January 2017 Keywords:

Large-scale software development Knowledge networks

Social capital Intellectual capital Teams

Agile Cross-functional Feature teams Empirical Case study

a b s t r a c t

Context: Large software development projects involve multiple interconnected teams, often spread aroundtheworld,developingcomplexproductsforagrowingnumberofcustomersandusers.Succeed- ingwithlarge-scale softwaredevelopment requiresaccess toan enormousamountofknowledgeand skills.Since neitherindividualsnor teamscan possiblypossessall the neededexpertise, the resource availabilityinateam’sknowledgenetwork,alsoknownassocialcapital,andeffectiveknowledgecoordi- nationbecomeparamount.

Objective: Inthispaper,weexploretheroleofsocialcapitalintermsofknowledgenetworksandnet- workingbehaviorinlarge-scalesoftwaredevelopmentprojects.

Method: Weconductedamulti-casestudyintwoorganizations,EricssonandABB,withsoftwaredevel- opmentteamsasembeddedunitsofanalysis.Weorganizedfocusgroupswithtensoftwareteamsand surveyed61membersfromtheseteamstocharacterize andvisualize theteams’ knowledgenetworks.

Tocomplementtheteamperspective, weconductedindividualinterviewswithrepresentativesofsup- portingand coordinationroles.Basedonsurveydata,dataobtainedfromfocusgroups, andindividual interviews,wecomparedthedifferentnetworkcharacteristicsandmechanismsthatsupportknowledge networks.Weusedsocialnetworkanalysistoconstructtheteamnetworks,thematiccodingtoidentify networkcharacteristicsandcontextfactors,andtabularsummariestoidentifythetrends.

Results: Ourfindingsindicatethatsocialcapitalandnetworkingareessentialforbothnoviceandmature teamswhensolvingcomplex,unfamiliar,orinterdependenttasks.Networksizeandnetworkingbehavior dependoncompany experience,employee turnover,team culture,needfornetworking,and organiza- tionalsupport.Anumberofmechanismscansupportthedevelopmentofknowledgenetworksandsocial capital,forexample,introductionofformaltechnicalexperts,facilitationofcommunitiesofpracticeand adequatecommunicationinfrastructure.

Conclusions: Ourstudyemphasizestheimportanceofsocialcapitalandknowledgenetworks.Therefore, wesuggestthat,alongwithinvestmentsintotrainingprograms,softwarecompaniesshouldalsocultivate anetworkingculturetostrengthentheirsocialcapital,aknowndriverofbetterperformance.

© 2017TheAuthors.PublishedbyElsevierB.V.

ThisisanopenaccessarticleundertheCCBYlicense.(http://creativecommons.org/licenses/by/4.0/)

1. Introduction

Nowadays,large-scale softwaredevelopmentprojects arechar- acterizedbyunprecedentedscaleintermsoflinesofcode,amount ofdata stored,accessed, manipulated,andrefined,aswell asthe numberofconnectionsandinterdependencies,hardwareandcom- putationalelements,customersandusers,and,ofcourse,thenum- ber of developers involved in the projects. Furthermore, today’s projectsaretechnologicallycomplexfrombothinnovationandde-

∗ Corresponding author at: Blekinge Institute of Technology, Campus Gräsvik, SE- 371 79, Karlskrona, Sweden.

E-mail address: Darja.Smite@bth.se (D. Šmite).

signperspectives,anddevelopersandleadershavealimitedability tolearn fromprevious efforts becauseall large-scale projectsare unique[1].

Large-scaleprojectsposea great risk andareoften associated withcost overruns,latecompletions,andoutrightprojectfailures [2,3]. One reason for the high risk is the complexity of large- scaleprojectgovernancestructures,whichisoftenproportional to thenumberofdevelopmentteamsinvolved.Deliveringresultsfre- quentlyanditeratively requireswork andknowledgecoordination ondifferentlevels,e.g.,theportfolio,project,andteamlevels.Ad- ditionalsupporting roles(e.g., portfolio management) are critical inlarge-scaleprojectsformanagingtheexponentialgrowthofin- terdependenciesand mitigatingassociated risks [4]. Furthermore,

http://dx.doi.org/10.1016/j.infsof.2017.01.003

0950-5849/© 2017 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY license. ( http://creativecommons.org/licenses/by/4.0/ )

teams in evolvingproduct development, which is often large in scale, require access to an enormous amount of knowledge and skills[5].Theexpertiseneededontheteamlevelincludesnotonly technicalskills (programming languages and methodologies), but also teamwork and process knowledge, domain knowledge, and product knowledge, e.g., the architecture, source code structure, andallocationofconceptswithinthecode.

The complexity and scale introduce three fundamental chal- lenges. First, large-scale development reaches the point where hardly anyone knows everything about a system’s development andevolution.Second,retainingoriginaldevelopersfordecadesis problematicbecauseofleavesofabsence,employee turnover,and retirements. Finally, large-scale projects often requirethe forma- tion ofnew teams and the addition of newdevelopers. The key questionisthen: howcansoftwareorganizationsefficientlyculti- vatetheknowledgeandskillsneededinthedevelopmentteams?

Evidently, enablingeffectiveknowledgenetworksis crucialfor succeedinginlarge-scalesoftwareprojects.Theneedforsuchnet- worksoutlinestheimportanceofsocialcapital—acontextualcom- plementtohumancapital(individualknowledgeandskills)—which isanemergingconceptinbusiness,politicalscience,andsociology [6].Socialcapitalrefers totheactual andpotential resourcesem- beddedwithin,availablethrough,andderivedfromthenetworkof relationshipspossessedbyanindividualorasocialunit[7].

The increase indemand for knowledge-basedeconomic activ- ity,particularlyproductinnovation,requiresthatwehaveagreater understandingof the factors that enableknowledge creation and sharing in a software team [8]. Moreover, because large organi- zationsoften have large and distributedmulti-team projects, we mustalsounderstandwhat enablesknowledgecreationandshar- ingbetweenteams,andbetweenteamsandtherestoftheorgani- zation.Motivatedbytheimportanceofnetworkingandsocialcap- italinlarge-scale softwareprojects,weexplore theactualknowl- edgenetworks andsocial practices of two large-scale projects in twosoftware-intensivecompanies,EricssonandABB.Ourresearch is exploratory in nature and is driven by the following research question:

RQ: Whatinfluencesteamknowledgenetworksandnetworking behaviorinlarge-scaleprojects?

The remainder of the paper is organized as follows. Section 2 outlines related work. In Section 3, we describe our research methodology.InSection4,wepresentourfindingsfromthecases andcross-caseanalysis, which arefurther discussed inSection 5. Finally,Section 6 concludes the paper witha summary ofmajor findings.

2. Backgroundandrelatedwork

Inthissection,wedescriberelatedresearchoncoordinationin large-scaleprojectsandtheroleofsocialcapitalinaddressingco- ordinationproblemsandknowledgeneeds.

2.1.Coordinationinlarge-scaleprojects

Coordinationisdefinedasthe“managementofinterdependen- ciesbetweenactivities”[9]andcoordinationmechanisms arethe organizational arrangements that allow individuals to act collec- tively [10].Interdependencies include shared resource dependen- ciesandactivitysynchronization.

Softwaredevelopmentiscreativework,whichmeansthatasin- gleoptimalsolutionmaynot exist,andprogresstowardscomple- tioncan be difficult to estimate [11]. One reasonfor thisis that interdependencies betweendifferent pieces of work maybe un- knownorchallengingtoidentify,making itdifficulttoknowwho shouldbeinvolvedinthework,andwhetherthereisacorrector- derinwhich partiesshouldcomplete their ownspecializedwork [10].

Coordination in large-scale software development is of paramount importance since the work is carried out simulta- neously by many developers and development teams [12]. In suchprojects,interdependenciesaremoreuncertainthaninsmall projects;therefore,teams needtoknowwho theexpertsareand which expertsto contact, particularlywhen they are outside the teamorevenatadifferentsite.LicorishandMacDonell[13]stud- iedglobalsoftwareteamsandfoundthattheavailabilityofexperts inteams’networkswaslinkedtoproject-levelperformance.

Coordination can be either predefined or situated [14]. Pre- defined coordination takes place prior to the situation being co- ordinated. It typically consists of establishing written or unwrit- ten rules, routines, procedures, roles,andschedules. Situatedco- ordination, on the other hand, occurs when a situation is un- known and/or unanticipated. Those involved in the situation do notknowinadvancehowtheyshouldcontribute.Theylackknowl- edge of what to achieve, who does what, how the work should be divided, in what sequence sub-activitiesshould be done, and when to act. Consequently, in situated coordination, those in- volved must improvise andcoordinate their efforts in an ad hoc manner.

Software developmentprojects, particularlylarge-scale efforts, haveamixofpredefinedandsituatedcoordination.Involvedteams may,forexample,alreadyknowthegoalandtheworkingprocess oftheteam,butthey maynot knowwhoperforms whatoutside the team,or they mayknow who doeswhat butnot whenit is done. To compensate fora lack of predefinedknowledge of how the activities will actually occur, teams andteam-members must keepthemselvesupdated onthestatusoftheactivity/situationto betterunderstandwhodoeswhat.Improvingtheknowledgetrans- actions between team members and between teams by, for ex- ample,co-locationandmeetings,can strengthenawarenessofthe processesandactivities.

Naturally, when team members are in closeproximity to one another, particularly when they are in the same room, they be- come more aware of other members’ work by seeing and over- hearingtheiractivities[15].Inaddition,during,forexample,daily meetings,teammembersconstantlyupdateeachotheronthesta- tus and become aware of the changes. However, putting every memberofa large-scaleprojectinto thesameroom orthesame meeting is often problematic. Empirical cases, e.g., Boden et al.

[16],demonstratethelimitationsof,forexample,groupwaretools, insupportingknowledgemanagement,ifnotgroundedinthework practicesofthecommunitiestheyaimtosupport.Similarly,Paasi- vaara andLassenius [17] describe a large-scale development ini- tiativeatEricsson, inwhichbasiccoordinationmechanismsfailed to support the coordination of 40 teams in three sites. Instead, knowledge sharing and work coordination in the Ericsson study wasenabledthroughanumberofcommunitiesofpractice,which are known as groupsin the organization that on a regular basis share a concern,or a set of problems[18]. Based on thesefind- ings, we propose that socialization-orientedcoordination mecha- nismsareparamountinlarge-scalemulti-teamandmulti-siteen- vironments.

2.2. Coordinationbyarchitecture

Coordinationbyarchitectureiscommonlyusedtominimizethe needtocoordinatebetweenteamsandacrossgeographic,cultural, andlanguageboundaries.Ovaskaetal.[19]foundthatparticipants inalarge-scale distributedprojectcoordinatedtheirdevelopment workthroughsoftwaremoduleinterfaces.Relyingonthisstrategy, eachsoftwaremodulescouldbedevelopedseparately,andthusthe coordinationproblemscouldbemitigated.

However, experience shows that the effectiveness of coor- dination by architecture is limited, since system modules are never truly independent. Development of technically interdepen-

dent modules in isolation may lead to discrepancies, which of- ten remain hidden until integration [20]. Additionally, organiza- tions that follow modularized development andassign the work onaspecificmoduletoasingleteam,cultivatedeeperspecialized knowledge aboutthat module, rather than a broader knowledge aboutdifferentpartsofthesystem.Thispotentiallyleadstomore knowledge dependencies, if the modules have functional depen- denciesorcomplexintegrationpoints.Herbslebetal.[20].demon- strated that modularization alone isinsufficient to overcome the challenges, andarchitecture-based, plan-based,andprocess-based coordinationwithoutthesupportofsituatedcoordinationislikely tofail.

One alternative to organizing the teams by modules in large- scale software development is assigning team responsibility for features.CoordinationbyfeatureswasexploredbyPaasivaaraetal.

[21]inacasestudyoflarge-scalegloballydistributedsoftwarede- velopment projectusingScrum. Afeature ina large-scaleproject can cover several sub-systems and modules. Paasivaara and col- leaguesfoundthatthefeature-basedScrumofScrummeetingcan beagoodcoordinationmechanism,becauseasmallgroupofpeo- plewithcommoninterestsandgoalscouldshare,discussandeven solveproblemstogether.

2.3. Coordinationbynetworking

Giventhepremisethatitisimpossibleforasingleindividualto possessalltheknowledgeneededtoworkonalarge-scaleproject andthat situatedcoordination isparamount, softwaredevelopers andsoftwareteamsneed torelyonknowledge resourcesembed- dedwithin, available through,andderived froma networkofre- lationships, alsoknownassocialcapital.Socialcapitalisboththe networkitself andtheassetsthatmaybemobilized throughthat network[22].Oliveretal.[23]referstoaknowledgenetworkasa networkthatfacilitateslearningandconnectsexpertsandnovices tosupporton-demand,continuouslearningthroughgroupinterac- tion.

As mentionedbefore, teamsin large-scaleprojects oftenwork in isolation, whilecommunicating andcoordinating withthe key expertsintheirnetwork[7].Therefore,coordination isneededon differentlevels:insidetheteam,amongtheteams,andbetweena teamandtherestoftheorganization.Intheirsystematicliterature review,Mathieuetal.[24]concludethatateam’scentralityinan inter-network is conducive to performance. Centrality appears to provideteamswithadvantagesintermsofacquiringandapplying resources.Theteamhassocialcapitalbothintermsofhowitcan leverage the social interaction within the team,and how it uses theexternalcontactsinitsnetworktocreatevalue[25].

Social capital enables software teams to achieve results that would be impossible without it orcould only be achievedat an extra cost for the developmentteam [25]. Furthermore, because social capital increases the efficiency of information diffusion, a large-scaleprojectcanhavelessredundancyine.g.,skillsorroles, if knowledge networks are cultivated; i.e., if the social capital is strong.

The value of socialcapital fora team andteammembers de- pends on a number of factors,including the knowledge network characteristics. For example,Burt [6]suggests that poorcommu- nicationandcoordination within an established networkleadsto poorperformance. Groupsworkinginisolationbenefitleast from external networking. In contrast,cohesive groupsare able to cir- culate the information gained from the knowledge network and maximizetheirownperformance.Characteristicsoftheknowledge networksurroundingateamalsoinfluencethevalueofsocialcap- ital.Onesuchfactorisexternalcontactredundancy.Thesamecon- tactsleadtothesameknowledgesources,resultinginredundancy.

Sincenetworkingrequirestimeandeffort,contactredundancyhin-

dersperformance.Thus,fortwoknowledgenetworksofequalsize, theonewithfewerredundantcontactswillprovidemorebenefits.

Network stability plays another important role. When people leave the organization, their connection usually dissolves with whateversocialcapitalit contained[26]. Itisfairto assumethat otherstaff changes, e.g.,teammemberrotations,promotions,and relocations, also affectthe social capital of the team(s). Further- more, different types of teams have different networking needs.

Lewis[27]foundthatrich externalknowledgenetworksaremore valuable to cross-functional teams working on unfamiliar tasks, than to team members workingon familiar and unrelated tasks.

Themainreasonisthat itmaybelesscriticalforteammembers inspecializedteams,e.g., componentteams,tointegrate theirex- pertisetoperformwell.

Evidently, a large-scale software development project enables theaccumulationofsocial capitalwhenits membersare brought togetherto undertaketheir primarytask,superviseactivities,and coordinatework,particularlyincontexts requiringmutualadjust- ment,i.e.,coordination by informalcommunication[28].Therole ofso-called“boundaryspanners” isparticularlyimportantforcon- necting the remote parts of organizational networks [16,29,30]. Furthermore,training mechanisms exist to accumulate the social capitalof softwaredevelopment teamsat work. Certaindevelop- mentapproaches (e.g.,agile softwaredevelopment) anddevelop- mentpractices(e.g.,pairprogramming,dailymeetings,andreview meetings)fosterfrequentnetworkingandextensiveinteractionin- sidethedevelopmentteams.Forexample,PaasivaaraandLassenius [17]foundthatcommunitiesofpractice(CoPs)andparticipationin differentforums fosternetworkingacrossdevelopmentteamsand units,asinlarge-scaledevelopment.Wohlinetal.[25]alsoempha- sizedthatbyinvestinginsocialcapital,organizationscanmakethe specializedoruniqueknowledgepossessedbythefewavailableto themany.

3. Researchmethodology

Ourresearchisexploratoryinnature[31].Tounderstandwhat influencesteamknowledgenetworksandnetworkingbehavior,we conducteda multi-casestudyoftwolarge-scale softwareprojects intwo software companies, Ericssonand ABB,with softwarede- velopmentteamsasembeddedunitsofanalysis.

3.1. Caseandsubjectselection

Weconductedanembeddedcasestudy[31].Theunit ofanal- ysiswasadevelopmentteaminthecontext ofa large-scalesoft- wareprojectinasoftware-intensivecompany.Asexploratorycase- based research, our sample strategy was not to obtain accurate statisticalevidenceon thedistribution ofvariables within a pop- ulation,asinhypothesis-testingstudies,butrathertorelyonthe- oretical sampling[32]. From large-scale multi-site companies,we selected software projects anddevelopment teams with overlap- pingandcomplementarycharacteristicsforthecasestudy,tofind abroaderrangeoffactorscontributingtonetworkingbehavior.

Companies: The companies were selected based on convenience sampling.BothEricssonandABB havelarge-scalesoftwaredevel- opmentprojects with company sitesin Sweden andat leastone offshorelocation.Inaddition,thetwocompaniesareofpolartypes whenitcomestoworkingmethods(agileversustraditional).Polar- ityincaseselectionislikelytohelpextendtheemergentfindings [32].

Large-scaleproduct development efforts: In each company, we selectedone large-scale distributed softwareproject that fulfilled the selection requirements, i.e., being a highly complex multi- teamandmulti-site endeavor. We evaluated complexityin terms of the knowledge demands, which were impossible to fulfill by

Table 1

Survey participants.

Teams Location Total team members

Participated in the survey

Response rate

Ericsson E-SWE-1 Sweden 8 6 75%

E-SWE-2 Sweden 7 5 71%

E-SWE-3 Sweden 6 5 83%

E-CHN-1 China 9 8 89%

E-CHN-2 China 5 5 100%

E-CHN-3 China 6 6 100%

ABB A-SWE1-1 Sweden 1 5 5 100%

A-SWE1-2 Sweden 1 6 4 67%

A-SWE2 Sweden 2 5 5 100%

A-IND India 18 12 67%

75 61 81%

a single individual. Company representatives selected the candi- dateprojectsthatfulfilledourrequirements:multi-team,multi-site projects concerned with maintaining and evolving complex soft- waresystems.

Teams:In each company, foreach large-scale software project,a selection of teams was identified and then analyzed. Since re- search activities required significant involvement fromthe teams andthe researchers,we selectedteams foranalysisfollowingthe maximum-variationstrategy[31].In bothcompanies, weselected teamsfromeachofthemain developmentlocations. Weselected matureaswell asrelatively newteams,andteams workingwith familiar and unfamiliar tasks. This sampling was done with the helpofcompanyrepresentatives.

3.2.Datacollection

As part of the case study, we gathered rich empirical data (see Table 2) from 65 survey responses, 31 interviews, 11 fo- cus groups, and observations from visiting five different sites (two in Ericsson and three in ABB). To improve the validity of ourfindings, we strivedfor triangulation [31]. We collected data throughdifferentmeans(aimingformethodologicaltriangulation) andfrom different roles in the developmentorganizations (aim- ing for data source triangulation). We also performed member- checking [33], i.e., we organized feedback sessions with all the teamsandthe management,where we presentedourfindings to obtainfeedbackonourinterpretationofthefindings,andderived conclusions.

3.2.1. Survey

To answer our research question, we conducted a social net- workanalysis survey to measureand capturethestructural rela- tions of teammembers inside and outsidethe team. The survey designwasapartialreplicationofan empiricalsurvey byManteli etal.[30].The social network survey is available in Appendix 1. We askedrespondents to identify people that they sent project- relatedknowledgeto,orretrievedknowledgefrom,aswellasthe natureandcontentoftheknowledgetransferredorretrieved.The respondentswere askedto freely recall their contacts andfill in thedetails abouteach contactin writing (on paperor electroni- cally).Basedon this, weobtaineda directed knowledgenetwork, i.e.,indicating thedirectionoftheknowledgetransfer, toorfrom theteam.

Our sample included the teams that participated in the fo- cus groups (see Table 2). The participation and response rates for the survey are given in Table 1. The networks included not only participants of the survey, but also non-participants re- called by the survey respondents, e.g., team members who did

not participate, members of other teams, orthose in supporting roles.

3.2.2. Interviews

Interviewswereconductedineachcompanytounderstandthe casesandthehistory.Weinterviewedrepresentativesfromallsites andincludeddifferentroles(31interviewsintotal,seeTable2for details). The interviews were one hour long, on average, and all but one interview wasconducted in person.All interviews were conducted in English and tape recorded. Interviews in Ericsson weretranscribed,whileinterviewsinABBwereanalyzedusingthe recordingsandnoteswrittenbytheresearchers.

3.2.3. Documentation

Thequalitative datawassupplemented bydocumentation (see Table 2) that helpedus tounderstand the softwaredevelopment context,processes,andgoalsatbothcompanies.

3.2.4. Observations

Onsite visits were organized to all onshore and offshore sites tobetterunderstandtheenvironmentsinthedifferentsitesofthe twocompanies.WevisitedEricsson’smainSwedishsiteandABB’s main Swedishsiteon multipleoccasions.Two researcherspaid a one-dayvisittoABB’sotherSwedishsite.Oneresearcherspentone week in ABB’s offshore site inIndia, andtwo researchers visited Ericsson’sChinesesiteforoneweek.Theobservationsmadeduring thevisitswerecapturedintheformofwrittennotes.

3.2.5. Focusgroups

Aftertheinterviews,focusgroupswithdevelopmentteamsand groups were organized in each of the companies. Focus groups are used to quickly obtain information on emerging phenomena through structured, moderateddiscussionswithgroups ofpracti- tioners[34].Moreimportantly,focusgroupshelptapintoagroup’s collective memory by allowing participants to build on the re- sponses of others, which leads to ideas and observations that mightnotemergeduringindividualinterviews[34].

All focus groups followed a predefined structured agenda. In eachfocusgroup,weacquiredinformationabouttheskillsneeded forsolving theteam’s tasks,teamworkpractices, interactionwith other teams, roles, andcommunities, usefulness of the external- ized knowledge, teams’ reliance on different types of knowledge andskills intheir daily work, andthe team’sperception of their performance.Thefocusgroupsweremoderatedbytheresearchers, andweretwo tothree hourslong.All focusgroupsinboth com- panieswererecordedandlatertranscribed.

3.2.6. Feedback

We presented the findings to the companies and teams as a part of member-checking. Member-checkinginvolved obtaining feedbackonourunderstandingofthenetworksandtheknowledge mobilizedthrough thesenetworks, ourinterpretations madedur- ing the data analysis, and perceived practical implications of the findings. Member-checkinghelpsreduce manytypesofthreatsto validity, since both the respondents and the researcher can look through the material [35]. Presentation ofthe findings made the subjectsfeel asbeingpart oftheprocess.Presenting the findings isalso veryimportant insituationswhere thefindings mayhave animpactonthewaythepractitionerswork[36].

Interestingly,duringthepresentations,wereceivedmorefeed- back fromthe managersthan theteams. The feedbackcontained explanations forcertainfindings, reflectionsonwhetherthefind- ings confirmed the beliefs of the managers and team members, andwhatthey thoughtwassurprisingorunexpectedinthefind- ings.We referredtothefeedbackreceivedfromthecompaniesin

Table 2

Empirical data collection and analysis.

Ericsson

Activity Location Time Participants Researchers ^∗ Data gathered

Survey Sweden Apr 2014 3 Swedish feature teams, 16 participants A1, A2, A3 Individual networks, purpose of communication, and availability scores China Mar 2014 3 Chinese feature teams, 19 participants A1, A2, A3

Interviews Sweden Aug 2013 7 interviews, incl. an agile coach, planning manager, product manager, release manager, two design owners, system owner, system architect, and three technical experts (TARs).

A1, A2 Description of the system, roadmap planning, assignment of the tasks to the teams, mechanisms for quality control, and administrative coordination.

China Mar 2014 8 interviews, incl. an agile coach, team responsible manager, two operational product owners, TAR, previous system owner, and node architect. One Chinese TAR was interviewed by phone.

A1, A2

Documentation Sweden, China

May 2013–

May 2014

System descriptions, specific role descriptions, list of team members, years of experience in the company, and process descriptions

– Context of software development activities and team information

Observations Sweden Aug 2013–

Sep 2014 Several office visits A1, A2, A3, A4 Context information for the teams’ work coordination, office layout

China Mar 2014 A week long office visit, observations of 5 daily Scrum meetings

A1, A2

Focus groups Sweden Oct 2013 3 Swedish feature teams A1, A2 Knowledge needs for feature development, presence of the knowledge in teams, external interaction, and externalized knowledge. Scores for reliance on different sources.

China Mar 2014 3 Chinese feature teams A1, A2

ABB

Activity Location Time Participants Researchers ^∗ Data gathered

Survey Sweden 1 Feb 2014 2 teams, 9 participants A1, A2, A3 Individual networks, purpose of communication, and availability scores Sweden 2 Feb 2014 1 team, 5 participants A1, A2, A3

India Jul 2014 Group of developers, 12 participants A1, A2, A3 Interviews Sweden 1 Aug 2013 6 interviews, incl. the system architect,

testing and support manager, product manager, team lead, project manager, and visiting senior developer from India.

A1, A2, A4 Description of the system, projects’

planning, development processes, and mechanisms for quality control

Sweden 2 Feb 2014 3 interviews, incl. a unit manager, project manager, and team lead

A1, A3 India Jul 2014 8 interviews, incl. a unit manager (2

times), project manager, 2 technical coordinators, and 3 developers (junior, experienced, and regular).

A3

Documentation Sweden, India

Oct 2013–

Sep 2014

System descriptions, specific role descriptions, list of team members, years of experience in the company, and process descriptions

– Context of software development activities and team information

Observations Sweden 1 Oct 2013 Office visit with an excursion, multiple visits

A1, A2, A3, A4 Context information for the teams’ work coordination, office layout

Sweden 2 Feb 2014 Office visit with an excursion A1, A3

India Jul 2014 Week-long office visit A3

Focus groups Sweden 1 Feb 2014 2 teams in the main Swedish location A1, A3 Knowledge needs for feature development, presence of the knowledge in teams, external interaction, and externalized knowledge. Scores for reliance on different sources.

Sweden 2 Feb 2014 The only team in the other Swedish location

A1, A3 India Jul 2014 Joint session with both groups of

developers

A3

∗This column refers to the authors’ participation in the data collection; the first author is A1, the second author is A2, and so forth.

theresultnarratives,wheneverwe founditusefultoexplain cer- tain observations.Finally,wesent themanuscriptofthispaperto thecompanyrepresentativestoverifytheaccuracyofourdescrip- tionofthecontext.

3.3. Dataanalysis

We startedwith a within-caseanalysis, whichwas conducted on multiple levels—team, site, and organizational—before moving toacross-companyanalysis,assuggestedbyEisenhardt[32].First,

we constructedknowledge networks foreach teambased on the survey data. Special preparations were performed to analyze the surveydata.

Surveydata preparation wasneededto ensure the reliability and quality of the obtained dataset. The first and third authors carefullyscreenedtheindividualresponses,whichincludedclarify- ingthenamesandrolesofeachnetworkcontact,clarifyingunclear responses(e.g.,unknownabbreviationsofroles,processes,orsub- systems),andremoving invalid responses. Wealso mergedrecip-

Fig. 1. Example: Team network visualization and measures.

rocalrelations.Ina reciprocalrelation,PersonA identifiesPerson B as a knowledge-sharing contact, andPerson B likewise identi- fiesPersonA.BothPersonAandPersonBreportedthepurposeof theknowledge relationbetweeneach other;we merged themby semanticallycombiningtheanswersandaveragingtheinteraction frequency.Finally, we transformed the datato reflect theknowl- edgeflows,i.e.,directedconnectionsintermsofincoming,outgo- ing,andexchangeflowsbetweentwocontactsinthenetwork,in- steadofthedirectionofthesurveyresponses,i.e.,whoreferredto whom.

Surveydataanalysisaimedtounderstandanindividualteam’s networking behavior. We started by deriving the purpose of the knowledgeflows.Duringthisprocess,welearnedthatrespondents regardedverydifferentinformationtypesastheknowledgeimpor- tantfortheirjob. Hence,we classifiedthe responsesintothefol- lowingcategories:

• Product-related knowledgeincludes knowledgeaboutprogram properties, existing architecture, concept location within the code,etc.[29];

• Process-related knowledge includes knowledge about coding conventions, development tools, ways of working, and skills [29];and

• Project-related work coordination includes information about project milestones, delivery schedules, progress updates, re- views,andinspections[37].

In Fig. 1, an example ofthe outcome of ouranalysis is visu- alized. For each team, we calculated the total number of exter- nalcontactsandexternalconnections(knowledgeflows).Wenoted thepurposeoftheknowledgeflowsasbeingrelatedtotheproduct knowledge,process knowledge,orworkcoordination.Inouranal- ysis,wealsoseparatedincoming,outgoing,andexchangeflows.Fi- nally,weconstructedtablesummaries,inwhichwevisualizedthe mostand leastcommon flows as a heat map (the frequency in- creaseofaknowledgeflowisvisualizedbyadarkercoloroftable cell(seeourexampleinFig.1).

Surveydatavisualization wasperformedusingGephi,¹ which is an open source software for visualization and analysis of so- cialnetworks. Networkgraphlayouts wereconstructed usingthe

1Gephi is maintained by Gephi Consortium, https://gephi.github.io .

Force-Atlas-2algorithm,whichisasimplespatializationalgorithm forlargenetworkvisualizaitonproposedbytheGephiteam.

Within-caseanalysisincludedaqualitativeanalysisofthetran- scribed data and aimed to better understand teams’ knowledge networksandnetworkingbehavior.Basedonthefocusgroupdata, teams’self-reported characteristics,observationnotes,andsurvey dataanalysis(asdescribedabove),wecreateddetailedcasewrite- ups, which were central to the generation of insights [32]. The companies’representativesverifiedtheaccuracyofthenarratives.

Cross-case analysis targeted cross-team, cross-site, and then cross-company comparisons. We started by comparing the con- structed knowledge networks, and then thematically analyzed team descriptions in search of patterns. Since the way team workedvaried across sites,and evenmore across companies, we also created project-level write-ups. The cross-company analysis was highly iterativeand led to refinements of the concept defi- nitions duetodifferences interminologyacross teams,sites,and companies,andbecauserelatedcategoriescouldbemergedunder more general concepts. This is not uncommon in pattern gener- ation accordingto Eisenhardt [32] who suggests that researchers shallapplycross-casesearchingtacticstolookatthedifferentcat- egories ordimensions,determinesimilaritiesanddifferences,and detecttheemergingpatterns.

Forexample, what later emerged as “having an expertin the team” was first identified in Ericsson’scase astechnical area re- sponsible developers (TARs), who acted as knowledge hubs and wereinsomecasesmembersofateam.TARshadasetofformal responsibilitiesanddedicatedtimefornetworking.ABBhadnofor- malexpertsinthesamesenseasinEricsson;thus,ouranalysisof theexpertstructurewastriggeredbythefindingsfromthecross- companyanalysis.Weperformedanadditionalinquiryandlearned thatABBteamsrelyprimarilyoninformalexpertswhodonothave formal roledescriptions;only afterwepresented ourpreliminary findings wasthe formalrole ofTechnicalCoordinators introduced intheIndiansite.

Theemergentexplanations anddeterminantsoftheteamnet- workswere summarizedin theformof teamprofiles (see Tables 3and6inthefindings).When profilingtheteams,we alsocom- paredtheemergentconceptswithexistingresearchthatidentified whatdeterminestheexternalnetworksizeandnetworkingbehav- iorofateam.Somefactorswereconsonantwithrelatedliterature, e.g.,companyexperience[37],taskcomplexity,andtaskfamiliarity [6],whileotherfactorswerecase-specific.

To help with hypothesis generation [32], we summarized our findings inthe formof arelation model,inwhich emergentfac- torsare linked withthe teams’externalknowledge networksand networking behavior (Fig. 5). The factors included in the model came frommultiple data sources (mentioned by more than one team).

4. Findings

Inthissection,wepresentourfindingsinthetwocaseprojects.

Ineachcase,westartwithadetailedprojectdescription(theEric- ssoncaseinSection4.1andtheABBcaseinSection4.3).Foreach company, we describe the product under development, the soft- ware development process, and how the teams were organized.

Case descriptions serve the purpose of putting our findings in context; thus,clarifying thevalidity and applicabilityof ourcon- clusions. We continue by presenting the teams’ knowledge net- works, network characteristics, and knowledge flows in light of thecontext (theEricssoncaseinSection 4.2andtheABBcasein Section4.4).Weconcludeourfindingswithacross-companyanal- ysis(Section4.5).

Table 3 Teams’ profiles.

Teams Location Team members

Expert in the team

Company experience (average)

Team experience (average)

Type of team Task familiarity

Task complexity

Approach to solving simple or familiar tasks

Approach to solving complex or unfamiliar tasks

Participation in forums and CoPs

E-SWE-1 Sweden 8 No 12.3 years 2.1 years Cross-functional feature team

Unfamiliar High Human capital Social capital Often E-SWE-2 Sweden 7 Yes 9.6 years 1.6 years Varying Varying Social capital Social capital Sometimes E-SWE-3 Sweden 6 Yes 13.3 years 2.3 years Familiar Varying Human capital Org. capital Sometimes

E-CHN-1 China 9 Yes 2 years 2 years Familiar Low Human capital Social capital Seldom

E-CHN-2 China 5 No 2.8 years 2.2 years Familiar Low Human capital Social capital Seldom E-CHN-3 China 6 No 2.2 years 0.9 years Unfamiliar Low Human capital Social capital Seldom

4.1. Ericssoncasedescription

Ericsson is a leading provider of telecommunication systems andequipmentformobileandfixednetworkoperators. Thecom- panydevelopsgenericsoftwareproductsofferedtoanopenmarket andcomplexcompoundsystemswithcustomizedversions.

4.1.1. Studiedproject

The projectunder studywasa distributeddevelopment effort of one of30 sub-systems belongingto a largesoftware-intensive productaccountingformorethanmany-millionlinesofcodewrit- tenindifferentprogramminglanguages.Thestudiedproduct was onthemarket formorethanfiveyears,andatthetimeofinves- tigationcontained14componentsandinteractedwitheightdiffer- entsub-systems.Thenumberofdevelopersworkingontheproject grewfromeightdevelopersin2007to30developersin2009,and scaled up to around 60 developers by 2013. In early 2014, there werefivein-houseteamsinSweden,eightin-houseteamsandtwo outsourcingteamsinChina,aswellastwoin-houseKoreanteams.

4.1.2. Developmentapproachandknowledgeneeds

Agile and Scrum have been practiced since 2008, and the projectwasorganizedinseventeenself-managingcross-functional featureteamscomprisedofmemberswithdifferentroles.Inmost cases,featureswerehandledbyoneteam,andrepresentedapiece offunctionalityora requirementrequested by thesystemowner.

Features can address enhancements required by the telecommu- nicationstandards,customerspecificrequirements,andevolution- based enhancements. Notably, features are domain specific; thus, particular domain knowledge is needed to be able to perform a task.Overtime,ateamdevelopsaspecializationinacertaintype offeatures, whichcan be associatedwith, butare notlimitedto, system functionality,system layers, orcomponents. Features also differ by complexity. The mostcomplex features require changes inseveralpartsofthecompletesystem. Implementingsuch com- plex featuresputs highdemands ontheteamandtheknowledge possessedbyoraccessibletothem.Occasionally,anexistingteam changesitsspecializationandlearnsanewtypeoffeatures.

Bugfixingisarotatingtask.Ateammayspenduptohalfayear on bug-fixing,simultaneouslybroadeningtheir expertise,because they must work in several parts of the complete system when fixing a bug. In addition, teams working for a specific customer areoftenrequiredtohaveabroaderexpertisetobe abletocom- pleteanyfeatureorbugfix inthesub-system.Ateam’s workon a feature starts by receiving a high-level description andcontin- ueswitha so-called“sprintzero,” in whichteammembers work closely together on designing the feature, followed by the demo of the feature design, development, and delivery.Technical-area- responsibledevelopers(TARs)playanimportantroleinconsulting featureteamsandapprovingfeaturesolutions.Thesearethemost seniordevelopersresponsibleforasystemarea,andspend50%of their time sharing their knowledge, supporting teams on techni-

calquestions,performingcodereviews,andapprovingfeatureso- lutions.Therestofthetime,aTARisateammember.

4.1.3. Teamsandteamworkcharacteristics

WestudiedsixEricssonteams—threefromtheSwedishsite(E- SWE-1,E-SWE-2,andE-SWE-3)andthreefromthecompany’sChi- nesesite(E-CHN-1,E-CHN-2,andE-CHN-3).Theteamprofilesare presentedinTable3.

Experience: From the profiles, we observe that the Swedish teams can be generallycharacterized by their long company ex- perience(around10yearsonaverage).Theexperienceofworking togetherintheteamvaries. IncontrasttotheSwedishteams,the Chineseteams are composed ofmembers withlesscompany ex- perience(onlytwotothreeyearsonaverage).TwooftheChinese teamshavehadoccasionalmemberchangesandhaveoperatedto- gether fortwo years,while team E-CHN-3 isthe mostimmature team,with less than a year’s jointwork experience. Finally,two Swedishteams(E-SWE-2andE-SWE-3)andoneChineseteam(E- CHN-1)haveTARsworking50%intheteam.

Approach to solving tasks:Most teams are workingwith fa- miliar tasks, and either rely on their own knowledge and skills (human capital)or teamwork(socialcapital). Teamwork andnet- workingwithexpertsareparamounttoovercomingcomplexityor a lackof knowledge.Team E-SWE-1 is an experienced teamthat hasbeenrecentlyassignedanewtypeoffeatureandis,therefore, currentlyperforming unfamiliar tasks. Team E-SWE-2 is working towardaspecificcustomer,meaningthatthey needtoworkon a largepartofthesystem;hence,thetaskfamiliarityvaries.TeamE- CHN-3isanewteam;therefore,thetasksareunfamiliarformost oftheteammembers.

Task complexity also differs. The Chinese teams andTeam E- SWE-3 areworking onrelatively simplefeatures, while TeamsE- SWE-1, E-SWE-2, and part of E-SWE-3 are assigned more com- plextasks.WhileteamsE-SWE-1,E-SWE-2,E-CHN-1,E-CHN-2,and E-CHN-3regardedteamdiscussionsandnetworkingwithothersas their main approach toproblem solving, Team E-SWE-3 revealed that communication played a background role. In areas where teammembers were lacking knowledge, they primarily relied on documentationandsourcecode(organizationalcapital), whilere- lyingonindividualskillswhenworkingonfamiliarorsimpletasks.

ParticipationinforumsandCoPs:Finally,weaskedtheteams todescribetheirparticipationindifferentforumsandcommunities ofpractice(CoPs)tolearnabouttheirnetworkinghabits.Wefound that the Swedish teams have a tradition ofattending disciplined CoPs,althoughsome teams aremoreactive than others,whilein Chinasuchforumsarelessattended.

Thenetworkgraphsfromthesocial-networkanalysissurveyat Ericssonare showninFig.2. Theblack dots andlinesin thefig- urerepresentrespectiveteammembersandteaminternalconnec- tions,whilethegreydotsareteamcontacts—supportingrolesand otherteammembersfromanylocation.Externalnetworksizeand knowledgeflowscanbefoundinTables3and4.

E-SWE-1 E-SWE-2 E-SWE-3 E-CHN-1 E-CHN-2 E-CHN-3

Fig. 2. Ericsson teams’ knowledge networks.

Table 4

Teams’ network characteristics.

Team Number of team

members Respondents External network size Total Average per

respondent

E-SWE-1 8 6 48 13 .2

E-SWE-2 7 5 26 5 .8

E-SWE-3 6 5 25 5 .6

E-CHN-1 9 8 21 4 .9

E-CHN-2 5 5 29 7 .6

E-CHN-3 6 6 11 3 .3

4.2.NetworkingbehaviorintheEricssoncase

Inthissub-section,wepresentourfindingsregardingtheteam networkingbehavior.Wedescribetheteamexternalnetworkmea- sures:networksizeandnetworkingpatterns.

4.2.1. Externalnetworksize

Fromtheexternalnetworksizemeasure,welearnthatSwedish TeamE-SWE-1hasthelargestnetwork,ChineseTeamE-CHN-3has thesmallest network, while the other teams have approximately thesame average network size. Teams havedifferent contacts in theirnetworks.Evidently,softwareteamsinlarge-scaleprojectsat Ericssonare supported by a large number of roles,including ar- chitects, TARs,informal technical experts,line managers, product owners, operative product owners, system managers, configura- tion managers, testing-framework experts, continuous-integration experts,agilecoaches,andintegrationleaders.Further,teams also interactwithmembersofotherteams.However,whenaskedabout theexpectedteamexternal-networksizeduringthefeedbackses- sions,the managersatEricssonsuggestedit wouldbe around10 contacts.In fact, since theamount of networking wasunderesti- mated,thecompany environmentdidnot satisfy all theneeds of theteams. Inthe focusgroups, teams complainedaboutthe lack ofdedicatedroomsandinabilityto haveadhocmeetingsdueto workingin an open-space environment and an unwillingness to disturbothers atwork. Asa developerfromTeam E-SWE-1 said:

“Ifyoucan’tbook ameeting [wellinadvance],itbecomesharderto [collaborate].”

Theselection ofteamsindifferentlocationsalsoallowedusto compareteams with differentbackgrounds. In focusgroups with theteams andfeedback sessions withthe Chinese managers, we receivedafewexplanationsofnetworkinginChinapointingtocul- turaldifferences.Chineseteamsweresaidtoprioritizenetworking within the teamover interactions withpeople outside the team, becausesupporting their ownteam wasseen as paramount.The developersexplainedthatdeliveringvalueforthecompanyinthe formofgood quality andnewfeatures was seenas mostimpor-

Table 5

Teams’ knowledge flows – networking patterns.

tant, andnetworking not directlysupporting this goalwas not a priority. This is alsoevidenced in the required improvements,as reported by Team E-CHN-2 and E-CHN-3. Both teams confessed thattheyshouldworkmoreoninteractingwithpeopleoutsideof the team, while E-CHN-1 stated that they do not interact much withother teams beyond thejoint-feature work. Languagebarri- ersbetweenChinaandSweden,somepeoplebeingshy,andnewly hiredpeoplewithoutanetworkweregivenasadditionalexplana- tions forwhysome Chineseteam membershadasmallnetwork.

Thissuggeststhatnetworkingpracticescouldberootedinculture.

4.2.2. Networkingpatterns

When analyzing knowledge flows (how the network is used), we found that teams depended on diverse knowledge pulled, pushed,andsharedintheirnetworks,i.e.productknowledge,pro- cess knowledge, andknowledge relatedto work coordination. In Table 5, we classify the teams’ knowledge flows in terms of the networking purposeand use a heat map to distinguish between the patterns— darker colors show the most common flows and lightercolorsshowtheleastcommonflows.Notethatweuseper- centages, and thus do not compare the actual number of flows acrossteams.Moreover,wecannotsayanythingabouttheamount ofcommunication, sincesome ofthecontactsinthenetwork are morefrequentthanothers.

Scoutingforproductknowledge innewteams:TeamE-CHN-3 wasa newly foundedteam.During the teamretrospective,many referred to the team as consisting of young graduates with lit- tle ornoexperience, meaningthere wasnot much knowledgeor connections in the organization. As someonesaid: “We know we

should communicate with other people, but we don’t know how to communicate efficiently.” As a consequence, their network was small,therewere nooutgoingknowledge flows andthe vastma- jority ofthereportedknowledge flows wereincoming (65%).The teammembersreportedreceivingproduct-relatedknowledge,tips, andtricksfromtheirpeersfromotherteams,aswellasprocedural directivesandsuggestionsfromsupportingroles.

Scouting for productknowledge inmatureteams:Due tothe large product size and changing needs for development efforts, teams need to learn newproduct areas.As someone said,“There arearound 30 sub-systems[in thecomplete product] andtwo-three engineers haveworked in 20 subsystems.They areexceptions. Most areworking in four-five… Iwouldsay thatnoone in theorganiza- tion, even senior architects, understandsthe complete product.” We found that even the team with long company experience (Team E-SWE-1) depended on product knowledge pulled fromthe net- work of formal and informal experts when working on complex orunfamiliartasks.Teamswithshortcompanyexperience(Teams E-CHN-1, E-CHN-2, and particularly E-CHN-3) scouted for prod- uct knowledge toperform thetasks,usually approaching thefor- malexperts(TARs).Developerswithlimitedexperiencementioned seeking knowledgeaboutthe sub-system’sarchitecture andcode, knowledge aboutrelatedsub-systems,andknowledgeofdifferent telecommunication protocols and standards. Evidently, all teams thatreportedteamworkandnetworkingastheirprimaryapproach to solving complex tasks reported a relatively high number of incoming-product knowledge flows (22% forE-SWE-1, 30% forE- CHN-1, 36% for E-CHN-2 and 65% for E-CHN-3), while Team E- SWE-3, which reliedon documentation andsource code,did not (only 3%ofall networkingconnections wereincomingknowledge flows).

Bridgingproductknowledge:Formaltechnicalexperts(TARs)in theteamplaytheroleofbridgesandproduct-knowledgehubsfor otherteams,andaretheonesbehindtheoutgoingflowsinTeams E-SWE-2,E-SWE-3,andE-CHN-1.Theyprovideproductknowledge fortheteamsworkingonmodules,whicharepartoftheirrespon- sibility.Fromthesurvey,wefoundthatteamswithaTARscouted lessforproduct knowledge,indicating that whena TAR waspart oftheteam,heorsheactedasaknowledgehubfortheteam.

TARswere foundtobe criticalfortheChinese teams.Amem- ber from Team E-CHN-2 commented: “For us designers, the most frequentpersonsweinteractwithoutsidetheteamaretheTARs.”Si- multaneously,wefoundthatTARscoulddelayteamswhentheex- perts disagreed.Asa memberfromTeam E-SWE-1stated:“When youhavedifferentTARs,theyhavedifferentopinions.”TeamE-SWE- 1 discussed a number of frictions withthe TARs, which demon- strated that the TARshave questioned their competenceand de- layed theirprogress.WhenaskedwhatwouldhappenifTARsdid not exist, someonefrom Team E-SWE-1 said,“The code wouldbe less structured,” and another commented, “I think that we would survive thatchange;I think thatwe would bebetter,” andanother said,“Willbefaster.”

Receiving process-related advice:Team E-CHN-3 reported re- ceivinga lotofguidancefromthelinemanagers,product owners and other roles in terms of how to perform their work (23% of all networking connections). Despitetheavailability of documen- tation, those whoare newto thecompany corporateculture and waysofworkingareoftenmentoredandreceivealotofadvice.As a memberof Team E-CHN-3 said: “Iamadjusting to this new or- ganization. ThefirstweekI’ m here,Iread quitea lotofdocuments abouttheprocess[…]So,probably,atthispoint,Igotalotofknowl- edge. But not all the knowledge”, and another member continues

“Yes, several teams havetold us thesame. It’s a lotof communica- tionwithdifferent[roles]”.

Sharingknow-how:TheSwedishteamsreportedhavingalarge amount of networking dedicated to exchanging know-howinfor-

mation anddiscussing waysto work withpeople inother teams (37% in E-SWE-1, 22% in E-SWE-2 and 17% in E-SWE-3). This mostlyhappens in disciplined forums asCoPs, and through per- sonallinks. One reasonfortheneed todiscussworkingmethods isthatthe processinformationisspreadacross multiplesystems.

This can be illustrated by the following quote: “… you often get [updates]inthemailandifyouarehappyorluckythentheyarealso updated on a webpageor a wikipage somewhere. It´sveryhard to [findtheinformation].”

Work-relatedknowledge coordination: Workcoordination oc- cupiedasubstantialpartofnetworkinginvolvingproductowners, otherteams,andinthecaseoftheChineseteams,systemanalysts whoworkoutsidetheteams(above20%infouroutofsixteams, andashighas46% inE-CHN-1).The coordination wasrelatedto requirements,technicalandmanagerialdependencies,anddeliver- ables. For example, several members from Team E-SWE-1 main- tainedlinks withthe supporting teams androles responsible for testingprocesses and toolsby reportingproblems, obtaining up- dates,andprovidingfeedbackonsolutions.TeamE-SWE-2 andE- CHN-3hadlesssuchnetworking (14%and4% respectively).Team E-SWE-2was workingtowards a specific customer andlesswith others,whileTeamE-CHN-3wasnewandthusworkedinrelative isolation.

4.3.ABBcasedescription

ABBis alarge internationalcompany developingcomplexem- bedded systems for powerand automation solutions. Systems in the safety-critical portfolio are developed following a traditional plan-driven software development methodology, in which pre- dictabilityandcontrolareimportant.

4.3.1. Studiedproject

Theprojectunderstudywasacomplexsoftware-intensivesys- tem containing a number of components consisting of many- millionlinesofcodewritteninseveralprogramminglanguages.At the time ofinvestigation, the system hadbeen evolvingfor over adecade.Inearly2014,theworkwasdistributedacrosstwosites inSwedenandonesiteinIndia,allbranchesofABB.TheSwedish site,referredtoasSweden1inthefindings,isresponsibleforthe product.Ingeneral, thereare sixsoftwareteams atthemainde- velopment site in Sweden (referred to as Sweden 1), a software teaminthesecondsiteinSweden(referredtoasSweden2),and agroupofdevelopersinIndia.BothSwedishsiteswereengagedin thesystemdevelopmentfromtheverybeginning,whiletheIndian sitejoinedin2006.

4.3.2. Developmentapproachandknowledgeneeds

AtABB,heavyemphasisisplacedonproductandprocessqual- ity, anda V-modeldevelopment methodology is put in practice, inwhichtasksarestructuredandprojectmembers’rolesaretask- specific.Developmentworkisorganizedinprojects,whichcanin- cludenewsystemgeneration,newfunctionalitydevelopment,roll- upsoflargemaintenanceprojects,andpuremaintenanceprojects.

The teams are disciplined teams comprised of programmers and led by a teamlead. Each teamspecializes in a particularpart of thesystem, i.e.,asystemcomponent. Agooddeveloperissaid to haveonlya50%overviewofthesystem.Onesystemarchitectsaid:

“Itrequiresatleast threeyearstogettoknowthecodebase.”Team membersmaybe involvedsimultaneouslyinseveralprojects.The teamresponsibleforthecorrespondingpartofthesystemusually fixesthebugs.However,locatingabuginthesystemcanbechal- lenging.Acomplextroublereportmayrequireaspecialtaskforce consistingof experts fromdifferent teams to locate the bugand fix it.This is mainly dueto the systemknowledge differentiated acrossmultipledisciplinedteams.

Table 6 Teams’ profiles.

Teams Location Team / group members

Expert in the team

Company experience (average)

Type of team Task familiarity

Task complexity

Approach to solving simple or familiar tasks

Approach to solving complex or unfamiliar tasks

Participation in forums and CoPs

A-SWE1-1 Sweden 1 5 No 8 years Disciplined component teams / group

Familiar Medium Org. capital Org. capital No

A-SWE1-2 Sweden 1 6 Yes 11.3 years Familiar Medium Social capital Social capital No

A-SWE2 Sweden 2 5 Yes 17.2 years Familiar Medium Org. capital Org. capital Seldom

A-IND India 18 Yes 4.6 years Unfamiliar Low Human capital Social capital No

ABB practices detailedup-front design in which onlyselected teammembersareinvolved,formingavirtualdesignteam.When thedevelopmentprojects start,thework isusually wellspecified andcoordinatedthroughteamleads, whofurtherassignthetasks toindividual team members. The role ofeach site isdetermined bythecomponentspecialization.Softwareprojectsareusuallyled fromSweden 1 (the main location), while hardwareprojects are led fromSweden 2.There are a number of senior developers in bothSwedishlocationswhoarefrequentlycontactedforconsulta- tion.Tosupportcross-sitecoordination,themostseniordevelopers inIndiahavebeenappointedastechnicalcoordinators.

4.3.3. Teamsandteamworkcharacteristics

In ABB, we studied three Swedish teams from two locations (Team A-SWE1-1, A-SWE1-2, and A-SWE2) and a large group of developers in India (A-IND).It is important to note that the In- dian group is not formed as a team, but rather as a working group. Therefore,the team-level findings from A-INDare not di- rectlycomparablewiththosefromtheteams.Theunitsstudiedin ABBareprofiledinTable6.

Experience: Developer experience at ABB differs across loca- tions:the company experience in Sweden is significantly higher thanthat in India(approx.8, 11, and17years on averageversus lessthan5years).

Tasks:Workorganizationwithintheteamsdiffers.InteamsA- SWE1-1 andA-SWE2, teammembers know acertain partofthe codeandusuallyonlyreceivetaskswithintheirownspecialization.

Redundantknowledgeintheseteamsisthereforerare,andcollab- orative development work is generally not common. In contrast, membersofTeam A-SWE1-2 areexpected tobe ableto workon diversetasks,andknowledgeredundancyisthereforebuiltinten- tionally.Thissubsequentlyrequiresmorecollaborationamongthe teammembers. Thecomplexity ofthe tasksassigned toSwedish teamsis perceived to be ofmedium difficulty andmost ofthese tasksarefamiliarfortheteams.

Indian developers are responsible for the development and maintenance oftwo types ofsoftware protocols that are respon- siblefor interaction between components; this work is regarded aslowcomplexity.Wealsolearnedthatsoftwareprotocolworkis quite isolated and requires only one or two developers per pro- tocol.Each protocol might be completely different,which means that the knowledge needed to develop a protocol is more spe- cializedandcannotbe fullyreusedorusefulforothers.However, welearnedthatdevelopersoftenchangedtheirspecialization,and knowledgeredundancywasbuiltintentionally,toprevent theloss ofknowledge dueto employee turnover.Giventhe frequent staff changes,theleveloffamiliaritywiththetaskswassaidtobelow.

Reliance: Duringthefocusgroups,welearnedthatwhensolv- ing complex tasks, the teams relied on a variety of strategies.

TeamsA-SWE1-1andA-SWE2primarilyreliedonthesourcecode and documentation, i.e., organizational capital, while Team A- SWE1-2andGroupA-INDreliedonteamworkandnetworking,i.e., socialcapital.Interestingly,mostIndiandevelopers perceivedthat theimportance ofsocial capitalgrowsasthe taskcomplexityin-

A-SWE2 A-SWE1-1 A-SWE1-2

A-IND

Fig. 3. ABB teams’ knowledge networks.

Table 7

Teams’ network characteristics.

Teams Team members Respondents External network size Total

Average per respondent

A-SWE1-1 5 5 19 6 .4

A-SWE1-2 6 4 23 7 .8

A-SWE2 5 5 28 5 .6

A-IND 18 12 14 1 .7

creases,admitting that simple tasks could be handled relying on theirownskills,i.e.,humancapital.

Participation inforums andCoPs:During theinterviews, we learned that there were no institutionalized regular meeting fo- rums fordevelopmentteams.However, Team A-SWE2 mentioned severalinterestgroups,e.g.,anarchitecture groupandstaticanal- ysisgroup,inwhichthoseinterestedoccasionallyorganizedsemi- narstodiscuss,e.g.,tools,tobeusedindevelopment.

The teamnetworksbasedon thesurvey datacan be foundin Fig.3,andnetworkcharacteristicsareinTable7.