Copyright © IEEE.
Citation for the published paper:
This material is posted here with permission of the IEEE. Such permission of the IEEE does
not in any way imply IEEE endorsement of any of BTH's products or services Internal or
personal use of this material is permitted. However, permission to reprint/republish this
material for advertising or promotional purposes or for creating new collective works for
resale or redistribution must be obtained from the IEEE by sending a blank email message to
pubs-permissions@ieee.org.
By choosing to view this document, you agree to all provisions of the copyright laws
protecting it.
2010
Agile Practices in Global Software Engineering - A Systematic Map
Samireh Jalali, Claes Wohlin
International Conference on Global Software Engineering (ICGSE)
2010
Princeton, NJ
Agile Practices in Global Software Engineering – A Systematic Map
Samireh Jalali
Blekinge Institute of Technology
SE-372 25 Ronneby, Sweden
samireh.jalali@bth.se
Claes Wohlin
Blekinge Institute of Technology
SE-372 25 Ronneby, Sweden
claes.wohlin@bth.se
Abstract—This paper presents the results of systematically
reviewing the current research literature on the use of agile
practices and lean software development in global software
engineering (GSE). The primary purpose is to highlight under
which circumstances they have been applied efficiently. Some
common terms related to agile practices (e.g. scrum, extreme
programming) were considered in formulating the search
strings, along with a number of alternatives for GSE such as
offshoring, outsourcing, and virtual teams. The results were
limited to peer-reviewed conference papers/journal articles,
published between 1999 and 2009. The synthesis was made
through classifying the papers into different categories (e.g.
research type, distribution). The analysis revealed that in most
cases agile practices were modified with respect to the context
and situational requirements. This indicates the need for
future research on how to integrate all experiences and
practices in a way to assist practitioners when setting up non-
collocated agile projects.
Keywords-systematic map, agile, scrum, lean software
development, extreme programming, pair programming, global
software engineering, global software development, offshore,
outsource, virtual team, distributed team, open source.
I. INTRODUCTION
Distributed teams consisting of stakeholders from
different national and organizational cultures, different
geographic locations and potentially different time zones
characterize global software engineering. These
characteristics have significant effects on communication,
coordination, and control, and mitigating the effects is a
challenge [16].
In comparison with plan-driven software development
approaches, agile methods are more flexible when it comes
to taking requirements’ changes into consideration in all
phases of software development [7]. They emphasize
extensive collaboration between customers and developers,
and encourage small self-organized collocated teams [12].
Although mitigating the GSE challenges by themselves is
not a straightforward task, combining agile practices with a
global or distributed context complicates things even further.
Frequent face-to-face communication among collocated team
members improves a feeling of “teamness” and builds trust
[5], whilst distance in GSE implies a different way of
working, organizational standards, organizational cultures
and policies, which may decrease a team’s cohesion.
However, (globally) distributed agile has attracted
attention due to its potential associated benefits such as
shorter time to market, reduced development cost, and
managing late requirements’ changes. This indicates the
need for investigating the experiences reported in the current
research literature to determine how agile practices can be
efficiently applied in (globally) distributed projects.
Although several studies have reported successful integration
of agile and GSE (e.g. [S77][S14]), a thorough analysis of
the studies to reveal the applicability of the reported
experiences and best practices in different organizational
settings and project demands is yet unexplored.
The objective of this study is to first summarize the
current research literature, and then to investigate which
agile practices have been used effectively in a GSE context.
Hence, a systematic review was conducted limited to peer-
reviewed conference papers or journal articles, published
between 1999 and 2009.
The remainder of the paper is organized as follows.
Section 2 gives a brief background and summarizes the
related work. Section 3 discusses the research methodology
and explains different steps of conducting this systematic
map. The results of the study are presented in Section 4, and
finally conclusions and future research directions are
presented in Section 5.
II. B
ACKGROUND AND RELATED WORK
The agile practices and GSE alternatives are shortly
presented in this section following by putting agile practices
in the context of GSE. Moreover, related research work
regarding agile practices and GSE is summarized, and finally
the motivations and objectives of this study are explained.
A. Agile Practices
The agile software development approach aims at
overcoming the limitations of plan-driven approaches
through considering changes of the system’s requirements
[7]. Agile methods focus on establishing close collaboration
between customers and developers, and delivering software
within time and budget constraints. Since they rely on
frequent informal face-to-face communication rather than
providing lengthy documentation, the process is repetitive,
adaptive, and minimally defined [4].
The key features of agile methods are continuous
requirements gathering; frequent face-to-face
communication; pair programming; refactoring; continuous
integration; early expert customer feedback; and minimal
documentation [S6]. The most widely used methodologies
based on the agile principals are extreme programming (XP)
and Scrum. However, other methods such as feature-driven
development and the crystal clear method have been also
used [1].
B. Global Software Engineering
Geographically distributed software development teams
characterize distributed software development, whilst
globally distributed teams characterize global software
development [11]. In this study, we have considered both as
GSE. The description of different terms related to GSE is
inspired by [11], and the authors have only made minor
changes and generalization presented as follows.
Outsourcing (offshore/onshore outsourcing): an external
company is responsible for providing software development
services or products for the client company. When both
subcontracting and client companies are located in the same
country, it is known as onshore outsourcing.
Offshoring (offshore insourcing): a company creates its
own software development centers located in different
countries to handle the internal demand.
Distributed team: team members are spread in different
locations and work remotely on different parts of the project
(independent tasks) with or without any face-to-face
interactions. The difference between a virtual and a
distributed team is that virtual team members work jointly on
the same tasks.
C. Agile Practices in Global Software Engineering
Although agile methods are well suited when customers
and developers are collocated and there is frequent
interaction among them [3], several software organizations
have reported their successful experience of incorporating
agile in distributed software development (e.g. [S77][S14]).
However, there are challenges associated with this
combination, and to get it to work effectively considerable
effort is needed. The major difficulties are summarized as
related to communication, personnel, culture, different time
zones, trust, and knowledge management [S6]. Nevertheless,
various tactics and solutions are also reported by different
software organizations to mitigate these challenges.
D. Related Work
Here, a summary of the previous relevant research is
presented. Systematic review studies on agile methods
or/and global software engineering are briefly presented. In
addition, studies that have partially explored the combination
of any agile method in any GSE context are introduced even
though if they are not a systematic review study.
Dybå and Dingsøyr [6] have conducted a systematic
review of empirical studies of agile software development up
to 2005 resulted in identifying 36 relevant empirical studies.
Besides the comprehensive analysis of the papers, the need
to increase both the number and the quality of studies and to
establish a common research agenda in the area of study is
pinpointed.
In a systematic review study by Smite et al. [14] the
empirical evidence in GSE-related research literature has
been investigated. The amount of empirical studies in the
area was found to be relatively small, hence it is concluded
that the GSE field is still immature. Hence, they have shed
light on paths for future work for both researchers and
practitioners.
Taylor et al. [S65] conducted a study in 2006 to evaluate
the usefulness for practitioners of the existing research on
agile global software development. The study included
articles published between 2001 and 2005. They concluded
that the published research is of minimal value to
practitioners since they do not provide novel guidance
particularly for distributed agile. It is concluded that the
current research of experience reports is similar to the guides
available before introduction of agile.
Bose [S6] performed an interesting study in 2008. He
selected 12 case studies from literature that claimed to be
successful in distributed agile software development, and
summarized them. The cases were evaluated in comparison
with the agile manifesto to determine to what extent agile
values and principles are followed. He discovered some
innovative reported solutions for overcoming the challenges
of distributed agile development. The conclusion was that
although many solutions seemed to be unique for the context
of the challenges, they can still suitably guide companies in
establishing and running distributed agile software
development.
Paasivaara et al. [S44] have described how Scrum
practices were adopted to benefit from distributed software
development. Multiple case studies were conducted and the
collected lessons learned were summarized. In addition, they
have summarized the results of literature review on practices
used in distributed agile software development. However, the
main contribution is not to explore the previous work.
Hence, a systematic literature review has not been
conducted.
The only systematic literature review in the area is
published in 2009, and is performed by Hossain et al. [S27].
It reviews 20 primary papers and identifies challenges of
using Scrum in global software development. Additionally,
the best practices addressing the identified challenges have
been extracted. The presented guidelines and conclusions
can help both practitioners and researchers in the area.
E. Motivations and Objectives
Confirming the findings of the previous works [14][S27],
the existing research in the area is exploratory in nature and
mostly reports the cases in which some challenges were
faced and some strategies were applied. It is also confirmed
that lessons learned in one context may not directly apply in
another one [13]. Hence, a standard approach for applying
agile in GSE does not exist.
Exploring previous research showed that a
comprehensive systematic review that covers all agile
methods in all GSE settings does not yet exist. Such a
systematic review helps identifying different conditions and
factors, which affect the success of agile methods in GSE
contexts. Hence, this study aims at systematically reviewing
and summarizing the existing research literature, and
investigating which agile practices have been used
effectively in a GSE context. The results and findings may
help practitioners in visualizing the risks and benefits of
agile global software development, and hence improving the
performance in their work. It also helps researchers in
obtaining an overview of the status of the area and
highlighting the gaps.
III. RESEARCH METHOD AND CONDUCT
The research was initially designed to be a systematic
literature review following the guidelines provided by
Kitchenham and Charters [8]. The first phase of the study
was to draw a systematic map, in which the guidelines on
how to conduct a systematic review was considered along
with guidelines provided for performing a systematic map by
Petersen et al. [9]. This report presents all steps taken in
designing and conducting the systematic review, and
presents the results considering the systematic map
guidelines.
A. Research Questions
Regarding the need for conducting a systematic literature
review in the area, the research questions for this study set to
be as follows.
1) RQ.1. What is reported in the current peer-reviewed
research literature about Agile practices in GSE?: In order
to answer this question, the current research literature had to
be explored.
2) RQ.2. Which agile practices, in which GSE settings,
under which circumstances have been successfully
applied?: To answer this question, the results of the
systemaric review had to be synthesized comprehensively.
B. Search Strategy
The research started with defining a suitable scope,
which was initially set to cover all agile practices in all types
of distributed development. It led to setting the preliminary
research questions, and identifying the keywords. The initial
keywords were searched in well-known databases such as
ACM Portal and IEEE Xplore. Based on the search results,
the research scope, research questions, and keywords were
refined, search strings were reformulated, and searches were
re-conducted. Moreover, the list of databases was expanded
to collect as many relevant papers as possible. In parallel, a
list of key papers was generated, which was used as a
validation list to ensure the reliability and relevancy of the
searches and to evaluate the search strings. The summary of
the process is shown in Figure 1.
C. Data Sources
In a progressive process as discussed previously, the
databases were decided as follows.
1) ACM Portal (http://portal.acm.org): This provides a
collection of citations and full-text from ACM journal and
newsletter articles and conference proceedings and covers
IT and programming areas.
2) IEEE Xplore (http://ieeexplore.ieee.org): It covers
electrical engineering, computer science, and electronic
subject areas, and provides full-text and bibliographic
access to IEEE transactions, journals, magazines and
conference proceedings published since 1988.
3) Inspec (http://www.engineeringvillage2.org): Inspec
gives bibliographic access to scientific literature in several
subjects including electrical engineering, control
engineering, information technology, communications,
computers, and computing. It is an online database that
includes literature from 1969 to the present, and records are
updated weekly.
Figure 1. Search strategy and process
4) Compendex (http://www.engineeringvillage2.org):
Compendex is a comprehensive interdisciplinary
engineering database with 9 million records referencing
5,000 engineering journals and conference materials since
1884.
5) AIS (http://aisel.aisnet.org): It covers research papers
and journal articles in information systems (IS). The reason
for including AIS elibrary was to cover papers with an IS
perspective.
D. Data Retrieval
Search strings were formulated by combining different
agile practices and different types of distribution. It can be
summarized as: (X1 OR X2 … OR Xn) AND (Y1 OR Y2 …
OR Yn), where X covers most common agile practices and Y
includes different alternatives of GSE as presented in the
following.
X: {agile, scrum, extreme programming, pair
programming, lean development, lean software
development}
Y: {global software engineering, global software
development, distributed software engineering, distributed
software development, GSE, GSD, distributed team, global
team, dispersed team, spread team, virtual team, offshore,
outsource, open source}
Agile practices were limited to scrum, extreme
programming, pair programming, and lean software
development, intending to cover the most common ones,
which are mostly used in practice. In addition, the objective
was to ensure a clear focus on the scope of the systematic
review. However, all spelling alternatives of keywords were
considered (e.g. offshore, offshoring, off-shore, offshored,
etc).
Furthermore, some limitations were applied on the
searches. The publication year was set to be between 1999
and 2009 with the purpose of summarizing the updated
relevant related work in approximately the past decade. The
written language was set to be English. In order to reduce the
number of irrelevant hits, the search places were limited to
title, abstract, and keywords. It should be noted that only
peer-reviewed publications were taken into consideration
and gray literature has not been explored.
E. Inclusion Process
The steps taken to extract the final set of studies for
further synthesis are summarized in Figure 2. The searches
resulted in identifying 192 papers. The decision on
inclusion/exclusion criteria was made based only on the
abstract due to the fact that the full-text was not available for
many of the papers. This was due to the fact that it was
deemed very difficult to order and pay for the papers and
then later find out that they should be removed from the
further analysis. Based on the evidence found in the title,
abstract or keywords implicitly or explicitly, the papers were
categorized as “relevant”, “irrelevant” or “maybe relevant”.
Figure 2. Inclusion process and results
In order to decrease the single researcher’s bias at this
stage, the list of “irrelevant” and “maybe relevant” ones was
given to the second researcher without showing the previous
judgments. The result of the second judgment was slightly
different regarding the “irrelevant” papers. However, it was
decided not to include the papers with one “irrelevant” vote
and one “maybe relevant”. Papers that both researchers
classified them as “maybe relevant” were included in the
further analysis.
Finally, both researchers agreed upon a final set of papers
for in-depth analysis. If the full paper was not accessible, an
email was delivered to the main or second author asking for
the paper in pdf. At the analysis step of this study, two
emails remained unanswered, so those two papers were
excluded. In addition, papers with no result or the same
content as other studies were excluded. Thus, 77 studies
were finally selected as primary papers for data extraction
and synthesis.
F. Data Extraction and Synthesis
The guidelines provided by Petersen et al. [9] were used
to build the classification scheme. Although they have
suggested exploring the text adaptively if the abstract was
not well structured, we decided to study full-text. We piloted
a few studies and realized that critical information such as
agile practices, distribution type, and research method could
not be extracted only from the abstract.
MS Excel was used for data extraction and collection
(see Appendix 1). The items in the form were selected in
alignment with the objectives of this study aiming at
enabling the authors to answer the research questions by
analyzing the extracted data.
All 88 papers were fully read and 11 were excluded at
this stage because either the results were not reported or the
same study was reported more than once. Hence, data
analysis was made for 77 remained papers, and the required
items were extracted, coded, and stored in Excel sheets.
Finally, several descriptive classifications of the content of
the studied papers were made with respect to research
methodology, empirical background, findings, participants,
and context of the studies.
IV. R
ESULTS
The data required for analysis was extracted by exploring
the full-text of each included paper. This section presents the
collected data.
A. Results of Literature Review
The outcome of the selection phase was 77 peer-
reviewed papers and articles. Table I shows the number of
papers for each studied year (1999-2009). The maximum
was in 2008 with 20 papers, and no relevant paper was found
in 1999, 2000, and 2001 as well as few papers in 2002 and
2003. This seems to indicate that GSE and agile in
combination has received more attention in the last five
years. This is not surprising given that the interest for both
agile and GSE have increased during the last 5-10 years.
TABLE I. DISTRIBUTION OF PAPERS OVER THE STUDIED YEARS
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
ACM
2 2 3 2
IEEE
1 2 1 2 6 15 9
Compendex
1 1 2 4 4 2 2
Inspec
1 5 1 3 2 1
AIS
12
Total
00012 10 6 12132013
The classification scheme suggested by Wieringa et al.
[15] was used as a basis for determining the research type for
the set of papers. A short description of each category, which
was considered in this study, is provided below.
1) Evaluation Research: Techniques or solutions are
implemented and evaluated in practice, and the
consequences are investigated.
2) Validation Research: Techniques are novel, but still
have not been implemented in practice. This is typically a
study of a technique in a laboratory environment.
3) Solution Proposal: A solution for a problem is
proposed, and the benefits are discussed. The difference
between a solution proposal and a validation research is in
the level of abstraction for suggested solutions, which is
higher for solution proposals.