Information & Management 52 (2015) 82–97

What drives knowledge sharing in software development teams:A literature review and classification framework

Shahla Ghobadi *

Australian School of Business, University of New South Wales, Sydney, NSW 2052, Australia

A R T I C L E I N F O

Article history:

Received 15 September 2013

Received in revised form 7 October 2014

Accepted 12 October 2014

Available online 22 October 2014

Keywords:

Software development

Software teams

Information system development

Knowledge sharing

Knowledge transfer

Literature review

A B S T R A C T

Although scholars have long studied knowledge sharing drivers within software development teams, our

knowledge remains fragmented by the divergent efforts that are based on and contribute to theoretical

perspectives. This study provides a review of the extant literature (1993–2011) on knowledge sharing

drivers in software teams and establishes a classification framework using an organizational change

perspective. A synthesis of the literature uncovers diverse themes and gaps in the existing body of

knowledge, suggests several paths for advancing theory on knowledge sharing in software development

contexts, and discusses implications for practitioners concerned with knowledge sharing in software

development.

� 2014 Elsevier B.V. All rights reserved.

Contents lists available at ScienceDirect

Information & Management

jo u rn al h om ep ag e: ww w.els evier .c o m/lo c ate / im

1. Introduction

Software development is a collaborative and knowledge-inten-sive process that requires the blending and interweaving of diverseknowledge dispersed across domains of specialization [72,81]. Theunique and inherent characteristics of software development signifythe importance of effective knowledge sharing, referring to the

exchange of task-related information, ideas, know-hows, and feedback

regarding software products and processes [19], in exploiting availableresources, addressing perceived challenges, and exploring emergingopportunities in software development and design [23,20,85]. Forexample, software, as a product, continuously emerges fromintensive and iterative development and quality assurance cyclesthat require rapid reflections and frequent introspections acrossteam members who represent different specializations, are oftendistributed, and may have opposing professional priorities[73,29,100,16]. Furthermore, from self-organizing open sourcecommunities [87] to distributed software development, which israpidly becoming a norm in software companies, effectiveknowledge sharing is necessary to allow team members to discusscritical aspects of projects and overcome the cultural and socialchallenges of coordinating work across distributed spaces [17].

* Current address: University of New South Wales, Sydney, NSW 2052, Australia.

Tel.: +61 2 9385 7130; fax: +61 2 9662 4061.

E-mail address: s.ghobadi@unsw.edu.au

http://dx.doi.org/10.1016/j.im.2014.10.008

0378-7206/� 2014 Elsevier B.V. All rights reserved.

Nonetheless, several challenges may complicate knowledgesharing in software development teams [84,14]. For example,managing the diverse social identities and cross-functionality ofteam members [28,15], overcoming coordination challengesacross distributed sites [17], creating homogeneous teams witha shared understanding [67] and motivating stakeholders to shareembedded knowledge with development teams [18] can bechallenging. Although technological solutions such as compo-nent-based development have been designed to facilitate rapiddevelopment and reduce the need for communication [50],research suggests that they have even exacerbated the need forknowledge sharing; for example, achieving ideal levels ofcomponent reuse requires developers to effectively share theirknowledge of different components that they have developed andused [50].

Accordingly, researchers have studied knowledge sharingdrivers in software teams (factors that drive the exchange of task-

related information, ideas, know-hows, and feedback regarding

products and processes) to propose effective ways of facilitatingknowledge sharing within these contexts [100,15,61,30]. Forexample, Kotlarski and Oshri [49] emphasize the role of human-related issues, such as ‘rapport’ and ‘transactive memory’, indriving knowledge sharing within globally distributed softwareprojects, Joshi et al. [45] employ a connectionist epistemologicalperspective and show the crucial role of ‘source credibility’ and‘extent of communication’ in shaping knowledge transfer.

S. Ghobadi / Information & Management 52 (2015) 82–97 83

Exploring the role of transactive memory in distributed softwareteams, Oshri et al. [70] suggest that the ‘standardization oftemplates and methodologies across remote sites’, ‘frequentteleconferencing sessions’ and ‘occasional short visits’ supportknowledge transfer. Pee et al. [73] use the lens of socialinterdependence theory to explain how goal, task, and rewardinterdependencies shape knowledge sharing between businessand external IT consultant subgroups. Building on Pee et al.’s study,Ghobadi and D’Ambra [30] describe the dynamics through whichinterdependencies, including ‘outcomes’ (goals, rewards), ‘means’(task-related), and ‘boundary’ (friendship, sense of identity,geographical closeness), interact and drive simultaneously coop-erative and competitive behaviors, which in turn shape high-quality knowledge sharing in multi-party software teams.

Despite the valuable findings of previous studies, our under-standing of this phenomenon is still emerging, and research isfragmented with limited integrated efforts that are based on andcontributing to rich and rigorous theoretical perspectives. Forexample, whilst studies point to knowledge sharing drivers insoftware development teams [100,16,49,70], their focus is limitedto examining a small and selected set of drivers; for instance, Chouand He [16] show the effect of ‘open source software values andnorms’ on collaborative knowledge sharing in open sourcesoftware teams, and Joshi et al. [45] highlight the importance ofa ‘source’s credibility’ and ‘extent of communication’ in shapingknowledge sharing practices. Furthermore, several researcharticles use terms such as ‘participation’ [2,5], ‘requirementgathering’ [34,33], ‘activity engagement’ [35], and ‘sense giving’[90] to refer to the exchange of task-related information, ideas,know-hows, and feedback regarding software products andprocesses (knowledge sharing); for example, ‘participation’ and‘activity engagement’ are used to refer to assisting others byanswering their questions [5] and contributing to mailing lists invirtual open source development teams [35], and ‘requirementgathering’ has been reported as the process through which usersshare business and technical knowledge along with ‘what theywant from the product’ with a development team [33]. In addition,researchers diverge in their underlying assumptions and researchterminologies when studying knowledge sharing in softwaredevelopment teams, and consequently, a clear consensus inconceptualizations and findings has not been realized; e.g., theterm ‘knowledge transfer’, which is primarily concerned with theinternalization of the shared knowledge [45], is also used to refer tothe simple sharing of knowledge [91,3,32].

Despite the importance of the subject, no research bridgesmultiple views and integrates existing findings into a comprehen-sive framework for researching and managing knowledge sharingdrivers in software development teams. Although systematicliterature reviews on the general aspects of knowledge manage-ment in software engineering exist [11], the lack of a focused

Fig. 1. Methodolo

review on knowledge sharing drivers within software teams andthe paucity of efforts to integrate the existing fragmentedknowledge complicate the prospect of understanding the currentstate of research and a continued discussion on the topic.

This study therefore aims to integrate existing findings,improve our understanding of the phenomenon of knowledgesharing in software development teams, and guide future researchin this area. For this, a synthesis of the predominant literature withthe following two research objectives is undertaken: (i) to identifypatterns that emerge from previous research on knowledgesharing drivers in software development teams and (ii) to studythe reported knowledge sharing drivers and integrate them into aframework that provides a rich picture of knowledge sharingdrivers in software teams and facilitates studying knowledgesharing in software development contexts. To address the researchobjectives, the following steps are followed: (i) the existingliterature is reviewed through the guidance of the followingresearch question, what drives knowledge sharing in software

development teams?, (ii) the contexts and terminologies referringto knowledge sharing and the employed research methodologiesare extracted and analyzed, (iii) the reported knowledge sharingdrivers are consolidated, classified and integrated into a classifica-tion framework, and (iv) the themes and gaps in the existing bodyof knowledge are highlighted, and avenues for future research arediscussed. The remainder of the paper is structured as follows.Section 2 details the research methodology. Sections 3–5 elucidatethe results of the literature review and synthesis and present theclassification framework. Research and practical implications arediscussed in Section 6, prior to outlining final remarks and researchlimitations in Section 7.

2. Research method

Fig. 1 demonstrates the three methodological phases along withtheir relevant steps. Based on the systematic mapping method[76,6], which focuses on categorizing the research phenomenonunder investigation and visualizing findings into a structuredframework, the methodology consists of three major phases,including: (i) planning the study, (ii) conducting the study, and (iii)reporting the review. Sections 3–5 explain each of the three phases,supplemented by a detailed discussion of the results and avenuesfor future research in Sections 6 and 7.

3. Phase 1: planning the study

The first and second steps in ‘planning the study’ involved‘identifying the need and rationale for the study’ and ‘formulatingthe research question’. The third step was the ‘development of areview protocol’ to guide the review; for this, an initial reviewprotocol was written and then was revisited and improved by two

gical phases.

S. Ghobadi / Information & Management 52 (2015) 82–9784

experienced researchers in the knowledge management andsoftware engineering fields. The protocol explicated and docu-mented the following items: (i) the need and rationale for thestudy and the research question (discussed in Section 1), (ii) thestrategy for searching primary studies, (iii) the selection proce-dures and quality assessment criteria, (iv) the data extractionpolicies and procedures, and (v) the data classification strategy.(These items are reflected in the following sections.)

4. Phase 2: conducting the study

4.1. Identification of research

The first step in ‘conducting the study’ involved the ‘identifica-tion of research’ (Fig. 1). Scopus (officially named as SciVerseScopus) was selected as the resource for the research because (i) itis the largest abstract and citation scientific database of peer-reviewed research literature1 [22] and (ii) it has been used as amajor search source in some key software engineering systematicreviews [47].

To establish the boundaries of what would be considered in thereview, the phenomenon of interest was defined as ‘research that

investigates knowledge sharing drivers in software development

teams’. To match this definition with the published research andaddress literature diversity in studying knowledge sharing, aninitial list of search keywords was developed by consulting fiveexperts in knowledge management, software development, andsystematic literature reviews. In addition, snowball sampling(finding relevant papers, checking their reference lists) was used tofurther investigate how knowledge sharing in software teams isreferred to in prior research, and this resulted in identifyingadditional keywords (e.g., data exchange, exchange of data).

4.2. Selection of primary studies

The second step in ‘conducting the study’ was the ‘selection ofprimary studies’ for the literature review. Two iterations werefollowed, including: (i) searching the literature using 29 keywordsin Scopus (the titles, keywords, and the abstracts) and identifyingrelevant papers; the keywords were (‘‘software engineering’’ OR

‘‘software development’’ OR ‘‘information system development’’ OR

‘‘system development’’) AND (‘‘Group’’ OR ‘‘project’’ OR ‘‘team’’) AND

(‘‘Knowledge transfer’’ OR ‘‘transfer of knowledge’’ OR ‘‘knowledge

exchange’’ OR ‘‘exchange of knowledge’’ OR ‘‘knowledge sharing’’ OR

‘‘knowledge share’’ OR ‘‘share of knowledge’’ OR ‘‘information

transfer’’ OR ‘‘transfer of information’’ OR ‘‘information exchange’’OR ‘‘exchange of information’’ OR ‘‘information sharing’’ OR

‘‘information share’’ OR ‘‘share of information’’ OR ‘‘data transfer’’OR ‘‘transfer of data’’ OR ‘‘data exchange’’ OR ‘‘exchange of data’’ OR

‘‘data sharing’’ OR ‘‘data share’’ OR ‘‘share of data’’) AND

(1993 < PUBYEAR < 2012), and (ii) examining the reference listof the identified papers and including additional papers.

Each iteration involved four stages, including: (i) excludingstudies based on the ‘title’ examination, (ii) excluding studiesbased on reviewing their ‘abstract’, (iii) excluding studies that didnot provide ‘empirical evidence’, and (iv) excluding studies basedon examining their ‘full text’. The criteria to be included in thestudy were: (i) Studies should have been published between Jan

1993 and Dec 2011 (including these dates), (ii) Studies should have

been published in the English language, and (iii) The main objective of

the study should have been investigating knowledge sharing drivers

within software teams; the papers in which knowledge sharing wasa peripheral (e.g., knowledge sharing was only briefly mentioned,

1 Scopus coverage details are available here: http://www.info.sciverse.com/

scopus/scopus-in-detail/content-coverage-guide/sourcetypes.

or it was just one of the numerous factors in the study), rather thanthe focal focus of the study, were excluded; this criterion wasconsidered to focus the review on the most relevant findings ratherthan including any publication that briefly ‘refers to’ or ‘suggests’knowledge sharing drivers. In addition, a liberal approach to howwe understand software teams was adopted, e.g., by includingpapers that study the teamwork aspects of virtual open sourcesoftware development (e.g., [35]), and (iv) Studies should have

provided empirical evidence of knowledge sharing drivers; thiscriterion was considered to improve reliability of the synthesizedfindings by limiting the review to empirically supported results.

In the first iteration, searching the aforementioned 29 keywordsin Scopus resulted in identifying an initial list of 3129 papers.Examining the title, abstract, empirical evidence, and the fullcontent of the identified papers resulted in excluding 1495 studiesbased on reviewing their titles, 1318 studies based on reading theirabstracts, 199 studies based on providing empirical evidence, and81 studies based on reading the full texts. In total, 36 papers wereselected in the first iteration. In the second iteration, the referencesof the identified 36 papers were examined against the selectioncriteria, and this resulted in including additional 13 papers.Altogether, 49 papers (36 + 13) were selected (listed in Table 2).

4.3. Data extraction

The third step in ‘conducting the study’ was extracting datafrom the 49 papers. The following items were extracted: (i)demographics of the study (year of publication, source name (e.g.,name of the journal), and author(s)’ details), (ii) knowledge sharing

context (e.g., enterprise information systems development, opensource, distributed software development, agile development, pairprogramming), (iii) terminology used for referring to knowledge

sharing (e.g., knowledge transfer, knowledge sharing, knowledgeflow, participation, exchange of ideas, gift giving, requirementgathering, communication, externalization, knowledge diffusion),(iv) research methodologies (e.g., case study, survey, longitudinal,experiments, mixed methods), and (v) knowledge sharing drivers

(e.g., motivational factors, organizational factors) and the reported

causal links between them (if any). The detailed results are providedin Section 5.

The extracted knowledge sharing drivers were carefully studiedto distil possible overlaps and merge related drivers. For example,the following drivers (contract persons, power users, programmanagers, knowledge brokers) were noted to be related to‘representative roles’ that may facilitate knowledge sharing withinsoftware teams’. Therefore, they were merged into one driver(‘Assignment of Representative Roles’); specifically, identifying‘contact persons’ was defined as selecting key representatives fromvendor personnel to provide continuity in communication andworking relationships [32], selecting ‘power users’ was aboutchoosing user representatives that work with development teams,get trained, and then share their updated knowledge with otherusers [91], assigning ‘program managers’ was about creating newroles that are aware of new components being developed for aspecific customer and facilitate sharing knowledge and the reuse ofcomponents across geographical implementations [50], andcreating ‘knowledge brokers’ was about assigning roles that bridgeand facilitate communication and fill the structural holes in socialnetworks [12]. These processes resulted in a consolidated list of44 knowledge sharing drivers; each of them is introduced andexplained in Section 5.

4.4. Developing the classification framework

The fourth step in ‘conducting the review’ involved ‘developingthe classification framework’ based on the 44 knowledge sharing

S. Ghobadi / Information & Management 52 (2015) 82–97 85

drivers. First, Leavitt’s organizational model [54] was chosen as theclassification scheme. Having roots in organizational changetheory, Leavitt’s organizational model [54] views organizationalsystems as multivariate systems of four interacting components,including actors, structure, tasks, structure, and technology[54,59]. Leavitt’s model is considered a solid theoretical foundationthat is simple, comprehensive, and anchored in theory [59], and ithas been utilized to synthesize organizational dynamics [54]. Forexample, IS researchers have employed the model to define andcategorize software development risks, arguing that the fourdimensions of Leavitt’s model can cover the key aspects of softwaredevelopment processes [75,60]. Specifically, (i) actors (people) cancover users, managers, developers, and other key stakeholders ofthe project, (ii) structure can represent project organization andinstitutional setting issues within software projects, (iii) tasks cancover the risks, nature and type of activities within softwareprojects, and (iv) technology can include development methods,tools, hardware, and software platforms for the final software.Based on its merits (a solid theoretical foundation and compre-hensiveness in studying software processes), Leavitt’s model canbe used to define the foci of knowledge sharing drivers areas insoftware teams. The application of Leavitt’s model is also useful toknowledge management literature. Specifically, although someknowledge management studies have reviewed the extantliterature to classify knowledge sharing drivers and provide abigger picture of knowledge sharing drivers, they define theircategories based on the similarity of concepts or constructs ratherthan approaching classification on the basis on a robust theoreticallogic; for example, Wang and NOE [94] identify 28 knowledgesharing drivers and classify them into four categories, motivation-related, individual-related, perceptions-related, and environment-related, and Riege [78] draws attention into 36 barriers toknowledge sharing and classifies them into individual, organiza-tional, and technological barriers.

Second, to classify knowledge sharing drivers, three steps werefollowed. First, each of the 44 knowledge sharing drivers wasexamined against the definition of the four components in Leavitt’smodel and then was assigned to the relevant categories of people,structure, tasks, and technology (Leavitt’s model). Two experts inthe area of software development and knowledge managementwere consulted. For example, ‘team subcultures’ is related to thediversity of stakeholders, and thus, it is linked to ‘people’ inLeavitt’s model; the ‘relocation of members between remote sites’is concerned with how team members are organized to workcollaboratively, and thus, it is linked to ‘structure’ in Leavitt’smodel. The constant comparison between drivers and categorieshelped determine whether the classification model supports andcontinues to support the emerging concepts and categories[83,36]. Confirming the adequacy of Leavitt’ model, the 44 driverswere classified into four categories: people-related (involving21 drivers), structure-related (involving 16 drivers), task-related(involving 3 drivers), and technology-related drivers (involving4 drivers). Second, along with experts and through an iterativeprocess, which examined the definition of each category and eachdriver and the similarity between drivers, seven subcategorieswere defined. Finally, based on a careful comparison between thedefinitions of each driver and each subcategory, the 44 driverswere assigned to relevant subcategories.

Third, the results were integrated into a classification frame-work and then presented to a group of 10 professionals over a 2 hfocus group session. The professionals represented different roles:developer, tester, project manager, and business analyst. On thebasis of their experience in software development, they were askedto make sense of the classifications and suggest improvements tothe framework. Additionally, six in-depth evaluation sessionsinvolving two project managers, two developers, one tester and

one user interface designer were conducted. Participants wereasked to make sense of and apply the classification framework toan ongoing project and to provide feedback and suggestions ontheir logic and applicability [82]. Overall, the focus group andinterview sessions resulted in some refinements to the frameworkto increase clarity and improve understanding. For example,‘collaboration technologies’ was initially under the category ofstructure-related drivers; however, professionals referred to thedefinitions of categories and considered it a technology-relateddriver (technology can include development methods, tools, hard-

ware, and software platforms for the final software). Additionally,although ‘project methodology’ was initially part of task-relateddrivers, the focus group argued that it is related to technology-related drivers. Such improvements enhanced the conciseness ofthe classification framework by ensuring that the 44 knowledgesharing drivers were placed in the most appropriate subcategory.The evaluation was terminated after six evaluation sessionsbecause the fourth and fifth sessions led to only minor changes,and the final classifications were found to be logical, easy tounderstand, and useful for understanding knowledge sharing insoftware development teams.

Finally, the reported causal links between knowledge sharingdrivers were mapped at the category level and incorporated into aclassification framework (Fig. 4). For example, different nationalcultures within the team may highlight and even exacerbate thedifferences between individuals and, in turn, diminish teammembers’ motivation to interact frequently [26]. Cultural differ-ences, a ‘team heterogeneity’ driver, is under the subcategory of‘diversity-related drivers’ and the ‘people-related’ category.Frequent interaction falls under the subcategory of ‘organizationalpractices drivers’ and the ‘structure-related’ category; as a result, acausal link between ‘people-related’ and ‘structure-related’ driversis established in the classification framework.

5. Phase 3: reporting the review

5.1. Results of theme analysis (Contexts, Terminologies and

Methodologies)

The first step in ‘reporting the review’ explains the majorobserved themes in the extant literature.

In terms of contexts, most of the reviewed studies investigated‘offshore or globally distributed software teams’ (35%; 17 papers)[49] (with an emerging theme focusing on client/vendor-vendorknowledge sharing relationships [86]). This is followed by focusingon ‘general software development’ (29%; 14 papers; where papers

do not highlight any specific practice such as virtual development,

open source or agile development) [33], and ‘open source develop-ment’ (16%; 8 papers) [5]. The rest of the papers (20%) reportcontexts such as ‘agile development’ [64], ‘pair programming’ [8],‘in-house software development’ [95], and ‘enterprise systemdevelopment’ [91].

In terms of knowledge sharing terminologies, ‘knowledgesharing’ is the most dominant reported term (39%; 19 papers)[96,40], followed by ‘knowledge transfer’ (20%; 10 papers)[84,45,86]. Whereas knowledge sharing (externalization ap-proach) is concerned with the extent of sharing knowledge,knowledge transfer (internalization approach) refers to a dyadicexchange where the recipient is affected by the experience of thesource [84,91]. Researchers following the internalization approachacknowledge that although knowledge must be shared, it mustalso be interpreted, internalized and then created by knowledgerecipients to become an integrated part of a synergic solution[56,1]. Although the review reflects an overall awareness regardingknowledge sharing and knowledge transfer terminologies (e.g.,[43]), these terms are used interchangeably; e.g., the term

S. Ghobadi / Information & Management 52 (2015) 82–9786

‘knowledge transfer’ is used to refer to the simple sharing ofknowledge [91,3,32]. Few studies (14%; 7 papers), primarily in thearea of open source development, use terms such as ‘participation’(3 papers) [2,5], ‘contribution’ (e.g., contributing code; 3 papers)[35,92], gift giving (1 paper) [10], and ‘fractal cubic distribution’(1 paper) [87]. Although some of these terms (e.g., participation)may initially seem to be irrelevant, close attention to theirreportage suggests that they refer to the exchange of task-relatedinformation, ideas, know-hows, and feedback (definition ofknowledge sharing); for example, participation is defined asproviding and obtaining information about the group andcontributing to discussions [2], ‘contribution (activity engage-ment)’ refers to assisting others by answering their questions [5]and contributing to mailing lists [35], and ‘fractal cubic distribu-tion’ refers to a peak period when knowledge sharing is veryintensive, followed by a period of ‘silence’ when knowledgesharing is less intensive. In general, the review suggests that theproliferation of open source development has given rise to newterms such as gift giving, participation, contributing code andjoining script, reflecting the contemporary aspects of softwaredevelopment practices. The rest (26%; 13 papers) use their ownspecific terms, such as ‘requirement gathering’ [34,33], ‘explicitand implicit knowledge sharing’ [102], ‘knowledge flow’ [65],‘knowledge distribution’ [4], ‘knowledge externalization’ [38],‘activity engagement’ [35], ‘knowledge withholding’ [57], ‘com-munication’, and ‘sense giving/sense breaking’ [90]. For example,‘requirement gathering’ is reported as the process through whichusers share their business and technical knowledge along with‘what they want from the product’ with a development team [33],‘knowledge withholding’ refers to when individuals share less andcontribute less effort in sharing knowledge [57], and ‘promotiveinteraction’ draws attention to practices through which teammembers teach each other the knowledge that is necessary tocollectively achieve goals and maximize team performance [44].

In terms of research methodologies, 27 papers (55%) employqualitative case studies (out of which 6 have a longitudinal focus[40]), and 15 papers (31%) use a quantitative survey (out of which3 take a longitudinal approach [52]). General software develop-ment and offshore system development studies primarily focus onqualitative investigations [68]; however, mixed methods [43,4]and experiments [8,9] are also employed, e.g., to observeknowledge sharing behaviors among components of pair pro-gramming teams. In contrast, open source literature primarilytakes a quantitative approach by using surveys and mailing lists/post observations over time [10]. Despite taking differentapproaches and using diverse measures, quantitative studies haveattempted to operationalize knowledge sharing behaviors[84,45,2,5,102,38,80,39,74]. For example, some studies operatio-nalize knowledge transfer to measure ‘to what extent individualshave learned about technical and managerial/behavioral projectissues from other team members’ [45], some focus on the extent towhich knowledge such as meeting notes, ideas and know-howswas shared [73,102], some examine the levels of knowledgewithholding by team members [57], and some analyze the postingand replying activities of virtual team members by counting thenumber of messages they posted to mailing lists and the number ofreplies they made to others’ questions [87].

5.2. Classification

The identified knowledge sharing drivers are classified into fourmajor categories (people-related, structure-related, task-related, and

technology-related) and seven specific subcategories. The subca-tegories include: (i) diversity-related drivers, which refer to team’sdiversity-related drivers, such as skills-related, geographical, andtime-related drivers, that may affect knowledge sharing, (ii)

capability-related drivers, which refer to team members’ knowl-edge, skills, experience and background, which collectivelycontribute to a team’s capability and may drive knowledgesharing, (iii) team perceptions drivers, which refer to the percep-tions, attitudes and values of team members that may driveknowledge sharing, (iv) team organization drivers, which refer toaspects of the team organization and conduct of the project thatmay drive knowledge sharing, (v) organizational practices drivers,which refer to existing organizational norms, communicationnetworks, and practices that may drive knowledge sharing, (vi)task-related drivers, which refer to contextual and task-relatedissues that may drive knowledge sharing, and (vii) technology-

related drivers, which refer to technological factors such astemplates, tools, and methodologies that may drive knowledgesharing. Table 1 outlines each of the categories, subcategories,related drivers, definitions, sources, and a sample quote showinghow each driver is related to knowledge sharing.

Furthermore, Table 2 shows a conceptual matrix that relateseach of the 49 papers to the seven subcategories.

Fig. 2 provides a sense of how much emphasis is given to eachdriver by showing the breakdown of the frequency of citations foreach driver. The two top cited drivers (marked as a highlightedcircles in Fig. 2) are ‘collaborative technologies’ (technology-related;14 times) and ‘team heterogeneity’ (diversity-related; 11 times).Within each subcategory, the most cited knowledge sharingdrivers are marked in Fig. 2 and include: ‘team heterogeneity’(diversity-related), ‘communicator’s capability’ (capability-related),‘extrinsic motives’ (team perceptions), ‘assignment of representative

roles’ (team organization), ‘face-to-face interactions’ (organizationalpractices), ‘project knowledge’ (task-related), and ‘collaborative

technologies’ (technology-related).Fig. 3 aggregates these results and provides the breakdown of

the frequency of citations for each subcategory. The top citedsubcategories are ‘team perceptions drivers’ (30 times), ‘organiza-

tional practices drivers’ (24 times), and ‘technology-related drivers’

(20 times), and the least cited subcategory is ‘task-related drivers’

(8 times), followed by ‘capability-related drivers’ (12 times). Thesubcategories with the highest number of drivers include ‘team

perceptions drivers’ (14 drivers) and ‘team organization drivers’(10 drivers), whereas the subcategories with the lowest number ofdrivers are ‘diversity-related drivers’ (2 drivers), ‘task-related drivers’(3 drivers) and ‘technology-related drivers’ (4 drivers).

Figs. 2 and 3 suggest that: (i) The reviewed literature has largelyfocused on exploring new team perceptions drivers (14 drivers)and organizational practices drivers (10 drivers) and has paidconsiderably less attention to identifying various aspects of projecttechnology (technology-related drivers; 4 drivers) and project tasks(task-related drivers; 3 drivers), (ii) despite focusing on only fourtechnology-related drivers, the role of collaborative technologies iswell-cited (the top cited driver; 14 citations), and this hasimproved the citations of the technology-related subcategory(20 citations), (iii) despite studying only 2 drivers within thediversity-related subcategory, these drivers are well-cited (17 cita-tions), and (iv) the task-related subcategory has the lowest numberof citations (8 times) and the lowest number of drivers. Theseresults are discussed in Section 6 in detail.

In addition, a closer look at the reviewed papers indicates thatcertain drivers are emphasized in specific contexts. Morespecifically, the importance of motivation-related drivers, bothintrinsic and extrinsic motives, is pronounced in open sourcevirtual teams [52,53], whereas globally distributed softwaredevelopment literature focuses on the role of organizationalpractices, such as collaborative technologies and the assignment ofrepresentative roles in addressing the challenges associated withteam heterogeneity (e.g., different national cultures) and geo-graphical distribution [34,68].

Table 1Categories, subcategories, drivers, sources, sample quotes.

Driver Studies Sample quote

People-related drivers (21 drivers)

Diversity-related drivers (2 drivers; 17 times citations) refer to team’s diversity-related drivers, such as skills-related, geographical, and time-related drivers,

that may affect knowledge sharing.

Team Heterogeneity refers to the degree

of dispersion among team members in

terms of their demographic

characteristics, experiences, skills,

cognitions, and values.

[86]

[32,7]

[34,12]

[84,9]

[8,68]

[2,40]

the Indian staff also found it difficult to understand the strong English accents. As a result, . . ., the

Indian staff refused to openly contradict one another or their manager [sharing information] [68] In

Information and Organization

Geographical Distribution refers to the

diversity of team members in terms of

being located in different physical

spaces.

[34,77]

[12,26]

[68,21]

This article focused on . . . difficulties in knowledge sharing due to physical distance. The solution of

the article is to have regular communication between the onshore and offshore site to make transfer

of knowledge easier [26] In International Journal of Computer Applications

Capability-related drivers (5 drivers; 12 citations) refer to team members’ knowledge, skills, experience and background, collectively contributing to teams’

capability, which may drive knowledge sharing.

Communicator’s Credibility refers to

the trustworthiness and reputation of

the communicator.

[84,45] the credibility of the communicator [was] found to significantly predict the extent of knowledge

transferred [84] In IEEE Transactions on Professional Communication

Communicator’s Capability reflects the

communicator’s capability in terms of

project skills, technical ability, project

management ability, and cultural

competency.

[32,86]

[87,68]

[92,93]

Feature gifts by newcomers are related to their specialization in open source software projects [92]

In Research Policy

Knowledge Recipient’s Starting Conditions

refer to knowledge receiver’s mindset

and level of knowledge.

[86] There was already an existing client-vendor relationship between the bank and each of the vendors

before the project started. Accordingly, as the project started, there was no significant need for the

transfer of functional and process knowledge from the client to the vendors, as this knowledge has

already been built up over years [86] In Pacific Asia Conference on Information Systems

Duration of team membership refers to

the length of the time that team

members have been part of the team.

[87] Dominant repliers [information sharing] tend to be long-term members of the community [87] In

Journal of Systems and Software

Transactive Memory is defined as the set

of knowledge possessed by a group

regarding an awareness of who knows

what.

[70,90] These mechanisms contributed to the development of the notion of ‘who knows what’ [transactive

memory] across onsite and offshore teams despite the challenges associated with globally

distributed teams, and supported the transfer of knowledge between onsite and offshore teams [70]

In Information Systems Journal

Team perceptions drivers (14 drivers; 30 citations) refer to the perceptions, attitudes and values of team members that may drive knowledge sharing.

Sense of Identity is defined by the

identification of team members to

in-group relationships.

[5,35] Participants’ engagement [in terms of sharing knowledge] was particularly determined by their

identification as a Linux developer [35] In Research policy

Project Commitment refers to the extent

to which individuals experience

affective involvement with the project,

the team, and the overall organization.

[102,4]

[5]

Project commitment was found to be significantly related to explicit knowledge sharing [102] In

IEEE Transactions on Engineering Management

Need to Become Part of the Group refers

to the desire of individuals to feel

part of the team.

[92] the transition from ‘‘joiner’’ to ‘‘newcomer’’ [information sharing] occurs when the joiner is given

CVS access and makes a first contribution to the software [92] In Research Policy

Extrinsic Motives refer to perceived

extrinsic reasons (such as signaling

competence, finding power over the

code, and getting future support) that

encourage team members to share

knowledge.

[4,80]

[21,71]

[10,53]

[2]

Open source software development relies on gift giving as a way of getting new ideas and

prototypes out into circulation. This also implies that the giver gets power from giving away [10] In

Information Systems Journal

Intrinsic Motives refer to perceived

intrinsic benefits (such as self-learning

and intellectual stimulation derived

from sharing code) that encourage

team members to share knowledge.

[57,53]

[35,52]

We also find that, when we partition the help system into its component tasks, 98% of the effort

expended by information providers in fact returns direct learning benefits to those providers. This

finding considerably reduces the puzzle of why information providers are willing to perform this

task ‘‘for free’’ [52] In Research Policy

Distributive Justice is defined as the

perceived fairness of organizational

rewards that an employee may receive.

[57] The results indicated that KW [knowledge withhold] is influenced by distributive justice in the

environmental dimensions [57] In Information & Management

Clarity of the Reward System reflects the

degree to which organizational

incentives for sharing knowledge were

clarified for and understood by team

members.

[71] Incentives to sharing knowledge among the OSC CAS stakeholders, however, were made clear to all

participants and consistently supported [71] In Information Technology and Management

Perceived Subjective Leadership Style

refers to the perception of team

members regarding the style of

leadership in working with various

sub-groups.

[7] Dr Prava was perceived to rely heavily on the most experienced Indian technical team leader. This

served to accentuate the privileging of technical knowledge and left the Jamaican members with

little room to influence the development process [7] In Human Relations

Trust refers to the willingness of a person

to relate to another, believing that the

other’s action will be beneficial rather

than detrimental, even though this

cannot be guaranteed.

[102,57]

[71]

Trust was found to be significantly related to both tacit and explicit knowledge sharing [102] In IEEE

Transactions on Engineering Management

S. Ghobadi / Information & Management 52 (2015) 82–97 87

Table 1 (Continued )

Driver Studies Sample quote

Interdependencies refer to the degree to

which team members depend on each

other for completing their tasks and

the degree to which they perceive that

their outcomes (goals and rewards) are

interdependent.

[73,4]

[91]

We found that perceived goal, task, and reward interdependencies are significantly related to

knowledge sharing between the subgroups [73] In Journal of Association for Information Systems

Anticipated Emotions and Attitudes refer to

forward-looking affective reactions,

when the person imagines the

emotional consequences of sharing or

not sharing knowledge.

Perceived Behavioral Control reflects

member’s perception of control over

his/her actions.

[5] We found that attitudes . . ., perceived behavioral control . . ., and negative anticipated emotions

(y = 0.15, SE = 0.04) were all significant predictors of we-intentions to participate and share

information [5] In Management Science

Perceived Indispensability reflects the

perceived importance of one’s own

contributions for the team outcome.

[57] Activities in these teams [in terms of sharing information] were particularly determined by

participants’ evaluation of the team goals as well as by their perceived indispensability [35] In

Research policy

Participants’ Evaluation of Team Goals

refers to people’s subjective evaluation

of goals in terms of how achieving

collective goals is important to them.

[35]

Structure-related drivers (16 drivers)

Team organization drivers (6 drivers; 13 citations) refer to aspects of the team organization and conduct of the project that may drive knowledge sharing.

Relocation of Members between Remote

Sites refers to changes in a team’s

structure in terms of members’

assignments into different work

environments.

[69] The relocation of experts between remote sites served also as a mechanism that accelerated the

sharing of knowledge and technical expertise of the Maui platform [69] In Journal of Strategic

Information Systems

Definitional Control refers to the

organizational dominance that

particular people may get through

defining new practices (e.g., imposing

the use of particular boundary objects).

[7] we found that the use of boundary objects [discussed in the technology-related drivers] at

transitions involving definitional control and the subsequent redistribution of power/authority may

inhibit knowledge sharing [7]. In Human Relations

Remote Leadership refers to the

organizational structure in which the

project is being managed and

implemented remotely.

[95] A persistent difficulty which project members had to cope with was the fact that a large part of the

program was being built by outside contractors . . . the patterns of role re-adjustment and

‘knowledge sharing’ described earlier, were not possible outside of the project because the external

contractors were physically remote and communication channels were severely limited [95] In

International Journal of Human-Computer Studies

Temporal Restructuring of Team Members

refers to occasional organizational

changes in the normal activities of

team members.

[32,95] if demands could still not be met, analysts were seconded to help out with the work of other teams

when and where necessary . . . the temporary restructuring of teams also facilitated the

achievement of a ‘shared understanding’ [though sharing knowledge] of the program [95] In

International Journal of Human-Computer Studies

Clients’ Embedment refers to the extent to

which client’s views and feedback are

incorporated and organized in

development processes.

[98] We find client–vendor knowledge transfer to the offshore vendor engineer to be positively

associated with . . . client embedment [98] In Information Systems Journal

Assignment of Representative Roles refers

to the allocation of specific people

whose role is to facilitate knowledge

sharing.

[32,12]

[50,69]

[91]

[95,68]

contact persons were the main contact points within the team and they ensured the smooth flow of

information between dispersed teams and, as a result, facilitated knowledge-sharing processes

between the Head OYce in Walldorf and remote sites [69] In Journal of Strategic Information Systems.

Organizational practices drivers (10 drivers; 24 citations) refer to existing organizational norms, communication networks, and practices that may drive knowledge

sharing.

Organizational Culture refers to the

overall organizational culture with

regard to sharing ideas and thoughts.

[12,43] The study concluded that a fear based culture is not likely to produce an atmosphere in which

[information on] doubts can be mentioned and problems discussed [43] In International Journal of

Project Management

Power User CoP (communities of practice)

refer to established communities of

practice that bridge the thoughts and

ideas of the user community and thus

support and encourage knowledge

sharing among them.

[91] we observed two emergent structures, a power user CoP and a bridge between the ES team and the

user community [share task; discussed in the next section]. These two structures are organizational

forms that support power users as a KT [knowledge transfer] mechanism [91] In Journal of Strategic

Information Systems

Informal Networks refer to gatherings or

networks that allow informal

interaction between people.

[32,12]

[68]

These events [informal gatherings] helped to legitimize informality, to nurture ‘‘questioning

behavior’’ irrespective of hierarchies, and enable information sharing through personal and

informal networks even outside the work place and time settings [68] In Information and

Organization

Frequent Communication refers to

frequent communication practices

between team members.

[3,32]

[84,45]

The volume of communication, . . . [was] found to significantly predict the extent of knowledge

transferred [84] In IEEE Transactions on Professional Communication

Face-to-Face Interactions refer to

communication practices through

face-to-face channels.

[70,32]

[64,93]

[69]

Face-to-face channels offer the prospect of richer communication because of the ability to transmit

multiple cues [and embedded knowledge] [64] In Agile Development Conference

Formal Training for Clients refers to

organized training sessions for

improving client’s understanding of

different aspects of development

processes.

[98] We find client–vendor knowledge transfer to the offshore vendor engineer to be positively

associated with formal training [98] In Information Systems Journal

S. Ghobadi / Information & Management 52 (2015) 82–9788

Table 1 (Continued )

Driver Studies Sample quote

Established Practices for Communication

refer to routine organizational

practices that are in place to bridge

boundaries and facilitate knowledge

sharing across team members and

organizations.

[73,32]

[95]

established organizational practices such as regular meetings involving management, team leaders

and other project members allowed the sharing of knowledge and information [95] In International

Journal of Human-Computer Studies

Organizational Design refers to

established organizational rules and

procedures for communication.

[21,51]

[93]

Organization design mechanisms facilitate knowledge flows by providing a structure through

which knowledge workers can channel their expertise . . . Organization design clarifies who is

supposed to know what and who is supposed to communicate with whom. It therefore economizes

knowledge flows [51] In Information & Management.

Project Screening refers to the

organizational practice of screening

and prioritizing projects in terms of

their complexity, urgency, budget and

resources, client’s understanding, and

cultural compatibility between users

and developers.

[38] screening of projects to consider user-related criteria can improve the active participation of users

by fostering trust, knowledge exchange, and a collective mind in the project team among users and

developers [38] In International Journal of Project Management

Team Autonomy is defined as the extent

to which a team in the organization has

been given the freedom, independence,

and discretion to determine what

actions are required and how best to

execute them.

[44] Our findings suggest that autonomous teams engage more frequently in cooperative learning

behaviors, and consequently perform more effectively and are more satisfied [44] In IEEE

Transactions on Engineering Management

Task-related drivers (3 drivers; 8 citations) refer to contextual and task related issues that may drive knowledge sharing.

Project Risks reflect potential risk factors,

such as project and task complexity,

that impose challenges over the course

of accomplishing tasks.

[90,71]

[79]

information sharing was greater with a moderately complex task as opposed to a highly complex

task [79] In IEEE Transactions on Professional Communication

Shared Task between Developers and Users

reflects mutual development tasks in

which developers and users need to

frequently interact.

[91] we observed two emergent structures, a power user CoP and a bridge between the ES team and the

user community [share task]. These two structures are organizational forms that support power

users as a KT [knowledge transfer] mechanism [91] In Journal of Strategic Information Systems

Project Knowledge refers to the type and

characteristic of knowledge that needs

to be shared (e.g., tacit/explicit,

functional/business, simple/complex).

[32,86]

[9,71]

The results confirm the difficulty of sharing tacit and interactional knowledge across agencies [71]

In Information Technology and Management

Technology-related drivers (4 drivers; 20 citations) refer to technological factors such as templates, tools, and methodologies that may drive knowledge sharing.

Boundary Objects are defined as artifacts

and documents through which

development teams can organize their

efforts.

[7,62]

[89]

The spec [boundary object] acted as a facilitating and coordinating device for information

exchanges across the cultural and occupational boundaries between workers [7] In Human Relations

Project Methodology refers to methods,

such as pair programming or waterfall,

for practicing development processes

and efforts.

[8,65] The results suggest that pair designing could be a suitable means to disseminate and enforce design

knowledge [8] In Journal of Software Maintenance and Evolution: Research and Practice

Standardization of Templates and

Methodologies refer to templates and

methods that are standardized across

stakeholders and team members.

[70] Standardization of templates and methodologies across the remote sites . . .. contributed to the

development of the notion of ‘who knows what’ across onsite and offshore teams . . .., and supported

the transfer of knowledge between onsite and offshore teams [70] In Information Systems Journal

Collaborative Technologies refer to the use

of collaborative and online

technologies for enabling and

encouraging communication.

[89,99]

[3,12]

[46,48]

[50,65]

[21,69]

[70,33]

[68,103]

Frequent communications between managers and developers of dispersed teams using on-line

chat, email, teleconferencing and videoconferencing streamline [d] information flows [50] In

Journal of Information Technology

S. Ghobadi / Information & Management 52 (2015) 82–97 89

In addition to investigating the effect of knowledge sharingdrivers on knowledge sharing practices (e.g., quotes in Table 1),some of the reviewed papers also discuss the interplay betweenknowledge sharing drivers. Examples include: (i) team perceptions

drivers (people-related), which may influence each other in anumber of ways; for example, project commitment is shown toincrease trust between team members [102], goal interdepen-dence between team members can increase the task interdepen-dency of individuals [73], extrinsic motives (e.g., paidcontributions) are shown to decrease [80] or at times feed intrinsicmotives of individuals [53], and trust can facilitate the realizationof extrinsic motives by helping team members understand thepossibility of receiving rewards through collective action [71], (ii)capability-related drivers (people-related), which may also be

interdependent; for example, the duration of team membershipis shown to influence users’ communication capability, althoughthis relationship is not observed among developers [87], (iii)collaborative technologies (technology-related drivers), which caninfluence organizational practices drivers (structure-related) byenabling frequent communication between team members [3],(iv) collaborative technologies (technology-related drivers), whichcan affect capability-related drivers (people-related) by helping teammembers quickly know who knows what within the team(transactive memory) [50], (v) collaborative technologies (technolo-

gy-related drivers), which may influence team perceptions drivers

(people-related) by increasing members’ sense of identity throughestablishing better collaborative experiences [65] or by increasingextrinsic and intrinsic motives of team members, e.g., by

Table 2Concept matrix (Studies and Subcategories).

Diversity-

related

drivers

Capability-

related

drivers

Team

Perceptions

drivers

Team

Organization

drivers

Organizational

Practices

drivers

Task-

related

drivers

Technology-

related

drivers

Walz et al. [93] * *

Waterson et al. [95] * *

Aladwani et al. [2] * *

Bergquist and Ljungberg [10] *

Zhuge [103] *

Huang et al. [40] *

Lakhani and Von Hippel [52] *

Hertel et al. [35] * *

Von Krogh et al. [92] *

Nicholson and Sahay [68] * * * *

Volkoff et al. [91] * * * *

Melnik and Maurer [64] *

Hands et al. [33] *

Lakhani and Wolf [53] *

Sarker et al. [84] * * *

Bellini et al. [8] *

Bellini et al. [9] * *

Bagozzi and Dholakia [5] * *

Pardo et al. [71] * *

Roberts et al. [80] *

Desouza et al. [21] * * *

Hanisch and Corbitt [34] *

Joshi et al. [45] * *

Korkala and Abrahamsson [48] * *

Kotlarsky et al. [50] * * *

Michaelides and Kehoe [65] *

Oshri et al. [69] * *

Aurum et al. [4] *

Jackson and Klobas [43] * *

Kaiser and Maseitz [46] * *

Oshri et al. [70] * * *

Sowe et al. [87] *

Vlaar et al. [90] *

Aman and Nicholson [3] * *

Boden et al. [12] * * *

Gregory et al. [32] * * *

Janz and Prasarnphanich [44] *

Yuan et al. [102] *

Barrett and Oborn [7] * * * *

Lin and Huang [57] *

McLeod and Doolin [62] *

Pee et al. [74] *

Pushpa and Mathew [77] *

Ganesh and Thangasamy [26] *

Hsu et al. [38] *

Schott [86] * * *

Vakkayil [89] *

Williams [98] * *

Wiredu [99] *

S. Ghobadi / Information & Management 52 (2015) 82–9790

encouraging people to signal their competence through recordedand monitored collaboration [46], (vi) diversity-related drivers

(people-related), which may affect organizational practices drivers

(structure-related) by highlighting the differences between teammembers and inhibiting organizational practices such as frequentinteraction [26], (vii) diversity-related drivers (people-related),which can influence technology-related drivers (technology-related);for example, Boden et al. [12] reports cultural differences betweenonshore (German) and offshore (Russian) teams that shape theiropinions on the role of documentation in software development(e.g., at which point documentation should be written, how muchdocumentation is ideal), and, in turn, the two groups tend to adoptdifferent documentation policies and procedures in one singleproject, and finally (viii) team organization drivers (structure-

related) can affect organizational practices drivers (structure-

related); for example, client embedment in development processes

can strengthen informal networks between developers ad clientrepresentatives [98].

5.3. Classification framework

The third step in ‘reporting the review’ presents the developedclassification framework (Fig. 4). The detailed process fordeveloping the framework was provided in Section 4.4. Theframework classifies the 44 knowledge sharing drivers into fourmajor categories and seven subcategories and also demonstratesthe reported and potential causal links between categories,subcategories, and drivers.

Four types of causal links are depicted in the framework. Thefirst type, represented by four causal links (bold lines), displays thedriving impact of the four categories on knowledge sharingpractices (e.g., the impact of ‘people-related’ drivers on knowledge

Fig. 2. Breakdown of citations to drivers.

S. Ghobadi / Information & Management 52 (2015) 82–97 91

sharing). The second type, represented by five causal links (normallines), shows the reported causal relationship between differentcategories or subcategories; for example, the link between ‘people-related’ and ‘structure-related’ categories refers to when ‘diversity-related drivers’ (e.g., different national cultures) highlight thedifferences between team members and undermine frequentinteraction (‘organizational practices drivers’) [26]. The third typeof causal links, represented in the form of a loop, shows the causalrelationships between knowledge sharing drivers within the samesubcategory; for example, one of the loops suggests the interplaybetween ‘capability-related drivers’ (e.g., the effect of the ‘durationof team membership’ on ‘communicator’s capability’), and anotherloop refers to the interplay between ‘team perceptions drivers’(e.g., the effect of ‘goal interdependence’ on ‘task interdepen-dence’). The fourth type (five dash lines) is based upon Leavitt’smodel, which recommends the interaction between people,technology, structure, and task-related drivers. Specifically, thesecausal links express the possibility of causal relationships betweenthe categories where the reviewed literature has not yet focused onthem. For example, despite studying the effect of ‘technology-related’ drivers on ‘structure-related’ drivers, the oppositerelationship (the effect of ‘structure-related’ on ‘technology-related’ drivers) has not been investigated; in addition, althoughresearch has studied the interaction between ‘people-related’ and‘technology-related’ drivers, the interaction between ‘task-relateddrivers’ and other categories has not received sufficient attention.

The next section discusses the research and practical implication ofthe reported findings.

6. Discussion

Knowledge sharing is an important area of concern incollaborative teams in general [58,88,27,42,25] and in softwaredevelopment teams in particular [100,16,30,45]. For example,developers, user interface designers, user representatives, andproject managers engage in iterative development cycles thatrequire intensive knowledge sharing in terms of rapid reflectionsto exploit diverse expertise and explore existing and potentialopportunities in software development [14,66,13]. Although theimportance of knowledge sharing drivers in software teams isrecognized, no research bridges the multiple views and integratesthe existing different findings into a comprehensive framework forresearching and managing the factors that drive the exchange oftask-related information, ideas, know-hows, and feedback regard-ing software products and processes in software teams.

With this background, this study was undertaken to identifypatterns that emerge from previous research on knowledgesharing drivers in software development teams and to study thereported knowledge sharing drivers and integrate them into asingle framework. Following the guidance from the researchquestion ‘What drives knowledge sharing in software teams?’, asystematic mapping review of prior research on the factors that

Fig. 3. Breakdown of citations to subcategories.

S. Ghobadi / Information & Management 52 (2015) 82–9792

drive knowledge sharing in software teams was undertaken. Thecontexts, terminologies, research methods, knowledge sharingdrivers and reported causal links between them were studied.Using the classification lens of Leavitt’s organizational model, theidentified knowledge sharing drivers were consolidated into aclassification framework that was evaluated and refined as a resultof in-depth focus group and interview sessions. The key implica-tions are discussed in the following.

6.1. Context-based research: terminologies, methods, drivers

First, the analysis of the results suggests that the use of diverseknowledge sharing terminologies along with different researchmethods is relatively tied to the contexts in which they are studied.For example, (i) in terms of terminologies, although ‘knowledgesharing’ [96,40] and ‘knowledge transfer’ [84,45,86] are frequentlyused in general software development literature and in globallydistributed software teams, open source literature opts to useterms such as ‘participation’ [2,5], ‘contribution’ [35,92], ‘giftgiving’ [10], and ‘fractal cubic distribution’ [87] to answerquestions and contribute to discussions in portals and mailinglists and (ii) in terms of research methods, open source literaturelargely relies on surveys and observations of posts and mailing lists[92,52,53], whereas general software development literature—along with new studies on agile development, offshore out-sourcing, globally distributed software teams, and multi-vendorrelationships—increasingly use explorative case studies to uncover

new phenomena, such as the specific effect of new technologiesand boundary objects on collaborative practices [98,99].

Furthermore, different themes of literature put emphasis onparticular knowledge sharing drivers. For example, open sourceliterature emphasizes the importance of understanding theunderlying motivations of individuals to contribute to freesoftware development practices (‘extrinsic and intrinsic motives’(team perceptions drivers)) [53], whereas globally distributeddevelopment literature pays attention into understanding team-diversity drivers such as geographical distribution and howcollaborative technologies address existing challenges [65], andenterprise software development literature has focused onunderstanding how networks such as power users communitiesof practice (organizational practices drivers) can link users anddevelopers and improve knowledge sharing practices.

Diverse terminologies in referring to knowledge sharing withinsoftware teams along with the new vocabularies that haveemerged from contemporary contexts such as open sourceliterature indicate that knowledge sharing in software teamsshould be studied in light of understanding such diversity and attimes definitional inconsistencies (previous discussion on knowl-edge transfer and sharing). Consequently, future literature reviewsin this domain should carefully consider different yet relatedthemes of research, such as open source, virtual teams, and agileand lean development in identifying prior research. The discusseddiversity indicates that much can be gained from interactionbetween different themes of literature, as well. For example,

Fig. 4. Classification framework (Knowledge Sharing Drivers in Software Teams).

S. Ghobadi / Information & Management 52 (2015) 82–97 93

compared to distributed software teams literature, open sourceresearch exhibits more consistency and focus in using terminolo-gies, and this is reflected in its use of less diverse terms (e.g.,participation, gift giving, and contributions). Unlike agile anddevelopment literature, which is inherently built upon thetraditional foundations of globally distributed and softwaredevelopment literature, research on free and open source softwareprojects has emerged through observing and investigatingrelatively new real-world experiences. Although open sourceliterature can benefit from existing theoretical perspectives insoftware development literature [73,30,49,45], the dynamicconcepts, characteristics and emerging vocabularies in opensource research [92,52,53] can be insightful for related domains.For example, potential equivalents of ‘gift giving’ and ‘fractal cubicdistribution’ in agile development practices can be investigated;

for instance, open source software development relies on andbenefits from gift giving, such as sharing pieces of code, as a way ofgetting new ideas and prototypes out into circulation [10]. Futureresearch may study whether agile development does or can rely onthe power of ‘knowledge gifts’ in organizing social relationshipsamong different stakeholders.

6.2. Classification framework

Second, the classification framework integrates 44 knowledgesharing drivers and classifies them into four major categories andseven subcategories. The first key advantage of the classificationframework is identifying, distilling, classifying, and integratingprior findings on knowledge sharing drivers in software teams inone single framework. The classification framework provides a

S. Ghobadi / Information & Management 52 (2015) 82–9794

more comprehensive picture of knowledge sharing drivers thanwhat has previously been offered in the software literature (e.g.,[100,16,84,45]) and in the existing reviews in the knowledgemanagement literature (e.g., [94,101]). In addition, the classifica-tion exercise is based on the merits of a solid theoreticalfoundation (Leavitt’s model). Based upon prior research, thisframework represents a generalization from theory (existingliterature; theoretical lens) and empirical evidence (integration;check with professionals) [55].

The second key advantage is that the classification framework,along with the analysis of results, lays a rich groundwork forfuture research on factors that influence knowledge sharingin software development contexts. More specifically, this studyproposes eight potential research areas, including: (i) a focus

on task-related drivers, (ii) a focus on technology-related drivers,(iii) contextual frameworks, (iv) exploring new knowledge sharing

drivers, (v) exploring new causal relationships, (vi) longitudinal

approaches, (vii) frameworks for managing knowledge sharing

risks, and (viii) operationalizing the classification framework. Eacharea is described below.

6.2.1. A focus on task-related drivers

The analysis of drivers, their subcategories and the emphasisthey are given in the reviewed literature (Section 5.2) indicate thatthe reviewed literature has largely focused on studying andexploring different team perceptions drivers (14 drivers; 30 cita-tions) and organizational practices drivers (10 drivers; 24 citations).The literature emphasis on people-related drivers (e.g., organiza-tional practices drivers) and technology-related drivers (collabora-tive technologies) has gained considerable momentum due to theemphasis that IS literature has put on addressing the neglectedsocial aspects of IS projects [49] and on understanding theincreasing trends of globally distributed software projects[50]. There has been much less attention to identifying variousaspects of project tasks (task-related drivers; 3 drivers; 8 citations).This is exacerbated by recognizing the fact that although researchhas relatively studied the causal interrelationships between‘technology-related drivers’ (‘collaborative technologies’), ‘peo-ple-related’, and ‘structure-related’ drivers, the relationship be-tween ‘task-related drivers’ and the other three categories isoverlooked. (No established link exists between task-relatedcategory and other categories in the classification framework.)For example, although ‘project risks’ [90,71], ‘project knowledge’[32,86], and ‘shared task between developers and users’ [91] arebriefly mentioned as task-related drivers, their various implications(e.g., multi-dimensional task-related risks such as task uncertainty,task routineness, and task coupling) and detailed interactions withother categories in driving knowledge sharing have not receivedsufficient attention; e.g., when the overall project is divided anddistributed across several sites, task uncertainty—which is aboutlacking the information needed to develop the software—emergesand can hinder effective knowledge sharing [75].

6.2.2. A focus on technology-related drivers

Different drivers within each subcategory have relativelysimilar citation numbers (Fig. 2); for example, within diversity-related subcategory, team heterogeneity and geographical distri-bution are cited 11 and 6 times, respectively. However, out of20 citations of technology-related drivers, 14 citations are relatedto ‘collaborative technologies’, and the remaining 6 citations aredivided into the other 3 drivers. Although this observationindicates that the extant literature has largely focused oninvestigating the driving role of collaborative technologies,research opportunities to study other important aspects of projecttechnology, such as methods-in-use [24], boundary objects [7], andthe role of standardization in software development [63], exist.

6.2.3. Contextual frameworks

Specific development practices, such as agile development, pairprogramming, globally distributed teams, outsourced projects, opensource development, and non-commercial software teams, may callfor different communication and knowledge sharing patterns. Infact, non-commercial software may involve different communica-tion patterns than commercial software [37,31]. Investigating howknowledge sharing and knowledge sharing drivers are different invarious settings would improve our understanding of softwaredevelopment processes and may have important implications formanaging projects in different contexts. The classification frame-work provides a basis for further analyses that examine and comparethe framework in different software development contexts.

6.2.4. Exploring new knowledge sharing drivers

Although the classification framework draws attention to acomprehensive list of 44 knowledge sharing drivers, additionalknowledge sharing drivers can be explored by paying attentioninto the growing contemporary issues in developing and usingsoftware (e.g., distribution of open data, non-commercial soft-ware). For example, socio-political factors such as the promotion ofopen data values and free software at national and internationallevels (e.g., [41]) may encourage software developers and softwarecompanies to participate in virtual software development andsupport social values. Other possible avenues for future researchcould be the intellectual engagement of different themes ofliterature (e.g., open source, agile, distributed software develop-ment) for the fusion of concepts and perspectives and therebyknowledge enrichment, e.g., the role of ‘knowledge gifts’ in drivingknowledge sharing in agile development (discussed in Section 6.1).

6.2.5. Exploring new causal relationships

Based on Leavitt’s model, the five causal links (dash lines) in theclassification framework suggest several opportunities for examin-ing and exploring potential relationships, such as: (i) the causal

relationships between the seven subcategories (e.g., the causal linkbetween diversity-related drivers and team perceptions drivers), (ii)the causal relationships between drivers within each subcategory (e.g.,the causal link between project knowledge and task uncertainty),and (iii) the causal relationships between drivers in different

subcategories and their situational effect on knowledge sharing

practices; for example, whereas collaborative technologies such ascomputer interviewing (technology-related drivers) can be instru-mental in eliciting information from end-users [33], using suchtechnologies can influence the organizational dominance of end-users or developers (definitional control; team organization drivers),promote cooperation or competition among them, and, in turn, havea mixed effect on knowledge sharing behaviors [30]. Similarly,future studies may focus on the dual effect of knowledge sharingdrivers; for example, in addition to facilitating understanding andknowledge sharing, boundary objects can highlight team diversity inmanaging boundary objects, cause conflict and negative stereotyp-ing (e.g., different cultures), disrupt a team’s sense of identity, and, inturn, adversely affect knowledge sharing [7].

6.2.6. Longitudinal approaches

The longitudinal effect of knowledge sharing on knowledgesharing drivers is mentioned in some studies; for example, (i) ‘giftgiving’ (sharing code) and ‘answering others’ questions’ (knowl-edge sharing) in open source virtual teams can promote self-learning and increase a communicator’ s capability, reputation andcredibility [10], (ii) knowledge sharing may increase trust betweenteam members [38], and (iii) sharing public code in an open sourcecan decrease the contribution barriers of developers who will jointhe virtual team in the future [92]. Future research may advancethe classification framework by exploring the dynamic and

S. Ghobadi / Information & Management 52 (2015) 82–97 95

longitudinal effect of knowledge sharing on knowledge sharingdrivers.

6.2.7. Frameworks for managing knowledge sharing risks

The 44 knowledge sharing drivers (e.g., representative roles,trust between team members, interdependencies) and theirclassification may provide a basis for understanding barriers orrisks to knowledge sharing in software teams. Specifically,depending on the situation, each of the 44 knowledge sharingdrivers may positively or negatively affect knowledge sharing. Forexample, although representative roles may bridge communica-tion between distributed sites, they can become bottlenecks (andrisks to effective knowledge sharing) if communication is primarilychanneled through them [12]. A careful monitoring and assess-ment of knowledge sharing drivers is an important prerequisite forchecking knowledge sharing patterns and their progress. Accord-ingly, future studies may link the 44 knowledge sharing drivers to‘potential knowledge sharing risks’ and then ‘possible techniquesfor resolving them’.

6.2.8. Operationalizing the classification framework

The knowledge sharing drivers and their definitions provide abasis for the operationalization of the classification framework (e.g.,creating measures). This can be facilitated by tracing knowledgesharing, knowledge sharing drivers, their definitions and theiroperationalization (if any) in prior research (Table 1); for example,quantitative studies have operationalized knowledge sharing[2,5,102,38,39] in a number of ways, including: (i) ‘measuring towhat extent individuals have learned about technical and manage-rial/behavioral project issues from other team members’ [45], (ii)‘measuring to what extent knowledge (meeting notes, ideas, know-hows) is shared among individuals [73,102], or (iii) ‘counting thenumber of email messages posted by team members to the mailinglists and the number of replies they made to posted questions [87].

6.3. Practical implications

The importance of knowledge sharing creates extensive burdensfor coordination and communication throughout all stages ofsoftware projects. To achieve effective knowledge sharing incomplex and dynamic development environments, software teamsmust understand variations in people-related, structure-related,task-related, and technology-related drivers (the four knowledgesharing categories). Software teams may utilize the classificationframework by going through the list of knowledge sharing driversand assessing themselves against the 44 drivers to get a sense of theirstrengths (e.g., collocated team) and the existing or potentialweakness areas (e.g., a client’s unfamiliarity with agile developmentrequirements). The results of such analysis may suggest wheremanagerial efforts and resources should be directed to fosterknowledge sharing in any particular software project; for example,where knowledge sharing may suffer from the lack of appropriatecollaboration technologies, project managers can help minimize therisk by defining representative roles for facilitating communicationand by introducing extrinsic motives for encouraging knowledgesharing behaviors. Finally, software teams may document theresults of their analysis and the devised strategies to (i) maintain aregistry of the identified drivers (both enablers and barriers) atdifferent stages, (ii) evaluate their progression over the course of theproject, and (iii) understand the longitudinal effect of devisedstrategies on knowledge sharing practices.

7. Concluding points and limitations

Understanding factors that drive knowledge sharing in today’ssoftware development teams is a prerequisite for allowing team

members to monitor knowledge sharing patterns and progressand, in turn, to take steps toward achieving ideal levels ofcommunication and knowledge sharing. This article reviews andsynthesizes predominant literature regarding knowledge sharingdrivers in software teams. Recognizing the contextual nature of thereviewed literature, diversity of knowledge sharing terminologies,and at times definitional inconsistencies, 44 knowledge sharingdrivers are identified, distilled, classified, and integrated into aclassification framework. The classification framework provides arich picture of knowledge sharing drivers in software teams andfacilitates continued inquiry into studying knowledge sharingpractices in software development contexts. For example, theanalysis of results suggests valuable opportunities for focusingon task-related and technology-related drivers, developing con-textual-based frameworks, exploring new knowledge sharingdrivers, exploring new causal relationships, taking longitudinalapproaches, developing knowledge sharing risk managementframeworks, and operationalizing the classification framework.

Existing guidelines were followed to strengthen the reviewprocess and provide a solid foundation for uncovering areaswhere future research is required [97]. For example, (i) theresearch topic, concepts, and boundaries are carefully explainedin Sections 2 and 4, (ii) the existing views in broad literature aretaken into account (Sections 1, 4 and 5), (iii) a conceptualapproach is selected, and the results are integrated intoconceptual representations (e.g., Table 2, Figs. 2–4), (iv) care isgiven to choosing the tone and tense of the report, (v) aclassification framework to guide future research is developedand discussed (Sections 5 and 6), (vi) the classification frameworkis evaluated through focus group and in-depth interview sessions(Section 4.4), and (vii) a detailed discussion of the findings andinsights for future research is provided (Section 6).

Because the findings are based on the reviewed studies, thelimitation of the reviewed papers may also apply to this research.This challenge was managed by the careful selection of inclusioncriteria (e.g., the review involves empirically supported publica-tions) and by conducting evaluation sessions involving seniorsoftware professionals. We are not immune to the commonlimitations of literature reviews, which are largely dependent onthe selected keywords [47]. For this, the review process and reviewprotocol were designed carefully, and scholars and professionals inthe field were consulted regarding the results of each stage.Software development literature is growing, and the popularity ofagile methodologies and hybrid software development (opensource and commercial) is on the rise. Accordingly, as new streamsof research emerge, future reviews on knowledge sharing insoftware teams should pay attention to how different themes ofsoftware development literature refer to knowledge sharing (e.g.,gift giving) and expand the 29 keywords provided in this study.Finally, a cross platform review process (e.g., between Scopus,Google Scholar, and Microsoft Academic Search) could be useful forfuture studies.

Acknowledgment

I would like to thank the associate editor and the reviewers fortheir constructive comments and suggestions on the earlier draftsof this paper.

References

[1] M. Ackerman, V. Pipek, V. Wulf, Sharing Expertise: Beyond KnowledgeManagement, MIT press, US, 2003.

[2] A.M. Aladwani, A. Rai, A. Ramaprasad, Formal participation and performance ofthe system development group: the role of group heterogeneity and group-basedrewards, ACM SIGMIS Database 31, 2000, pp. 25–40.

S. Ghobadi / Information & Management 52 (2015) 82–9796

[3] A. Aman, B. Nicholson, Managing knowledge transfer in offshore softwaredevelopment: the role of copresent and ICT-Based interaction, J. Glob. Inf.Manage. 17, 2009, pp. 55–73.

[4] A. Aurum, F. Daneshgar, J. Ward, Investigating knowledge management practicesin software development organisations: an Australian experience, Inf. Softw.Technol. 50, 2008, pp. 511–533.

[5] R.P. Bagozzi, U.M. Dholakia, Open source software user communities: a study ofparticipation in Linux user groups, Manage. Sci. 52, 2006, pp. 1099–1115.

[6] J. Bailey, D. Budgen, M. Turner, B. Kitchenham, P. Brereton, S. Linkman, Evidencerelating to object-oriented software design: a survey, Empirical SoftwareEngineering and Measurement, IEEE Computer Society, Madrid, Spain, 2007,pp. 482–484.

[7] M. Barrett, E. Oborn, Boundary object use in cross-cultural software developmentteams, Hum. Relat. 63, 2010, pp. 1199–1221.

[8] E. Bellini, G. Canfora, F. GarcA-a, M. Piattini, C.A. Visaggio, Pair designing aspractice for enforcing and diffusing design knowledge, J. Softw. Maint. Evol. Res.Pract. 17, 2005, pp. 401–423.

[9] E. Bellini, G. Canfora, A. Cimitile, F. Garcia, M. Piattini, C. Visaggio, The impact ofeducational background on design knowledge sharing during pair programming:an empirical study, Prof. Knowl. Manage. 1, 2005, pp. 455–465.

[10] M. Bergquist, J. Ljungberg, The power of gifts: organizing social relationships inopen source communities, Inform. Syst. J. 11, 2001, pp. 305–320.

[11] F.O. Bjørnson, T. Dingsøyr, Knowledge management in software engineering: asystematic review of studied concepts, findings and research methods used, Inf.Softw. Technol. 50, 2008, pp. 1055–1068.

[12] A. Boden, G. Avram, L. Bannon, V. Wulf, Knowledge management in distributedsoftware development teams-does culture matter? IEEE International Confer-ence on Global Software Engineering, IEEE, Limerick, Ireland, 2009, pp. 18–27.

[13] E. Carmel, J.A. Espinosa, Y. Dubinsky, Follow the sun workflow in global softwaredevelopment, J. Manage. Inf. Syst. 27, 2010, pp. 17–38.

[14] S. Chakraborty, S. Sarker, An exploration into the process of requirementselicitation: a grounded approach, J. Assoc. Inf. Syst. 11, 2010, pp. 212–249.

[15] T. Chau, F. Maurer, Knowledge sharing in agile software teams, in: L. Wolfgang(Ed.), Logic Versus Approximation, Springer, United States, 2004, pp. 173–183.

[16] S.-W. Chou, M.-Y. He, Understanding OSS development in communities: theperspectives of ideology and knowledge sharing, Behav. Inform. Technol. 30,2011, pp. 325–337.

[17] A.L. Chua, S.L. Pan, Knowledge transfer and organizational learning in IS offshoresourcing, Omega 36, 2008, pp. 267–281.

[18] K. Conboy, S. Coyle, X. Wang, M. Pikkarainen, People over process: key peoplechallenges in agile development, IEEE Softw. 8, 2010, pp. 48–57.

[19] J.N. Cummings, Work groups, structural diversity, and knowledge sharing in aglobal organization, Manage. Sci. 50, 2004, pp. 352–364.

[20] B. Curtis, H. Krasner, N. Iscoe, A field study of the software design process forlarge systems, CACM 31, 1988, pp. 1268–1287.

[21] K.C. Desouza, Y. Awazu, P. Baloh, Managing knowledge in globalsoftware development efforts: issues and practices, IEEE Softw. 23, 2006, pp.30–37.

[22] M.E. Falagas, V.D. Kouranos, R. Arencibia-Jorge, D.E. Karageorgopoulos, Compar-ison of SCImago journal rank indicator with journal impact factor, FASEB J. 22,2008, pp. 2623–2628.

[23] S. Faraj, L. Sproull, Coordinating expertise in software development teams,Manage. Sci. 46, 2000, pp. 1554–1568.

[24] B. Fitzgerald, K.-J. Stol, R. O‘Sullivan, D. O‘Brien, Scaling agile methods toregulated environments: an industry case study, International Conference onSoftware Engineering, IEEE, San Francisco, CA, USA, 2013, pp. 863–872.

[25] M.G. Friberger, G. Falkman, Collaboration processes, outcomes, challenges andenablers of distributed clinical communities of practice, Behav. Inform. Technol.32, 2011, pp. 519–531.

[26] N. Ganesh, S. Thangasamy, Issues identified in the software process due tobarriers found during eliciting requirements on agile software projects: insightsfrom India, Int. J. Comput. Appl. 16, 2011, pp. 7–12.

[27] S. Garrett, B. Caldwell, Describing functional requirements for knowledge shar-ing communities, Behav. Inform. Technol. 21, 2002, pp. 359–364.

[28] S. Ghobadi, Challenges of cross-functional software development teams: aconceptual study, J. Inf. Technol. Manage. 22, 2011, pp. 26–35.

[29] S. Ghobadi, J. D‘Ambra, Coopetitive relationships in cross-functional softwaredevelopment teams: how to model and measure? J. Syst. Softw. 85, 2011, pp.1096–1104.

[30] S. Ghobadi, J. D‘Ambra, Modeling high-quality knowledge sharing in cross-functional software development teams, Inf. Process. Manage. 49, 2013, pp.138–157.

[31] S. Ghobadi, L. Mathiassen, Perceived barriers to effective knowledge sharing inagile software teams, Inf. Syst. J. 2014, (in press).

[32] R. Gregory, R. Beck, M. Prifling, Breaching the knowledge transfer blockade in IToffshore outsourcing projects-A case from the financial services industry, HawaiiInternational Conference on System Sciences, IEEE, Hawaii, United States, 2009,pp. 1–10.

[33] K. Hands, D.R. Peiris, P. Gregor, Development of a computer-based interviewingtool to enhance the requirements gathering process, Requir. Eng. 9, 2004, pp.204–216.

[34] J. Hanisch, B. Corbitt, Impediments to requirements engineering during globalsoftware development, Eur. J. Inf. Syst. 16, 2007, pp. 793–805.

[35] G. Hertel, S. Niedner, S. Herrmann, Motivation of software developers in OpenSource projects: an Internet-based survey of contributors to the Linux kernel,Res. Policy 32, 2003, pp. 1159–1177.

[36] J.A. Holton, The coding process and its challenge, in: A. Bryant, K. Charmaz (Eds.),The Sage Handbook of Grounded Theory, Sage Publications, London, UK, 2007,pp. 265–290.

[37] J. Howison, J.D. Herbsleb, Scientific software production: incentives and collab-oration, in: Proceedings of the ACM 2011 conference on Computer supportedcooperative work, ACM, 2011, pp. 513–522.

[38] J.S. Hsu, T.P. Liang, S.P.J. Wu, G. Klein, J.J. Jiang, Promoting the integration of usersand developers to achieve a collective mind through the screening of informa-tion system projects, Int. J. Project Manage. 29, 2011, pp. 514–524.

[39] J.C. Huang, S. Newell, Knowledge integration processes and dynamics withinthe context of cross-functional projects, Int. J. Project Manage. 21, 2003, pp. 167–176.

[40] J.C. Huang, S. Newell, R.D. Galliers, S.L. Pan, Dangerous liaisons? Component-based development and organizational subcultures IEEE Trans. Eng. Manage. 50,2003, pp. 89–99.

[41] N. Huijboom, T. Van den Broek, Open data: an international comparison ofstrategies, Eur. J. ePract. 12, 2011, pp. 1–13.

[42] S.-Y. Hung, H.-M. Lai, W.-W. Chang, Knowledge-sharing motivations affectingR&D employees’ acceptance of electronic knowledge repository, Behav. Inform.Technol. 30, 2011, pp. 213–230.

[43] P. Jackson, J. Klobas, Building knowledge in projects: a practical application ofsocial constructivism to information systems development, Int. J. Project Man-age. 26, 2008, pp. 329–337.

[44] B.D. Janz, P. Prasarnphanich, Freedom to cooperate: gaining clarity into knowl-edge integration in information systems development teams, IEEE Trans. Eng.Manage. 56, 2009, pp. 621–635.

[45] K.D. Joshi, S. Sarker, S. Sarker, Knowledge transfer within information systemsdevelopment teams: examining the role of knowledge source attributes, Decis.Support Syst. 43, 2007, pp. 322–335.

[46] S. Kaiser, G. Maseitz, Leveraging lead user knowledge in software development:the case of weblog technology, Ind. Innov. 15, 2008, pp. 199–221.

[47] B. Kitchenham, O. Pearl Brereton, D. Budgen, M. Turner, J. Bailey, S. Linkman,Systematic literature reviews in software engineering – a systematic literaturereview, Inf. Softw. Technol. 51, 2009, pp. 7–15.

[48] M. Korkala, P. Abrahamsson, Communication in distributed agile development: acase study, EUROMICRO Conference on Software Engineering and AdvancedApplications, 2007203–210.

[49] J. Kotlarsky, I. Oshri, Social ties, knowledge sharing and successful collaborationin globally distributed system development projects, Eur. J. Inf. Syst. 14, 2005,pp. 37–48.

[50] J. Kotlarsky, I. Oshri, J. Van Hillegersberg, K. Kumar, Globally distributed com-ponent-based software development: an exploratory study of knowledge man-agement and work division, J. Inf. Technol. 22, 2007, pp. 161–173.

[51] J. Kotlarsky, P.C. Van Fenema, L.P. Willcocks, Developing a knowledge-basedperspective on coordination: the case of global software projects, Inf. Manage.45, 2008, pp. 96–108.

[52] K.R. Lakhani, E. Von Hippel, How open source software works: ‘free’ user-to-userassistance, Res. Policy 32, 2003, pp. 923–943.

[53] K. Lakhani, R. Wolf, Why hackers do what they do: understanding motivationand effort in free/open source software projects, Perspectives on Free and OpenSource Software, 2005 pp. 3–22.

[54] H.J. Leavitt, Applied organization change in industry: structural, technical andhuman approaches, in: W.W. Cooper, H.J. Leavitt, M.W. Shelly (Eds.), NewPerspectives in Organizational Research, John Wiley and Sons, New York, UnitedStates, 1964, pp. 55–71.

[55] A.S. Lee, R.L. Baskerville, Generalizing generalizability in information systemsresearch, Inf. Syst. Res. 14, 2003, pp. 221–243.

[56] N. Levina, E. Vaast, Innovating or doing as told? Status differences and over-lapping boundaries in offshore collaboration MIS Q. 32, 2008, pp. 307–332.

[57] T.C. Lin, C.C. Huang, Withholding effort in knowledge contribution: the role ofsocial exchange and social cognitive on project teams, Inf. Manage. 47, 2010, pp.188–196.

[58] L. Lundvoll Nilsen, Collaboration and learning in medical teams by using videoconference, Behav. Inform. Technol. 30, 2011, pp. 507–515.

[59] K. Lyytinen, M. Newman, Explaining information systems change: a punctuatedsocio-technical change model, Eur. J. Inf. Syst. 17, 2008, pp. 589–613.

[60] K. Lyytinen, L. Mathiassen, J. Ropponen, Attention shaping and software risk—acategorical analysis of four classical risk management approaches, Inf. Syst. Res.9, 1998, pp. 233–255.

[61] M. Martınez-Torres, S. Toral, F. Barrero, D. Gregor, A text categorisation tool foropen source communities based on semantic analysis, Behav. Inform. Technol.32, 2011, pp. 532–544.

[62] L. McLeod, B. Doolin, Documents as mediating artifacts in contemporary ISdevelopment, Hawaii International Conference on System Sciences, IEEE,Hawaii, United States, 2010, pp. 1–10.

[63] L. McLeod, S. MacDonell, B. Doolin, Standard method use in contemporary ISdevelopment: an empirical investigation, J. Syst. Inf. Technol. 9, 2007, pp. 6–29.

[64] G. Melnik, F. Maurer, Direct verbal communication as a catalyst of agile knowl-edge sharing, Agile Development Conference, IEEE, Utah, United States, 2004, pp.21–31.

[65] R. Michaelides, D. Kehoe, Internet communities and open innovation: an infor-mation system design methodology, International Conference on Computer andInformation Science, IEEE Computer Society, Melbourne, Australia, 2007, pp.769–775.

[66] S. Nerur, V.G. Balijepally, Theoretical reflections on agile development method-ologies, CACM 50, 2007, pp. 79–83.

S. Ghobadi / Information & Management 52 (2015) 82–97 97

[67] S. Nerur, R.K. Mahapatra, G. Mangalaraj, Challenges of migrating to agile meth-odologies, CACM 48, 2005, pp. 72–78.

[68] B. Nicholson, S. Sahay, Embedded knowledge and offshore software develop-ment, Inf. Organ. 14, 2004, pp. 329–365.

[69] I. Oshri, J. Kotlarsky, L.P. Willcocks, Global software development: exploringsocialization and face-to-face meetings in distributed strategic projects, J. Stra-teg. Inf. Syst. 16, 2007, pp. 25–49.

[70] I. Oshri, P. Van Fenema, J. Kotlarsky, Knowledge transfer in globally distributedteams: the role of transactive memory, Inform. Syst. J. 18, 2008, pp. 593–616.

[71] T.A. Pardo, A.M. Cresswell, F. Thompson, J. Zhang, Knowledge sharing in cross-boundary information system development in the public sector, Inf. Technol.Manage. 7, 2006, pp. 293–313.

[72] R. Patnayakuni, A. Rai, A. Tiwana, Systems development process improvement:a knowledge integration perspective, IEEE Trans. Eng. Manage. 54, 2007, pp.286–300.

[73] L.G. Pee, A. Kankanhalli, H.W. Kim, Knowledge sharing in IS developmentprojects: a social interdependence perspective, J. Assoc. Inf. Syst. 11, 2010,pp. 550–575.

[74] L.G. Pee, A. Kankanhalli, H.W. Kim, Knowledge sharing in information systemsdevelopment: a social interdependence perspective, J. Assoc. Inf. Syst. 11, 2010,pp. 550–575.

[75] J.S. Persson, L. Mathiassen, J. Boeg, T.S. Madsen, F. Steinson, Managing risks indistributed software projects: an integrative framework, IEEE Trans. Eng. Man-age. 56, 2009, pp. 508–532.

[76] K. Petersen, R. Feldt, S. Mujtaba, M. Mattsson, Systematic mapping studies insoftware engineering, International Conference on Evaluation and Assessment inSoftware Engineering, 2008.

[77] R.R. Pushpa, M. Mathew, Interactive and collaborative behaviour of softwareproduct-development teams, Team Perform. Manage. 16, 2010, pp. 434–450.

[78] A. Riege, Three-dozen knowledge-sharing barriers managers must consider,J. Knowl. Manage. 9, 2005, pp. 18–35.

[79] T.L. Roberts, P.H. Cheney, P.D. Sweeney, Project characteristics and group com-munication: an investigation, IEEE Trans. Prof. Commun. 45, 2002, pp. 84–98.

[80] J.A. Roberts, I.H. Hann, S.A. Slaughter, Understanding the motivations, partici-pation, and performance of open source software developers: a longitudinalstudy of the Apache projects, Manage. Sci. 52, 2006, pp. 984–999.

[81] P.N. Robillard, The role of knowledge in software development, CACM 42, 1999,pp. 87–92.

[82] M. Rosemann, I. Vessey, Toward improving the relevance of information systemsresearch to practice: the role of applicability checks, MIS Q. 2008, pp. 1–22.

[83] S. Sarker, S. Sarker, Exploring agility in distributed information systems devel-opment teams: an interpretive study in an offshoring context, Inf. Syst. Res. 20,2009, pp. 440–461.

[84] S. Sarker, D.B. Nicholson, K.D. Joshi, Knowledge transfer in virtual systemsdevelopment teams: an exploratory study of four key enablers, IEEE Trans. Prof.Commun. 48, 2005, pp. 201–218.

[85] S. Sawyer, P.J. Guinan, J. Cooprider, Social interactions of information systemsdevelopment teams: a performance perspective, Inform. Syst. J. 20, 2010,pp. 81–107.

[86] K. Schott, Vendor-vendor knowledge transfer in global ISD outsourcing projects:insights from A German Case Study, Pacific Asia Conference on InformationSystems, Brisbane, Australia, 2011.

[87] S.K. Sowe, I. Stamelos, L. Angelis, Understanding knowledge sharing activities infree/open source software projects: an empirical study, J. Syst. Softw. 81, 2008,pp. 431–446.

[88] M.-T. Tsai, N.-C. Cheng, Understanding knowledge sharing between it profes-sionals – an integration of social cognitive and social exchange theory, Behav.Inform. Technol. 31, 2012, pp. 1069–1080.

[89] J.D. Vakkayil, Learning through shared objects in outsourced software develop-ment, Int. J. Manag. Projects Bus. 4, 2011, pp. 616–632.

[90] P.W.L. Vlaar, P.C. van Fenema, V. Tiwari, Cocreating understanding and value indistributed work: how members of onsite and offshore vendor teams give, make,demand, and break sense, MIS Q. 32, 2008, pp. 227–255.

[91] O. Volkoff, M.B. Elmes, D.M. Strong, Enterprise systems, knowledge transfer andpower users, J. Strateg. Inf. Syst. 13, 2004, pp. 279–304.

[92] G. Von Krogh, S. Spaeth, K.R. Lakhani, Community, joining, and specializationin open source software innovation: a case study, Res. Policy 32, 2003, pp. 1217–1241.

[93] D.B. Walz, J.J. Elam, B. Curtis, Inside a software design team: knowledge acqui-sition, sharing, and integration, CACM 36, 1993, pp. 63–77.

[94] S. Wang, R.A. Noe, Knowledge sharing: a review and directions for futureresearch, Hum. Resour. Manage. Rev. 20, 2010, pp. 115–131.

[95] P.E. Waterson, C.W. Clegg, C.M. Axtell, The dynamics of work organization,knowledge and technology during software development, Int. J. Hum. Comput.Stud. 46, 1997, pp. 79–101.

[96] P.E. Waterson, C.W. Clegg, C.M. Axtell, Dynamics of work organization, knowl-edge and technology during software development, Int. J. Hum. Comput. Stud.46, 1997, pp. 79–101.

[97] J. Webster, R.T. Watson, Analyzing the past to prepare for the future: writing aliterature review, MIS Q. 26, 2002, p. 3.

[98] C. Williams, Client-vendor knowledge transfer in IS offshore outsourcing:insights from a survey of Indian software engineers, Inform. Syst. J. 21, 2011,pp. 335–356.

[99] G.O. Wiredu, Understanding the functions of teleconferences for coordinatingglobal software development projects, Inf. Syst. J. 21, 2011, pp. 175–194.

[100] C. Xiang, Y. Lu, S. Gupta, Knowledge sharing in information system developmentteams: examining the impact of shared mental model from a social capitaltheory perspective, Behav. Inform. Technol. 2013http://dx.doi.org/10.1080/0144929X.2012.745901.

[101] T.-M. Yang, T.A. Maxwell, Information-sharing in public organizations: a liter-ature review of interpersonal, intra-organizational and inter-organizationalsuccess factors, Gov. Inf. Q. 28, 2011, pp. 164–175.

[102] M. Yuan, X. Zhang, Z. Chen, D.R. Vogel, X. Chu, Antecedents of coordinationeffectiveness of software developer dyads from interacting teams: an empiricalinvestigation, IEEE Trans. Eng. Manage. 56, 2009, pp. 494–507.

[103] H. Zhuge, Knowledge flow management for distributed team software develop-ment, Knowl. Based Syst. 15, 2002, pp. 465–471.

Shahla Ghobadi has a BEng in Industrial Engineering, aMSc in Information Technology Management, and aPhD in Information Systems from the University ofNew South Wales, Australia. Her research focuses oncoopetition and knowledge management in softwaredevelopment contexts and the social-political use ofthe Internet. Her research is published (or in press) inInformation Systems Journal, Information Processing& Management, Journal of Systems and Software,Behaviour & Information Technology, Journal ofKnowledge Management, and AIS conferences suchas ICIS and ECIS. Shahla has worked extensively as aconsultant in software and automobile industries,

commercial and non-profit sectors, locally and internationally. She can be reachedat s.ghobadi@unsw.edu.au.