03-11-2016, 02:19 PM
1464014654-JaliliSLR2012.pdf (Size: 322.9 KB / Downloads: 18)
SUMMARY
Agile practices have received attention from industry as an alternative to plan-driven software development
approaches. Agile encourages, for example, small self-organized collocated teams, whereas global software
engineering (GSE) implies distribution across cultural, temporal, and geographical boundaries. Hence, combining
them is a challenge. A systematic review was conducted to capture the status of combining agility
with GSE. The results were limited to peer-reviewed conference papers or journal articles, published between
1999 and 2009. The synthesis was made through classifying the papers into different categories (e.g.
publication year, contribution type, research method). At the end, 81 papers were judged as primary for further
analysis. The distribution of papers over the years indicated that GSE and Agile in combination has received
more attention in the last 5 years. However, the majority of the existing research is industrial experience reports
in which Agile practices were modified with respect to the context and situational requirements. The emergent
need in this research area is suggested to be developing a framework that considers various factors from different
perspectives when incorporating Agile in GSE. Practitioners may use it as a decision-making basis in early
phases of software development. Copyright © 2011 John Wiley & Sons, Ltd.
INTRODUCTION
Distributed teams consisting of stakeholders from different national and organizational cultures, different
geographic locations, and potentially different time zones characterize global software engineering (GSE).
These characteristics have significant effects on communication, coordination, and control, and mitigating
the effects is a challenge [27].
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
[11]. They emphasize extensive collaboration between customers and developers, and encourage small
self-organized collocated teams [20].
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 [7],
whereas distance in GSE implies a different way of working, organizational standards, organizational
cultures and policies, which may decrease the team’s cohesion.
However, (globally) distributed Agile has attracted attention because of 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. [26] [9]), 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.
This research primarily aims at extending the systematic mapping study conducted by Jalali and
Wohlin [13] into a systematic review. The previous study provided a classification and a visual summary
of the type of research reports and results that have been published. The study methods and classification
approaches in a systematic mapping and a systematic review differ in terms of goals, breadth,
and depth [17]. Therefore, we have used both methods complementary. In this paper, the list of databases
is expanded, and the analysis is extended to research method, contribution, and the results of the
included papers. Further, the discussions are enriched and detailed in order to better explain the current
status of using Agile practices in GSE based on findings from the literature. Hence, 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 which GSE contexts.
The remainder of the paper is organized as follows. Section 2 gives a brief background and
summarizes related work. Section 3 discusses the research methodology and explains different steps
of conducting this systematic review. The results of the study are presented in Section 4, and
discussion and observations around them are provided in Section 5. Finally, conclusions and future
research directions are presented in Section 6.
2. BACKGROUND AND RELATED WORK
The Agile practices and GSE alternatives are shortly presented in this section before 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.
2.1. Agile practices
Agile methods consist of a set of practices for software development that have been created by
experienced practitioners [28], aiming at overcoming the limitations of plan-based approaches through
considering changes of the system’s requirements [11]. Agility is defined as “flexibility” and “leanness”
[6], and mentioned to be about “feedback and change” in a way to “embrace, rather than reject,
higher rates of change” [24].
Agile approaches focus on establishing close collaboration between customers and developers and
delivering software within time and budget constraints. Because they rely on frequent informal faceto-face
communication rather than providing lengthy documentation, the process is repetitive,
adaptive, and minimally defined [5].
The key features of Agile methods are continuous requirements gathering, frequent face-to-face
communication, pair programming, refactoring, continuous integration, early expert customer’s
feedback, and minimal documentation [4]. The most widely used methodologies based on the Agile
principals are Extreme Programming (XP) and Scrum. However, other methods such as FeatureDriven
Development, Dynamic Systems Development Method, crystal clear method, and Lean Development
have been also used [1][10].
2.2. Global software engineering
Geographically distributed software development teams characterize distributed software development,
whereas globally distributed teams characterize global software development [19]. In this study, we have
considered both as GSE. The description of different terms related to GSE is inspired by [19], 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.
2.3. 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. [26] [9]). 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 [4]. Nevertheless, various tactics and solutions are
also reported by different software organizations to mitigate these challenges.
2.4. Related work
Here, a summary of the previous relevant research is presented. Systematic review studies on Agile
methods or/and GSE are briefly presented. In addition, studies that have partially explored the
combination of any Agile method in any GSE context are introduced even though they are not a
systematic review study.
Dybå and Dingsøyr [10] conducted a systematic review of empirical studies of Agile software development
up to 2005 and it 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. [22], 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. [23] conducted a study in 2006 to evaluate the usefulness of the existing research on
Agile global software development for practitioners. The study included articles published between
2001 and 2005. They concluded that the published research is of minimal value to practitioners because
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 [4] 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. [16] 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. [12]. 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.
2.5. Motivations and objectives
Confirming the findings of the previous works [22] [12], 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
[22]. Hence, a standard approach for applying Agile in GSE does not exist despite the existence of
great interest in Agile methodologies from software industry.
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 GSE contexts. 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.
3. RESEARCH METHOD AND CONDUCT
The research was designed to be a systematic literature review following the guidelines provided by
Kitchenham and Charters [15]. 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. [17]. This paper presents all steps taken in designing
and conducting the systematic review and the results.
3.1. Research questions
Based on perceived need for conducting a systematic literature review in the area, the research
questions for this study are as follows:
RQ.1: What is reported in the peer-reviewed research literature about Agile practices in GSE?
In order to answer this question, the current research literature had to be explored and summarized
through conducting a systematic literature review study.
RQ.2: Which Agile practices in which GSE settings, under which circumstances have been successfully
applied?
To answer this question, the results of the systematic review had to be synthesized comprehensively
to identify the successful empirical cases reported in the literature and analyze them carefully.
3.2. 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, the research
questions, and the keywords were refined, search strings were reformulated, and searches were reconducted.
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.
Data sources
In a progressive process as discussed previously, the following databases were used: ACM Portal
(http://portal.acm.org), IEEE Xplore (http://ieeexplore.ieee.org), AIS (http://aisel.aisnet.org), Inspec
(http://www.engineeringvillage2.org), Compendex (http://www.engineeringvillage2.org), and Scopus
(http://www.scopus.com).
3.4. 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, XP, 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, XP, 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 written language was set to be English
and 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.
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.
3.5. 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 534 papers. The decision on inclusion/exclusion criteria was made based
only on the abstract because of two reasons. First, it is infeasible to evaluate the full text of 534 papers, and second, full text was not available for all papers. Based on the evidence found in the title, abstract, or keywords
implicitly or explicitly, the papers were categorized as “relevant”, “irrelevant”, or “maybe relevant”.
Although the search strategy was carefully planned in a way to minimize the number of irrelevant or
out-of-scope papers in the result of searches, many papers were judged as out of scope (e.g. not fit into
the software engineering discipline). Hence, we put them in the irrelevant category as well.
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 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 sent 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, 81 studies
were finally selected as primary papers for data extraction and synthesis.
3.6. Data extraction and synthesis
The guidelines provided by Petersen et al. [17] 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 in [14]). 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.
The classification scheme suggested by Wieringa et al. [25] 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 next.
Evaluation research: Techniques or solutions are implemented and evaluated in practice, and the
consequences are investigated.
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.
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.
Philosophical paper: It structures the area in the form of a taxonomy or conceptual framework, hence
sketches a new way of looking at existing things.
Experience paper: It includes the personal experience of the author on what and how something
happened in practice.
Opinion paper: The personal opinion on a special matter is reflected in an opinion paper without
relying on related work and research methodologies.
All 93 papers were fully read and 12 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 81
remaining papers, and the required items were extracted, coded, and stored in Excel. 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.
4. RESULTS
The data required for analysis was extracted by exploring the full text of each included paper. This section
presents the collected data.
4.1. Results of literature review
The outcome of the selection phase was 81 peer-reviewed papers and articles. Table I shows the distinctive
number of papers for each 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
indicates that GSE and Agile in combination have received more attention in the last 5 years. This is
not surprising given that the interest for both Agile and GSE has increased during the last 5–10 years.
The classification scheme explained in Section 3.6 was used for classifying the papers based on
the research type. The results of the categorization are presented in Figure 3. It shows that the
majority of the current literature is in the form of experience reports, in which practitioners have
reported their own experiences on a particular issue and the method used to mitigate it. The distribution
of different research types over studied years pinpoints the need for conducting more philosophical,
validation, and evaluation research. Although experience reports are valuable, evaluation and validation
research with a rigorous research method is required to establish foundations for a more mature area.
Furthermore, the collected data were processed to check which Agile practices had been applied in
which distribution settings (see Figure 4). The current literature is mostly using “Agile” as a general
term, and the term “distributed team” seems to be the most used team/organization setting in GSE.
However, 12 studies did not report the context, and it was not derivable from the full text of their studies.
The lack of context and the quite general formulations regarding Agile and team make it difficult
for others to make use of the findings