Conference PaperPDF Available

Using Scrum in Global Software Development: A Systematic Literature Review

Authors:

Abstract

There is a growing interest in applying agile practices in global software development (GSD) projects. The literature on using Scrum, one of the most popular agile approaches, in distributed development projects has steadily been growing. However, there has not been any effort to systematically select, review, and synthesize the literature on this topic. We have conducted a systematic literature review of the primary studies that report using Scrum practices in GSD projects. Our search strategy identified 366 papers, of which 20 were identified as primary papers relevant to our research. We extracted data from these papers to identify various challenges of using Scrum in GSD. Current strategies to deal with the identified challenges have also been extracted. This paper presents the reviewpsilas findings that are expected to help researchers and practitioners to understand the challenges involved in using Scrum for GSD projects and the strategies available to deal with them.
Using Scrum in Global Software Development: A Systematic Literature Review
Emam Hossain
CSE, The University of New South
Wales and National ICT Australia
Sydney, Australia
Emam.Hossain@nicta.com.au
Muhammad Ali Babar
Lero,
University of Limerick
Limerick, Ireland
Muhammad.AliBabar@lero.ie
Hye-young Paik
CSE,The University of New South
Wales, UNSW
Sydney, Australia
hpaik@cse.unsw.edu.au
Abstract
There is a growing interest in applying agile practices
in Global Software Development (GSD) projects. The literature
on using Scrum, one of the most popular agile approaches, in
distributed development projects has steadily been growing.
However, there has not been any effort to systematically select,
review, and synthesize the literature on this topic. We have
conducted a systematic literature review of the primary studies
that report using Scrum practices in GSD projects. Our search
strategy identified 366 papers, of which 20 were identified as
primary papers relevant to our research. We extracted data from
these papers to identify various challenges of using Scrum in
GSD. Current strategies to deal with the identified challenges
have also been extracted. This paper presents the review’s
findings that are expected to help researchers and practitioners
to understand the challenges involved in using Scrum for GSD
projects and the strategies available to deal with them.
Keywords- Global software development, agile approaches,
Scrum, systematic literature reviews
I. I
NTRODUCTION
The trend in the recent software development industry is
to move towards Global Software Development (GSD).
This is driven by a number of factors such as improved
network infrastructure, move towards component-based
architecture and increased time-to-market pressure[1].
Despite its popularity, the question of “which agile practices
are effective for GSD under which circumstances?” has not
been closely researched yet [2].
Agile Software Development (ASD) paradigm has
gained significant attention due to its flexible approach to
managing the requirement volatility and emphasis on
extensive collaboration between customers and developers
[3]. Recently, we have observed that an increased number of
GSD project managers are seriously considering introducing
agile practices [4]. Given the increased interest in applying
agile practices in GSD projects, it appears worthwhile for
the practitioners and researchers to investigate the relevant
experiences reported in the literature to learn how agile
practices can be effectively used in GSD projects. Due to
the fact that agile practices are based on the philosophy of
close, frequent and collocated collaborations, the
geographical distance in GSD alone can present a challenge.
Through a number of reports by GSD practitioners in the
literature, we have found that, despite the obvious
difficulties, there are some instances of success of using
agile practices with distributed teams [S1-S5]. But other
researchers [5] still argue that the fundamental question on
whether agile practices can be used in a distributed setting is
still open to debate.
As the interest in using agile approaches in GSD projects
is growing; so is the research literature on various
mechanisms, challenges and strategies of deploying agile
practices for GSD projects. However, there has not been any
significant effort to systematically identify, synthesize, and
report the literature on using agile in GSD projects. To
address this research gap, this systematic literature review
seeks to identify, synthesize, and present the findings
reported about using Scrum practices in GSD to date. In this
review, we only investigate agile practices that pertain to
software project management. We chose “Scrum” as it has a
focus on day to day project management and is the most
widely adopted agile project management method. Recently,
an increasing number of GSD project managers are also
seriously considering the use of Scrum practices in their
development environment [6].
The next section gives an overview of Scrum method and
discusses the motivation of this research. Section 3 describes
the research methods used. The results of this study are
presented in Section IV. Section V discusses the findings to
draw some conclusions. The limitations of the study are
mentioned in Section VI. Section VII closes the paper with a
brief discussion of the researchable issues on this topic.
II. B
ACKGROUND AND
M
OTIVATION
In this section, we first introduce the Scrum method,
place the Scrum in the context of GSD and more concretely
justify the need for this review.
A. Scrum
Scrum is an iterative and incremental project
management approach that provides a simple “inspect and
adapt” framework. In Scrum, software is delivered in
increments called “Sprints” (usually 2-4 weeks iterations)
[6]. Each sprint starts with planning and ends with a review.
A sprint planning by a Scrum team is a time-boxed meeting,
which could last up to 4 hours. It is dedicated to developing
2009 Fourth IEEE International Conference on Global Software Engineering
978-0-7695-3710-8/09 $25.00 © 2009 IEEE
DOI 10.1109/ICGSE.2009.25
175
2009 Fourth IEEE International Conference on Global Software Engineering
978-0-7695-3710-8/09 $25.00 © 2009 IEEE
DOI 10.1109/ICGSE.2009.25
175
Authorized licensed use limited to: Universidad Federal de Pernambuco. Downloaded on July 19,2010 at 19:55:36 UTC from IEEE Xplore. Restrictions apply.
detailed plans for the sprint. The Stakeholders of a project
attend sprint review meetings to review the state of the
business, the market and technology. These meetings could
also last up to 4 hours. A retrospective meeting may be
scheduled to assess the teamwork in the completed sprints. A
daily Scrum meeting by a Scrum team is a 15-minute long
and each team member addresses three questions: what did I
do yesterday, what will I do today and what impediments are
in my way? Scrum produces three artefacts, namely: product
backlogs, sprint backlogs and burn-down charts. Backlogs
contain customer requirements and daily burn down charts
show the cumulative work remaining.
B. Scrum in Global Software Development
Agile approaches are usually considered effective for the
projects with high uncertainty [3]. Paasivaara et al [S1]
reported that distributed software development projects with
volatile requirements and uncertain implementation
technologies can use various agile practices for effectively
organizing and managing projects. Scrum has been already
found an effective approach to managing projects with
many small, collocated development teams [3]. Sutherland
and Schwaber [6] argue that Scrum can also be used for
large and distributed teams. Indeed, from the papers
reviewed in this review, we have found some distributed
projects in which Scrum has been successfully used.
C. Objective of this Review
Scrum teams are self organized, are facilitated by rich
communication and a collaborative environment and are
usually considered effective for co-located projects with a
small team size [3]. Thus, it is apparently difficult to apply
Scrum practices in GSD projects because of the physical
separation of the development team members [4]. There can
be other GSD project contextual factors (e.g., number of
distributed sites, collaboration modes, i.e., inter
organizational or intra organizational, number of teams,
project personnel or team size, socio-cultural distance and
so on) that may also impact on Scrum team collaboration
processes. A recent survey about agile practice adoption rate
[7], reported that agile practices can be successfully used by
significantly distributed team members. Another survey
concludes that among the various agile practices, project
management practices such as Scrum practices have a
higher adoption rate [8]. Thus, we can argue that Scrum, as
an agile method, is becoming increasingly popular and may
also be used for globally distributed teams. But the actual
process of using Scrum’s collaborative practices instead of
project stakeholder’s distribution is not clearly understood
[4]. For this reason we have decided to explore, investigate
and explain various challenging factors that restrict the use
of Scrum practices due to the global project. Current
strategies to reduce these challenging factors are also be
explored.
III. R
ESEARCH
M
ETHOD
This research has been carried out by following
Kitchenham and Charters [9] guidelines for conducting
Systematic Literature Review (SLR) or Systematic Review
(SR), which involves several activities such as the
development of review protocol, the identification and
selection of primary studies, the data extraction and
synthesis, and reporting the results. We followed all these
steps for the reported study as described in the following
sections of this paper.
The broad objective of this study is to answer the
following research question.
RQ. What is currently known about the use of the Scrum
practices in GSD projects?
More specifically, this study focuses on the following two
questions:
RQ1. What challenging or risk factors restrict the use of
Scrum practices in globally distributed projects?
RQ2. What strategies or practices are being commonly used
to deal with these challenging factors to support the use of
Scrum practices in globally distributed projects?
A. Data Sources and Search Strategies
We only searched for papers that are written in English
and available online. The search strategy included electronic
databases and manual searches of conference proceedings.
The following electronic databases were used.
IEEEXplore (www.ieeexplore.ieee.org/Xplore/)
ACM Digital library (www.portal.acm.org/dl.cfm)
Google Scholar (http://scholar.google.com.au/)
Compendex EI (www.engineeringvillage2.org/)
Wiley InterSciene (www.interscience.wiley.com/)
Elsevier Science Direct (www.sceincedirect.com/)
AIS eLibrary (www.aisel.aisnet.org/)
SpringerLink (www.springerlink.com/)
We also searched the following conference proceedings
for papers on the use of the Scrum practice(s) in GSD
context.
Agile Processes in Software Engineering and Extreme
Programming(XP/Agile Universe)
Agile Conference
The types of papers ranged from industry experience
reports, theoretical, empirical and experimental academic
papers. Figure 1 shows the review process and the number
of papers identified at each stage. In stage 1, we searched
the databases using the search terms listed in Table I.
Category 1 has more keywords and shows many variations
of the same term “Global Software Development”. All these
search items were combined by using the Boolean “AND”
operator, which entails that an article that focuses on both
Agile and Global Software Development, will be retrieved.
That is, we searched every possible combination of one item
from Category Type 1 AND Category Type 2. The search
excluded articles that address editorials, prefaces, article,
reviews, discussion comments, news, summaries of
176176
Authorized licensed use limited to: Universidad Federal de Pernambuco. Downloaded on July 19,2010 at 19:55:36 UTC from IEEE Xplore. Restrictions apply.
tutorials, workshops, panels and poster sessions. This search
strategy resulted in a total of 583 “hits’ that included 366
unduplicated papers.
TABLE I. S
EARCH
T
ERMS
U
SED IN THIS
R
EVIEW
B. Managing Studies and Inclusion Decisions
Our study followed the citation management procedure
reported by Dyba and Dingsoyr [10]. We used EndNote for
storing relevant citations from stage 1 (n=366). The
citations were then imported into a spreadsheet where we
recorded the sources of each citation and subsequent
inclusion / exclusion decision. We maintained separate
Endnote library and spreadsheet for each stage. In the
second stage, two of the authors sat together and went
through the titles of all the 366 studies that resulted from
stage 1, to determine their relevance to the systematic
review. At this stage, articles with titles that indicated
clearly that the articles were outside the scope of the SLR
boundary were excluded and identified 123 relevant studies.
However, a paper’s title may not always represent the
content of the paper. During the next stage, we divided 123
abstracts among three researchers in such a way so that each
abstract was reviewed by two researchers independently.
We found 109 abstract agreements among 123 assessments.
All the disagreements were resolved by three researcher’s
discussions. At the end of stage 3, we were left with 77
papers for stage 4 of the selection process.
C. Final Selection
We used the following screening criteria to ensure the
papers address our research topic.
1. Does a paper address the use of any Scrum practices in
distributed projects?
2. Does a paper discuss any real life experience of using
Scrum practices in distributed projects?
As there is a lack of existing empirical research, we also
consider “lesson learned” report based on expert opinion
that address the use of Scrum practice in GSD projects. For
additional quality assessment, we included following two
criteria related to the quality of each paper’s description.
3. Does the objective of the paper is clearly mentioned?
4. Does the paper discuss GSD project contextual factors
adequately?
The adequacy of project contextual factors discussion
was measured based on the GSE background information as
shown in Appendix B. These 4 points provided a measure of
the extent to which we are confident that a selected paper
could make a valuable contribution to understand the
current use of Scrum practices in distributed setting. Each of
the 4 criteria was graded on a dichotomous (“yes” or “no”)
scale.
Figure 1. The selection process of primary papers.
We selected 21 papers out of the 77 articles by carrying
out the quality assessment based on these four screening
criteria. We accepted a paper that has satisfied 4 criteria and
graded as all “yes”. For example, we excluded a number of
papers that discussed some other agile methods and
practices (e.g. XP, pair programming). Among the 21
papers, we found that one journal paper [S1] was an
extended version of previously published conference paper
[S1a]. We also found that two papers [S3] and [S3a]
published in two different conferences were based on the
same empirical study. In both cases, we included the
comprehensive recently published papers as mentioned in
appendix A. In addition, one researcher went through the
reference list of every selected paper of this final stage. This
helped us to identify any relevant paper that was not
extracted by our search strategy. In this process, we
identified one journal paper [S8] that was not retrieved
through our search of electronic databases but was cited by
some of the selected papers [S1, S4]. The abstract was
reviewed by two researchers independently and agreed that
the paper [S8] appeared to be within the scope of the
research. Finally we selected 20 papers (excluding two
177177
Authorized licensed use limited to: Universidad Federal de Pernambuco. Downloaded on July 19,2010 at 19:55:36 UTC from IEEE Xplore. Restrictions apply.
repeated papers S1a and S3a and including one journal
paper S8 from initially selected 21 papers) for data
extraction and synthesis phases. We have enlisted the
selected primary studies in Appendix A.
D. Data Extraction and Synthesis
From the final selected studies, we extracted data using a
pre-defined data extraction form as shown in Appendix B.
The detail description of the data extraction form can be
obtained in the technical report [11]. During data extraction,
we found it quite difficult to extract relevant and meaningful
information that can answer the research questions. This is
because the primary studies included in this SLR are mainly
based on industry based experience reports and most of
them are not described in a commonly used research paper
structure. As usually a standard research report discusses
research problem, related research work, research method,
data analysis technique and conclusion adequately [12]. For
this reason, two researchers performed data extraction
independently. Extracted data from each researcher were
compared and disagreements were discussed and resolved
by consensus in meetings. For further disagreement, we
consulted with a third independent researcher who has
extensive experience in SLR. We used a qualitative data
analysis tool (NVivo) to store textual data that are able to
address our research questions.
We synthesized the data by identifying themes emanating
from the findings reported in each of the paper reviewed in
this study. In the following section, we present frequencies
of the number of times each theme is identified in different
studies. The respective frequencies reflect the number of
times a particular challenge has been mentioned in different
papers.
IV. R
ESULTS
A. Overview of Studies
Table II shows that the number of papers on the issue of
using Scrum practices in GSD context are increasing over
the last few years. It can be argued that the publication trend
may be an indicator of practitioners and researchers’
growing interest in using and reporting Scrum practices for
GSD projects.
TABLE II. S
ELECTED
P
APERS BY
Y
EAR
I
NTERVAL
Year 2003 2004 2005 2006 2007 2008 2009
papers 1 1 1 3 4 9 1
% 5% 5% 5% 15% 20% 45% 5%
Table III shows that only 4 studies (20%) included in this
SLR are empirical studies and all of them are industrial case
studies. Rest of the 16 studies (80%) are classified as
“lesson learned” or industrial experience reports. Hence, we
conclude that there is a little empirical evidence based
reported on the use of Scrum practices in GSD context.
TABLE III. T
YPES OF
S
TUDIES
R
EVIEWED
Study Focus Number
of Papers
percentage Reference
Empirical Study 4 20% [S1-4]
Industrial
Experience
Reports
16 80% [S5-20]
Table IV presents project frequencies that are
categorized according to few distributed project contextual
factors. We have found that most of the studies report the
use of Scrum practices in GSD projects from intra-
organizational, multi-national companies. Our findings also
reveal that a limited number of distributed sites are involved
while Scrum practices are used in distributed sites.
However, some researchers claim that a distributed project
with multiple teams can also use Scrum in their
development [6]. Scrum can also be used in a distributed
project with large number of project personnel or team size.
In this case a number of Scrum teams are involved within
the project. Some of the distributed projects can also use
Scrum by minimizing the challenge of no overlap time
between distributed sites. We have also found that a wide
range of project domains ranging from simple web
application to mission critical projects have been undertaken
using Scrum in distributed development environment.
TABLE IV. P
ROJECT
C
ATOGORIZATION
A
CCORDING TO
F
EW
P
ROJECT
C
ONTEXT
F
ACTORS
178178
Authorized licensed use limited to: Universidad Federal de Pernambuco. Downloaded on July 19,2010 at 19:55:36 UTC from IEEE Xplore. Restrictions apply.
B. Findings about Research Questions
This section discusses how the data extracted from the
reviewed studied address our research questions. By
investigating the two research questions, we aim to provide a
synthesized overview of the literature on using Scrum
practices in different distributed projects.
1) RQ1-Challenges of Using Scrum Due to Project
Distribution
We have identified sixteen papers that can help us to
answer the research question 1 (RQ1), “What are the
challenges of using Scrum practices in distributed
development?”
Our analysis of the extracted data has revealed that the
temporal, geographical and socio-cultural distance of GSD
projects impact on using various Scrum practices in
distributed settings. We have found that communication
related issues are the major challenges when using Scrum in
distributed settings. Cultural differences among distributed
team members may also impact on team collaboration and
communication processes. Managing a large team can also
be considered as one of the key challenges. A lack of
dedicated meeting room for each site and Scrum team
distribution at multiple sites also appear to be challenging
factors that restrict the team communication and
collaboration processes. Table V summarizes our findings
about the key challenges of using the Scrum practices in
GSD projects. Usually sprint planning or retrospective
sessions can last up to four hours or sometimes even more
[6]. Thus, it is very difficult to conduct such a long meeting
if the distributed teams experience significant time zone
differences. For this reason, lack of synchronous
communication is considered as one of the most vital
challenges for using Scrum in GSD context.
TABLE V. C
HALLENGING
F
ACTORS
D
UE TO
P
ROJECT
G
LOBAL
D
ISTRIBUTION
Challenging factors Paper references Frequency
(# of
studies)
Synchronous
communication
[S1-2,S6-7,S9-
10,S16-17,S19]
9
Collaboration
difficulties
[S1-3,S15-16,S19] 6
Communication
Bandwidth
[S5-7,S15-16,S19-
20]
6
Tool support [S4, S10-11,S15-
18]
6
Large Team [S2,S5,S7,S10,S16] 5
Office Space [S15-17] 2
Multiple sites [S9] 1
A distributed project usually involves people with
cultural and linguistic diversity, which may discourage
offshore team members from voicing their opinions or
views fully and completely [S1]. This situation usually
results in miscommunication, misunderstandings or
confusion among team members. This SLR has found that
some Scrum teams could not conduct effective retrospective
meetings due to the socio-cultural distance involved in the
distributed project [S1, S7]. Communication networks can
also be slow and unreliable with poor transmission quality
hampering communication standards when using various
communication tools (e.g. video conferencing) [S15-16,
S19]. Providing better communication bandwidth and right
tool in a distributed project that use distributed Scrum
meeting practices is vital [S17].
Lack of effective collaborative tools, global task boards,
suitable bug and issue trackers, globally accessible backlog
tool are also reported to be challenging factors [S10-11,
S15]. Managing a project with a team of large number of
members distributed at multiple sites is considered a
challenging undertaking [S2, S5, S7]. The need of a
dedicated meeting room with necessary infrastructure and
tool support is also considered necessary in a number of
reviewed studies [S15-17]. Using Scrum in a team that is
distributed in more than two sites with different time zone
differences is also observed quite difficult [S9].
2) RQ2- Used Strategiesto deal with these challenging
factors
Our SLR has found that Scrum teams use various
practices or strategies to reduce these challenging factors to
support the use of Scrum practices in globally distributed
projects. This review has identified and categorized these
practices as follows.
Synchronous communication: Our SLR found that Scrum
teams used some strategies to provide synchronous
communication when distributed team has no overlap time.
From the reviewed papers, we found ten projects had
distributed sites without any overlapping working hours.
Thus we can argue that Scrum can be used within a
distributed project that has even no overlap time between
distributed sites. To address the lack of synchronous
communication following practices were widely used.
Synchronized work hours: This practice is widely used by
Scrum teams to ensure synchronous communication among
distributed sites can be arranged. This is done by adjusting
working hours, working from home, working long hours
and so on [S1-2, S6, S9, S13-14, S16-17, S19-20]. Some
Scrum teams used strategies to avoid the need of increased
overlap time. For example, a Scrum team used strict time-
boxed meeting (e.g. two hours planning meeting) to avoid
late night meeting at some sites [S6]. To make the meetings
short and effective, team members post their three daily
Scrum questions or develop backlog (feature list) before
attending the distributed meetings [S8, S10, S12, S15].
Local Scrum team: Due to the lack of overlap time, Scrum
teams are formed locally and each site conducts their own
scrum [S6-9, S10-11, S18]. The meeting practice Scrum of
Scrums is attended by a key touch point member for each
team to ensure inter-team communication. To form such a
179179
Authorized licensed use limited to: Universidad Federal de Pernambuco. Downloaded on July 19,2010 at 19:55:36 UTC from IEEE Xplore. Restrictions apply.
Scrum team, the local team should be autonomous and
should also allocate independent architectural subsystems
with well defined interfaces to each team to reduce inter site
communication [S6- 9, S13]. To establish multiple
communication lines, Scrum team allows additional
distributed meetings along with Scrum master meeting
attended by technical lead or design architect of each local
Scrum team [S9].
Modified practices: In some cases, Scrum team modifies or
extends Scrum practices to address the communication
challenges. For example, Berczuk reports that having a local
“mini-scrum” in the morning after a distributed scrum
meeting can be very effective to reinforce the value of the
Scrum within a local team [S17]. Scrum teams also use
strict communication policy (e.g. E-mail reply within 12
hours) to avoid delay due to the temporal distance of a
distributed team [S9]. Instead of whole team presence in the
late night (or early morning) Scrum meetings, only key
members of the team attend the meetings with distributed
teams [S5, S7, S13]. Moreover, the distributed daily Scrum
meetings are usually cut down to twice-a-week meetings
[S16]. We also found other modified practices such as
asynchronous retrospective meetings (e.g., posting
comments and results on Wikis, emailing the minutes of
local Scrum meeting to the onshore team), conducting sprint
demo by onshore team only (later onshore team briefs
offshore team) [S1-3, S9, S13, S16].
Team Collaboration: Our SLR revealed that socio-cultural
distance in GSD projects substantially impacts team
collaboration processes and may cause ineffective Scrum
meeting practices (e.g. daily Scrum meeting). GSD project
managers use a number of practices that facilitate better
team collaboration while using Scrum practices.
Team Gathering: To increase a project’s domain knowledge
and reduce the cultural distance, a Scrum team gathers and
performs few initial sprints at one site before distributed
development starts [S13, S15-19]. The members of a
distributed Scrum team are also gathered quarterly or
annually for few days [S1, S6, S10, S18]. During this
gathering, a Scrum team can perform scrum planning,
review meeting, retrospectives, sprint and various
socializing activities, which can help to reduce cultural
distance [S18].
Visit: To reduce the cultural distance and increase project
vision, a Scrum team adopts the practice of exchange visits
for example Product owners regularly visit offshore team
throughout the development. [S15-16, S19]. Cultural
exchange is also performed by maintaining planned rotation
among offshore and onshore teams and cross-location visits
[S14-15]. Practices like product owners organizing quarterly
product roadmap meetings were also proven effective for
helping team’s members to fully understand a project’s
vision [S16].
Unofficial distributed meetings: For increased team
collaboration, along with formal meetings, distributed
Scrum team members may also use frequent informal
meetings for clarifying various issues [S1]. These unofficial
meetings may involve leadership meetings, testing, and
architectural meetings, distributed team lead meetings, peer
meetings, and socializing meetings (for example, virtual
party or games) or even “coffee talks” for the collocated
team members [S14].
Training: Our SLR also found that Scrum teams use some
practices that can be categorized as “training”. Practices
for example “initial Scrum training,” “technical Scrumto
clarify new technology issues, reinforce the value of Scrum
and improve team collaboration while using Scrum practices
in GSD projects [S9, S16].
Key documentation: Maintaining valuable documentation
may also improve GSD team collaboration processes while
using Scrum practices [S7, S9, S16, S19]. For example,
supplementing user stories with Use Case diagrams in
globally accessible backlogs helps reduce
misunderstandings and improves team collaboration
processes [S16]. Scrum teams use a number of tools, for
example, issue tracker (e.g. Jira), enterprise wikis (e.g.
Confluence), and project management tool (e.g. Scrum
works) to maintain better documentation and project
transparency [S9, S16].
Mandatory participation: To reduce “offshore silence”
challenge, Scrum team can assign each site a thirty-minute
mandatory demo presentation during retrospective sessions
[S18]. The participation in these sessions helps make an
empowered distributed team [S16]. To reduce cultural
impediments, offshore teams are also encouraged to provide
useful information during daily Scrum meetings [S1].
Gradual team distribution: Scrum teams may move from a
collocated project to a distributed project gradually through
several stages (i.e., evaluation, inception, transition and
steady state) [S13]. The gradual transition helps deal with
the challenges caused by cultural distances and also helps to
increase project domain knowledge. Our SLR reveals that in
one specific Scrum project, during initial three stages of
gradual team distribution (i.e. evaluation, inception and
transition phase) only a representative of an offshore team
participated with onshore team in Scrum meeting practices.
However, in steady state stage, all the Scrum team members
located in onshore and offshore teams participated in the
distributed Scrum meetings [S13]. In another project, one
onshore Scrum master facilitated offshore Scrum meetings
for few initial sprints and came back to onshore when the
offshore team became familiar with Scrum practices [S15].
Communication bandwidth: To provide a rich
communication environment and also to avoid slow,
unreliable, and poor transmission, Scrum teams use the
practice “multiple communication modes”. The practice
ensures that a Scrum team with distributed project
stakeholders is supported with various options of
communication tools such as phone, web camera,
teleconference, video conference, web conference, net
meeting, email, shared mailing list, Instant Message (IM),
Short Message Service (SMS), and Internet Relay chat
180180
Authorized licensed use limited to: Universidad Federal de Pernambuco. Downloaded on July 19,2010 at 19:55:36 UTC from IEEE Xplore. Restrictions apply.
(IRC) [S1]. Hence, Scrum team can choose appropriate tool
from a wide range of communication tools suitable to the
communication bandwidth. For example, if a Scrum team
found videoconferencing is not supported by the existing
communication bandwidth, they may choose a
teleconference in their distributed meeting sessions.
Tool Support: GSD projects that consider using Scrum
need a wide range of tool support. Tools may include
communication, collaborative, project management, issue
tracking, bug tracking, globally accessible backlog, and
burn down chart etc. We found the practice “proactive
resource management” helps ensure that a Scrum team has
the necessary tools and skills to support their Scrum
practices in distributed settings. Our SLR revealed that
along with communication tools, Scrum teams also use a
number of collaborative tools including Wikis, Blogs, social
book marking, expertise finders, whiteboards, electronic
work space, desktop and application sharing, photo charts,
knowledge bases, experience databases, lesson learned
repositories, while using Scrum practices [S1-20]. An
enterprise wiki (e.g. Confluence) has been found to be very
effective while using Scrum practices [S20]. Distributed
team members can communicate and publish the results of
various Scrum meetings minutes in wiki [S20]. To increase
project transparency and visibility and to support the Scrum
practice “Backlog”, our SLR has also revealed that
distributed Scrum teams use a number of tools including
globally accessible project management tools (e.g. “Rally”),
issue tracker, bug tracker (e.g. “Jira”), backlog management
tools (e.g. “Scrum works”), and tools for supporting the
Scrum artifacts “Burn down charts” [S1- 4, S7, S10, S17,
S19-20].
Team management: we have also found that a commonly
used strategy for managing a large distributed team that
considered using Scrum is to split into small manageable
sub-teams [S1-2, S5]. Thus, a large GSD project may
contain a number of Scrum teams (or sub teams) and some
of the Scrum teams may also be geographically distributed
[S1]. Scrum teams use a number of strategies to form sub
teams. An autonomous sub team can be built and allocated
based on features, functions and so on that ensure each sub
team is allocated independent architectural subsystems with
well defined interfaces [S6-8, S9, S13]. For example, highly
volatile features need frequent interaction with business
users and such features can be developed with a sub-team
close to the customer [S3, S13]. In some cases, a sub-team
has its own product owner and Scrum master and conducts
their own Scrum [S1, S3, S5].
We also observed that GSD projects used following
Scrum team models suitable to their development
environments while considering Scrum [6].
Isolated Scrum team: GSD project teams are geographically
isolated; in most cases offshore teams are not cross-
functional and may not use Scrum processes. There is less
empirical evidence of using this type of team model while
using Scrum.
Distributed Scrum of Scrums team: In this team model,
Scrum teams (or sub-teams) are formed based on local site
and each team perform their site based own independent
Scrum. The meeting practice, Scrum of Scrums that is
attended by the key touch points (e.g. Scrum master) from
each site based sub-team ensures effective inter-team
communication [S1]. If the number of sub-teams increases,
in some cases, a nested Scrum of Scrums meeting practice
(e.g. Scrum of Scrum of Scrums) ensures effective sub-team
coordination [6].
Fully Integrated Scrum team: In this team model, Scrum
teams are cross-functional with team members distributed
across geographical locations. This type of Scrum team
should consider the risks due to geographical, temporal and
socio-cultural distances. In this model, all team members
should attend and participate in every Scrum meeting
practice. We found in some cases, a GSD project that has
several fully integrated Scrum teams follows the practice
“centrally located management team” in which
management persons of each Scrum team are located in a
central site (e.g. onshore) [S1-2]. In this case frequent
meetings among a centrally located product owner team, a
team of Scrum masters, and architects from the sub-teams
ensures effective multiple sub-team communication and
collaboration [S2].
Office space: Our SLR has revealed that to support a better
communication and collaborative work and meeting
environment, Scrum teams use following practices:
Single room: This practice ensures each Scrum team is
allocated to a single room so that they can communicate
with each other [S1, S9, S11]. In this case if a person
switches teams, he or she is also relocated to the new team’s
room [S1]. If the Scrum team is divided into multiple sub-
teams, then all co-located sub-teams are able to work in a
single room should be ensured [S1].
Dedicated meeting room: This practice also ensures each
site has a separate meeting room with all necessary network
connectivity and tools while attending a distributed meeting
[S1, S3]. To make Scrum meetings visible to everyone, each
site can use a video projector [S15]. In some cases, a virtual
conference room can also be used as a dedicated meeting
room for Scrum meetings sessions [S5].
Multi sites: It has been reported that Scrum teams usually
use the following strategies while using Scrum practices in
GSD projects with multi sites development.
Local Scrum team: GSD project managers build
autonomous site-based local Scrum teams and allocate tasks
with independent architectural subsystems and well defined
interfaces to each local team [S6-8, S9, S13]. The practice
Scrum of Scrums attended by a key touch point (e.g. Scrum
master) of each site provides inter-team coordination [S14].
Restricted team distribution: In this practice, a fully
integrated Scrum team is restricted within a limited number
of sites distributions. For example, one of the studies
reported on a project that was distributed over multiple sites
181181
Authorized licensed use limited to: Universidad Federal de Pernambuco. Downloaded on July 19,2010 at 19:55:36 UTC from IEEE Xplore. Restrictions apply.
but each Scrum team was distributed between two sites only
[S9].
V. D
ISCUSSION
In this section, we review various findings of our
Systematic Literature Review (SLR) and draw following
conclusions
Conclusion 1. There is a growing interest and literature
demands more empirical study to understand the use of
Scrum practices in globally distributed projects.
It is still an open debate whether or not the Scrum
practices can successfully be used in distributed settings
[[5]. However, the increasing number of publications on this
topic, as shown in table 1, appears to be an indication that
there is an increasing interest in using Scrum practices in
GSD projects. We have found that most of the papers and
all the empirical studies have been published after 2007.
Among the reviewed twenty studies, all of the four
empirical studies and few experience reports have reported
some degree of success in using Scrum practices in GSD.
Despite these successes, the mechanics of combining Scrum
practices and GSD are not well understood [4]. These
findings highlight a vital research gap that needs immediate
attention of GSD and agile communities. Hence, there is a
clear need of building empirically founded knowledge about
using agile practices in general and Scrum practices in
particular in the context of GSD.
Conclusion 2. The use of Scrum practices may be limited
by various GSD project’s contextual factors.
Our review has revealed that there can be several
contextual factors of a project that may impact the use of
Scrum practices in GSD. Some of the factors identified in
the reviewed studies are shown in Table 2. Our findings also
reveal that most of the distributed projects were within the
same company and the team distribution was limited by the
number of distributed sites. We also found that there is a
limited evidence of using Scrum for safety critical
applications. Though our findings reveal that the Scrum
practices can be used in a distributed project that has
multiple numbers of teams, very large project personnel or
even no overlap time between distributed sites, but the
actual process of using Scrum is not clearly understood yet.
We did not consider the impact of other project contextual
factors (for example: budget, complexity, criticality, team
experience, time constraints, contract nature and so on) on
using Scrum in GSD projects. Thus, we conclude that the
use of Scrum practices may be limited by various contextual
factors of a GSD project.
Conclusion 3. Globally distributed Scrum teams usually
face a number of challenges as project distribution impact
on communication, coordination and collaboration
processes.
Our review findings reveal that the temporal,
geographical and socio-cultural distances due to the project
stakeholder’s distribution cause a number of challenging
factors that impact GSD communication, coordination and
collaboration processes. The communication related
challenges are identified as vital. Any cultural differences
involved in a distributed team can substantially impact on
the team’s collaboration process. Managing a large team
distributed at multiple sites is quite challenging as well.
Lack of tools and insufficient infrastructure support may
also make use of Scrum practices in GSD difficult.
Conclusion 4. Scrum practices need to be extended or
modified in order to support globally distributed software
development teams.
Our findings reveal that to support the use of Scrum
practices in various distributed projects, Scrum teams need
to add a number of strategies suitable to their development
environments. A distributed Scrum team can choose
different Scrum team models to reduce its project
distribution challenges. A distributed team usually needs
some overlap time between them to carry out various Scrum
meeting practices. To support a distributed team that has no
overlap time, Scrum teams may use some supporting
distributed practices including synchronized work hours,
local Scrum, additional local team meetings, strict
communication policy, key persons attending all distributed
meetings, reducing number of Scrum meetings,
asynchronous retrospective and so on. To increase the team
collaboration processes, Scrum team can also use some
practices including team gathering, exchange visits,
informal meetings of distributed team members, mandatory
presentations, maintaining key documentation, and gradual
team distribution which also help to reduce team cultural
differences. A Scrum team can also use different practices
such as multiple modes of communication to address the
challenges caused by the lack of communication bandwidth
and tools. A distributed Scrum team also needs to be
supported by various tools for project management, backlog
management, tracking issues, and so on.
VI. L
IMITATION
Like any empirical study, this study also has certain
limitations that should be kept in mind while considering
the reported findings. With the increasing number of studies
in this area, this review may have missed some papers that
address the use of Scrum practices in GSD. However, we
are confident that it would not have been a systematic
omission.
The papers included in this review have undergone a
thorough selection process and involved two researchers
cross checking the completeness of searchers and validating
the suitability of each paper for inclusion. However, the
182182
Authorized licensed use limited to: Universidad Federal de Pernambuco. Downloaded on July 19,2010 at 19:55:36 UTC from IEEE Xplore. Restrictions apply.
findings of this review may have been affected by the
systematic bias in describing the use of Scrum practices in
various primary studies as some of the selected studies
describe the use of various Scrum practices along with other
agile practices (e.g. XP practices).
During the data extraction process, we found that several
papers lacked sufficient details about the reported projects’
contextual factors and the challenges faced and strategies
used while using Scrum practices in GDS projects. We
synthesized our data by identifying and categorizing the
themes from the papers included in this review. Since some
of the selected papers do not provide detailed information,
there is a possibility that the extraction process may have
resulted in some inaccuracies.
VII. C
ONCLUSIONS AND
F
UTURE
R
ESEARCH
We have conducted a systematic review of the literature
on the use of Scrum practices in GSD projects. The aim of
this review was to identify various challenging factors that
restrict the use of Scrum practices in projects that are
globally distributed. Exploring potential strategies to deal
with those challenging factors were also another research
focus. We have presented our findings in two stages: initial
quantitative data presentation about the number of published
papers in each year starting from 2003, the types of studies
reported in the reviewed papers and the contextual factors of
the reported projects. In the second stage, we have analyzed
and interpreted the data extracted from the primary studies
included in this review in order to find the answers to our
research questions. Our analysis and interpretation of the
data have enabled us to draw some general conclusions in
Section 5 about the current state of practice of using Scrum
practices in GSD projects.
The results of this review provide information that can be
useful for GSD practitioners understanding the various
challenging factors that may impact on GSD
communication, collaboration and coordination processes
and restrict the use of Scrum practices. Moreover, the GSD
project managers can also benefit from the synthesized
knowledge about the strategies that are being used to deal
with the identified challenges. However, the strength of
evidence found in the literature about the identified
strategies is very low. That is why it is difficult to offer any
specific advice to practitioners solely based on this review.
This review has also identified several interesting research
challenges that need to be addressed in the future research
efforts by GSD and agile researchers. A clear finding of this
review is that there is an immediate need of increasing the
quantity and quality of empirical studies to describe,
evaluate, explore and explain the use of various Scrum
practices in GSD projects.
To enhance the findings of this review, we intend to
conduct a comprehensive survey of practitioners to identify
the key challenges involved in and the strategies to reduce
these challenges to support the use of Scrum practices in
GSD projects. In addition to this survey, we will also
conduct multiple in depth industry based case studies to
provide an empirically supported body of knowledge about
the use of Scrum in GSD projects considering various
contextual factors.
Appendix A. Papers included in the review
[S1] M. Paasivaara, S. Durasiewicz, C. Lassenius,
“Distributed Agile Development: Using Scrum in a Large
Project,” Software Process Improvement and Practice, Vol.
13, Issue 6, pp. 527-544, 2008.
[S1a] (Excluded) M. Paasivaara, S. Durasiewicz, C.
Lassenius, “Distributed Agile Development: Using Scrum
in a Large Project,” in Proceedings of ICGSE 2008, pp. 87-
95, 2008.
[S2] J. Sutherland, A. Viktorov, J. Blount, N. Puntikov,
“Distributed Scrum: Agile Project management with
Outsourced Development Teams” in Proceedings of the
Conference on HICSS’40, pp. 274, 2007.
[S3] J. Sutherland, G. Schoonheim, M. Rijk, “Fully
distributed Scrum: Replacing Local Productivity and
Quality with Offshore Teams,” in proceedings of the
Conference on HICSS’42, pp. 1-8, 2009.
[S3a] (Excluded) J. Sutherland, G. Schoonheim, E.
Rustenburg, M. Rijk, Fully distributed Scrum: The secret
sauce for Hyperproductive Outsourced Development
Teams” in Proceedings of the Conference on Agile 2008,
pp. 339-344, 2008.
[S4] J. Cho, “Distributed Scrum for Large-Scale and
Mission-Critical Projects,” in Proceedings of the Conference
on AMCIS 2007, paper 235, 2007.
[S5] W. Williams, M. Stout, “Colossal, Scattered, and
Chaotic (Planning with a Large Distributed Team),” in
Proceedings of the Conference on Agile 2008, pp. 356-361,
2008.
[S6] B. Drummond, J. F. Unson, “Yahoo! Distributed Agile:
Notes from the World Over,” in Proceedings of the
Conference on Agile 2008, pp. 315-321, 2008.
[S7] M. Cristal, D. Wildt, R. Prikladnicki, “Usage of
SCRUM Practices within a Global Company,” in
Proceedings of ICGSE 2008, pp. 22-226, 2008.
[S8] H. Holmstrom, B. Fitzgerald, P. J. Agerfalk, E. O.
Conchuir, “Agile Practices Reduce Distance in Global
Software Development” Information Systems Management,
Summer, pp. 7-26, 2006.
[S9] M. Vax, S. Michaud, “Distributed Agile: Growing a
Practice Together” in Proceedings of the Conference on
Agile 2008.pp.310, 2008.
[S10] H. Smits, “Implementing Scrum in a Distributed
Software Development Organization,” in proceedings of the
Conference on AGILE 2007, pp.371-375, 2007.
[S11] B. Jensen, A. Zilmer, “Cross- continent Development
using Scrum and XP” in Proceedings of the Conference on
XP 2003, pp.146-153, 2003.
183183
Authorized licensed use limited to: Universidad Federal de Pernambuco. Downloaded on July 19,2010 at 19:55:36 UTC from IEEE Xplore. Restrictions apply.
[S12] C. Kussmaul, R. Jack, B. Sponsler, “Outsourcing and
Off shoring with Agility: A Case Study” in Proceedings of
the Conference on XP/Agile Universe, pp. 147-154, 2004.
[S13] K. Sureshchandra, J. Shrinivasavadhani, “Adopting
Agile in Distributed Development” in Proceedings of
ICGSE’08,pp. 217-221, 2008.
[S14] A. Danait, “Agile offshore techniques- A case Study”
in proceedings of the Conference on Agile Development
Conference, pp.214-217, 2005.
[S15] M. Summers, “Insights into an Agile Adventure with
Offshore Partners,” in Proceedings of the Conference on
Agile 2008, pp. 333-338, 2008.
[S16] E. Therrien, “Overcoming the Challenges of Building
a Distributed Agile Organization,” in Proceedings of the
Conference on Agile 2008, pp. 368-372, 2008.
[S17] S. Berczuk, “Back to Basics: The Role of agile
Principles in Success with a Distributed Scrum Team,” in
Proceedings of AGILE 2007, pp. 382-388, 2007.
[S18] P. Karsten, F. Cannizzo, “The Creation of a
distributed Agile Team,” in proceedings of XP 2007,
pp.235-239, 2007.
[S19] M. Cottmeyer, “The Good and Bad of Agile Offshore
Development,” in proceedings of the Conference on AGILE
2008, pp.362-367, 2008.
[S20] M. Paasivaara, C. Lassenius, “Could Global Software
Development Benefit from Agile Method?” in proceedings
of ICGSE 2006, pp. 109-113, 2006.
Appendix B. Data Extraction form
Paper description:
1. Paper identifier: Unique id for the paper
2. Date of data extraction:
3. Bibliographic reference: Author, year, title, source
4. Type of article: Journal article/conference paper/
workshop paper/unclear
5. Paper aims: what were the aims of this paper?
6. Paper Evidence: empirical study/experience
report/unclear
GSD Background:
1. Collaboration mode: inter organizational/intra
organizational/unclear
2. Number of Sites: ……./unclear
3. Number of Teams:……/unclear
4. Project personnel:……/unclear
5. Time zone differences:……/unclear
6. Application Domain: ……./unclear
Study Findings:
1. Scrum team scenario (model): Isolated Scrum
team/Scrum of Scrum meeting used for site based team
coordination/Fully integrated ( e.g. Scrum team contain
onshore and offshore personnel)/unclear
2. Challenges: challenging factors that impact GSD
communication, coordination and collaboration
processes and restrict the use of Scrum practices.
3. Strategies: Used various strategies to reduce project
stakeholder’s distribution challenges to support the use
of Scrum practices.
4. Subjective evaluation: a small summary of the findings
from the paper.
A
CKNOWLEDGMENT
M. Ali Babar’s research is partially supported by
Science foundation Ireland under grant number
03/CE2/I303-1.
R
EFERENCES
[1] E. Carmel, Global software teams: collaborating across
borders and time zones: Prentice-Hall, 1999.
[2] J. D. Herbsleb “Global Software Engineering: The Future of
Socio- technical Coordination” in proceeding of Future of
Software Engineering, FOSE, pp.188-298, 2007.
[3] P. Abrahamsson, O. Salo, J. Ronkainen, and J. Warsta, Agile
software development methods - Review and analysis, VTT
Electronics ed.: VTT Publications, 2002.
[4] P. J. Ågerfalk and B. Fitzgerald, "Flexible and distributed
software processes: Old petunias in new bowls?" Communications
of the ACM, vol. 49, Oct 2006, pp. 26-34.
[5] F. Abbattista, F. Calefato, D. Gendarmi, F. Lanubile,
“Incorporating Social Software into Distributed Agile
Development Environments” in proceedings of the 23
rd
ASE
workshop, pp.46-51,2008.
[6] J. Sutherland, K. Schwaber, “The Scrum Papers: Nuts, Bolts,
and Origin of an Agile Process,”
http://scrumtraininginstitute.com/home/stream_download/scrumpa
pers, Last accessed 11 Apr 2009.
[7] Ambler, S.: Agile Adoption Rate Survey: February 2008
http://www.ambysoft.com/surveys/agileFebruary2008.html Last
accessed 11 Apr 2009.
[8] Ambler, S.: Agile Practice and Principles Survey: July
2008,http://www.ambysoft.com/surveys/practicesPrinciples2008.ht
ml Last accessed 11 Apr 2009.
[9] B. Kitchenham, S. Charters, “Guidelines for Performing
Systematic Literature Reviews in Software Engineering” EBSE
Technical Report, EBSE-2007-01, 2007.
[10] T. Dyba and T. Dingsoyr, "Empirical Studies of Agile
Software Development: A Systematic Review," Information and
Software Technology, Vol. 50, Issue 9-10, 2008, pp-833-859.
[11]E., Hossain, M., A., Babar, H., Paik, “Using Agile Practices in
Global Software Development: A Systematic Review,” UNSW
CSE Technical Report, TR 904, (2009).
[12] R. K., Yin, “Case Study Research,” Thousand Oaks, Ca. Sage
publications, (2003).
184184
Authorized licensed use limited to: Universidad Federal de Pernambuco. Downloaded on July 19,2010 at 19:55:36 UTC from IEEE Xplore. Restrictions apply.
... Other reasons include allowing people from different teams to see each other using additional events such as Scrum of Scrums or just giving people the possibility of having an informal conversation before starting the workday. Although seen as something new as an effect of the sudden change to remote working by many people, additional and extended Daily Scrums are a common adaptation of using Scrum in a remote context, as noted in the literature [25]. Furthermore, daily Scrums are an essential part of a healthy Scrum implementation; they "improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team's level of knowledge" [10]. ...
... As previously mentioned, the adaptations of Scrum events undergone while people had to work from home are similar to the adaptations that a distributed Scrum team has to enforce to support the communication between geographically dispersed co-workers [19]. The working environment plays a big role in how people interact with each other, and working from home impacted the transparency between the people in the Scrum team, causing Daily Scrums to be extended or even requiring better documentation practices, effects also seen on distributed Scrum projects [25]. The ability of working from home has repercussions on the freedom and frequency of communication between team members, growing the chance of individualism, which is detrimental for the use of Scrum [54]. ...
... Ken Schwaber and Jeff Sutherland, the creators of Scrum, promote that "the essence of Scrum is a small team of people" [10] and that Scrum is "a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value" [10]. There is no silver bullet recipe for implementing Scrum, and each company can have varied ways of using Scrum [25]. Moreover, even though there should be a Scrum Master to promote and support the good use of the framework within the project, the self-organizing Development Team (Developers) is responsible for managing their own work [10]. ...
Article
Full-text available
With the COVID-19 pandemic, Scrum teams had to switch abruptly from a traditional working setting into an enforced working from home one. This abrupt switch had an impact on software projects. Thus, it is necessary to understand how potential future disruptive events will impact Agile software teams’ ability to deliver successful projects while working from home. To investigate this problem, we used a two-phased Multi-Method study. In the first phase, we uncover how working from home impacted Scrum practitioners through semi-structured interviews. Then, in the second phase, we propose a theoretical model that we test and generalize using Partial Least Squares - Structural Equation Modeling (PLS-SEM) surveying 138 software engineers who worked from home within Scrum projects. We concluded that all the latent variables identified in our model are reliable, and all the hypotheses are significant. This paper emphasizes the importance of supporting the three innate psychological needs of autonomy, competence, and relatedness in the home working environment. We conclude that the ability of working from home and the use of Scrum both contribute to project success, with Scrum acting as a mediator.
... As Scrum is the most widely adopted agile software development method and dominates the industrial agile practices [5,11,21,40,49,72,76], it provides a solid opportunity for investigating the influence of team maturity on the successful application of a specific agile methodthe Scrum framework [59]. In this paper, we empirically investigate the impact of team maturity on the successful application of the Scrum framework. ...
... Nevertheless, after the initial attention directed at XP, both the academic community and industry practitioners have turned their focus to Scrum [11,21,76]. As more and more companies are adopting Scrum [5], it has become the most widely applied agile method [17,40,71]. More precisely, 66% of organizations apply Scrum, 6% a Scrum/XP hybrid, 9% Scrumban, 6% Kanban, 1% lean startup, 1% XP, 4% iterative, and 2% unknown, according to the 15th annual State of Agile Report [76]. ...
... The focal point of Scrum is organizing teams to produce software in a dynamic and constantly changing environment [10,16]. Scrum is an iterative and incremental approach that emphasizes transparency, inspection, and adaptation [40,58,59,71]. To successfully apply Scrum, people must become accomplished at living in accordance with the five Scrum values of commitment, focus, openness, respect, and courage [59]. ...
Article
Context Several studies contribute with valuable insights into agile teamwork performance. Currently, Scrum is dominating the industrial agile software development practices. Yet, there is a lack of studies that directly explores the role of team maturity and key components of the Scrum framework on being successful at Scrum. Objective We investigate the impact of team maturity and four categories of the Scrum framework (team composition, Scrum values, Scrum roles, and Scrum events) on the perception of being successful at Scrum. Hence, we uncover and provide deeper insights into the characteristics and practices of what makes a team successful at Scrum. Method We carry out a large-scale and cross-sectional survey. We conduct Pearson's chi-square test of independence and logistic regression analysis for team maturity and the remaining variables on being successful. Results After surveying 182 Scrum team members, the results show that being successful at Scrum depends on the team maturity level. Team composition variables (fully allocated, low turnover rates, required skills and expertise, and self-management) and directing work in accordance with Scrum values (openness and courage) have an impact. All three Scrum roles are important. Particularly impactful are the developers’ ability to adapt their plans, the product owners’ mandate to prioritize, and the Scrum masters’ ability to ensure that all events take place. Following all Scrum events has an effect on the perception of being successful at Scrum. Conclusion This work constitutes a valuable contribution to agile practitioners and organizations who are already involved in agile development or plan to pursue agility. Organizations can influence Scrum teams’ journey towards becoming successful at Scrum by ensuring the stability required to allow team maturation and decision-making relevant to team composition variables. This work also provides reflections that are useful for Scrum teams’ practices and internal dynamics related to values, roles, and events.
... While assigning the task to the teams, clearly consider the competencies required to accomplish that task, and after assigning the task to the teams, clearly define the responsibilities of each member of team related to a specific task, and use tools to track the progress of the team and the work [8,23,[54][55][56][57][58][59]. ...
... An example of such customization is Scaled Extreme Programming [24] XP also assists the developers to consistently recognize and get work done on the software artifacts with higher priorities [15]. Scrum is an iterative project management model which gives a straightforward 'inspect and adapt' system [25]. In this model the delivery of the software is in increments known as Sprints. ...
Article
For past couple of years agile software methods have been quite popular among the researchers. Agile models are known as light weight in contrast with conventional software development methodologies, due to their casual, versatile and adaptable style. Agile frameworks became heartily accepted by the software society in view of their concentration towards timely software conveyance, product quality and user satisfaction. For the fulfillment of requirements and needs of different software projects multiple agile frameworks are present to choose from. Out of these models Extreme Programming and Scrum are the most recognizable and generally utilized frameworks. This research contributes by investigating these two frameworks thoroughly. This paper conducts a comprehensive comparison between Scrum and Extreme programming to track down their commonalities, dissimilarities and investigate those attributes which complement each other.
... Whereas Scrum in its early years would only be applied in a single team at a single location, its rapid rising crossed both the single team as well as the single location boundary. Hossain et al. [9], already in 2009, made a plea for more empirical study to understand Scrum practices in teams at different locations, more notably globally distributed projects. The introduction of Scrum frameworks like SAFe 1 or LeSS 2 emphasize the need for guidance in scaling Scrum from a team to an organizational level. ...
Conference Paper
In Scrum, teams working collaboratively on interdependent pieces of software face alignment issues as they need to coordinate their work. Organisations aim to minimise time to market of their products, which makes it relevant to identify how alignment issues affect time to market. Currently, empirical evidence of the effect of implementing alignment activities on delivering software is scarce. This research aims to identify those alignment activities that shorten the time to market of backlog items. First, examination of key concepts led to a grounded choice of alignment activities taken into account. Use of alignment activities in development of features was identified by sending feature owners a close-ended questionnaire on the alignment of their collaborating Scrum teams. The cycle times of backlog items were measured by using the application programmable interface of the agile tool used for tracking backlog items. Results show that when user stories were developed using a shared Definition of Ready, process and lead time decreased significantly. Process and lead time also differed between user stories implementing a different number of shared feedback sessions, where using two shared feedback sessions per sprint resulted in the lowest process and lead time.KeywordsAgileAgile toolsAlignmentScrumScrum collaborationTime to market
... An example of such customization is Scaled Extreme Programming [24] XP also assists the developers to consistently recognize and get work done on the software artifacts with higher priorities [15]. Scrum is an iterative project management model which gives a straightforward 'inspect and adapt' system [25]. In this model the delivery of the software is in increments known as Sprints. ...
Article
Full-text available
For past couple of years agile software methods have been quite popular among the researchers. Agile models are known as light weight in contrast with conventional software development methodologies, due to their casual, versatile, and adaptable style. Agile frameworks became heartily accepted by the software society in view of their concentration towards timely software conveyance, product quality and user satisfaction. For the fulfillment of requirements and needs of different software projects multiple agile frameworks are present to choose from. Out of these models Extreme Programming and Scrum are the most recognizable and generally utilized frameworks. This research contributes by investigating these two frameworks thoroughly. This paper conducts a comprehensive comparison between Scrum and Extreme programming to track down their commonalities, dissimilarities and investigate those attributes which complement each other.
... As per Hossain et al. [31] , this cannot be taken as systematic omission. ...
Chapter
This research proposal targets public sector ICT practices. The goal is to explore in-depth the causes of issues in public ICT. Furthermore, the goal is to fill research gaps in public agency and supplier interrelationships, EA practices, and intended public sector technological solutions. The proposed research binds these areas to establish a coherent framework for how ICT should be built and led in public agencies.KeywordsPublic procurementEnterprise architectureSustainable softwareInteroperability
Conference Paper
The software industry is changing rapidly, and software firms look for processes, approaches, and methodologies that focus on effective software development gaining stakeholder satisfaction. Software development models mainly help firms to deploy projects in a smooth way by using specific methods and techniques. The challenge of choosing between traditional software development methodologies and agile development methodologies plays a crucial role when firms are looking for software processes, approaches and tools that help to create stable products. The choice of a software development model depends on project timeframe, business requirements, availability of resources, team, client involvement and perception. The traditional models face shortcomings of being rigid, difficulty in accommodating changing requirements and heavy documentation. Agile models represent a major innovation from traditional, plan-based approaches to software engineering. The objective of this paper is to review the concept of agile and traditional methodologies in terms of definitions, processes, and impact on the delivery of innovative products and compare between agile and traditional software engineering models. The implementation of scrum agile model in a software firm with web application (webapps) domain is also presented in this paper.
Article
Full-text available
The objective of this report is to propose comprehensive guidelines for systematic literature reviews appropriate for software engineering researchers, including PhD students. A systematic literature review is a means of evaluating and interpreting all available research relevant to a particular research question, topic area, or phenomenon of interest. Systematic reviews aim to present a fair evaluation of a research topic by using a trustworthy, rigorous, and auditable methodology. The guidelines presented in this report were derived from three existing guidelines used by medical researchers, two books produced by researchers with social science backgrounds and discussions with researchers from other disciplines who are involved in evidence-based practice. The guidelines have been adapted to reflect the specific problems of software engineering research. The guidelines cover three phases of a systematic literature review: planning the review, conducting the review and reporting the review. They provide a relatively high level description. They do not consider the impact of the research questions on the review procedures, nor do they specify in detail the mechanisms needed to perform meta-analysis.
Article
Full-text available
Agile - denoting "the quality of being agile; readiness for motion; nimbleness, activity, dexterity in motion" - software development methods are attempting to offer an answer to the eager business community asking for lighter weight along with faster and nimbler software development processes. This is especially the case with the rapidly growing and volatile Internet software industry as well as for the emerging mobile application environment. The new agile methods have evoked a substantial amount of literature and debates. However, academic research on the subject is still scarce, as most of existing publications are written by practitioners or consultants. The aim of this publication is to begin filling this gap by systematically reviewing the existing literature on agile software development methodologies. This publication has three purposes. First, it proposes a definition and a classification of agile software development approaches. Second, it analyses ten software development methods that can be characterized as being "agile" against the defined criteria. Third, it compares these methods and highlights their similarities and differences. Based on this analysis, future research needs are identified and discussed.
Article
Full-text available
This book is dedicated to the Godfathers of Scrum, Takeuchi and Nonaka [1], who gave Scrum its name and helped created a global transformation of software development. In 2021 Scrum is used in over 77% of Agile transformations worldwide. Many others have contributed to the creation of Scrum: • Jim Coplien and the ATT Bell Labs Pasteur Project for the paper on the most productive software development team ever documented – the Borland Quattro Pro Project [2]. The first Scrum team implemented the Scrum daily meeting after reading this paper. • Nobel Laureates Muhammad Yunus and the Grameen Bank for originating microenterprise development and the Accion International President’s Advisory Board, responsible for much of microenterprise development in the western hemisphere. As a member of the Accion advisory board, Jeff Sutherland noticed the strategy for bootstrapping the poor out of poverty is a model for freeing hundreds of thousands of software developers from developer abuse caused by poor management practices. • Alan Kay and his team at Xerox Parc [3] for inventing Smalltalk, the mouse, the graphical user interface, the personal computer, the Ethernet, and the laser printer. Listening to his insights on innovation inspired the first Scrum team to go from “good” to “great” [4]. • Professor Rodney Brooks for launching the startup iRobot in space leased from Jeff Sutherland. He taught us the subsumption architecture [5], how to create simple rules to produce highly intelligent performance from complex adaptive systems. • Christopher Langton of Los Alamos Labs and the Sante Fe Institute for coining the term “artificial life” and showing that increasing degrees of freedom up to the edge of chaotic behavior accelerated their evolution [6]. Scrum feels “chaotic” by intent, so as to accelerate software evolution. • The French object-database developers working near the MIT campus at Graphael (later Object Databases, then Matisse Software) for demonstrating first in Lisp and then in C++ the Agile patterns of pair programming, radical refactoring, continuous integration, common ownership of code, world class user interface design, and other tips and tricks which Kent Bent used to create eXtreme Programming a decade later. These were all incorporated into the first Scrum. • The Creative Initiative Foundation for their work with Silicon Valley volunteers to help make the world a better place, the underlying motivation driving the founders of Scrum. This connected the Co-Creators of Scrum with the early systems thinking of MIT Professor Peter Senge who later wrote “The Fifth Discipline.” • Capers Jones and his productivity experts at Software Productivity Research who analyzed and reanalyzed the output of early Scrum teams, as well as many of the software products built with Scrum during 1994-2000 [7]. These analyses allowed us to provide a money back guarantee that users would double productivity during the first month using tools created by the first Scrum. • The first Scrum team – John Scumniotales (Scrum Master), Don Roedner (Product Owner), Jeff McKenna (Senior Consultant), Joe Kinsella (object-relational mapping), Laurel Ginder (QA), and three Danish developers - Grzegorz Ciepiel, Bent Illum, and John Lindgreen. They endured repeated failure, depressing analysis of these failures in front of their technical peers from other companies, and transcendence of their missteps. They were the first Scrum team to achieve the hyperproductive state for which Scrum was designed and their product, Object Studio, is in 2021 still considered one of the top five development tools every created by industry leaders. Little did they know that Scrum would be their greatest contribution, although Object Studio still lives on as a successful product almost 30 years later. • PatientKeeper, Inc., the first company to fully implement an “All at Once” or Type C Scrum involving the entire company in Scrum practice. This innovation in process design has been documented by Mary and Tom Poppendieck in their book on Lean Software Development [8]. “I find that the vast majority of organizations are still trying to do too much stuff, and thus find themselves thrashing. The only organization I know of which has really solved this is Patient Keeper [9].” PatientKeeper was the first company to achieve a hyperproductive revenue state driven by Scrum in 2007. Revenue quadrupled from 13M to 50M in one year. • Jim Johnson, CEO of the Standish Group, continuously shared data on over 500,000 project sets, each with 8-25 projects over the years since Scrum began. These data continually showed that while Agile projects (77% Scrum) were more successful than traditional projects, 58% of Agile projects fail to deliver. The data in the 2018 Chaos Report – Decision Latency Theory: It’s All About the Interval [10] showed clearly that Scrum success was primarily driven by shortening decision time. • Last, but not least, many Scrum practitioners experience the quality without a name (QWAN) - a phrase used by Christopher Alexander in his book “The Timeless Way of Building” [11]. Alexander describes a certain quality that we seek, but which cannot be named. This may be the most important feature of Scrum and can only be spoken of as a set of core values - openness, focus, commitment, courage, and respect. It could be viewed as the “speed of trust” or one of the sources of “ba” often seen on Scrum teams. Ba is the Japanese term for the creative flow of innovation described by Takeuchi and Nonaka [12].
Conference Paper
Full-text available
The use of social software applications, such as wikis and blogs, has emerged as a practical and economical option to consider as global teams may use them to organize, track, publish their work, and then, share knowledge. We intend to push further the application of social software principles and technologies into collaborative development environments for agile and distributed projects. As a first step, in this paper we first present a survey of social software, as well as tools and environments for collaborative development. Then, we present some opportunities and challenges of incorporating social software aspects in agile distributed development.
Article
Full-text available
Agile software development represents a major departure from traditional, plan-based approaches to software engineering. A systematic review of empirical studies of agile software development up to and including 2005 was conducted. The search strategy identified 1996 studies, of which 36 were identified as empirical studies. The studies were grouped into four themes: introduction and adoption, human and social factors, perceptions on agile methods, and comparative studies. The review investigates what is currently known about the benefits and limitations of, and the strength of evidence for, agile methods. Implications for research and practice are presented. The main implication for research is a need for more and better empirical studies of agile software development within a common research agenda. For the industrial readership, the review provides a map of findings, according to topic, that can be compared for relevance to their own settings and situations.
Conference Paper
Key challenges of finding right skilled resources and the cost arbitrage factors have made distributed software development indispensable for quite some time now. The success stories of many offshore service providers particularly from India underlines the fact that this is working well in a "hands-free" mode, especially for projects following traditional development life cycles. The recent trend is an increase in the number of organizations adopting agile methodologies to tackle the challenges of requirements volatility and shorter time to market. However, the concept of a collocated team which is central to agile does not easily translate to distributed development. This paper captures our experience at Wipro in handling Distributed Agile projects. We discuss a validated model to make a smooth transition from a collocated to a distributed scenario in agile projects. We also share the lessons learnt and best practices that we have gained in implementing this model.