11) knowledge sharing in development teams
DESCRIPTION
Knowledge sharingTRANSCRIPT
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: [email protected]
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 [email protected].