Challenges in Distributed Agile Software Development Environment: A Systematic Literature Review

Abstract

Due to increasing interest in distributed agile software development, there is a need to systematically review the literature on challenges encountered in the agile software development environment. Using the Systematic Literature Review (SLR) approach, 32 relevant publications, dated between 2013 and 2018 were selected from four electronic databases. Data from these publications were extracted to identify the key challenges across the system development life cycle (SDLC) phases, which essentially are short phases in each agile-based iteration. 5 types of key challenges were identified as impacting the SDLC phases; these challenges are Communication, Coordination, Cooperation, Collaboration and Control. In the context of the SLDC phases, the Communication challenge was discussed the most often (79 times, 33%). The least discussed challenges were Cooperation and Collaboration (26 times, 11% each). The 5 challenges occur because of distances which occur in distributed environment. This SLR identified 4 types of distances which contribute to the occurrence of these key challenges - physical, temporal, social-cultural and knowledge/experience. Of the 32 publications, only 4 included research which proposed new solutions to address challenges in agile distributed software development. The authors of this article believe that the findings in this SLR are a resource for future research work to deepen the understanding of and to develop additional solutions to address the challenges in distributed agile software development.

1. Introduction

This paper is a Systematic Literature Review (SLR) regarding the challenges of distributed agile development. A SLR is a critical evaluation and summarization of previous research related to the research question(s) [1] and is conducted in a sequence of structured and systematic stages to gather, assess and synthesize the available knowledge [2].

Agile software development methods were originally intended for small projects with co-located team members [3, 4]. Co-location enables face-to-face collaboration between team members which facilitates rapid releases of working software. This results in benefits such as delivering value to the business more frequently than traditional software development methods, enabling more timely changes to the software being developed and improving rates of fixing software defects [5, 6].

Given these benefits, the use of agile was extended to larger-scale software projects, including those where teams work in distributed locations [3, 7]. Using agile for distributed software development has been associated with benefits such as follow-the-sun development which increases overall project productivity, reducing costs by moving work to lower cost countries and having access to a wider pool of talent [5, 7]. However, the use of agile methods in distributed environments is challenging because of the conflict between agility and distribution [25, 29, 32]. The limited or non-existent opportunities for face-to-face interactions is the key root cause of obstacles when using agile software development in a distributed context [5, 7, 8].

After studying several papers from the existing literature, we have identified five challenges in distributed agile software development. We call them “5-Cs of Challenges". They are control, collaboration, cooperation, coordination, and communication. These challenges are caused by four types of distances. We call them “Distance Factors”. These distances are physical distance, temporal distance, socio-cultural distance and knowledge /experience distance. In order to resolve these challenges, certain researchers have proposed methods. We discuss these methods in this paper as well.

 

2. Motivation

Given the widespread use of software in companies, and the increasing globalization of businesses, many software development projects are being carried out by distributed teams, and the numbers continue to grow [9]. Many distributed teams use the agile approach for their software development. As per the 2017 report by VersionOne [10], “86% of respondents had at least some distributed teams practicing agile”.

Additionally, 20% of those surveyed in [10] responded that agile helped to improve the management of distributed teams. However, despite the high adoption rates and benefits of distributed agile, there is recognition of the lack of depth of research in this area and the need for more attention from the academic community to understand the impact of agile on distributed teams [3, 6, 54, 55]. Though, some of the areas are still relevant but have been polished significantly such as “trust, and control”. One of the published work [5] was systematic literature review on distributed agile environment but it was a short form of literatrue. Thus, it was appropriate to consider relatively a mature era (after 2013), rather than relatively immautre era (before 2013) whereas several issues have been resolved already.

 

3. Research Method

The method used to research this SLR is outlined in Fig. 1 below. This method was developed based on the 3-phase approach described in the technical report by Kitchenham & Charters in [2] and incorporating lessons learnt of conducting SLR within s of twareengineering as described in [11]. Therefore, it was more appropriate to use the enhanced version of [2] in this study.

 

Fig. 1. Research method used in this systematic literature review

 

3.1 Research Questions

The following questions were studied in this review:

R1: For each of the system development life cycle (SDLC) phases (analysis, design, implementation, testing, deployment and maintenance) within agile iterations, what are the challenges which impact the use of the Agile approach in distributed development teams?

•  Motivation for R1: There is a lack of literature that could go deeper into phase-level in agile-based iterations and synthesise challenges scattered in several studies because product owner is sitting somewhere else with the customer. But both are working together in the same iteration.

R2: Based on the challenges identified in R1, what are the most common challenges throughout all the phases?

•  Motivation for R2: After analysing challenges in individual phases, it is inadequate if we do not synthesise them together to share an overall picture to the reader, especially in terms of common challnges in each phase during iteration cycles.

R3: For each of the most common challenges identified in R2:

R3-1: What are the factors which contributed to the existence of each of these challenges?

R3-2: What are the recommended solutions to overcome each of these challenges?

•  Motivation for R3: There is a need to sythesise factors contributing to the challenges, which are scaterred in seveal studies. Also, it is equally important for the readers to know the available solutions to resolve these challenges.

 

3.2 Search Keywords

Based on the research questions, set of keywords was constructed to be used in the electronic database search described in section 3.4

1) The first part was related to the word challenge and its synonyms; i.e. challenge, issue, problem, obstacle, limitation, difficulty and barrier.

2) The second part was “distributed agile”.

3) The third part was related to the phases in an Agile development; i.e. analysis, design, implementation, testing, deployment and maintenance.

4) The forth part was related to specifice agile methods i.e. Scrum, XP, FDD and DSDM

These search keywords were combined using Boolean operators, resulting in the following search string: (challenge OR issue OR problem OR obstacle OR limitation OR difficulty OR barrier) AND (distributed AND agile) AND (global AND agile) AND (distributed AND Scrum) AND (distributed AND eXtreme Programming) AND (distributed AND Feature Driven Development) AND (distributed AND Dynamic Systems Development Method) AND (analysis OR design OR implementation OR testing OR deployment OR maintenance)

 

3.3 Process to Select Set of Publications for Analysis

The phase “Conducting the SLR” as per Fig. 1 above involves the selection of the set of publications for data extraction. The process to identify this set of publications for inclusion in this SLR has 4 steps as illustrated in Fig. 2 below. Details are described in sections 3.4 and 3.5.

 

Fig. 2. Process to select final set of publications for inclusion

 

3.4 Search of Electronic Databases

The electronic databases searched (Fig. 2, Step 1) were the ACM digital library, IEEEXplore, ScienceDirect and SpringerLink. The coverage provided by these 4 databases were deemed sufficiently extensive for this SLR. Within these databases, only English publications in the field of Computer Science. Using the search keywords listed in section 3.2 resulted in a total search result of of 3,695 publications.

 

3.5 Inclusion and Exclusion Criteria

Using the results of the electronic database search, the next step (Fig. 2, Step 2) in the selection process was a review of titles, keywords, and abstracts against the search strings -those which had words which matched the search strings were included whereas those which did not were excluded. From the 3,695 identified from Step 1, only 59 (2%) were included whereas a large majority (3,636, 98%) of publications were excluded. Apparently, it looks like a drastic reduction in number of papers. The reason we noticed was that, based on theese strings, search engines bring up several papers that merely mention “distributed agile” in the text. For instance, this portion of our search string

“(distributed AND Scrum) AND (distributed AND eXtreme Programming) AND (distributed AND Feature Driven Development) AND (distributed AND Dynamic Systems Development Method)”

brings up 87 articles from ScienceDirect, 103 from IEEE Xplore, 109 from SpringerLink and 35 from ACM digital library. Of these almost 334 articles, majority was brought up because they mentioned “distributed” in their titles such as “Reliability and availability issues in large-scale distributed systems”, or “Crowd Sensing Applications: A Distributed Flow-Based Programming Approach”, and many like these. Such papers were absolutly out of the focus of our study hence were not included for further review. This is one of the limiations of search engine as their algorithms are designed to bring up wider range of results which poses difficulty for the reseachers of SLR, and waste the time to review irrelevant papers as well.

The search keywords identified in section 3.2 resulted in a broad search string which generated a high number of search results when used in the search engines of the electronic databases being searched. The high number of search results, which required significant manual effort to filter the titles, keywords and abstract to reduce the numbers to a more managed able set for review of the abstracts; had the benefit of reducing selection basis as compared if a more narrow search string had been used.

Table 1 provides the inclusion and exclusion results, by database, from the review of titles, keywords and abstracts.

 

Table 1. Inclusion and exclusion results from review of titles, keywords and abstracts

Step 3 in the selection process (Fig. 2, Step 3) was a review of the abstracts of the 59 publications included from the previous step. This review assessed if the abstract provided an indication that the publication contained data relevant to answer the research questions. Publications were included if they did and excluded if otherwise. This resulted in 44 (75%) publications included and15 (25%) publications excluded and as input into the next step.

The final step (Fig. 2, Step 4) in the process was a high level review of the full text of the 44 publications included from the Step 3. This full text high level review assessed if the contents of the publication were relevant to the research questions. A publication was included if the contents were relevant and excluded otherwise. This resulted in 32 (73%) inclusions and 12 (27%) publications being excluded.

 

4. Types of Distributed Teams

 

4.1 Distributed Team Members and / or Distributed Teams

Within the 32 publications, 3 different types of distributed projects were discussed. These differences were typically a result of the scope of the research being conducted and not due to different definitions. The 3 types project distribution described in the publications were:

1) Single-team; distributed team members - refers to a single team where team members are distributed in different physical locations: For example [12] described a team of testers which are distributed across 2 European countries and India; and [13] discussed a team where 15 members of a test team are in Norway and China. There were 2 [14, 15] other publications which described this type of distribution ; making it a total of 4 (13%) publications.

2) Multiple distributed teams; co-located team members - are multiple teams located in different physical locations; and where team members within the same team are co- located in the same place. For example, [16] described a software that was developed with 16 teams distributed across three continents (Asia, Europe and North America). All team members within a team are co-located to enable face-to-face interactions. [17] discussed the development of a software product where there were 3 development teams - two in different locations in North America and the third team in India - team members in each location were working physically together. 5 other publications [18-22] also researched projects with multiple distributed teams and co-located team members; a total of 7 (22%) publications

3) Multiple distributed teams; distributed team members - these are where teams are in different locations and team members are not co-located but also spread out in various places. For example, [23] is a case study of a development project where teams and team members within the teams were distributed across 3 countries (Germany, India and USA). [24] described multiple projects with teams that were distributed across 2 or more countries in Europe. 13 other publications researched projects where both teams and team members were distributed [25-37]; a total of 15 (47%) publications.

 

Fig. 3 below illustrates these 3 types of distributed and lists the publications in which these types of distribution are discussed.

For the remaining 6 (19%) publications [38-43] the distribution of the projects researched were not specified or unclear

 

Fig. 3. Types of distributed teams

 

4.2 Scale of Physical Distribution

The publications included in this SLR described projects which encompassed a range of scale of physical distributions. The least physically distributed were projects which were in the same city but in different locations in the city. The most distributed were projects which were distributed across different countries; with different time zones. Table 2 provides a summary of the range of scale of distribution described in the publications.

1) It was observed that the most limited distribution were projects which were in the same city but in different physical locations [14, 24, 37, 41].

2) A slightly larger scale of project distribution was those located in different cities within the same country and with no time difference between the cities [24, 25, 34].

3) There were also projects which were distributed across different countries which were in the same time zone [24, 25, 35].

4) Most of the publications described projects which had the widest scale of distribution - these projects were distributed across different countries covering different time zones [12-18, 20, 21, 23, 26-31, 36, 38-40, 42].

5) There were 5 publications [19, 22, 32, 33, 43], which although there was mention that teams were in different locations, did not specify if these were in the same or different cities or countries.

 

Table 2. Scale of project distribution

 

4.3 Distance Factors Causing Challenges

A key underpinning of the Agile Manifesto [44] is individuals and teams working closely with each other resulting in rapid turnaround of the software being developed. Working closely requires an awareness of the activities which the individuals and teams are working on; and provides context for each other’s work [45, 46], thus enabling the close interactions which the manifesto describes. Distributed agile development however introduces distances which create barriers to developing a strong awareness of others. There are 4 key types of distances, which we refer to as the “Distance Factors” affecting distributed agile. The "Distance Factors” are:

1) Physical distance. This is the most fundamental distance which occurs in distributed projects. This distance refers to individuals or teams who are in different locations and have no face-to-face visibility to each other [14]. We recommend the use of thisphysical distance instead of geographical distance which is used in some publications. The latter is a more limited definition of distributed (i.e. being in different parts of acity [37], different parts of the same country [24] or different countries [12]. The former is a broader definition of distributed as it encompasses the latter, and includesthe additional definition of being in a different part of a floor / building.

2) Temporal distance. This distance refers to being separated by time zones or working on different shifts with limited or no time overlap [14, 38, 47].

3) Socio-cultural distance. This is the most complex of distances and refers to individuals / teams where their differences are caused by their socio-culturalenvironment. These include differences such as different languages, different cultural believes, different ethical values and different work practices [47, 48]. Whilst socio-cultural distances exist even with co-located individuals; the physical distance exacerbates the social-cultural distance.

4) Knowledge / Experience distance. This refers to knowledge / experience that is related to the organization for which the software is being developed for. A project team which is closer to the main hubs of the organization have better knowledge /experience of the organization than those which are further afield [16, 36, 49]. It also refers to the different levels of knowledge / experience across distributed teams [20].

These “Distance Factors”, which occur when work is distributed, contribute to the existent of challenges with the agile approach which is premised on proximity. Based on the data from the publications reviewed for this SLR, we propose grouping these challenges into 5 categories, which we refer to as the “5-Cs of Challenges” - Communication, Coordination, Cooperation, Collaboration and Control. The “5-Cs of Challenges” is developed based on previous frameworks to categorize challenges in software development [47, 50]. The uniqueness of the proposed “5-Cs” grouping is that whilst previous literature described sub-sets of the fives challenges, our research has identified that assessment of the challenges of distributed agile software development should be done from all 5 areas to provide a more comprehensive perspective. Additionally, it is the addition of the understanding of the “Distance factors” which contribute to the existence of the “5-Cs” that adds to the uniqueness of our findings. It is worth nothing that whilst Cooperation and Collaboration are sometimes used inter changeable, these 2 terms have subtly different meanings - in particular, Collaboration requires Cooperation whereas Cooperation can exist without Collaboration [53].

 

Fig. 4. The “5-Cs of challenges”

The “5-Cs of Challenges” is depicted visually in Fig. 4 and described in more detail below.

• Communications refers to unambiguous and transparent sharing of information - formally and / or informally; verbally and / or written; in hardcopy and / or digital format [47, 50]. Project documentation, knowledge management systems and
  training are considered part of communications.
• Coordination is the sequencing and integration of inter-dependent activities to achieve a common objective / outcome [47, 50].
•  Cooperation is when two (or more) individuals / teams have mutually agreed to work on activities which have been divided amongst each other [52, 53].
•  Collaboration takes cooperation to the next level - where individuals / teams not only agree to work together but do so for mutual benefit and develop deep meaningful relationships when working together [52-53].
•  Control refers to the governance and project management activities in system development [47, 51]. Provision of the required work environment (e.g. office space, hardware and software) fall in this category. We thus propose the “Distance Factors and 5-Cs of Challenges” framework as discussed in this SLR.

 

5. Discussion of Research Questions

 

5.1 Answer to R1- Challenges by Phases

Before we elaborate these challenges, it is useful to mention that there are several obvious differences in agile and traditional development approaches. Majority of them is related to the “practices” in a development environment such as customer involvement, less design, more collaboration among team members. However, in terms of common features, one of the fundamental commonalities between waterfall method and agile approach is that agile approaches e.g., Scrum, FDD, DSDM, Kanban, Scrumban are phase-based methods, like we have in waterfall. In these methods, team literally have to execute waterfall like phases (user stories/requirements analysis, design, implementation, testing, deployment and maintenance). But these are shorter phases in agile environment as compared to a traditional waterfall method. Agile approaches e.g., Lean and XP are practice-based approaches (no-phases in them so far). These practice-based approaches work inside these phases such as XP preaches to have less documentation or design in design phase and so on. The purpose of short -phases is to achieve frequent delivery, early feedback and/or fail-fast among others.

 

5.2 Answer to R2 - The Most Common Challenges

Based on Fig. 5 which is visualization of the frequency distribution of the number of times the 5-Cs are discussed in the publications in this SLR, the most common challenge is Communications (at 33%) followed by Coordination (28%). The other 3 challenges are discussed significantly less frequently; i.e. >=10% less frequent than the Communication and Coordination challenges.

 

Fig. 5. Frequency of discussion of the 5-Cs

Within the communication category of challenges for agile distributed projects, there exists the challenge between onshore and offshore software development. An offshore site team requires efficient communication to reduce the iteration time with teams at the onshore sites. However, it is not only onshore and offshore teams which face communication challenges. Customers in a distributed environment also face difficulties in resolving project issues due to the limited opportunity for face-to-face communications.

 

5.3 Answer to R3-1 - Factors Contributing to the 2 Most Common Challenges
(Communication and Coordination)

For the 2 most common challenges (Communication and Coordination) as identified in section 5.1, the frequency of the distances which contribute to the occurrence of each of these challenges, as discussed in the SLR publications, are summarized in Table 3 below.

 

Table 3. Distances which contribute to the communication and coordinate

Fig. 6 below is a visual representation of the frequencies of the distances. As these the figure shows, the most frequently occurring distance which affects both Communications and Coordination challenge is the physical distance. This is to be expected given that, physical distance is the most fundamental distance which occurs in distributed projects. Temporal distance is the second most described distance - this distance only occurs for projects where teams are distributed in different time zones or are working in different shifts with no time overlap. Socio-cultural distances (languages, cultural believes, ethical values and work practices) which is described the third most frequently, may occur despite being co-located; but in the case of distributed environments, the publications describe the physical distance as exacerbating the socio-cultural distance, thus leading to communication and coordination challenges. Knowledge / Experience distances is the least researched of the distances which cause challenges in agile distributed software development - and thus is described the least frequent.

 

Fig. 6. Distances contributing to the coordination challenge

 

5.4 Answer to R3-2 - Solutions to Overcome the 2 Most Common Challenges (Communication and Coordination)

We identified 4 publications [17, 29, 33, 41] where new methods were developed and tested as part of the research. 2 publications proposed methods to specific address the most common challenge - i.e. the Communications challenge. The other 2 methods developed were applicable to all the 5-Cs, and thus would also be relevant to overcome the second most common challenge (Coordination). The remaining 28 publications did not identify new methods to overcome the 5-Cs - they either provided lessons learnt based on projects researched or did not provide any solutions.

1) Solutions to overcome Communication Challenge: SLR17 proposed that distributed communications could be improved through a structured approach to waste identification and mitigation [17]. SLR18 developed a "feature tree” [41] to improve the communications of changes in requirements throughout the software development process.

2) Solutions applicable to overcome all 5-Cs: The proposed frameworks in SLR08 and SLR27 were targeted at helping to address all 5 of the challenges. SLR08 described the “PBRUC patterns-based unsupervised requirements clustering framework” [29] for validating requirements between distributed stakeholders. In SLR27, a framework to manage risks was proposed based on inputs from the industry [33].

 

6. Conclusion

In this SLR we identified the key challenges across the agile-based iterations including short SDLC phases within iterations. Five types of key challenges were identified as impacting the SDLC phases within agile-based iterations. We called these the “5-Cs of Challenges” : Communication, Coordination, Cooperation, Collaboration and Control. We also identified 4 types of distances which contributed to the occurrence of these 5 types of key challenges. These distances are physical, temporal, social-cultural and knowledge/experience. Based on these, we proposed the “Distance Factors and 5-Cs of Challenges” framework to categorize the findings of this SLR. The framework also provides a guide as to the category of challenge that could occur if a type of distance factor was present in a  agile software development project. We also identified that there were limited new proposed solutions to help address challenges in distributed agile environment - of the 32 selected publications, only 4 proposed new solutions to address challenges in agile distributed software development. Given that this research was focused on challenges faced by the distributed agile approach at large, and excluded specific agile methods, models, practices and frameworks, there is opportunity for future research to assess if there are challenges caused by use of specific tools.