11) Knowledge Sharing in Development Teams

Information & Management 52 (2015) 8297
Contents lists available at ScienceDirect
Information & Management

journal homepage: www.elsevier.com/locate/im
What drives knowledge sharing in software development teams:

A literature review and classication 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
A B S T R A C T
Article history:
Received 15 September 2013
Received in revised form 7 October 2014
Accepted 12 October 2014
Available online 22 October 2014
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 (19932011) on knowledge sharing
drivers in software teams and establishes a classication 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.
Keywords:
Software development
Software teams
Information system development
Knowledge sharing
Knowledge transfer
Literature review
1. Introduction
Software development is a collaborative and knowledge-intensive process that requires the blending and interweaving of diverse
knowledge dispersed across domains of specialization [72,81]. The
unique and inherent characteristics of software development signify
the 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 available
resources, addressing perceived challenges, and exploring emerging
opportunities in software development and design [23,20,85]. For
example, software, as a product, continuously emerges from
intensive and iterative development and quality assurance cycles
that require rapid reections and frequent introspections across
team members who represent different specializations, are often
distributed, and may have opposing professional priorities
[73,29,100,16]. Furthermore, from self-organizing open source
communities [87] to distributed software development, which is
rapidly becoming a norm in software companies, effective
knowledge sharing is necessary to allow team members to discuss
critical aspects of projects and overcome the cultural and social
challenges of coordinating work across distributed spaces [17].
* Current address: University of New South Wales, Sydney, NSW 2052, Australia.
Tel.: +61 2 9385 7130; fax: +61 2 9662 4061.
E-mail address: s.ghobadi@unsw.edu.au
http://dx.doi.org/10.1016/j.im.2014.10.008
0378-7206/ 2014 Elsevier B.V. All rights reserved.
Nonetheless, several challenges may complicate knowledge

sharing in software development teams [84,14]. For example,
managing the diverse social identities and cross-functionality of
team members [28,15], overcoming coordination challenges
across distributed sites [17], creating homogeneous teams with
a shared understanding [67] and motivating stakeholders to share
embedded knowledge with development teams [18] can be
challenging. Although technological solutions such as component-based development have been designed to facilitate rapid
development and reduce the need for communication [50],
research suggests that they have even exacerbated the need for
knowledge sharing; for example, achieving ideal levels of
component reuse requires developers to effectively share their
knowledge of different components that they have developed and
used [50].
Accordingly, researchers have studied knowledge sharing
drivers in software teams (factors that drive the exchange of taskrelated information, ideas, know-hows, and feedback regarding
products and processes) to propose effective ways of facilitating
knowledge sharing within these contexts [100,15,61,30]. For
example, Kotlarski and Oshri [49] emphasize the role of humanrelated issues, such as rapport and transactive memory, in
driving knowledge sharing within globally distributed software
projects, Joshi et al. [45] employ a connectionist epistemological
perspective and show the crucial role of source credibility and
extent of communication in shaping knowledge transfer.
S. Ghobadi / Information & Management 52 (2015) 8297
Exploring the role of transactive memory in distributed software

teams, Oshri et al. [70] suggest that the standardization of
templates and methodologies across remote sites, frequent
teleconferencing sessions and occasional short visits support
knowledge transfer. Pee et al. [73] use the lens of social
interdependence theory to explain how goal, task, and reward
interdependencies shape knowledge sharing between business
and external IT consultant subgroups. Building on Pee et al.s study,
Ghobadi and DAmbra [30] describe the dynamics through which
interdependencies, including outcomes (goals, rewards), means
(task-related), and boundary (friendship, sense of identity,
geographical closeness), interact and drive simultaneously cooperative and competitive behaviors, which in turn shape highquality knowledge sharing in multi-party software teams.
Despite the valuable ndings of previous studies, our understanding of this phenomenon is still emerging, and research is
fragmented with limited integrated efforts that are based on and
contributing to rich and rigorous theoretical perspectives. For
example, whilst studies point to knowledge sharing drivers in
software development teams [100,16,49,70], their focus is limited
to examining a small and selected set of drivers; for instance, Chou
and He [16] show the effect of open source software values and
norms on collaborative knowledge sharing in open source
software teams, and Joshi et al. [45] highlight the importance of
a sources credibility and extent of communication in shaping
knowledge sharing practices. Furthermore, several research
articles use terms such as participation [2,5], requirement
gathering [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 and
processes (knowledge sharing); for example, participation and
activity engagement are used to refer to assisting others by
answering their questions [5] and contributing to mailing lists in
virtual open source development teams [35], and requirement
gathering has been reported as the process through which users
share business and technical knowledge along with what they
want from the product with a development team [33]. In addition,
researchers diverge in their underlying assumptions and research
terminologies when studying knowledge sharing in software
development teams, and consequently, a clear consensus in
conceptualizations and ndings has not been realized; e.g., the
term knowledge transfer, which is primarily concerned with the
internalization of the shared knowledge [45], is also used to refer to
the simple sharing of knowledge [91,3,32].
Despite the importance of the subject, no research bridges
multiple views and integrates existing ndings into a comprehensive framework for researching and managing knowledge sharing
drivers in software development teams. Although systematic
literature reviews on the general aspects of knowledge management in software engineering exist [11], the lack of a focused
83
review on knowledge sharing drivers within software teams and

the paucity of efforts to integrate the existing fragmented
knowledge complicate the prospect of understanding the current
state of research and a continued discussion on the topic.
This study therefore aims to integrate existing ndings,
improve our understanding of the phenomenon of knowledge
sharing in software development teams, and guide future research
in this area. For this, a synthesis of the predominant literature with
the following two research objectives is undertaken: (i) to identify
patterns that emerge from previous research on knowledge
sharing drivers in software development teams and (ii) to study
the reported knowledge sharing drivers and integrate them into a
framework that provides a rich picture of knowledge sharing
drivers in software teams and facilitates studying knowledge
sharing in software development contexts. To address the research
objectives, the following steps are followed: (i) the existing
literature is reviewed through the guidance of the following
research question, what drives knowledge sharing in software
development teams?, (ii) the contexts and terminologies referring
to knowledge sharing and the employed research methodologies
are extracted and analyzed, (iii) the reported knowledge sharing
drivers are consolidated, classied and integrated into a classication framework, and (iv) the themes and gaps in the existing body
of knowledge are highlighted, and avenues for future research are
discussed. The remainder of the paper is structured as follows.
Section 2 details the research methodology. Sections 35 elucidate
the results of the literature review and synthesis and present the
classication framework. Research and practical implications are
discussed in Section 6, prior to outlining nal remarks and research
limitations in Section 7.
2. Research method
Fig. 1 demonstrates the three methodological phases along with
their relevant steps. Based on the systematic mapping method
[76,6], which focuses on categorizing the research phenomenon
under investigation and visualizing ndings into a structured
framework, the methodology consists of three major phases,
including: (i) planning the study, (ii) conducting the study, and (iii)
reporting the review. Sections 35 explain each of the three phases,
supplemented by a detailed discussion of the results and avenues
for future research in Sections 6 and 7.
3. Phase 1: planning the study
The rst and second steps in planning the study involved
identifying the need and rationale for the study and formulating
the research question. The third step was the development of a
review protocol to guide the review; for this, an initial review
protocol was written and then was revisited and improved by two
Fig. 1. Methodological phases.
84
experienced researchers in the knowledge management and

software engineering elds. The protocol explicated and documented the following items: (i) the need and rationale for the
study and the research question (discussed in Section 1), (ii) the
strategy for searching primary studies, (iii) the selection procedures and quality assessment criteria, (iv) the data extraction
policies and procedures, and (v) the data classication strategy.
(These items are reected in the following sections.)
4. Phase 2: conducting the study
4.1. Identication of research
The rst step in conducting the study involved the identication of research (Fig. 1). Scopus (ofcially named as SciVerse
Scopus) was selected as the resource for the research because (i) it
is the largest abstract and citation scientic database of peerreviewed research literature1 [22] and (ii) it has been used as a
major search source in some key software engineering systematic
reviews [47].
To establish the boundaries of what would be considered in the
review, the phenomenon of interest was dened as research that
investigates knowledge sharing drivers in software development
teams. To match this denition with the published research and
address literature diversity in studying knowledge sharing, an
initial list of search keywords was developed by consulting ve
experts in knowledge management, software development, and
systematic literature reviews. In addition, snowball sampling
(nding relevant papers, checking their reference lists) was used to
further investigate how knowledge sharing in software teams is
referred to in prior research, and this resulted in identifying
additional keywords (e.g., data exchange, exchange of data).
4.2. Selection of primary studies
The second step in conducting the study was the selection of
primary studies for the literature review. Two iterations were
followed, including: (i) searching the literature using 29 keywords
in Scopus (the titles, keywords, and the abstracts) and identifying
relevant 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 list
of the identied papers and including additional papers.
Each iteration involved four stages, including: (i) excluding
studies based on the title examination, (ii) excluding studies
based on reviewing their abstract, (iii) excluding studies that did
not provide empirical evidence, and (iv) excluding studies based
on examining their full text. The criteria to be included in the
study 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 was
a peripheral (e.g., knowledge sharing was only briey 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 than
the focal focus of the study, were excluded; this criterion was
considered to focus the review on the most relevant ndings rather
than including any publication that briey refers to or suggests
knowledge sharing drivers. In addition, a liberal approach to how
we understand software teams was adopted, e.g., by including
papers that study the teamwork aspects of virtual open source
software development (e.g., [35]), and (iv) Studies should have
provided empirical evidence of knowledge sharing drivers; this
criterion was considered to improve reliability of the synthesized
ndings by limiting the review to empirically supported results.
In the rst iteration, searching the aforementioned 29 keywords
in Scopus resulted in identifying an initial list of 3129 papers.
Examining the title, abstract, empirical evidence, and the full
content of the identied papers resulted in excluding 1495 studies
based on reviewing their titles, 1318 studies based on reading their
abstracts, 199 studies based on providing empirical evidence, and
81 studies based on reading the full texts. In total, 36 papers were
selected in the rst iteration. In the second iteration, the references
of the identied 36 papers were examined against the selection
criteria, 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 data
from 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, open
source, distributed software development, agile development, pair
programming), (iii) terminology used for referring to knowledge
sharing (e.g., knowledge transfer, knowledge sharing, knowledge
ow, participation, exchange of ideas, gift giving, requirement
gathering, 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 provided
in Section 5.
The extracted knowledge sharing drivers were carefully studied
to distil possible overlaps and merge related drivers. For example,
the following drivers (contract persons, power users, program
managers, knowledge brokers) were noted to be related to
representative roles that may facilitate knowledge sharing within
software teams. Therefore, they were merged into one driver
(Assignment of Representative Roles); specically, identifying
contact persons was dened as selecting key representatives from
vendor personnel to provide continuity in communication and
working relationships [32], selecting power users was about
choosing user representatives that work with development teams,
get trained, and then share their updated knowledge with other
users [91], assigning program managers was about creating new
roles that are aware of new components being developed for a
specic customer and facilitate sharing knowledge and the reuse of
components across geographical implementations [50], and
creating knowledge brokers was about assigning roles that bridge
and facilitate communication and ll the structural holes in social
networks [12]. These processes resulted in a consolidated list of
44 knowledge sharing drivers; each of them is introduced and
explained in Section 5.
4.4. Developing the classication framework
The fourth step in conducting the review involved developing
the classication framework based on the 44 knowledge sharing
drivers. First, Leavitts organizational model [54] was chosen as the

classication scheme. Having roots in organizational change
theory, Leavitts organizational model [54] views organizational
systems as multivariate systems of four interacting components,
including actors, structure, tasks, structure, and technology
[54,59]. Leavitts model is considered a solid theoretical foundation
that is simple, comprehensive, and anchored in theory [59], and it
has been utilized to synthesize organizational dynamics [54]. For
example, IS researchers have employed the model to dene and
categorize software development risks, arguing that the four
dimensions of Leavitts model can cover the key aspects of software
development processes [75,60]. Specically, (i) actors (people) can
cover users, managers, developers, and other key stakeholders of
the project, (ii) structure can represent project organization and
institutional setting issues within software projects, (iii) tasks can
cover the risks, nature and type of activities within software
projects, and (iv) technology can include development methods,
tools, hardware, and software platforms for the nal software.
Based on its merits (a solid theoretical foundation and comprehensiveness in studying software processes), Leavitts model can
be used to dene the foci of knowledge sharing drivers areas in
software teams. The application of Leavitts model is also useful to
knowledge management literature. Specically, although some
knowledge management studies have reviewed the extant
literature to classify knowledge sharing drivers and provide a
bigger picture of knowledge sharing drivers, they dene their
categories based on the similarity of concepts or constructs rather
than approaching classication on the basis on a robust theoretical
logic; for example, Wang and NOE [94] identify 28 knowledge
sharing drivers and classify them into four categories, motivationrelated, individual-related, perceptions-related, and environmentrelated, and Riege [78] draws attention into 36 barriers to
knowledge sharing and classies them into individual, organizational, and technological barriers.
Second, to classify knowledge sharing drivers, three steps were
followed. First, each of the 44 knowledge sharing drivers was
examined against the denition of the four components in Leavitts
model and then was assigned to the relevant categories of people,
structure, tasks, and technology (Leavitts model). Two experts in
the area of software development and knowledge management
were consulted. For example, team subcultures is related to the
diversity of stakeholders, and thus, it is linked to people in
Leavitts model; the relocation of members between remote sites
is concerned with how team members are organized to work
collaboratively, and thus, it is linked to structure in Leavitts
model. The constant comparison between drivers and categories
helped determine whether the classication model supports and
continues to support the emerging concepts and categories
[83,36]. Conrming the adequacy of Leavitt model, the 44 drivers
were classied into four categories: people-related (involving
21 drivers), structure-related (involving 16 drivers), task-related
(involving 3 drivers), and technology-related drivers (involving
4 drivers). Second, along with experts and through an iterative
process, which examined the denition of each category and each
driver and the similarity between drivers, seven subcategories
were dened. Finally, based on a careful comparison between the
denitions of each driver and each subcategory, the 44 drivers
were assigned to relevant subcategories.
Third, the results were integrated into a classication framework and then presented to a group of 10 professionals over a 2 h
focus group session. The professionals represented different roles:
developer, tester, project manager, and business analyst. On the
basis of their experience in software development, they were asked
to make sense of the classications and suggest improvements to
the framework. Additionally, six in-depth evaluation sessions
involving two project managers, two developers, one tester and
85
one user interface designer were conducted. Participants were

asked to make sense of and apply the classication framework to
an ongoing project and to provide feedback and suggestions on
their logic and applicability [82]. Overall, the focus group and
interview sessions resulted in some renements to the framework
to increase clarity and improve understanding. For example,
collaboration technologies was initially under the category of
structure-related drivers; however, professionals referred to the
denitions of categories and considered it a technology-related
driver (technology can include development methods, tools, hardware, and software platforms for the nal software). Additionally,
although project methodology was initially part of task-related
drivers, the focus group argued that it is related to technologyrelated drivers. Such improvements enhanced the conciseness of
the classication framework by ensuring that the 44 knowledge
sharing drivers were placed in the most appropriate subcategory.
The evaluation was terminated after six evaluation sessions
because the fourth and fth sessions led to only minor changes,
and the nal classications were found to be logical, easy to
understand, and useful for understanding knowledge sharing in
software development teams.
Finally, the reported causal links between knowledge sharing
drivers were mapped at the category level and incorporated into a
classication framework (Fig. 4). For example, different national
cultures within the team may highlight and even exacerbate the
differences between individuals and, in turn, diminish team
members motivation to interact frequently [26]. Cultural differences, a team heterogeneity driver, is under the subcategory of
diversity-related drivers and the people-related category.
Frequent interaction falls under the subcategory of organizational
practices drivers and the structure-related category; as a result, a
causal link between people-related and structure-related drivers
is established in the classication framework.
5. Phase 3: reporting the review
5.1. Results of theme analysis (Contexts, Terminologies and
Methodologies)
The rst step in reporting the review explains the major
observed 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-vendor
knowledge sharing relationships [86]). This is followed by focusing
on general software development (29%; 14 papers; where papers
do not highlight any specic practice such as virtual development,
open source or agile development) [33], and open source development (16%; 8 papers) [5]. The rest of the papers (20%) report
contexts such as agile development [64], pair programming [8],
in-house software development [95], and enterprise system
development [91].
In terms of knowledge sharing terminologies, knowledge
sharing 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 approach) is concerned with the extent of sharing knowledge,
knowledge transfer (internalization approach) refers to a dyadic
exchange where the recipient is affected by the experience of the
source [84,91]. Researchers following the internalization approach
acknowledge that although knowledge must be shared, it must
also be interpreted, internalized and then created by knowledge
recipients to become an integrated part of a synergic solution
[56,1]. Although the review reects an overall awareness regarding
knowledge sharing and knowledge transfer terminologies (e.g.,
[43]), these terms are used interchangeably; e.g., the term
86
knowledge transfer is used to refer to the simple sharing of

knowledge [91,3,32]. Few studies (14%; 7 papers), primarily in the
area 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 their
reportage suggests that they refer to the exchange of task-related
information, ideas, know-hows, and feedback (denition of
knowledge sharing); for example, participation is dened as
providing and obtaining information about the group and
contributing to discussions [2], contribution (activity engagement) refers to assisting others by answering their questions [5]
and contributing to mailing lists [35], and fractal cubic distribution refers to a peak period when knowledge sharing is very
intensive, followed by a period of silence when knowledge
sharing is less intensive. In general, the review suggests that the
proliferation of open source development has given rise to new
terms such as gift giving, participation, contributing code and
joining script, reecting the contemporary aspects of software
development practices. The rest (26%; 13 papers) use their own
specic terms, such as requirement gathering [34,33], explicit
and implicit knowledge sharing [102], knowledge ow [65],
knowledge distribution [4], knowledge externalization [38],
activity engagement [35], knowledge withholding [57], communication, and sense giving/sense breaking [90]. For example,
requirement gathering is reported as the process through which
users 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 and
contribute less effort in sharing knowledge [57], and promotive
interaction draws attention to practices through which team
members teach each other the knowledge that is necessary to
collectively achieve goals and maximize team performance [44].
In terms of research methodologies, 27 papers (55%) employ
qualitative case studies (out of which 6 have a longitudinal focus
[40]), and 15 papers (31%) use a quantitative survey (out of which
3 take a longitudinal approach [52]). General software development and offshore system development studies primarily focus on
qualitative investigations [68]; however, mixed methods [43,4]
and experiments [8,9] are also employed, e.g., to observe
knowledge sharing behaviors among components of pair programming teams. In contrast, open source literature primarily
takes a quantitative approach by using surveys and mailing lists/
post observations over time [10]. Despite taking different
approaches and using diverse measures, quantitative studies have
attempted to operationalize knowledge sharing behaviors
[84,45,2,5,102,38,80,39,74]. For example, some studies operationalize knowledge transfer to measure to what extent individuals
have learned about technical and managerial/behavioral project
issues from other team members [45], some focus on the extent to
which knowledge such as meeting notes, ideas and know-hows
was shared [73,102], some examine the levels of knowledge
withholding by team members [57], and some analyze the posting
and replying activities of virtual team members by counting the
number of messages they posted to mailing lists and the number of
replies they made to others questions [87].
5.2. Classication
The identied knowledge sharing drivers are classied into four
major categories (people-related, structure-related, task-related, and
technology-related) and seven specic subcategories. The subcategories include: (i) diversity-related drivers, which refer to teams
diversity-related drivers, such as skills-related, geographical, and
time-related drivers, that may affect knowledge sharing, (ii)
capability-related drivers, which refer to team members knowledge, skills, experience and background, which collectively
contribute to a teams capability and may drive knowledge
sharing, (iii) team perceptions drivers, which refer to the perceptions, attitudes and values of team members that may drive
knowledge sharing, (iv) team organization drivers, which refer to
aspects of the team organization and conduct of the project that
may drive knowledge sharing, (v) organizational practices drivers,
which refer to existing organizational norms, communication
networks, and practices that may drive knowledge sharing, (vi)
task-related drivers, which refer to contextual and task-related
issues that may drive knowledge sharing, and (vii) technologyrelated drivers, which refer to technological factors such as
templates, tools, and methodologies that may drive knowledge
sharing. Table 1 outlines each of the categories, subcategories,
related drivers, denitions, sources, and a sample quote showing
how each driver is related to knowledge sharing.
Furthermore, Table 2 shows a conceptual matrix that relates
each of the 49 papers to the seven subcategories.
Fig. 2 provides a sense of how much emphasis is given to each
driver by showing the breakdown of the frequency of citations for
each driver. The two top cited drivers (marked as a highlighted
circles in Fig. 2) are collaborative technologies (technology-related;
14 times) and team heterogeneity (diversity-related; 11 times).
Within each subcategory, the most cited knowledge sharing
drivers are marked in Fig. 2 and include: team heterogeneity
(diversity-related), communicators capability (capability-related),
extrinsic motives (team perceptions), assignment of representative
roles (team organization), face-to-face interactions (organizational
practices), 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 cited
subcategories are team perceptions drivers (30 times), organizational 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). The
subcategories 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 of
drivers 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 largely
focused on exploring new team perceptions drivers (14 drivers)
and organizational practices drivers (10 drivers) and has paid
considerably less attention to identifying various aspects of project
technology (technology-related drivers; 4 drivers) and project tasks
(task-related drivers; 3 drivers), (ii) despite focusing on only four
technology-related drivers, the role of collaborative technologies is
well-cited (the top cited driver; 14 citations), and this has
improved the citations of the technology-related subcategory
(20 citations), (iii) despite studying only 2 drivers within the
diversity-related subcategory, these drivers are well-cited (17 citations), and (iv) the task-related subcategory has the lowest number
of citations (8 times) and the lowest number of drivers. These
results are discussed in Section 6 in detail.
In addition, a closer look at the reviewed papers indicates that
certain drivers are emphasized in specic contexts. More
specically, the importance of motivation-related drivers, both
intrinsic and extrinsic motives, is pronounced in open source
virtual teams [52,53], whereas globally distributed software
development literature focuses on the role of organizational
practices, such as collaborative technologies and the assignment of
representative roles in addressing the challenges associated with
team heterogeneity (e.g., different national cultures) and geographical distribution [34,68].
87
Table 1
Categories, subcategories, drivers, sources, sample quotes.
Driver
Studies
Sample quote
People-related drivers (21 drivers)

Diversity-related drivers (2 drivers; 17 times citations) refer to teams diversity-related drivers, such as skills-related, geographical, and time-related drivers,
that may affect knowledge sharing.
the Indian staff also found it difcult to understand the strong English accents. As a result, . . ., the
[86]
Team Heterogeneity refers to the degree
[32,7]
of dispersion among team members in
Indian staff refused to openly contradict one another or their manager [sharing information] [68] In
[34,12]
terms of their demographic
Information and Organization
[84,9]
characteristics, experiences, skills,
[8,68]
cognitions, and values.
[2,40]
This article focused on . . . difculties in knowledge sharing due to physical distance. The solution of
[34,77]
Geographical Distribution refers to the
[12,26]
diversity of team members in terms of
the article is to have regular communication between the onshore and offshore site to make transfer
[68,21]
being located in different physical
of knowledge easier [26] In International Journal of Computer Applications
spaces.
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.
[84,45]
Communicators Credibility refers to
the credibility of the communicator [was] found to signicantly predict the extent of knowledge
the trustworthiness and reputation of
transferred [84] In IEEE Transactions on Professional Communication
the communicator.
Feature gifts by newcomers are related to their specialization in open source software projects [92]
[32,86]
Communicators Capability reects the
[87,68]
communicators capability in terms of
In Research Policy
[92,93]
project skills, technical ability, project
management ability, and cultural
competency.
[86]
There was already an existing client-vendor relationship between the bank and each of the vendors
Knowledge Recipients Starting Conditions
refer to knowledge receivers mindset
before the project started. Accordingly, as the project started, there was no signicant need for the
and level of knowledge.
transfer of functional and process knowledge from the client to the vendors, as this knowledge has
already been built up over years [86] In Pacic Asia Conference on Information Systems
Duration of team membership refers to
[87]
Dominant repliers [information sharing] tend to be long-term members of the community [87] In
the length of the time that team
Journal of Systems and Software
members have been part of the team.
[70,90]
These mechanisms contributed to the development of the notion of who knows what [transactive
Transactive Memory is dened as the set
of knowledge possessed by a group
memory] across onsite and offshore teams despite the challenges associated with globally
regarding an awareness of who knows
distributed teams, and supported the transfer of knowledge between onsite and offshore teams [70]
what.
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 dened by the
[5,35]
Participants engagement [in terms of sharing knowledge] was particularly determined by their
identication of team members to
identication as a Linux developer [35] In Research policy
in-group relationships.
[102,4]
Project commitment was found to be signicantly related to explicit knowledge sharing [102] In
Project Commitment refers to the extent
[5]
to which individuals experience
IEEE Transactions on Engineering Management
affective involvement with the project,
the team, and the overall organization.
[92]
the transition from joiner to newcomer [information sharing] occurs when the joiner is given
Need to Become Part of the Group refers
to the desire of individuals to feel
CVS access and makes a rst contribution to the software [92] In Research Policy
part of the team.
Open source software development relies on gift giving as a way of getting new ideas and
[4,80]
Extrinsic Motives refer to perceived
[21,71]
extrinsic reasons (such as signaling
prototypes out into circulation. This also implies that the giver gets power from giving away [10] In
[10,53]
competence, nding power over the
Information Systems Journal
[2]
code, and getting future support) that
encourage team members to share
knowledge.
[57,53]
We also nd that, when we partition the help system into its component tasks, 98% of the effort
Intrinsic Motives refer to perceived
[35,52]
intrinsic benets (such as self-learning
expended by information providers in fact returns direct learning benets to those providers. This
and intellectual stimulation derived
nding considerably reduces the puzzle of why information providers are willing to perform this
from sharing code) that encourage
task for free [52] In Research Policy
team members to share knowledge.
[57]
The results indicated that KW [knowledge withhold] is inuenced by distributive justice in the
Distributive Justice is dened as the
perceived fairness of organizational
environmental dimensions [57] In Information & Management
rewards that an employee may receive.
[71]
Incentives to sharing knowledge among the OSC CAS stakeholders, however, were made clear to all
Clarity of the Reward System reects the
degree to which organizational
participants and consistently supported [71] In Information Technology and Management
incentives for sharing knowledge were
claried for and understood by team
members.
[7]
Dr Prava was perceived to rely heavily on the most experienced Indian technical team leader. This
Perceived Subjective Leadership Style
refers to the perception of team
served to accentuate the privileging of technical knowledge and left the Jamaican members with
members regarding the style of
little room to inuence the development process [7] In Human Relations
leadership in working with various
sub-groups.
[102,57]
Trust was found to be signicantly related to both tacit and explicit knowledge sharing [102] In IEEE
Trust refers to the willingness of a person
[71]
to relate to another, believing that the
Transactions on Engineering Management
others action will be benecial rather
than detrimental, even though this
cannot be guaranteed.
88
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.
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 reects
members perception of control over
his/her actions.
Perceived Indispensability reects the
perceived importance of ones own
contributions for the team outcome.
Participants Evaluation of Team Goals
refers to peoples subjective evaluation
of goals in terms of how achieving
collective goals is important to them.
[73,4]
[91]
We found that perceived goal, task, and reward interdependencies are signicantly related to
knowledge sharing between the subgroups [73] In Journal of Association for Information Systems
[5]
We found that attitudes . . ., perceived behavioral control . . ., and negative anticipated emotions
(y = 0.15, SE = 0.04) were all signicant predictors of we-intentions to participate and share
information [5] In Management Science
[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
[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.
[69]
Relocation of Members between Remote
The relocation of experts between remote sites served also as a mechanism that accelerated the
Sites refers to changes in a teams
sharing of knowledge and technical expertise of the Maui platform [69] In Journal of Strategic
structure in terms of members
Information Systems
assignments into different work
environments.
[7]
we found that the use of boundary objects [discussed in the technology-related drivers] at
Denitional Control refers to the
organizational dominance that
transitions involving denitional control and the subsequent redistribution of power/authority may
particular people may get through
inhibit knowledge sharing [7]. In Human Relations
dening new practices (e.g., imposing
the use of particular boundary objects).
[95]
Remote Leadership refers to the
A persistent difculty which project members had to cope with was the fact that a large part of the
organizational structure in which the
program was being built by outside contractors . . . the patterns of role re-adjustment and
project is being managed and
knowledge sharing described earlier, were not possible outside of the project because the external
implemented remotely.
contractors were physically remote and communication channels were severely limited [95] In
International Journal of Human-Computer Studies
Temporal Restructuring of Team Members
if demands could still not be met, analysts were seconded to help out with the work of other teams
[32,95]
refers to occasional organizational
when and where necessary . . . the temporary restructuring of teams also facilitated the
changes in the normal activities of
achievement of a shared understanding [though sharing knowledge] of the program [95] In
team members.
International Journal of Human-Computer Studies
Clients Embedment refers to the extent to
We nd clientvendor knowledge transfer to the offshore vendor engineer to be positively
[98]
which clients views and feedback are
associated with . . . client embedment [98] In Information Systems Journal
incorporated and organized in
development processes.
contact persons were the main contact points within the team and they ensured the smooth ow of
[32,12]
Assignment of Representative Roles refers
[50,69]
to the allocation of specic people
information between dispersed teams and, as a result, facilitated knowledge-sharing processes
[91]
whose role is to facilitate knowledge
between the Head OYce in Walldorf and remote sites [69] In Journal of Strategic Information Systems.
[95,68]
sharing.
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
[12,43]
The study concluded that a fear based culture is not likely to produce an atmosphere in which
overall organizational culture with
[information on] doubts can be mentioned and problems discussed [43] In International Journal of
regard to sharing ideas and thoughts.
Project Management
[91]
Power User CoP (communities of practice)
we observed two emergent structures, a power user CoP and a bridge between the ES team and the
refer to established communities of
user community [share task; discussed in the next section]. These two structures are organizational
practice that bridge the thoughts and
forms that support power users as a KT [knowledge transfer] mechanism [91] In Journal of Strategic
ideas of the user community and thus
Information Systems
support and encourage knowledge
sharing among them.
[32,12]
These events [informal gatherings] helped to legitimize informality, to nurture questioning
Informal Networks refer to gatherings or
[68]
networks that allow informal
behavior irrespective of hierarchies, and enable information sharing through personal and
interaction between people.
informal networks even outside the work place and time settings [68] In Information and
Organization
Frequent Communication refers to
[3,32]
The volume of communication, . . . [was] found to signicantly predict the extent of knowledge
[84,45]
frequent communication practices
transferred [84] In IEEE Transactions on Professional Communication
between team members.
Face-to-face channels offer the prospect of richer communication because of the ability to transmit
[70,32]
Face-to-Face Interactions refer to
[64,93]
communication practices through
multiple cues [and embedded knowledge] [64] In Agile Development Conference
[69]
face-to-face channels.
[98]
We nd clientvendor knowledge transfer to the offshore vendor engineer to be positively
Formal Training for Clients refers to
organized training sessions for
associated with formal training [98] In Information Systems Journal
improving clients understanding of
different aspects of development
processes.
89
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.
Organizational Design refers to
established organizational rules and
procedures for communication.
[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
[21,51]
[93]
Organization design mechanisms facilitate knowledge ows by providing a structure through

which knowledge workers can channel their expertise . . . Organization design claries who is
supposed to know what and who is supposed to communicate with whom. It therefore economizes
knowledge ows [51] In Information & Management.
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
Project Screening refers to the

organizational practice of screening
and prioritizing projects in terms of
their complexity, urgency, budget and
resources, clients understanding, and
cultural compatibility between users
and developers.
Team Autonomy is dened 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.
[38]
[44]
Our ndings suggest that autonomous teams engage more frequently in cooperative learning
behaviors, and consequently perform more effectively and are more satised [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 reect potential risk factors,
[90,71]
information sharing was greater with a moderately complex task as opposed to a highly complex
[79]
such as project and task complexity,
task [79] In IEEE Transactions on Professional Communication
that impose challenges over the course
of accomplishing tasks.
we observed two emergent structures, a power user CoP and a bridge between the ES team and the
[91]
Shared Task between Developers and Users
reects mutual development tasks in
user community [share task]. These two structures are organizational forms that support power
which developers and users need to
users as a KT [knowledge transfer] mechanism [91] In Journal of Strategic Information Systems
frequently interact.
[32,86]
The results conrm the difculty of sharing tacit and interactional knowledge across agencies [71]
Project Knowledge refers to the type and
[9,71]
characteristic of knowledge that needs
In Information Technology and Management
to be shared (e.g., tacit/explicit,
functional/business, simple/complex).
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 dened as artifacts
[7,62]
The spec [boundary object] acted as a facilitating and coordinating device for information
[89]
and documents through which
exchanges across the cultural and occupational boundaries between workers [7] In Human Relations
development teams can organize their
efforts.
[8,65]
Project Methodology refers to methods,
The results suggest that pair designing could be a suitable means to disseminate and enforce design
such as pair programming or waterfall,
knowledge [8] In Journal of Software Maintenance and Evolution: Research and Practice
for practicing development processes
and efforts.
Standardization of templates and methodologies across the remote sites . . .. contributed to the
[70]
Standardization of Templates and
Methodologies refer to templates and
development of the notion of who knows what across onsite and offshore teams . . .., and supported
methods that are standardized across
the transfer of knowledge between onsite and offshore teams [70] In Information Systems Journal
stakeholders and team members.
Frequent communications between managers and developers of dispersed teams using on-line
[89,99]
Collaborative Technologies refer to the use
[3,12]
of collaborative and online
chat, email, teleconferencing and videoconferencing streamline [d] information ows [50] In
[46,48]
technologies for enabling and
Journal of Information Technology
[50,65]
encouraging communication.
[21,69]
[70,33]
[68,103]
In addition to investigating the effect of knowledge sharing

drivers on knowledge sharing practices (e.g., quotes in Table 1),
some of the reviewed papers also discuss the interplay between
knowledge sharing drivers. Examples include: (i) team perceptions
drivers (people-related), which may inuence each other in a
number of ways; for example, project commitment is shown to
increase trust between team members [102], goal interdependence between team members can increase the task interdependency of individuals [73], extrinsic motives (e.g., paid
contributions) are shown to decrease [80] or at times feed intrinsic
motives of individuals [53], and trust can facilitate the realization
of extrinsic motives by helping team members understand the
possibility of receiving rewards through collective action [71], (ii)
capability-related drivers (people-related), which may also be
interdependent; for example, the duration of team membership

is shown to inuence users communication capability, although
this relationship is not observed among developers [87], (iii)
collaborative technologies (technology-related drivers), which can
inuence organizational practices drivers (structure-related) by
enabling frequent communication between team members [3],
(iv) collaborative technologies (technology-related drivers), which
can affect capability-related drivers (people-related) by helping team
members quickly know who knows what within the team
(transactive memory) [50], (v) collaborative technologies (technology-related drivers), which may inuence team perceptions drivers
(people-related) by increasing members sense of identity through
establishing better collaborative experiences [65] or by increasing
extrinsic and intrinsic motives of team members, e.g., by
90
Table 2
Concept matrix (Studies and Subcategories).
Diversityrelated
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]
Capabilityrelated
drivers
Team
Perceptions
drivers
Team
Organization
drivers
Organizational
Practices
drivers
*
*
*
*
Taskrelated
drivers
Technologyrelated
drivers
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
encouraging people to signal their competence through recorded

and monitored collaboration [46], (vi) diversity-related drivers
(people-related), which may affect organizational practices drivers
(structure-related) by highlighting the differences between team
members and inhibiting organizational practices such as frequent
interaction [26], (vii) diversity-related drivers (people-related),
which can inuence technology-related drivers (technology-related);
for example, Boden et al. [12] reports cultural differences between
onshore (German) and offshore (Russian) teams that shape their
opinions on the role of documentation in software development
(e.g., at which point documentation should be written, how much
documentation is ideal), and, in turn, the two groups tend to adopt
different documentation policies and procedures in one single
project, and nally (viii) team organization drivers (structurerelated) can affect organizational practices drivers (structurerelated); for example, client embedment in development processes
*
*
*
*
*
can strengthen informal networks between developers ad client

representatives [98].
5.3. Classication framework
The third step in reporting the review presents the developed
classication framework (Fig. 4). The detailed process for
developing the framework was provided in Section 4.4. The
framework classies the 44 knowledge sharing drivers into four
major categories and seven subcategories and also demonstrates
the reported and potential causal links between categories,
subcategories, and drivers.
Four types of causal links are depicted in the framework. The
rst type, represented by four causal links (bold lines), displays the
driving impact of the four categories on knowledge sharing
practices (e.g., the impact of people-related drivers on knowledge
91
Fig. 2. Breakdown of citations to drivers.
sharing). The second type, represented by ve causal links (normal

lines), shows the reported causal relationship between different
categories or subcategories; for example, the link between peoplerelated and structure-related categories refers to when diversityrelated drivers (e.g., different national cultures) highlight the
differences between team members and undermine frequent
interaction (organizational practices drivers) [26]. The third type
of causal links, represented in the form of a loop, shows the causal
relationships between knowledge sharing drivers within the same
subcategory; for example, one of the loops suggests the interplay
between capability-related drivers (e.g., the effect of the duration
of team membership on communicators capability), and another
loop refers to the interplay between team perceptions drivers
(e.g., the effect of goal interdependence on task interdependence). The fourth type (ve dash lines) is based upon Leavitts
model, which recommends the interaction between people,
technology, structure, and task-related drivers. Specically, these
causal links express the possibility of causal relationships between
the categories where the reviewed literature has not yet focused on
them. For example, despite studying the effect of technologyrelated drivers on structure-related drivers, the opposite
relationship (the effect of structure-related on technologyrelated drivers) has not been investigated; in addition, although
research has studied the interaction between people-related and
technology-related drivers, the interaction between task-related
drivers and other categories has not received sufcient attention.
The next section discusses the research and practical implication of

the reported ndings.
6. Discussion
Knowledge sharing is an important area of concern in
collaborative teams in general [58,88,27,42,25] and in software
development teams in particular [100,16,30,45]. For example,
developers, user interface designers, user representatives, and
project managers engage in iterative development cycles that
require intensive knowledge sharing in terms of rapid reections
to exploit diverse expertise and explore existing and potential
opportunities in software development [14,66,13]. Although the
importance of knowledge sharing drivers in software teams is
recognized, no research bridges the multiple views and integrates
the existing different ndings into a comprehensive framework for
researching and managing the factors that drive the exchange of
task-related information, ideas, know-hows, and feedback regarding software products and processes in software teams.
With this background, this study was undertaken to identify
patterns that emerge from previous research on knowledge
sharing drivers in software development teams and to study the
reported knowledge sharing drivers and integrate them into a
single framework. Following the guidance from the research
question What drives knowledge sharing in software teams?, a
systematic mapping review of prior research on the factors that
92
Fig. 3. Breakdown of citations to subcategories.
drive knowledge sharing in software teams was undertaken. The

contexts, terminologies, research methods, knowledge sharing
drivers and reported causal links between them were studied.
Using the classication lens of Leavitts organizational model, the
identied knowledge sharing drivers were consolidated into a
classication framework that was evaluated and rened as a result
of in-depth focus group and interview sessions. The key implications are discussed in the following.
6.1. Context-based research: terminologies, methods, drivers
First, the analysis of the results suggests that the use of diverse
knowledge sharing terminologies along with different research
methods is relatively tied to the contexts in which they are studied.
For example, (i) in terms of terminologies, although knowledge
sharing [96,40] and knowledge transfer [84,45,86] are frequently
used in general software development literature and in globally
distributed software teams, open source literature opts to use
terms such as participation [2,5], contribution [35,92], gift
giving [10], and fractal cubic distribution [87] to answer
questions and contribute to discussions in portals and mailing
lists and (ii) in terms of research methods, open source literature
largely 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 outsourcing, globally distributed software teams, and multi-vendor
relationshipsincreasingly use explorative case studies to uncover
new phenomena, such as the specic effect of new technologies

and boundary objects on collaborative practices [98,99].
Furthermore, different themes of literature put emphasis on
particular knowledge sharing drivers. For example, open source
literature emphasizes the importance of understanding the
underlying motivations of individuals to contribute to free
software development practices (extrinsic and intrinsic motives
(team perceptions drivers)) [53], whereas globally distributed
development literature pays attention into understanding teamdiversity drivers such as geographical distribution and how
collaborative technologies address existing challenges [65], and
enterprise software development literature has focused on
understanding how networks such as power users communities
of practice (organizational practices drivers) can link users and
developers and improve knowledge sharing practices.
Diverse terminologies in referring to knowledge sharing within
software teams along with the new vocabularies that have
emerged from contemporary contexts such as open source
literature indicate that knowledge sharing in software teams
should be studied in light of understanding such diversity and at
times denitional inconsistencies (previous discussion on knowledge transfer and sharing). Consequently, future literature reviews
in this domain should carefully consider different yet related
themes of research, such as open source, virtual teams, and agile
and lean development in identifying prior research. The discussed
diversity indicates that much can be gained from interaction
between different themes of literature, as well. For example,
93
Fig. 4. Classication framework (Knowledge Sharing Drivers in Software Teams).
compared to distributed software teams literature, open source

research exhibits more consistency and focus in using terminologies, and this is reected in its use of less diverse terms (e.g.,
participation, gift giving, and contributions). Unlike agile and
development literature, which is inherently built upon the
traditional foundations of globally distributed and software
development literature, research on free and open source software
projects has emerged through observing and investigating
relatively new real-world experiences. Although open source
literature can benet from existing theoretical perspectives in
software development literature [73,30,49,45], the dynamic
concepts, characteristics and emerging vocabularies in open
source research [92,52,53] can be insightful for related domains.
For example, potential equivalents of gift giving and fractal cubic
distribution in agile development practices can be investigated;
for instance, open source software development relies on and

benets from gift giving, such as sharing pieces of code, as a way of
getting new ideas and prototypes out into circulation [10]. Future
research may study whether agile development does or can rely on
the power of knowledge gifts in organizing social relationships
among different stakeholders.
6.2. Classication framework
Second, the classication framework integrates 44 knowledge
sharing drivers and classies them into four major categories and
seven subcategories. The rst key advantage of the classication
framework is identifying, distilling, classifying, and integrating
prior ndings on knowledge sharing drivers in software teams in
one single framework. The classication framework provides a
94
more comprehensive picture of knowledge sharing drivers than

what has previously been offered in the software literature (e.g.,
[100,16,84,45]) and in the existing reviews in the knowledge
management literature (e.g., [94,101]). In addition, the classication exercise is based on the merits of a solid theoretical
foundation (Leavitts model). Based upon prior research, this
framework represents a generalization from theory (existing
literature; theoretical lens) and empirical evidence (integration;
check with professionals) [55].
The second key advantage is that the classication framework,
along with the analysis of results, lays a rich groundwork for
future research on factors that inuence knowledge sharing
in software development contexts. More specically, this study
proposes 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 classication framework. Each
area is described below.
6.2.1. A focus on task-related drivers
The analysis of drivers, their subcategories and the emphasis
they are given in the reviewed literature (Section 5.2) indicate that
the reviewed literature has largely focused on studying and
exploring different team perceptions drivers (14 drivers; 30 citations) and organizational practices drivers (10 drivers; 24 citations).
The literature emphasis on people-related drivers (e.g., organizational practices drivers) and technology-related drivers (collaborative technologies) has gained considerable momentum due to the
emphasis that IS literature has put on addressing the neglected
social aspects of IS projects [49] and on understanding the
increasing trends of globally distributed software projects
[50]. There has been much less attention to identifying various
aspects of project tasks (task-related drivers; 3 drivers; 8 citations).
This is exacerbated by recognizing the fact that although research
has relatively studied the causal interrelationships between
technology-related drivers (collaborative technologies), people-related, and structure-related drivers, the relationship between task-related drivers and the other three categories is
overlooked. (No established link exists between task-related
category and other categories in the classication framework.)
For example, although project risks [90,71], project knowledge
[32,86], and shared task between developers and users [91] are
briey 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 with
other categories in driving knowledge sharing have not received
sufcient attention; e.g., when the overall project is divided and
distributed across several sites, task uncertaintywhich is about
lacking the information needed to develop the softwareemerges
and can hinder effective knowledge sharing [75].
6.2.2. A focus on technology-related drivers
Different drivers within each subcategory have relatively
similar citation numbers (Fig. 2); for example, within diversityrelated subcategory, team heterogeneity and geographical distribution are cited 11 and 6 times, respectively. However, out of
20 citations of technology-related drivers, 14 citations are related
to collaborative technologies, and the remaining 6 citations are
divided into the other 3 drivers. Although this observation
indicates that the extant literature has largely focused on
investigating the driving role of collaborative technologies,
research opportunities to study other important aspects of project
technology, such as methods-in-use [24], boundary objects [7], and
the role of standardization in software development [63], exist.
6.2.3. Contextual frameworks

Specic development practices, such as agile development, pair
programming, globally distributed teams, outsourced projects, open
source development, and non-commercial software teams, may call
for different communication and knowledge sharing patterns. In
fact, non-commercial software may involve different communication patterns than commercial software [37,31]. Investigating how
knowledge sharing and knowledge sharing drivers are different in
various settings would improve our understanding of software
development processes and may have important implications for
managing projects in different contexts. The classication framework provides a basis for further analyses that examine and compare
the framework in different software development contexts.
6.2.4. Exploring new knowledge sharing drivers
Although the classication framework draws attention to a
comprehensive list of 44 knowledge sharing drivers, additional
knowledge sharing drivers can be explored by paying attention
into the growing contemporary issues in developing and using
software (e.g., distribution of open data, non-commercial software). For example, socio-political factors such as the promotion of
open data values and free software at national and international
levels (e.g., [41]) may encourage software developers and software
companies to participate in virtual software development and
support social values. Other possible avenues for future research
could be the intellectual engagement of different themes of
literature (e.g., open source, agile, distributed software development) for the fusion of concepts and perspectives and thereby
knowledge enrichment, e.g., the role of knowledge gifts in driving
knowledge sharing in agile development (discussed in Section 6.1).
6.2.5. Exploring new causal relationships
Based on Leavitts model, the ve causal links (dash lines) in the
classication framework suggest several opportunities for examining and exploring potential relationships, such as: (i) the causal
relationships between the seven subcategories (e.g., the causal link
between 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 as
computer interviewing (technology-related drivers) can be instrumental in eliciting information from end-users [33], using such
technologies can inuence the organizational dominance of endusers or developers (denitional control; team organization drivers),
promote cooperation or competition among them, and, in turn, have
a mixed effect on knowledge sharing behaviors [30]. Similarly,
future studies may focus on the dual effect of knowledge sharing
drivers; for example, in addition to facilitating understanding and
knowledge sharing, boundary objects can highlight team diversity in
managing boundary objects, cause conict and negative stereotyping (e.g., different cultures), disrupt a teams sense of identity, and, in
turn, adversely affect knowledge sharing [7].
6.2.6. Longitudinal approaches
The longitudinal effect of knowledge sharing on knowledge
sharing drivers is mentioned in some studies; for example, (i) gift
giving (sharing code) and answering others questions (knowledge sharing) in open source virtual teams can promote selflearning and increase a communicator s capability, reputation and
credibility [10], (ii) knowledge sharing may increase trust between
team members [38], and (iii) sharing public code in an open source
can decrease the contribution barriers of developers who will join
the virtual team in the future [92]. Future research may advance
the classication framework by exploring the dynamic and
longitudinal effect of knowledge sharing on knowledge sharing

drivers.
6.2.7. Frameworks for managing knowledge sharing risks
The 44 knowledge sharing drivers (e.g., representative roles,
trust between team members, interdependencies) and their
classication may provide a basis for understanding barriers or
risks to knowledge sharing in software teams. Specically,
depending on the situation, each of the 44 knowledge sharing
drivers may positively or negatively affect knowledge sharing. For
example, although representative roles may bridge communication between distributed sites, they can become bottlenecks (and
risks to effective knowledge sharing) if communication is primarily
channeled through them [12]. A careful monitoring and assessment of knowledge sharing drivers is an important prerequisite for
checking knowledge sharing patterns and their progress. Accordingly, future studies may link the 44 knowledge sharing drivers to
potential knowledge sharing risks and then possible techniques
for resolving them.
6.2.8. Operationalizing the classication framework
The knowledge sharing drivers and their denitions provide a
basis for the operationalization of the classication framework (e.g.,
creating measures). This can be facilitated by tracing knowledge
sharing, knowledge sharing drivers, their denitions and their
operationalization (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 to
what extent individuals have learned about technical and managerial/behavioral project issues from other team members [45], (ii)
measuring to what extent knowledge (meeting notes, ideas, knowhows) is shared among individuals [73,102], or (iii) counting the
number of email messages posted by team members to the mailing
lists and the number of replies they made to posted questions [87].
6.3. Practical implications
The importance of knowledge sharing creates extensive burdens
for coordination and communication throughout all stages of
software projects. To achieve effective knowledge sharing in
complex and dynamic development environments, software teams
must understand variations in people-related, structure-related,
task-related, and technology-related drivers (the four knowledge
sharing categories). Software teams may utilize the classication
framework by going through the list of knowledge sharing drivers
and assessing themselves against the 44 drivers to get a sense of their
strengths (e.g., collocated team) and the existing or potential
weakness areas (e.g., a clients unfamiliarity with agile development
requirements). The results of such analysis may suggest where
managerial efforts and resources should be directed to foster
knowledge sharing in any particular software project; for example,
where knowledge sharing may suffer from the lack of appropriate
collaboration technologies, project managers can help minimize the
risk by dening representative roles for facilitating communication
and by introducing extrinsic motives for encouraging knowledge
sharing behaviors. Finally, software teams may document the
results of their analysis and the devised strategies to (i) maintain a
registry of the identied drivers (both enablers and barriers) at
different stages, (ii) evaluate their progression over the course of the
project, and (iii) understand the longitudinal effect of devised
strategies on knowledge sharing practices.
7. Concluding points and limitations
Understanding factors that drive knowledge sharing in todays
software development teams is a prerequisite for allowing team
95
members to monitor knowledge sharing patterns and progress

and, in turn, to take steps toward achieving ideal levels of
communication and knowledge sharing. This article reviews and
synthesizes predominant literature regarding knowledge sharing
drivers in software teams. Recognizing the contextual nature of the
reviewed literature, diversity of knowledge sharing terminologies,
and at times denitional inconsistencies, 44 knowledge sharing
drivers are identied, distilled, classied, and integrated into a
classication framework. The classication framework provides a
rich picture of knowledge sharing drivers in software teams and
facilitates continued inquiry into studying knowledge sharing
practices in software development contexts. For example, the
analysis of results suggests valuable opportunities for focusing
on task-related and technology-related drivers, developing contextual-based frameworks, exploring new knowledge sharing
drivers, exploring new causal relationships, taking longitudinal
approaches, developing knowledge sharing risk management
frameworks, and operationalizing the classication framework.
Existing guidelines were followed to strengthen the review
process and provide a solid foundation for uncovering areas
where future research is required [97]. For example, (i) the
research topic, concepts, and boundaries are carefully explained
in Sections 2 and 4, (ii) the existing views in broad literature are
taken into account (Sections 1, 4 and 5), (iii) a conceptual
approach is selected, and the results are integrated into
conceptual representations (e.g., Table 2, Figs. 24), (iv) care is
given to choosing the tone and tense of the report, (v) a
classication framework to guide future research is developed
and discussed (Sections 5 and 6), (vi) the classication framework
is evaluated through focus group and in-depth interview sessions
(Section 4.4), and (vii) a detailed discussion of the ndings and
insights for future research is provided (Section 6).
Because the ndings are based on the reviewed studies, the
limitation of the reviewed papers may also apply to this research.
This challenge was managed by the careful selection of inclusion
criteria (e.g., the review involves empirically supported publications) and by conducting evaluation sessions involving senior
software professionals. We are not immune to the common
limitations of literature reviews, which are largely dependent on
the selected keywords [47]. For this, the review process and review
protocol were designed carefully, and scholars and professionals in
the eld were consulted regarding the results of each stage.
Software development literature is growing, and the popularity of
agile methodologies and hybrid software development (open
source and commercial) is on the rise. Accordingly, as new streams
of research emerge, future reviews on knowledge sharing in
software teams should pay attention to how different themes of
software 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 for
future studies.
Acknowledgment
I would like to thank the associate editor and the reviewers for
their constructive comments and suggestions on the earlier drafts
of this paper.
References
[1] M. Ackerman, V. Pipek, V. Wulf, Sharing Expertise: Beyond Knowledge
Management, MIT press, US, 2003.
[2] A.M. Aladwani, A. Rai, A. Ramaprasad, Formal participation and performance of
the system development group: the role of group heterogeneity and group-based
rewards, ACM SIGMIS Database 31, 2000, pp. 2540.
96
[3] A. Aman, B. Nicholson, Managing knowledge transfer in offshore software

development: the role of copresent and ICT-Based interaction, J. Glob. Inf.
Manage. 17, 2009, pp. 5573.
[4] A. Aurum, F. Daneshgar, J. Ward, Investigating knowledge management practices
in software development organisations: an Australian experience, Inf. Softw.
Technol. 50, 2008, pp. 511533.
[5] R.P. Bagozzi, U.M. Dholakia, Open source software user communities: a study of
participation in Linux user groups, Manage. Sci. 52, 2006, pp. 10991115.
[6] J. Bailey, D. Budgen, M. Turner, B. Kitchenham, P. Brereton, S. Linkman, Evidence
relating to object-oriented software design: a survey, Empirical Software
Engineering and Measurement, IEEE Computer Society, Madrid, Spain, 2007,
pp. 482484.
[7] M. Barrett, E. Oborn, Boundary object use in cross-cultural software development
teams, Hum. Relat. 63, 2010, pp. 11991221.
-a, M. Piattini, C.A. Visaggio, Pair designing as
[8] E. Bellini, G. Canfora, F. GarcA
practice for enforcing and diffusing design knowledge, J. Softw. Maint. Evol. Res.
Pract. 17, 2005, pp. 401423.
[9] E. Bellini, G. Canfora, A. Cimitile, F. Garcia, M. Piattini, C. Visaggio, The impact of
educational background on design knowledge sharing during pair programming:
an empirical study, Prof. Knowl. Manage. 1, 2005, pp. 455465.
[10] M. Bergquist, J. Ljungberg, The power of gifts: organizing social relationships in
open source communities, Inform. Syst. J. 11, 2001, pp. 305320.
[11] F.O. Bjrnson, T. Dingsyr, Knowledge management in software engineering: a
systematic review of studied concepts, ndings and research methods used, Inf.
Softw. Technol. 50, 2008, pp. 10551068.
[12] A. Boden, G. Avram, L. Bannon, V. Wulf, Knowledge management in distributed
software development teams-does culture matter? IEEE International Conference on Global Software Engineering, IEEE, Limerick, Ireland, 2009, pp. 1827.
[13] E. Carmel, J.A. Espinosa, Y. Dubinsky, Follow the sun workow in global software
development, J. Manage. Inf. Syst. 27, 2010, pp. 1738.
[14] S. Chakraborty, S. Sarker, An exploration into the process of requirements
elicitation: a grounded approach, J. Assoc. Inf. Syst. 11, 2010, pp. 212249.
[15] T. Chau, F. Maurer, Knowledge sharing in agile software teams, in: L. Wolfgang
(Ed.), Logic Versus Approximation, Springer, United States, 2004, pp. 173183.
[16] S.-W. Chou, M.-Y. He, Understanding OSS development in communities: the
perspectives of ideology and knowledge sharing, Behav. Inform. Technol. 30,
2011, pp. 325337.
[17] A.L. Chua, S.L. Pan, Knowledge transfer and organizational learning in IS offshore
sourcing, Omega 36, 2008, pp. 267281.
[18] K. Conboy, S. Coyle, X. Wang, M. Pikkarainen, People over process: key people
challenges in agile development, IEEE Softw. 8, 2010, pp. 4857.
[19] J.N. Cummings, Work groups, structural diversity, and knowledge sharing in a
global organization, Manage. Sci. 50, 2004, pp. 352364.
[20] B. Curtis, H. Krasner, N. Iscoe, A eld study of the software design process for
large systems, CACM 31, 1988, pp. 12681287.
[21] K.C. Desouza, Y. Awazu, P. Baloh, Managing knowledge in global
software development efforts: issues and practices, IEEE Softw. 23, 2006, pp.
3037.
[22] M.E. Falagas, V.D. Kouranos, R. Arencibia-Jorge, D.E. Karageorgopoulos, Comparison of SCImago journal rank indicator with journal impact factor, FASEB J. 22,
2008, pp. 26232628.
[23] S. Faraj, L. Sproull, Coordinating expertise in software development teams,
Manage. Sci. 46, 2000, pp. 15541568.
[24] B. Fitzgerald, K.-J. Stol, R. OSullivan, D. OBrien, Scaling agile methods to
regulated environments: an industry case study, International Conference on
Software Engineering, IEEE, San Francisco, CA, USA, 2013, pp. 863872.
[25] M.G. Friberger, G. Falkman, Collaboration processes, outcomes, challenges and
enablers of distributed clinical communities of practice, Behav. Inform. Technol.
32, 2011, pp. 519531.
[26] N. Ganesh, S. Thangasamy, Issues identied in the software process due to
barriers found during eliciting requirements on agile software projects: insights
from India, Int. J. Comput. Appl. 16, 2011, pp. 712.
[27] S. Garrett, B. Caldwell, Describing functional requirements for knowledge sharing communities, Behav. Inform. Technol. 21, 2002, pp. 359364.
[28] S. Ghobadi, Challenges of cross-functional software development teams: a
conceptual study, J. Inf. Technol. Manage. 22, 2011, pp. 2635.
[29] S. Ghobadi, J. DAmbra, Coopetitive relationships in cross-functional software
development teams: how to model and measure? J. Syst. Softw. 85, 2011, pp.
10961104.
[30] S. Ghobadi, J. DAmbra, Modeling high-quality knowledge sharing in crossfunctional software development teams, Inf. Process. Manage. 49, 2013, pp.
138157.
[31] S. Ghobadi, L. Mathiassen, Perceived barriers to effective knowledge sharing in
agile software teams, Inf. Syst. J. 2014, (in press).
[32] R. Gregory, R. Beck, M. Priing, Breaching the knowledge transfer blockade in IT
offshore outsourcing projects-A case from the nancial services industry, Hawaii
International Conference on System Sciences, IEEE, Hawaii, United States, 2009,
pp. 110.
[33] K. Hands, D.R. Peiris, P. Gregor, Development of a computer-based interviewing
tool to enhance the requirements gathering process, Requir. Eng. 9, 2004, pp.
204216.
[34] J. Hanisch, B. Corbitt, Impediments to requirements engineering during global
software development, Eur. J. Inf. Syst. 16, 2007, pp. 793805.
[35] G. Hertel, S. Niedner, S. Herrmann, Motivation of software developers in Open
Source projects: an Internet-based survey of contributors to the Linux kernel,
Res. Policy 32, 2003, pp. 11591177.
[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. 265290.
[37] J. Howison, J.D. Herbsleb, Scientic software production: incentives and collaboration, in: Proceedings of the ACM 2011 conference on Computer supported
cooperative work, ACM, 2011, pp. 513522.
[38] J.S. Hsu, T.P. Liang, S.P.J. Wu, G. Klein, J.J. Jiang, Promoting the integration of users
and developers to achieve a collective mind through the screening of information system projects, Int. J. Project Manage. 29, 2011, pp. 514524.
[39] J.C. Huang, S. Newell, Knowledge integration processes and dynamics within
the 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? Componentbased development and organizational subcultures IEEE Trans. Eng. Manage. 50,
2003, pp. 8999.
[41] N. Huijboom, T. Van den Broek, Open data: an international comparison of
strategies, Eur. J. ePract. 12, 2011, pp. 113.
[42] S.-Y. Hung, H.-M. Lai, W.-W. Chang, Knowledge-sharing motivations affecting
R&D employees acceptance of electronic knowledge repository, Behav. Inform.
Technol. 30, 2011, pp. 213230.
[43] P. Jackson, J. Klobas, Building knowledge in projects: a practical application of
social constructivism to information systems development, Int. J. Project Manage. 26, 2008, pp. 329337.
[44] B.D. Janz, P. Prasarnphanich, Freedom to cooperate: gaining clarity into knowledge integration in information systems development teams, IEEE Trans. Eng.
Manage. 56, 2009, pp. 621635.
[45] K.D. Joshi, S. Sarker, S. Sarker, Knowledge transfer within information systems
development teams: examining the role of knowledge source attributes, Decis.
Support Syst. 43, 2007, pp. 322335.
[46] S. Kaiser, G. Maseitz, Leveraging lead user knowledge in software development:
the case of weblog technology, Ind. Innov. 15, 2008, pp. 199221.
[47] B. Kitchenham, O. Pearl Brereton, D. Budgen, M. Turner, J. Bailey, S. Linkman,
Systematic literature reviews in software engineering a systematic literature
review, Inf. Softw. Technol. 51, 2009, pp. 715.
[48] M. Korkala, P. Abrahamsson, Communication in distributed agile development: a
case study, EUROMICRO Conference on Software Engineering and Advanced
Applications, 2007203210.
[49] J. Kotlarsky, I. Oshri, Social ties, knowledge sharing and successful collaboration
in globally distributed system development projects, Eur. J. Inf. Syst. 14, 2005,
pp. 3748.
[50] J. Kotlarsky, I. Oshri, J. Van Hillegersberg, K. Kumar, Globally distributed component-based software development: an exploratory study of knowledge management and work division, J. Inf. Technol. 22, 2007, pp. 161173.
[51] J. Kotlarsky, P.C. Van Fenema, L.P. Willcocks, Developing a knowledge-based
perspective on coordination: the case of global software projects, Inf. Manage.
45, 2008, pp. 96108.
[52] K.R. Lakhani, E. Von Hippel, How open source software works: free user-to-user
assistance, Res. Policy 32, 2003, pp. 923943.
[53] K. Lakhani, R. Wolf, Why hackers do what they do: understanding motivation
and effort in free/open source software projects, Perspectives on Free and Open
Source Software, 2005 pp. 322.
[54] H.J. Leavitt, Applied organization change in industry: structural, technical and
human approaches, in: W.W. Cooper, H.J. Leavitt, M.W. Shelly (Eds.), New
Perspectives in Organizational Research, John Wiley and Sons, New York, United
States, 1964, pp. 5571.
[55] A.S. Lee, R.L. Baskerville, Generalizing generalizability in information systems
research, Inf. Syst. Res. 14, 2003, pp. 221243.
[56] N. Levina, E. Vaast, Innovating or doing as told? Status differences and overlapping boundaries in offshore collaboration MIS Q. 32, 2008, pp. 307332.
[57] T.C. Lin, C.C. Huang, Withholding effort in knowledge contribution: the role of
social exchange and social cognitive on project teams, Inf. Manage. 47, 2010, pp.
188196.
[58] L. Lundvoll Nilsen, Collaboration and learning in medical teams by using video
conference, Behav. Inform. Technol. 30, 2011, pp. 507515.
[59] K. Lyytinen, M. Newman, Explaining information systems change: a punctuated
socio-technical change model, Eur. J. Inf. Syst. 17, 2008, pp. 589613.
[60] K. Lyytinen, L. Mathiassen, J. Ropponen, Attention shaping and software riska
categorical analysis of four classical risk management approaches, Inf. Syst. Res.
9, 1998, pp. 233255.
[61] M. Martnez-Torres, S. Toral, F. Barrero, D. Gregor, A text categorisation tool for
open source communities based on semantic analysis, Behav. Inform. Technol.
32, 2011, pp. 532544.
[62] L. McLeod, B. Doolin, Documents as mediating artifacts in contemporary IS
development, Hawaii International Conference on System Sciences, IEEE,
Hawaii, United States, 2010, pp. 110.
[63] L. McLeod, S. MacDonell, B. Doolin, Standard method use in contemporary IS
development: an empirical investigation, J. Syst. Inf. Technol. 9, 2007, pp. 629.
[64] G. Melnik, F. Maurer, Direct verbal communication as a catalyst of agile knowledge sharing, Agile Development Conference, IEEE, Utah, United States, 2004, pp.
2131.
[65] R. Michaelides, D. Kehoe, Internet communities and open innovation: an information system design methodology, International Conference on Computer and
Information Science, IEEE Computer Society, Melbourne, Australia, 2007, pp.
769775.
[66] S. Nerur, V.G. Balijepally, Theoretical reections on agile development methodologies, CACM 50, 2007, pp. 7983.

[67] S. Nerur, R.K. Mahapatra, G. Mangalaraj, Challenges of migrating to agile methodologies, CACM 48, 2005, pp. 7278.
[68] B. Nicholson, S. Sahay, Embedded knowledge and offshore software development, Inf. Organ. 14, 2004, pp. 329365.
[69] I. Oshri, J. Kotlarsky, L.P. Willcocks, Global software development: exploring
socialization and face-to-face meetings in distributed strategic projects, J. Strateg. Inf. Syst. 16, 2007, pp. 2549.
[70] I. Oshri, P. Van Fenema, J. Kotlarsky, Knowledge transfer in globally distributed
teams: the role of transactive memory, Inform. Syst. J. 18, 2008, pp. 593616.
[71] T.A. Pardo, A.M. Cresswell, F. Thompson, J. Zhang, Knowledge sharing in crossboundary information system development in the public sector, Inf. Technol.
Manage. 7, 2006, pp. 293313.
[72] R. Patnayakuni, A. Rai, A. Tiwana, Systems development process improvement:
a knowledge integration perspective, IEEE Trans. Eng. Manage. 54, 2007, pp.
286300.
[73] L.G. Pee, A. Kankanhalli, H.W. Kim, Knowledge sharing in IS development
projects: a social interdependence perspective, J. Assoc. Inf. Syst. 11, 2010,
pp. 550575.
[74] L.G. Pee, A. Kankanhalli, H.W. Kim, Knowledge sharing in information systems
development: a social interdependence perspective, J. Assoc. Inf. Syst. 11, 2010,
pp. 550575.
[75] J.S. Persson, L. Mathiassen, J. Boeg, T.S. Madsen, F. Steinson, Managing risks in
distributed software projects: an integrative framework, IEEE Trans. Eng. Manage. 56, 2009, pp. 508532.
[76] K. Petersen, R. Feldt, S. Mujtaba, M. Mattsson, Systematic mapping studies in
software engineering, International Conference on Evaluation and Assessment in
Software Engineering, 2008.
[77] R.R. Pushpa, M. Mathew, Interactive and collaborative behaviour of software
product-development teams, Team Perform. Manage. 16, 2010, pp. 434450.
[78] A. Riege, Three-dozen knowledge-sharing barriers managers must consider,
J. Knowl. Manage. 9, 2005, pp. 1835.
[79] T.L. Roberts, P.H. Cheney, P.D. Sweeney, Project characteristics and group communication: an investigation, IEEE Trans. Prof. Commun. 45, 2002, pp. 8498.
[80] J.A. Roberts, I.H. Hann, S.A. Slaughter, Understanding the motivations, participation, and performance of open source software developers: a longitudinal
study of the Apache projects, Manage. Sci. 52, 2006, pp. 984999.
[81] P.N. Robillard, The role of knowledge in software development, CACM 42, 1999,
pp. 8792.
[82] M. Rosemann, I. Vessey, Toward improving the relevance of information systems
research to practice: the role of applicability checks, MIS Q. 2008, pp. 122.
[83] S. Sarker, S. Sarker, Exploring agility in distributed information systems development teams: an interpretive study in an offshoring context, Inf. Syst. Res. 20,
2009, pp. 440461.
[84] S. Sarker, D.B. Nicholson, K.D. Joshi, Knowledge transfer in virtual systems
development teams: an exploratory study of four key enablers, IEEE Trans. Prof.
Commun. 48, 2005, pp. 201218.
[85] S. Sawyer, P.J. Guinan, J. Cooprider, Social interactions of information systems
development teams: a performance perspective, Inform. Syst. J. 20, 2010,
pp. 81107.
[86] K. Schott, Vendor-vendor knowledge transfer in global ISD outsourcing projects:
insights from A German Case Study, Pacic Asia Conference on Information
Systems, Brisbane, Australia, 2011.
[87] S.K. Sowe, I. Stamelos, L. Angelis, Understanding knowledge sharing activities in
free/open source software projects: an empirical study, J. Syst. Softw. 81, 2008,
pp. 431446.
[88] M.-T. Tsai, N.-C. Cheng, Understanding knowledge sharing between it professionals an integration of social cognitive and social exchange theory, Behav.
Inform. Technol. 31, 2012, pp. 10691080.
97
[89] J.D. Vakkayil, Learning through shared objects in outsourced software development, Int. J. Manag. Projects Bus. 4, 2011, pp. 616632.
[90] P.W.L. Vlaar, P.C. van Fenema, V. Tiwari, Cocreating understanding and value in
distributed work: how members of onsite and offshore vendor teams give, make,
demand, and break sense, MIS Q. 32, 2008, pp. 227255.
[91] O. Volkoff, M.B. Elmes, D.M. Strong, Enterprise systems, knowledge transfer and
power users, J. Strateg. Inf. Syst. 13, 2004, pp. 279304.
[92] G. Von Krogh, S. Spaeth, K.R. Lakhani, Community, joining, and specialization
in 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 acquisition, sharing, and integration, CACM 36, 1993, pp. 6377.
[94] S. Wang, R.A. Noe, Knowledge sharing: a review and directions for future
research, Hum. Resour. Manage. Rev. 20, 2010, pp. 115131.
[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. 79101.
[96] P.E. Waterson, C.W. Clegg, C.M. Axtell, Dynamics of work organization, knowledge and technology during software development, Int. J. Hum. Comput. Stud.
46, 1997, pp. 79101.
[97] J. Webster, R.T. Watson, Analyzing the past to prepare for the future: writing a
literature 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. 335356.
[99] G.O. Wiredu, Understanding the functions of teleconferences for coordinating
global software development projects, Inf. Syst. J. 21, 2011, pp. 175194.
[100] C. Xiang, Y. Lu, S. Gupta, Knowledge sharing in information system development
teams: examining the impact of shared mental model from a social capital
theory 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 literature review of interpersonal, intra-organizational and inter-organizational
success factors, Gov. Inf. Q. 28, 2011, pp. 164175.
[102] M. Yuan, X. Zhang, Z. Chen, D.R. Vogel, X. Chu, Antecedents of coordination
effectiveness of software developer dyads from interacting teams: an empirical
investigation, IEEE Trans. Eng. Manage. 56, 2009, pp. 494507.
[103] H. Zhuge, Knowledge ow management for distributed team software development, Knowl. Based Syst. 15, 2002, pp. 465471.
Shahla Ghobadi has a BEng in Industrial Engineering, a

MSc in Information Technology Management, and a
PhD in Information Systems from the University of
New South Wales, Australia. Her research focuses on
coopetition and knowledge management in software
development contexts and the social-political use of
the Internet. Her research is published (or in press) in
Information Systems Journal, Information Processing
& Management, Journal of Systems and Software,
Behaviour & Information Technology, Journal of
Knowledge Management, and AIS conferences such
as ICIS and ECIS. Shahla has worked extensively as a
consultant in software and automobile industries,
commercial and non-prot sectors, locally and internationally. She can be reached
at s.ghobadi@unsw.edu.au.

11) Knowledge Sharing in Development Teams

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

11) Knowledge Sharing in Development Teams

Hochgeladen von

Copyright:

Verfügbare Formate

Information & Management 52 (2015) 8297

Contents lists available at ScienceDirect

Information & Management

What drives knowledge sharing in software development teams:

Nonetheless, several challenges may complicate knowledge

S. Ghobadi / Information & Management 52 (2015) 8297

Exploring the role of transactive memory in distributed software

review on knowledge sharing drivers within software teams and

Fig. 1. Methodological phases.

S. Ghobadi / Information & Management 52 (2015) 8297

experienced researchers in the knowledge management and

S. Ghobadi / Information & Management 52 (2015) 8297

drivers. First, Leavitts organizational model [54] was chosen as the

one user interface designer were conducted. Participants were

S. Ghobadi / Information & Management 52 (2015) 8297

knowledge transfer is used to refer to the simple sharing of

S. Ghobadi / Information & Management 52 (2015) 8297

People-related drivers (21 drivers)

S. Ghobadi / Information & Management 52 (2015) 8297

Interdependencies refer to the degree to

Structure-related drivers (16 drivers)

S. Ghobadi / Information & Management 52 (2015) 8297

Established Practices for Communication

Organization design mechanisms facilitate knowledge ows by providing a structure through

Project Screening refers to the

In addition to investigating the effect of knowledge sharing

interdependent; for example, the duration of team membership

S. Ghobadi / Information & Management 52 (2015) 8297

encouraging people to signal their competence through recorded

can strengthen informal networks between developers ad client

S. Ghobadi / Information & Management 52 (2015) 8297

Fig. 2. Breakdown of citations to drivers.

sharing). The second type, represented by ve causal links (normal

The next section discusses the research and practical implication of

S. Ghobadi / Information & Management 52 (2015) 8297

Fig. 3. Breakdown of citations to subcategories.

drive knowledge sharing in software teams was undertaken. The

new phenomena, such as the specic effect of new technologies

S. Ghobadi / Information & Management 52 (2015) 8297

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

compared to distributed software teams literature, open source

for instance, open source software development relies on and

S. Ghobadi / Information & Management 52 (2015) 8297

more comprehensive picture of knowledge sharing drivers than

6.2.3. Contextual frameworks

S. Ghobadi / Information & Management 52 (2015) 8297

longitudinal effect of knowledge sharing on knowledge sharing

members to monitor knowledge sharing patterns and progress

S. Ghobadi / Information & Management 52 (2015) 8297

[3] A. Aman, B. Nicholson, Managing knowledge transfer in offshore software

S. Ghobadi / Information & Management 52 (2015) 8297

Shahla Ghobadi has a BEng in Industrial Engineering, a

Das könnte Ihnen auch gefallen