Requirements Engineering (2022) 27:117–134

https://doi.org/10.1007/s00766-021-00363-3

ORIGINAL ARTICLE

Exploring the challenges and benefits for scaling agile project

management to large projects: a review
Paula de Oliveira Santos1 · Marly Monteiro de Carvalho1

Received: 25 February 2021 / Accepted: 9 October 2021 / Published online: 25 October 2021
© The Author(s), under exclusive licence to Springer-Verlag London Ltd., part of Springer Nature 2021

Abstract
Organizations have increasingly applied agile project management; however, they face challenges in scaling up this approach
to large projects. Thus, this study investigates the key barriers and benefits of scaling agile methods to large projects. The
research approach is a literature review, applying bibliometrics and content analysis with Bibliometrix and UCINET soft-
ware. We conducted a sampling process in the Web of Science and Scopus databases and surveyed 76 articles in depth.
The results identified 53 barriers clustered into six main categories: organizational issues, managerial issues, agile method-
specific barriers, product/process issues, customer issues, and team issues. Thirty-two benefits were coded and clustered into
three categories: business, project, and team. Requirement management appears as a core topic, impacting both barriers and
benefits for scaling agile project management. We identified a strong relationship between the barriers and benefits. These
results can be used to create questionnaires to explore these barriers and benefits in practice.

Keywords Agile · Large scale · Project management · Barriers · Benefits

1 Introduction However, for large projects, there are still several con-
cerns about APM. APM is considered “light” and more
Much has been studied about agile project management appropriate to small-scale projects, while “heavy” meth-
(APM), its characteristics, advantages, and disadvantages ods, which emphasize documentation and structure, respond
compared to traditional approaches. Companies have imple- better to medium- and large-scale projects [2]. For [62],
mented this methodology, introducing cross-functional self- the ideal format for using agile methodology in software
managed teams and customer focus, bringing acceleration to development is colocated teams of up to 15 people, with a
profitable growth and creating new generations of qualified defined and stable architecture and direct governance rules.
general managers [87]. For distinct project characteristics, APM could be chal-
A typical scenario for large software development organi- lenged and, in some cases, inadequate. Practitioners and
zations in the early 2000s was the implementation of defined other researchers understood that the agile approach would
development processes, including systems to ensure qual- best suit teams of up to 50 people, with easy access to users
ity through all the processes, which place constraints on who develop noncritical projects [108]. Thus, despite APM
the development team, limiting development practices and being an attractive approach, it was initially designed for
affecting how quickly they can develop software [67]. More small teams, and new challenges arise when scaling to large
recently, cases of software developments in larger projects projects in which the development team interacts with other
or multiple projects demonstrate the companies' interest in organizational units [29].
applying methodologies that provide better results, greater Despite this criticism, organizations are expanding APM
flexibility, and faster customer response [3, 7, 82]. applications to complex projects and are facing several chal-
lenges [5, 10, 77]. This is because companies hope, with
the use of agile, to reach a single mindset, providing sym-
* Paula de Oliveira Santos metrical and standardized solutions, above cultural, techni-
[email protected] cal, or environmental issues [41]. Large-scale transformation
is complex, with high costs and great risks; there is thus a
1
Polytechnic School - University of São Paulo, Av. Prof. significant challenge in accessing high-quality, independent
Luciano Gualberto, 1380, São Paulo 05508‑010, Brazil

13
Vol.:(0123456789)

Content courtesy of Springer Nature, terms of use apply. Rights reserved.

118 Requirements Engineering (2022) 27:117–134

advice from corporate governance teams [106], facing dif- value simplicity, sustainable development, technical excel-
ficulties in project control, which leads to product and cus- lence, and agility. It is expected that it will deliver properly
tomer problems with poor-quality results [73]. functioning software through constant face-to-face conversa-
Organizations are looking for benefits from the advan- tions that reflect on the work to make it increasingly effec-
tages promised by small-scale agile development [17], even tive, accepting changes.
though large-scale product development projects find more The product view encompasses tools and processes for
difficulties in maintaining the original assumptions. Con- communicating the simple project plan and iterative plan-
sequently, there is a need to adapt to the preconditions and ning to self-managed and self-directed teams. The teams
organizational conditions to reap the benefits of agility [58]. work on development, planning, monitoring activities, and
To narrow this research gap, this paper aims to answer the updating project plans [25]. The characteristics of self-
following research questions: management define the APM structure, vision, and itera-
tion presented [6].
– (RQ1) What are the key barriers to scaling APM to large APM generates iterative activity cycles designed to han-
projects? dle change, driven by value, intended to be executed only
– (RQ2) What are the main benefits observed for adopting when needed, providing the project team with flexible
APM for large projects? and adaptive training that enables them to manage change
– (RQ3) What is the relationship between barriers and ben- requests properly [97]. Consequently, the generation of prod-
efits? ucts that benefit the customer and create value for the pub-
lic [70] through continuous deliveries of valuable products
For answering the research questions, we performed a brings a competitive advantage [28].
literature review applying bibliometric and content analysis The focus of the agile approach on simplicity, team build-
with the assistance of Bibliometrix and UCINET software. ing, and products contrasts with process-oriented and matu-
This paper contributes by identifying relevant barriers and rity-oriented approaches that require established procedures
benefits of scaling APM to large and complex projects, and standards for product quality assurance [55]. Its accept-
exploring the alignment with program and portfolio perspec- ance in the industry comes with caveats in the development
tives based on an extensive survey of the current literature. of critical security systems, and it is considered an undis-
For the requirement engineering (RE) community, the study ciplined methodology regarding documentation and lacks
shows the critical role of requirement management to over- rigorous verification and validation techniques [5].
come the barriers for scaling APM. However, “agile development methods do not preclude
This article presents the theoretical background to agile the use of documentation in their processes” [88] (p. 117).
project management and definitions of large-scale projects Besides, adopting agile methodology in development pro-
in the second section. The third section presents the research jects can lead to some benefits, such as collaboration with
methodology, followed by the results from the analysis per- the client, processes to better deal with defects, team aware-
formed and discussions on research findings. The last sec- ness through the high level of autonomy and responsibility,
tion comprises conclusions, limitations, and an agenda for improvement in self-confidence, and increased quality of
future research. working life and interpersonal skills [37].
The agile wave of the early millennium, and the visible
challenges for organizations steeped in traditional system
2 Literature review development methodologies, cannot be ignored [74]. How-
ever, traditional project management can coexist with agile
2.1 Agile project management management to bring security and agility to team members,
allowing adaptations that best respond to the work to be
The agile project management (APM) approach became developed [69, 94].
world famous from a movement that happened in February
2001. This movement engaged software development profes-
sionals disappointed with the traditional project management 2.2 Large scale of projects
in creating the Agile Manifesto [1]. The central values are
individuals and interactions, working software, customer There is a lack of consensus in the literature about “large
collaboration, and responding to change. scale” applications to the APM context. One stream refers
The Agile Manifesto [1] established twelve principles, to the scalability from the lines of code in software devel-
which can be summarized in customer satisfaction through opment, amount of data, hardware relationships, number of
collaborative work between self-organized and motivated customers, users, and developers involved [100]. Another
teams, containing business people and developers, who stream has focused on the organization's size, different

13

Content courtesy of Springer Nature, terms of use apply. Rights reserved.

Requirements Engineering (2022) 27:117–134 119

sectors involved, and the degree of iteration among these the ScienceDirect database. However, for downloading
sectors for configuring the large-scale agile method [80]. the full papers, we have to search the publisher archives.
A third flow refers to the size of the project and takes into According to the flowchart presented in Fig. 1, initially, the
account the project cost [15], the project duration, and the search string and logic operators applied to the research
number of people involved [29]. Projects can be considered topics (title, abstract, and keywords) of the databases were
large scale when they have 2 to 9 collaborating teams [31] or the following: “scal*” And “agile” And “project.” The *
at least six different teams [29]. For being considered large allows different variations of the search string, such as
scale, the team has to be over 50 people in size [15, 29]. scaling and scale so scal*. Then, we applied two filters,
For this research, we defined large scale considering both document types (article and review) and language (Eng-
project size according to [31] and organizational environ- lish). This initial sample extracted 200 papers from the
ments when discussing the evolution of APM adoption to Scopus database and 112 from the ISI Web of Science
other areas according to [80], in order to obtain the larg- database. From these 312 articles, there were 83 duplicates
est possible scope of research from the literature, which is between the two databases, closing the first sample with
understood and will allow a more complete analysis of the 229 documents to be analyzed.
proposed theme. The 229 documents were screened considering two
selection criteria: (i) lack of scope fit, i.e., the relation-
ship with agile project management themes and discus-
3 Research methodology sions within complex and/or large-scale project environ-
ments, (ii) lack of research methods and/or lack of research
3.1 Sampling process background. According to the scope fit criterion, most of
the surveyed publications (122 articles) were excluded
The searching process was conducted in both Scopus and in this step. Considering the fit with APM, we identified
ISI Web of Science databases to identify studies con- papers using the term agility referring to the speed or the
ducted in different areas, which addressed agile project speed in executing an activity; there were also articles in
management. They provide a simultaneous search in vari- which the scale approach did not apply to this study, thus
ous sources and publishers through an interface that uses not responding to the research interest and scope. A few
a standard set of search fields, generating large amounts papers (7) were excluded because it was not possible to
of data [42]. Scopus is a comprehensive database that download the articles. Thus, the final sample of this study
indexes metadata from thousands of publishers, including consisted of 76 articles.

Search Strategy
Strings & Logic Operators

Search filters
(Document types and
language)

WoS 112
WoS Ω Scopus = 83 papers
Initial Sample
(WoS and Scopus)

Scopus 200
229 papers

Bibliometric
(Sample demographics and
Exclusion Criteria 76 papers citation analysis)
(Scope fit and Quality)
Sample screening Data Extraction

Content Analysis

Fig. 1  Research flow

13

Content courtesy of Springer Nature, terms of use apply. Rights reserved.

120 Requirements Engineering (2022) 27:117–134

3.2 Data analysis performed applying the IBM SPSS software, aiming to asso-
ciate variables and attributes [46]. Second, the core–periph-
Given the sample of 76 publications, bibliometric and con- ery analysis and network analysis were both performed by
tent analyses were performed. Such types of investigation the UCINET6 software [22].
allow the elaboration of a more robust analytical framework,
in order to respond to research questions [68] in a consistent
way, presenting analyses that complement each other and
4 Results
point out relevant points for discussions.
The results obtained in this study are adequate to answer
3.2.1 Bibliometric analysis
the proposed research questions. To answer the question
(RQ1): “What are the key barriers to scaling APM to large
Bibliometrics reaches large volumes of digital bibliomet-
projects?”, 53 barriers found in the literature are presented in
ric data to distill reliable and easily processible informa-
Sect. 4.2.2, separated into 7 categories. Such barriers address
tion [10]. We used bibliometric analysis because it allows
organizational issues, management issues, agile method bar-
quantifying the results from the sample, providing research
riers, product and process issues, customer issues, and team
metrics from a data set extracted from the bases [50]. [60,
issues, as shown in Table 3.
61] summarize the SLR guidelines in three main phases
The Research Question (RQ2) “What are the main
that appear sequential but involve interaction: planning the
benefits observed for adopting APM for large projects?”
review, conducting the study, and reporting the review. We
responds in this study to 32 identified benefits, as presented
applied bibliometrics to sample demographics as the most
in Sect. 4.2.3. Benefits were categorized into business ben-
cited works, the leading journals on the topic, and the pub-
efits, process/product benefits, and team benefits and are
lications' evolution over the years.
shown in Table 4.
We performed bibliometric analysis through descrip-
Finally, the third research question (RQ3) “What is the
tive statistics and Bibliometrix software [8]. In this step,
relationship between barriers and benefits?” is answered in
we characterized the sample demographics by identifying
Sect. 4.4, which presents analyses that identify possible rela-
the most relevant authors and reference documents. Then,
tionships between management issues and benefits for the
in the Bibliometrix-Biblioshiny software, we performed the
team (Fig. 6), barriers of the agile method and all categories
conceptual structure and intellectual structure analysis [84],
of benefits (Fig. 7), as well as relationships between the bar-
running thematic mapping.
riers of the method agile (Fig. 8).
3.2.2 Content analysis
4.1 Sample demographics
In content analysis, it is necessary to make decisions about
what will be searched, and sometimes it is even required to The APM in the large-scale literature shows an increasing
review the categories previously selected [95]. It analyzes publications pattern. It is interesting to note that the last five
trends, categorizations, and evolution of the theme in the years represent 50% of the 18-year sample, highlighting the
literature over time [101], which directs this research to the growth in importance of the theme. This phenomenon can
entire reading of the sample. We developed a coding scheme reflect what [34] (p. 36) pointed out as the “second wave of
for the content analysis in an iterative process seeking to agile methods” which “address challenges of scale, replacing
identify core codes, frequencies, and literature traceability. advice from project management frameworks on address-
Coding allows ground hypotheses, discovering patterns, ing layered organizations with portfolios, addressing risks,
moving from a lower to a higher level of understanding [9]. increasing the number of roles and practices for coordination
We applied the Weber protocol for developing the cod- and alignment across teams.”
ing schema [36], which begins with recording unit defini- The sample demographics show that the 20 most cited
tion (word and text segments), coding categories definition, articles per year of the sample represent around 70% of the
identifying the codes, and testing on a sample of text to start total number of citations, as shown in Table 1. Table 1 shows
codebook development. As the content analysis progressed, the most cited articles per year of the sample. Together, they
it was crucial to assess the accuracy and reliability of the represent around 70% of the total number of citations from
sample coding and revise the coding rules while finishing the sample articles.
the codebook. After identifying the top reference in Table 1, we identi-
Further analyses were performed exploring the relation- fied the more productive and cited authors over time (see
ship among codes through cross-tabulation, core–periphery Fig. 2). The figure shows greater production referring to the
analysis, and network analysis. First, cross-tabulation was agile theme from the second decade of the 2000s onward, in

13

Content courtesy of Springer Nature, terms of use apply. Rights reserved.

Requirements Engineering (2022) 27:117–134 121

Table 1  Number of citations per year addition to highlighting authors with the highest number of
References Cited by Cited/year % citations, such as Dingsøyr and Moe.
To identify the trend topics over time, we used Bibliome-
Nerur et al. [74] 562 35.13 19.59 trix (Biblioshiny), as shown in Fig. 3. It is interesting that
Serrador and Pinto [94] 179 29.83 6.24 requirement engineering moves from an emerging topic to
Dingsøyr et al. [33] 60 20.00 2.09 a basic theme.
Boehm and Turner [19] 296 18.50 10.32
Ramesh et al. [83] 191 17.36 6.66 4.2 Content analysis
Hoda et al. [52] 59 14.75 2.06
Petersen and Wohlin [78] 134 11.17 4.67 To answer RQ1 and RQ2, we performed the codes fre-
Daneva et al. [27] 88 11.00 3.07 quency analysis and triangulated them with the qualitative
Shameem et al. [96] 11 11.00 0.38 content analysis of the articles, as presented in the following
Šmite et.al. [100] 41 10.25 1.43 sections.
Akbar et al. [2] 30 10.00 1.05
Mergel [70] 47 9.40 1.64 4.2.1 Type of study
Alqudah and Razali [3] 44 8.80 1.53
Hobbs and Petit [51] 35 8.75 1.22 The type of study category is composed of four codes, as
Petersen and Wohlin [79] 94 8.55 3.28 shown in Table 2. According to the large-scale concepts
Bick et al. [17] 25 8.33 0.87 raised in Sect. 2.2, 50 articles conducted just the large-scale
Dingsøyr et al. [32] 23 7.67 0.80 project study (TS_01). Sixteen dealt only with the sched-
Dingsøyr et al. [31] 47 6.71 1.64 uling for the organizational environment (TS_02), with 5
Dingsøyr and Moe [30] 46 6.57 1.60 addressed both directions (TS_01 and TS_02), and another
Bass [11] 38 6.33 1.32 five did not specify the approach. Twenty-three papers
dealt only with the agile project management application
(TS_03), and the other 35 addressed only the hybrid system
of traditional project management methods with GAP or the
transition from the first to the second within organizations

Legend:
Lines represents authors’ timeline.
Bubble size is proportional to the number of documents.
Color intensity is proportional to the total citation per year.

Fig. 2  Top authors’ production over time. Note Extracted using Biblioshiny

13

Content courtesy of Springer Nature, terms of use apply. Rights reserved.

122 Requirements Engineering (2022) 27:117–134

Fig. 3  Thematic map. Note: Extracted using Biblioshiny

Table 2  Types of study on large-scale agile methodology

Description Code # % References

Type of study Scaling for large projects or multi-projects TS_01 55 72 [2, 4, 11–13, 15–18, 23, 24, 26–28, 30–35, 40, 41, 44, 45, 48, 51,
53, 54, 56, 59, 63, 65, 70–73, 75, 78, 82, 85, 86, 90, 93, 94, 96,
98–100, 102–105, 107, 110, 111]
Scaling for organizational environment TS_02 21 28 [3, 19, 20, 28, 30, 34, 38, 39, 43, 47, 49, 51, 57, 58, 64, 67, 70, 74,
76, 91, 109]
Only agile methods TS_03 25 33 [4, 7, 12, 13, 30–32, 34, 35, 41, 44, 52, 54, 57, 59, 65, 72, 73, 83,
85, 96, 102, 103, 109, 111]
Hybrid approaches TS_04 37 49 [2, 15–20, 23, 24, 26–28, 30, 33, 39, 43, 45, 47, 49, 51, 65, 67, 70,
71, 74, 76, 78, 79, 81, 91, 93, 94, 99, 100, 104, 105, 110]

(TS_04). Just two articles approached both aspects (TS_03 changes.” [51] (p. 5) address the challenges “related to the
and TS_04), describing the demands of studies of the clash between the agile and traditional cultures; for exam-
themes, while 16 did not clarify the type of scenario studied. ple, development process conflicts, variability in subsys-
tems developed that might not integrate easily, different life
4.2.2 Barriers cycles, and difficulty in using agile in legacy systems.”
Among the managerial barriers, architecture (MI_10) and
The barriers category comprises six categories and 53 codes, requirement (MI_01) issues are more often mentioned. [78]
as shown in Table 3: organizational issues (OI), managerial (p. 1486) highlight that in a large scale, “the architecture
issues (MI), agile method barriers (AMB), product/process receives little focus in agile development leading to bad
issues (PPI), customer issues (CI), and team issues (TI). design decisions” and “due to the complexity and the num-
In the organizational issues, culture (OI_01) is the most ber of people that have to be involved in each decision, the
mentioned issue (10 times), followed by approaches (OI_03) continuity of the requirements flow is thwarted.”
and transition (OI_04) with nine articles each, exploring The barriers to scaling the agile method most often men-
these barriers. [74] (p.74) highlight that “such changes may tioned are minimal documentation (AMB_06) (13 times)
impact several aspects of the organization including its and technologies/tools/methods (AMB_04) (11 times). As
structure, culture, and management practices.” The relation- [19] (p. 35) highlights, “unfortunately, most agile methods
ship between culture and process is also highlighted by [70] don't support the degree of documentation and infrastructure
(p. 522), who argue that the main challenge is “the cultural required for lower-level certification; it might, in fact, make
change that needs to go hand-in-hand with the procedural agile methods less effective.”

13

Content courtesy of Springer Nature, terms of use apply. Rights reserved.

Requirements Engineering (2022) 27:117–134 123

Table 3  Key barriers to large scale

Description Code # % References

Organizational issues Organizational culture OI_01 10 13 [15, 19, 41, 43, 51, 52, 70, 74, 96, 105]
Organizational structure OI_02 6 8 [17, 19, 30, 40, 74, 96]
Organizational approach OI_03 9 12 [43, 51, 57, 58, 67, 70, 86, 96, 104]
Transition framework OI_04 9 12 [17, 39, 41, 43, 45, 51, 74, 76, 79]
Strategic management OI_05 4 5 [51, 58, 83, 86]
Managerial issues Requirement management MI_01 17 22 [4, 15, 16, 19, 26–28, 40, 41, 48, 65, 67, 78, 79, 83, 105,
107]
Innovation management MI_02 1 1 [57]
Knowledge management MI_03 12 16 [4, 20, 27, 30, 31, 41, 52, 57, 70, 74, 96, 100]
Resource management MI_04 9 12 [2, 17, 39, 48, 49, 57, 79, 90, 103]
Scope management MI_05 14 18 [2, 7, 18, 27, 28, 40, 49, 51, 53, 65, 71, 78, 96, 102]
Configuration management MI_06 1 1 [78]
Cost management MI_07 5 7 [2, 18, 65, 83, 90, 96]
Schedule management MI_08 11 14 [2, 18, 32, 40, 49, 71, 78, 83, 90, 93]
Change management MI_09 4 5 [32, 65, 102, 103]
Architecture management MI_10 17 22 [4, 13, 28, 30, 32, 33, 38, 40, 48, 51, 57, 67, 71, 78, 82,
83, 85]
Portfolio management MI_11 5 7 [3, 30, 57, 102, 103]
Contractual criteria MI_12 4 5 [51, 53, 70, 81]
Agile Method_Barriers Knowledge of agile methods AMB_01 8 11 [4, 20, 39–41, 51, 93, 96]
People-centric AMB_02 1 1 [74]
Agile principles and values AMB_03 9 12 [19, 20, 26, 28, 40, 74, 78, 79, 100]
Technologies/tools/methods AMB_04 11 14 [24, 28, 41, 43, 65, 67, 74, 93, 96, 98, 104]
Development cycle AMB_05 7 9 [19, 26, 28, 30, 40, 41, 53]
Minimal documentation AMB_06 13 17 [4, 19, 20, 26, 28, 65, 67, 78, 81–83, 90, 96]
Over-optimism AMB_07 1 1 [48]
Ignorance to risk awareness AMB_08 4 5 [2, 19, 82, 111]
Product and process issues Quality PPI_01 4 5 [2, 4, 65, 81]
Reuse limitation PPI_02 2 3 [81, 111]
Mainly use in software PPI_03 3 4 [40, 45, 94]
Traceability PPI_04 2 3 [26, 28]
Certification processes PPI_05 3 4 [19, 40, 67]
Effort invested in the planning events PPI_06 3 4 [48, 65, 96]
Maintenance PPI_07 5 7 [19, 26, 28, 65, 78]
Project size PPI_08 11 14 [2, 27, 32, 40, 59, 78, 81, 96, 100, 105, 111]
Progress measurement PPI_09 4 5 [7, 19, 53, 79]
Legacy projects PPI_10 4 5 [4, 19, 23, 58]
Project/system portfolio PPI_11 7 9 [19, 35, 49, 57, 67, 102, 103]
Supplier management and partnering PPI_12 2 3 [40, 57]
Development interfaces PPI_13 4 5 [4, 26, 40, 58]
Regulatory compliance PPI_14 4 5 [20, 40, 53, 81]
Customer issues Customer adjustment CI_01 7 9 [15, 33, 41, 43, 51, 83, 96]
Customer relationship CI_02 11 14 [15, 27, 33, 40, 41, 49, 51, 53, 74, 96, 102]
Multiple customers CI_03 7 9 [24, 27, 33, 51, 58, 83, 105]

13

Content courtesy of Springer Nature, terms of use apply. Rights reserved.

124 Requirements Engineering (2022) 27:117–134

Table 3  (continued)
Description Code # % References

Team issues Team coordination TI_01 26 34 [4, 17–19, 26–28, 30–33, 40, 48, 51, 59, 65, 67, 72, 75,
78, 79, 90, 100, 105, 107, 111]
Management features TI_02 12 16 [19, 30, 39, 41, 49, 51, 70, 74, 75, 79, 86, 96]
Reward systems TI_03 4 5 [19, 74, 96, 103]
Teamwork TI_04 11 14 [3, 15, 32, 51, 52, 59, 74, 81, 93, 96, 100]
Overcommitment TI_05 1 1 [49]
Level of competence TI_06 7 9 [3, 40, 41, 65, 74, 100, 105]
Team maturity TI_07 8 11 [4, 11, 20, 49, 96, 98, 100, 105]
Time zone difference TI_08 5 7 [11, 39, 52, 59, 96]
Dependency TI_09 8 11 [11–13, 17, 32, 59, 65, 72]
Communication TI_10 16 21 [4, 15, 19, 39, 41, 52, 59, 65, 67, 73, 78, 90, 96, 100,
105, 107]
Geographic distribution TI_11 10 13 [11, 19, 39, 59, 67, 81, 90, 100, 105, 111]

Among the main barriers related to product and process grouped into the macro themes: business, product and pro-
issues, project size (PPI_08) is explored in 11 articles, as cess, and team.
stated by [27] (p.1336), “agile requirements engineering Among the business benefits, we can highlight fast
practices need to be implemented differently in large pro- cycle time (BB_05) and best financial and performance
jects because at a specific project size and mode of execu- results (BB_09), explored in more than 10 articles each.
tion (such as offshore outsourced),” and the size of product According to [57] (p. 417), “Agile software development
customization projects “measured in the actual effort (work models advocate short (no longer than a few weeks),
hours), beyond a certain level brings with it all the complexi- usually time-boxed development iterations” because the
ties of scale, and therefore impact the accuracy of the effort “highest priority is to satisfy the customer through early
estimates” [105] (p. 11). and continuous delivery of valuable software.” “The level
As regards customer issues, customer relationship of Agile used in a project does have a statistically signifi-
(CI_02) is the most indicated. [51] (p. 16) highlight that cant impact on all three dimensions of project success, as
“One of the biggest challenges is the relationship between judged by efficiency, stakeholder satisfaction, and percep-
the project and the client organization, which is related to tion of overall project performance” [94] (p. 1049).
the challenges with the role of product owner.” Product and process benefits, productivity (PPB_03)
Team coordination (TI_01) and communication (TI_10) and requirement management improvement (PPB_11) are
are more often mentioned among the team issues category. more often mentioned. [64] (p.9) highlights, “early adop-
“Larger organizations must pay specific attention to identi- ters of Scaled Agile Framework have reported significant
fying how to synchronize teams” [19] (p. 31), because “the improvement in terms of productivity and quality.” Also,
team must be able to communicate and coordinate with other according to [47] (p. 293) “Agile requirements handling
teams in the organization, and the developed software must entails that knowledge be managed when available, mini-
integrate smoothly with a larger software system” [67] (p. mizing the strain and wasted effort of eliciting information
30). that is not yet available.”
In the team benefits, frequent feedback (TB_01) and
communication (TB_04) are the most cited benefits. [78]
4.2.3 Benefits (p. 1481) corroborates when identifying there were “bet-
ter knowledge transfer due to better communication and
The benefit codes are composed of three categories (busi- frequent feedback from each iteration.” “The short cycle
ness, product and process, and team) and 32 codes, as shown time and frequent feedback help an agile development
in Table 4. The 32 kinds of benefits obtained using APM team create better estimates for each iteration, especially
in more than one company's project or department were after gaining experience over several cycles” [83] (p. 463).

13

Content courtesy of Springer Nature, terms of use apply. Rights reserved.

Requirements Engineering (2022) 27:117–134 125

Table 4  Key benefits to large scale

Description Code # % References

Business benefits Customer engagement BB_01 10 13 [15, 17, 23, 26, 27, 44, 56, 65, 91, 104]
Stakeholders satisfaction BB_02 5 7 [18, 67, 73, 91, 94]
Sharing the benefits BB_03 1 1 [103]
Business process integration BB_04 5 7 [34, 47, 57, 91, 109]
Fast cycle time BB_05 15 20 [18, 39, 45, 49, 53, 54, 57, 64, 65, 67, 76, 79, 104,
110, 111]
Better resource management BB_06 6 8 [48, 67, 76, 91, 109, 111]
Stakeholders management BB_07 1 1 [44]
Change management BB_08 3 4 [12, 44, 83]
Best financial and performance results BB_09 12 16 [27, 39, 48, 49, 64, 67, 70, 75, 78, 91, 94, 109]
Product and process benefits Quality PPB_01 8 11 [45, 51, 63, 67, 76, 79, 91, 104]
Reliability PPB_02 2 3 [45, 99]
Productivity PPB_03 12 16 [3, 47, 51, 64, 65, 67, 91, 93, 99, 104, 109, 111]
Simplicity PPB_04 4 5 [3, 64, 93, 103]
Compliance PPB_05 1 1 [91]
Flexibility PPB_06 3 4 [19, 49, 103]
Prototyping and experimentation PPB_07 6 8 [26, 56, 64, 75, 103, 111]
Lean features PPB_08 4 5 [57, 63, 76, 93]
Better risk and failure management PPB_09 9 12 [12, 39, 48, 65, 70, 76, 79, 91, 104]
Documentation amount PPB_10 3 4 [32, 75, 79]
Requirements management improvement PPB_11 12 16 [18, 39, 47, 48, 54, 63, 73, 78, 79, 83, 91, 110]
Team benefits Frequent feedback TB_01 20 26 [17–19, 23, 27, 28, 39, 47, 48, 51, 64, 65, 75, 76, 78,
79, 83, 104, 110, 111]
Learning TB_02 10 13 [39, 44, 63, 64, 67, 75, 78, 104, 109, 111]
Practice community TB_03 3 4 [100, 109, 111]
Communication TB_04 19 25 [3, 18, 26, 27, 32, 39, 44, 48, 49, 65, 67, 78, 79, 83,
91, 93, 104, 110, 111]
Transparency TB_05 10 13 [18, 27, 39, 48, 70, 78, 93, 99, 104, 111]
Control TB_06 5 7 [39, 44, 78, 93, 104]
Responsiveness TB_07 8 11 [39, 44, 57, 64, 91, 99, 104, 110]
Leadership TB_08 4 5 [51, 57, 64, 111]
Work life quality and team motivation TB_09 7 9 [39, 44, 49, 51, 57, 67, 111]
High level of trust TB_10 2 3 [39, 111]
Cooperation TB_11 7 9 [3, 39, 64, 75, 79, 93, 111]
Customer commitment TB_12 3 4 [56, 73, 99]

4.3 Cross‑tabulation analysis (AMB_06), Schedule Management (MI_08), Communi-

cation (TI_10), and Scope Management (MI_05), with a
For understanding the relationship among different code cat- core/periphery fit of 0.5889 (see Fig. 4). We identified
egories, we performed the core–periphery analysis that uses 32 benefits to the business, process/product, and teams,
a genetic algorithm to fit a core/periphery model [21]. We when large-scale projects adhere to agile management.
used two different levels of analysis: In the first, all barrier Figure 5 shows the core–periphery analysis that identi-
codes were used, while the second used benefit codes as a fies class benefits as core membership, which are Best
basis, as shown in Figs. 4 and 5. financial and performance results (BB_09), Learning
The analysis revealed that the barrier categories are (TB_02), Fast cycle time (BB_05), Requirements man-
strongly connected, mainly the core membership class agement improvement (PPB_11), Transparency (TB_05),
barriers, namely Project size (PPI_08), Architecture Man- Communication (TB_04), Frequent Feedback (TB_01),
agement (MI_10), Requirement Management (MI_01), and Productivity (PPB_03), with a core/periphery fit of
Team coordination (TI_01), Minimal Documentation 0.7143.

13

Content courtesy of Springer Nature, terms of use apply. Rights reserved.

126 Requirements Engineering (2022) 27:117–134

Fig. 4  Core–periphery analysis

results for barrier codes. Note
Based on content analysis data
using the UCINET software

Fig. 5  Core–periphery analysis

results for benefit codes. Note
Content analysis data using the
UCINET software

4.4 Network analysis TB_01, TB_04, BB_05, PPB_03 is more often mentioned

in the surveyed literature. Figure 8 shows the relationship
To help understand the relationships among barriers and among the 8 AMBs that suggest a strong binding among
benefits and thus answer RQ 3, we performed two networks agile principles and values (AMB_03) with the Technolo-
based on the cross-tabulation data in NetDraw software [22]. gies/tools/methods (AMB_04) and Minimal Documentation
The greater the thickness of the lines, the greater the rela- (AMB_06).
tionship between them. That is, the more times both vari-
ables were co-cited in the surveyed sample. Figure 6 shows
the relation between the six barrier categories and the three 5 Discussions
benefit categories. The relationship between managerial bar-
riers (MI) and team barriers (TB) is more often connected The theme under study addresses a challenge for organiza-
with all three categories of benefits. There is a lack of studies tions seeking ways to respond to new demands and requests
exploring customer barriers with benefits. by reviewing their processes and ways of managing them,
Figures 7 and 8 show in depth the relationship among the as it is increasingly important to be flexible in dealing with
agile methods barriers and between them and the benefits. the incessant requirement changes, customer needs, and to
Figure 7 focuses on the specific barriers related to the agile be able to bring solutions quickly to the market [78]. Under-
method and their relationship with the benefits. The link standing the organization's ramifications of a changing phe-
between barriers AMB_03, AMB_04, AMB_06 and benefits nomenon is critical in planning and managing such a change

13

Content courtesy of Springer Nature, terms of use apply. Rights reserved.

Requirements Engineering (2022) 27:117–134 127

Customer Issues
(CI)

Organizational Issues
(OI)

Business Benefits
(BB)

Managerial Issues
(MI)

Product & Process Benefits

(PPB)

Team Issues
(TI)

Team Benefits
Agile Method Barriers (TB)
(AMB)

Product & Process Issues

(PPI)

Fig. 6  Relationship between all barrier categories and benefit categories. Note Based on content analysis data using the UCINET software. Line
thickness represents the intensity of relations

[74]. The approaches adopted will always have advantages company may encounter when scaling its agile team. In
and disadvantages that need to be assessed to maximize the addition, other teams involved in the project [72], stake-
advantages and minimize the disadvantages. holder involvement, and adjustment [15] can present
The survey of the points of attention or challenges por- problems in large-scale scenarios, affecting the aspect of
trays the importance of understanding the main problems in autonomy of self-managed teams in small groups.
large-scale agile development to obtain the most significant In large traditional organizations, it is necessary to
benefits [78]. Even a management methodology that allows review their organizational cultures and management
flexibility and agility, such as agile project management, has modes to apply APM in large proportions and produce
points that must be analyzed and mixed with other manage- good results [51, 70]. This issue also collides with the
ment forms to provide better results. adoption of a new work methodology that is no longer
restricted to just one group but becomes part of the routine
5.1 Large‑scale agile barriers of a significant portion of the organization. [109] high-
lights the importance of leaders' responsibility for promot-
The scalability of the agile project management method- ing the change, developing the vision and strategy that
ology highlights some features as evidence that when it help identify the necessary improvements and support the
is applied alone or to pilot projects, it may not be evident teams to achieve business goals.
or be overlooked due to the excellent counterpart results Traditional management aspects, such as requirements,
[19, 78]. However, these are relevant issues for a broader scope, costs, and timelines, also have to be raised when
set of projects or applications across multiple sectors of an agile management takes on more significant proportions
organization. within the organization, be it in multiple projects or mul-
Project size, geographic distribution, regulatory compli- tiple sectors. The complexity, number of people involved,
ance [81], cultural and organizational complexities, and many stakeholders, a large number of partners, the waiting
corporate strategy issues [51] are critical factors that a for creations and the prioritization and re-prioritization

13

Content courtesy of Springer Nature, terms of use apply. Rights reserved.

128 Requirements Engineering (2022) 27:117–134

Fig. 7  Relationship between agile methods barriers and benefits. Note Based on content analysis data using the UCINET software. Line thick-
ness represents the intensity of relations

process in large-scale development using agile methods self-implemented practices, but rather regard the interface
are challenges for management [14, 27, 78]. between these practices and other existing ones [67].
One of the reasons for focusing on such aspects is the Such a structure may require product owners to take on
certification requirements observed in bodies such as ISO, new roles, primarily because of the need to manage multiple
CMMI, and other certifying or process regulating bod- development teams elsewhere, and it will probably include
ies [19]. By focusing on meeting demands quickly, devel- other countries while customers are in the organization's
opment teams focus on implementing functionality, no host country [11]. The autonomy and improvisation inher-
longer documenting requirements or specifications [83]; ent to the agile approaches directly affect the agile project
this means that companies do not have enough records to portfolio, which requires greater coordination among pro-
prove their actions toward facing certification processes jects to ensure the portfolio being built is aligned with the
and which may not be sufficient for the stakeholder knowl- intended portfolio [103].
edge required [92]. Leaders who will implement agile management in larger
Hence, the challenges of implementing large-scale agile projects can face challenges other than those routinely exist-
methodologies are not in the agile project or in the new ing due to dealing with the coordination among teams, such

13

Content courtesy of Springer Nature, terms of use apply. Rights reserved.

Requirements Engineering (2022) 27:117–134 129

Fig. 8  The relationship between

agile methods barriers. Note
Based on content analysis data
using the UCINET software.
Line thickness represents the
intensity of relations

AMB_01 AMB_02 AMB_03 AMB_04 AMB_05 AMB_06 AMB_07 AMB_0

AMB_01 - Knowledge of Agile Methods 8 2 3 2 3

AMB_02 - People-centric 1 1 1
AMB_03 - Agile principles and values 2 1 9 2 4 5 1
AMB_04 - Tecnologies / tools / methods 3 1 2 11 2 4
AMB_05 - Development cycle 2 4 2 7 3 1
AMB_06 - Minimal Documentation 3 5 4 3 13 2
AMB_07 - Over-optimism 1
AMB_08 - Ignorance to risk awareness 1 1 2 4

as difficulties in estimations and communication [105]; it can sharing information, logistical issues, and difficulties vari-
require more planning structure and effort to coordinate all ability [19], as well as multi-site development with teams
those involved toward the same goal [78]. Although smaller geographically distributed working together, which exacer-
projects have colocated teams, the different teams are prob- bates the bias of underestimation of the efforts required to
ably distributed across multiple locations, including in other accomplish the project [105].
countries with different time zones, making network prac- Agile teams tend to improve internal communication but
tices necessary to consider the distances among them [100]. become more isolated from the business context. It could be
Development teams must interact with other organiza- a problem when trying to scale agile project management at
tional units, understanding that organizational forms and the organization level because the involvement of key deci-
innovation-driven cultures can adopt agile methods more sion-makers and the bureaucratic nature of the business can
quickly than those built around bureaucracy and formali- work in opposition to the principles of agility [15]. The use
zation [74]. To develop a product that goes beyond soft- of flexible planning, extensive communication, and social
ware, having embedded systems and hardware is even more bonding can be proposed to promote understanding, col-
required from the large-scale agile methodology. Core prod- laboration, and coordination of the distributed work [111].
ucts with significant investments in areas other than pro- Therefore, the coordination of teams in large-scale agile
ject teams tend to become a priority, which raises issues applications is crucial, involving constant iterations and
about the appropriate distribution of development resources deliveries. At different levels of team, project, and program,
within programs and the portfolio [40]. More than project it is possible to identify work proposals that allow greater
size related to team size, for a successful application of agile support to companies [72]. To contribute to adopting the
project management on a large scale, it is essential to note large-scale agile methodology, it needs to be more organic
that transformational leadership, agility, and value congru- in this relevant aspect; structural models have been launched
ence are significant factors for successful outcomes in these in the market.
scenarios [86]. Project managers have to work so that teams [49] discussed some examples of structured models such
are less impacted by problems encountered in applying as the Large_Scale Scrum (LeSS®) framework and Scaled
agile on a large scale, such as competition, difficulties in Agile Framework® (SAFe). In LeSS®, development teams

13

Content courtesy of Springer Nature, terms of use apply. Rights reserved.

130 Requirements Engineering (2022) 27:117–134

are maintained over time; there are levels of product owners frequent feedback and interact more directly with product
by area and combinations of areas that manage the backlog development [23], establishing greater trust and transpar-
[49]. According to the official Web site, LeSS is based on ency in the team environment [99].
large-scale work, whereby several teams work together on a Through combined identification of critical path and team
product, using Scrum's principles, purposes, and elements dependencies [39], the approach focused on requirements
[66]. SAFe has three layers (portfolio, program, and team), prioritization reduces waste on non-profit or non-viable
whose backlogs are divided into resources that are group- items [49], increasing quality, capability to perform tests,
ings of stories organized among teams, which have dedicated and the traceability of requirements from process optimiza-
product owners [49]. SAFe combines agile practices with tion and the pursuit of gradual improvements [63].
other methodologies, including a lean approach through These approaches, coupled with early defect detection
planning guidelines and continuous delivery iterations [89]. and resolution [76] facilitated by agile initiatives, contribute
Other compatible methods are also common when agile is to higher product quality [79]. Thus, it is possible to envis-
practiced in other organizational environments, such as the age a sharing of benefits through broader standardization,
Lean philosophy, as agile principles may not guide an organ- which contributes to self-organization among projects [103],
ization in the most efficient way with respect to portfolio greater effectiveness in cost [70], when considering the level
management and program levels, for example [64]. of programs or portfolio.

5.2 Benefits of large‑scale agile 5.3 Coexistence of barriers and benefits

Despite what has been pointed out about the limitations The use of agile practices can lead to benefits, but such
found in the application of agile large-scale project man- results may justify the emergence of new barriers or dif-
agement, some researchers found benefits in such scenarios. ficulties because they require new behavior and actions not
Different viewpoints, differences of opinion, and tensions previously practiced. An example is the case of increased
are inevitable in any large-scale movement [111]. Therefore, transparency and control, identified as advantages, simulta-
it is vital to have a strategic alignment by sharing the vision neously generating the need for greater management coor-
behind the change, its motivators, goals, value, and mean- dination when applied to large projects and large numbers
ing [109], adapting to new ways of working to be coherent of people involved, which is a challenge [78].
and motivating. Adaptations of agile management to existing work meth-
Agile project management on a large scale contributes to odologies are referenced to minimize the negative impacts
adding flexibility to mature organizations, showing that it is observed in agile deployment, allowing the organization to
suitable even for large systems with long life cycles, highly enjoy its benefits. Companies need to analyze the relation-
complex projects, and safety criticality since the corporate ship between methods to avoid unnecessary conflicts and
culture is convergent and promotes the acceptance of the efforts [67].
proposed methodology [67]. Although the adoption of agile project management in a
The shared knowledge and the perception of the benefits large-scale context can bring benefits, this research did not
[93] when adopting agile project management are differen- identify a systematized approach that analyzes the relation-
tials that motivate teams to continue on the path to scaling ships between benefits and barriers. Figures 6, 7, and 8 point
such principles in the work environment. Communities of out some interesting insights for future research because they
practices are a positive influence, as they promote knowl- suggest some propositions.
edge exchange among different teams, increasing the fre- Some barriers and benefits appear simultaneously in sev-
quency of communication and networking, facilitating team eral papers, generating interest in the possibility of a cor-
coordination informally [100]. relation between them and the effect of one on the other. In
Increasing trust between teams, maturity, knowledge Fig. 6, the managerial barriers (MI) appear strongly related
integration, and sharing of ideology provides well-being to all the benefit categories, which suggest the following
and pride in the work performed [44], promoting a better proposition for a future research agenda:
quality of life for employees, fostering understanding and P1 Managerial barriers (MI) influence the achievement
learning. Communication at frequent planning events leads of the potential. However, the MI effect on each benefit cat-
to a greater understanding of business requirements and the egory (BB, TB, and PPB) can have a distinctive magnitude.
alignment of the next steps. These enable revisions as well as Similar reasoning can be applied to the relationship
sharing responsibilities across the organization [48]. These between the barriers specifically related to the team issues
aspects also influence the involvement and commitment of (TI) and the three categories of benefits (BB, TB, and PPB).
clients, who become part of the project, seeking and support- There is a lack of studies bridging AMB and business ben-
ing the search for quick solutions [110]. They also receive efits, while the team benefit (TB) and product and process

13

Content courtesy of Springer Nature, terms of use apply. Rights reserved.

Requirements Engineering (2022) 27:117–134 131

benefits are more often explored, as shown in Fig. 7. There- This paper presents limitations related to the methodolog-
fore, this is a research gap that may be better explored and ical approach adopted. First, the searching strategies adopted
could contribute to the decision-making for adopting agile (databases selected, search strings, logical operators applied,
in large projects and large organizations. Therefore, the fol- search filters, and exclusion criteria) can narrow the sample.
lowing proposition should be investigated in depth. The inherent subjectivity of the qualitative content analysis
P2 The barriers of scaling agile methods to large projects process by researchers may also present limitations.
(AMB) affect the achievement of benefits.
Figure 8 presents the relations between agile methods Acknowledgements The authors gratefully acknowledge the financial
support of the Brazilian research funding agencies CNPq (National
issues in the sample analyzed. It is possible to identify that Council for Scientific and Technological Development).
Agile Principles and Values (AMB_03) and Minimal Docu-
mentation (AMB_06) are mentioned concurrently in several
articles, leading to the proposition:
P3 Implementation of Agile Principles and Values References
is generally associated with a Minimal Documentation
characteristic. 1. Agile Manifesto (2020) Manifesto for agile Software Develop-
ment. https://​agile​manif​esto.​org/
2. Akbar MA, Sang J, Khan AA, Amin FE, Hussain S, Sohail
MK, Xiang H, Cai B (2018) Statistical analysis of the effects of
heavyweight and lightweight methodologies on the six-pointed
6 Conclusions, limitations, and future star model. IEEE Access 6:8066–8079. https://​doi.​org/​10.​1109/​
research ACCESS.​2018.​28057​02
3. Alqudah M, Razali R (2016) A review of scaling agile methods
in large software development. Int J Adv Sci Eng Inf Technol.
This article brings threefold contribution to the literature. https://​doi.​org/​10.​18517/​ijase​it.6.​6.​1374
First, it identifies the main barriers to scaling up the agile 4. Alsaqaf W, Daneva M, Wieringa R (2019) Quality requirements
method for large projects. We identified 53 barriers clustered challenges in the context of large-scale distributed agile: An
into six categories: organizational issues, managerial issues, empirical study. Inf Softw Technol 110:39–55. https://​doi.​org/​
10.​1016/j.​infsof.​2019.​01.​009
agile method-specific barriers, product/process issues, cus- 5. Al Blooshi M, Jafer S, Patel K (2018) Review of formal agile
tomer issues, and team issues. Second, it identifies the 32 methods as cost-effective airworthiness certification processes.
benefits of applying APM to large projects clustered into J Aerosp Inf Syst. https://​doi.​org/​10.​2514/1.​I0106​01
three categories: business, product and process, and team. 6. Amaral DC, Conforto EC, Benassi JLG, Araújo C (2011) Geren-
ciamento Ágil de Projetos - Aplicação em produtos inovadores,
Finally, the third contribution is related to the cross-tabula- Saraiva, São Paulo
tion of barriers and benefits, looking for potential correla- 7. Amjad S, Ahmad N, Saba T, Anjum A, Manzoor U, Balubaid
tions. For the requirement engineering (RE) community, the MA, Malik SUR (2017) Calculating completeness of agile scope
study shows the critical role of requirement management, in scaled agile development. IEEE Access 6:5822–5847. https://​
doi.​org/​10.​1109/​ACCESS.​2017.​27653​51
impacting both barriers and benefits for scaling agile project 8. Aria M, Cuccurullo C (2017) bibliometrix: An R-tool for com-
management. prehensive science mapping analysis. J Informet 11(4):959–975
Some practical implications can be drawn from this study 9. Auerbach CF, Silverstein LB (2003) Qualitative data: an intro-
by exploring how different barriers can arise when apply- duction to coding and analysis. New York University Press
books, New York
ing APM to large-scale projects. The study pointed out the 10. Ball R, Tunger D (2006) Bibliometric analysis – a new business
categories of barriers at a distinctive level of analysis: the area for information professionals in libraries? Support for sci-
organization, the team, and the customer perspectives. It entific research by perception and trend analysis. Scientometrics
demonstrates the lack of research exploring the benefits of 66(3):561–577. https://​doi.​org/​10.​1007/​s11192-​006-​0041-0
11. Bass JM (2015) How product owner teams scale agile methods to
APM for the business. It also pointed out the lack of studies large distributed enterprises. Empir Softw Eng 20(6):1525–1557.
exploring barriers related to the customer. https://​doi.​org/​10.​1007/​s10664-​014-​9322-z
Another issue for future research is the validation of 12. Bass JM (2019) Agile on a large scale. ITNOW 61(1):56–57.
the factors identified in the literature in the business envi- https://​doi.​org/​10.​1093/​itnow/​bwz023
13. Bass JM, Haxby A (2019) Tailoring Product Ownership in Large-
ronment. The coding book developed herein can be used Scale Agile Projects: Managing Scale, Distance, and Govern-
for researchers to create questionnaires for future surveys ance. IEEE Softw 36(2):58–63. https://​doi.​org/​10.​1109/​MS.​
with practitioners to explore these barriers and benefits in 2018.​28855​24
practice. Thus, these remain as potential topics for a future 14. Belsis P, Koutoumanos A, Sgouropoulou C (2014) PBURC: a
patterns-based, unsupervised requirements clustering frame-
research agenda. The data analysis, obtained from project work for distributed agile software development. Requir Eng
members involved in agile projects on a large scale, can 19(2):213–225. https://​doi.​org/​10.​1007/​s00766-​013-​0172-9
bring more information about the occurrence of barriers and 15. Berger H, Beynon-Davies P (2009) The utility of rapid appli-
benefits, including considerations about their correlation. cation development in large-scale, complex projects. Inf Syst

13

Content courtesy of Springer Nature, terms of use apply. Rights reserved.

132 Requirements Engineering (2022) 27:117–134

J 19(6):549–570. https://​doi.​org/​10.​1111/j.​1365-​2575.​2009.​ Jedlitschka A, Kuvaja P, Kuhrmann M, Männistö T, Münch

00329.x J, Raatikainen M (eds) Product-focused software process
16. Beyer H, Holtzblatt K, Baker L (2004) An agile customer-cen- improvement. PROFES 2014. Lecture notes in computer sci-
tered method: rapid contextual design. In: Zannier C, Erdog- ence, vol 8892. Springer, Cham https://​doi.​org/​10.​1007/​978-
mus H, Lindstrom L (eds) Extreme programming and agile 3-​319-​13835-0_​20
methods - XP/Agile Universe 2004. XP/Agile Universe 2004. 32. Dingsøyr T, Moe NB, Seim EA (2018) Coordinating knowl-
Lecture Notes in Computer Science, vol 3134. Springer, Berlin, edge work in multi-team programs: findings from a large-scale
Heidelberg agile development program. Proj Manag J 49(6):64–77. https://​
17. Bick S, Spohrer K, Hoda R, Scheerer A, Heinzl A (2018) Coor- doi.​org/​10.​1177/​87569​72818​798980
dination challenges in large-scale software development: a case 33. Dingsøyr T, Moe NB, Fægri TE, Seim EA (2018) Exploring
study of planning misalignment in hybrid settings. IEEE Trans software development at the very large-scale: a revelatory
Softw Eng 44(10):932–950. https://​doi.​org/​10.​1109/​TSE.​2017.​ case study and research agenda for agile method adaptation.
27308​70 Empir Softw Eng 231:490–520. https://​d oi.​o rg/​1 0.​1 007/​
18. Bjarnason E, Wnuk K, Regnell B (2012) Are you biting off more s10664-​017-​9524-2
than you can chew? A case study on causes and effects of over- 34. Dingsøyr T, Falessi D, Power K (2019) Agile development at
scoping in large-scale software engineering. Inf Softw Technol scale: the next frontier. IEEE Softw 36(2):30–38. https://​doi.​
54:1107–1124. https://​doi.​org/​10.​1016/j.​infsof.​2012.​04.​006 org/​10.​1109/​MS.​2018.​28848​84
19. Boehm B, Turner R (2005) Management challenges to imple- 35. Dingsøyr T, Dybå T, Gjertsen M, Jacobsen AO, Mathisen TE,
menting agile processes in traditional development organizations. Nordfjord JO, Røe K, Strand K (2019) Key lessons from tai-
IEEE Softw 22(5):30–39. https://​doi.​org/​10.​1109/​MS.​2005.​129 loring agile methods for large-scale software development. IT
20. Boehm B, Turner R (2003) Rebalancing your organization’s agil- Prof 21(1):34–41. https://​doi.​org/​10.​1109/​MITP.​2018.​28769​84
ity and discipline. In: Maurer F, Wells D (eds) Extreme program- 36. Duriau VJ, Reger RK, Pfarrer MD (2007) A content analysis of
ming and agile methods - XP/Agile Universe 2003. XP/Agile the content analysis literature in organization studies: Research
Universe 2003. Lecture notes in computer science, vol 2753. themes, data sources, and methodological refinements. Organ
Springer, Berlin, Heidelberg Res Methods 10(1):5–34
21. Borgatti SP, Everett MG (1999) Models of core/periphery struc- 37. Dyba T, Dingsøyr T (2008) Empirical studies of agile software
tures. Soc Netw 21:375–395. https://​doi.​org/​10.​1016/​S0378-​ development: a systematic review. Inf Softw Technol 50:833–
8733(99)​00019-2 859. https://​doi.​org/​10.​1016/j.​infsof.​2008.​01.​006
22. Borgatti SP, Everett MG, Freeman LC (2002) Ucinet for Win- 38. Eckstein J (2014) Architecture in large scale agile develop-
dows: software for social network analysis. Analytic Technolo- ment. In: Dingsøyr T, Moe NB, Tonelli R, Counsell S, Gencel
gies, Harvard C, Petersen K (eds) Agile methods. Large-scale development,
23. Britto R, Smite D, Damm LO (2016) Software architects in large- refactoring, testing, and estimation. XP 2014. Lecture notes in
scale distributed projects: an ericsson case study. IEEE Softw business information processing, vol 199. Springer, Cham
33(6):48–55. https://​doi.​org/​10.​1109/​MS.​2016.​146 39. Eickhoff FL, McGrath ML, Mayer C, Bieswanger A, Wojciak
24. Chen PS, Chen GYH, Lien SF, Huang WT (2019) Using Scrum PA (2018) Large-scale application of IBM design thinking and
and unified modelling language to analyze and design an auto- agile development for IBM z14. IBM J Res Dev 62(2/3):1–9.
matic course scheduling system. J Chin Inst Eng 42(6):534–543. https://​doi.​org/​10.​1147/​JRD.​2018.​27958​79
https://​doi.​org/​10.​1080/​02533​839.​2019.​16139​30 40. Eklund U, Olsson HH, Strøm NJ (2014) Industrial challenges
25. Conforto EC, Salum F, Amaral DC, Silva SL, Almeida LFM of scaling agile in mass-produced embedded systems. In: Ding-
(2014) Can agile project management be adopted by industries søyr T, Moe NB, Tonelli R, Counsell S, Gencel C, Petersen
other than software development? Proj Manag J 45(3):21–34. K (eds) Agile methods. Large-scale development, refactoring,
https://​doi.​org/​10.​1002/​2Fpmj.​21410 testing, and estimation. XP 2014. Lecture notes in business
26. Dabney JB, Arthur JD (2019) Applying standard independent information processing, vol 199, pp 30–42
verification and validation techniques within an agile framework: 41. Faisal Abrar M, Sohail M, Ali S, Faran Majeed M, Ali Shah
Identifying and reconciling incompatibilities. Syst Eng 22:348– I, Rashid N, Ullah N (2020) De-motivators for the adoption
360. https://​doi.​org/​10.​1002/​sys.​21487 of agile methodologies for large-scale software development
27. Daneva M, van der Veen E, Amrit C, Ghaisas S, Sikkel K, Kumar teams: an SLR from management perspective. J Soft Evol Pro-
R, Ajmeri N, Ramteerthkar U, Wieringa R (2013) Agile require- cess 32(12):e2268. https://​doi.​org/​10.​1002/​smr.​2268
ments prioritization in large-scale outsourced system projects: 42. Franco EF, Hirama K, Carvalho MM (2018) Applying system
An empirical study. J Syst Softw 86:1333–1353. https://​doi.​org/​ dynamics approach in software and information system pro-
10.​1016/j.​jss.​2012.​12.​046 jects: A mapping study. Inf Softw Technol 93:58–73. https://​
28. Díaz J, Pérez J, Alarcón PP, Garbajosa J (2011) Agile product doi.​org/​10.​1016/j.​infsof.​2017.​08.​013
line engineering—a systematic literature review. Softw Pract Exp 43. Gandomani TJ, Nafchi MZ (2015) An empirically-developed
41(8):921–941. https://​doi.​org/​10.​1002/​spe.​1087 framework for agile transition and adoption: a grounded theory
29. Dikert K, Paasivaara M, Lassenius C (2016) Challenges and suc- approach. J Syst Softw 107:204–219. https://​doi.​org/​10.​1016/j.​
cess factors for large-scale agile transformations: a systematic jss.​2015.​06.​006
literature review. J Syst Softw 119:87–108. https://​doi.​org/​10.​ 44. Goh JCL, Pan SL, Zuo M (2013) Developing the agile is devel-
1016/j.​jss.​2016.​06.​013 opment practices in large-scale it projects: The trust-mediated
30. Dingsøyr T, Moe NB (2014) Towards principles of large-scale organizational controls and it project team capabilities perspec-
agile development. In: Dingsøyr T, Moe NB, Tonelli R, Coun- tives. J Assoc Inf Syst 14(12):722–756
sell S, Gencel C, Petersen K (eds) Agile methods. Large-scale 45. Grimheden ME (2013) Can agile methods enhance mechatron-
development, refactoring, testing, and estimation. XP 2014. Lec- ics design education? Mechatronics 23(8):967–973. https://​doi.​
ture notes in business information processing, vol 199. Springer, org/​10.​1016/j.​mecha​troni​cs.​2013.​01.​003
Cham https://​doi.​org/​10.​1007/​978-3-​319-​14358-3_1 46. Hair JF Jr, Black WC, Babin BJ, Anderson RE (2009) Multi-
31. Dingsøyr T, Fægri TE, Itkonen J (2014) What is large in large- variate data analysis, 7th edn. Harlow, Pearson
scale? A taxonomy of scale for agile software development. In:

13

Content courtesy of Springer Nature, terms of use apply. Rights reserved.

Requirements Engineering (2022) 27:117–134 133

47. Hannay JE, Brathen K, Mevassvik OM (2017) Agile requirements 66. LeSS® (2020) Large-scale scrum. https://​less.​works/​less/​frame​
handling in a service-oriented taxonomy of capabilities. Requir work/​intro​ducti​on.​html
Eng 22(2):289–314. https://​doi.​org/​10.​1007/​s00766-​016-​0244-8 67. Lindvall M, Muthig D, Dagnino A, Wallin C, Stupperich M,
48. Heikkilä VT, Paasivaara M, Rautiainen K, Lasssenius C, Toivola Kiefer D, May J, Kahkonen T (2004) Agile software development
T, Järvinen J (2015) Operational release planning in large-scale in large organizations. IEEE Computer Society 37(12):26–34.
Scrum with multiple stakeholders - a longitudinal case study at https://​doi.​org/​10.​1109/​MC.​2004.​231
F-Secure Corporation. Inf Softw Technol 57:116–140. https://​ 68. Lopes APVBV, Carvalho MM (2018) Evolution of the open
doi.​org/​10.​1016/j.​infsof.​2014.​09.​005 innovation paradigm: towards a contingent conceptual model.
49. Heikkilä VT, Paasivaara M, Lasssenius C, Damian D, Engb- Technol Forecast Soc Chang 132:284–298. https://​doi.​org/​10.​
lom C (2017) Managing the requirements flow from strategy to 1016/j.​techf​ore.​2018.​02.​014
release in large-scale agile development: a case study at Erics- 69. Mahnic V (2012) A capstone course on agile software develop-
son. Empir Softw Eng 22(6):2892–2936. https://d​ oi.o​ rg/1​ 0.1​ 007/​ ment. IEEE Trans Educ 55(1):99–106. https://​doi.​org/​10.​1109/​
s10664-​016-​9491-z TE.​2011.​21423​11
50. Henneken EA, Kurtz MJ (2017) Usage bibliometrics as a tool to 70. Mergel I (2016) Agile innovation management in government:
measure research activity a research agenda. Gov Inf Q 33:516–523. https://​doi.​org/​10.​
51. Hobbs B, Petit Y (2017) Agile methods on large projects in large 1016/j.​giq.​2016.​07.​004
organizations. Proj Manag J 48(3):3–19. https://d​ oi.o​ rg/1​ 0.1​ 177/​ 71. Mitsuyuki T, Hiekata K, Goto T, Moser B (2017) Evaluation
2F875​69728​17048​00301 of project architecture in software development mixing water-
52. Hoda R, Salleh N, Grundy J, Tee HM (2017) Systematic litera- fall and agile by using process simulation. J Ind Integ Manage.
ture reviews in agile software development: a tertiary study. Inf https://​doi.​org/​10.​1142/​S2424​86221​75000​75
Softw Technol 85:60–70. https://​doi.​org/​10.​1016/j.​infsof.​2017.​ 72. Moe NB, Dingsøyr T, Rolland K (2018) To schedule or not to
01.​007 schedule? An investigation of meetings as an inter-team coordi-
53. Hoeren T, Pinelli S (2018) Agile programming – introduction and nation mechanism in large-scale agile software development. Int
current legal challenges. Comput Law Secur Rev 34(5):1131– J Inf Syst Proj Manag 6(3):45–59. https://​doi.​org/​10.​12821/​ijisp​
1138. https://​doi.​org/​10.​1016/j.​clsr.​2018.​04.​004 m0603​03
54. Jorgensen M (2019) Relationships between project size, agile 73. Muñoz Sanabria LG, Hurtado Alegria JA, Álvarez Rodriguez FJ
practices, and successful software development: results and (2018) Agile architecture in action (AGATA). Ing Univ. https://​
analysis. IEEE Softw 36(2):39–43. https://​doi.​org/​10.​1109/​MS.​ doi.​org/​10.​11144/​Javer​iana.​iyu22-1.​aaaa
2018.​28848​63 74. Nerur S, Mahapatra R, Mangalaraj G (2005) Challenges of
55. Karlström D, Runeson P (2005) Combining agile methods with migrating to agile methodologies. Commun ACM Adapt Com-
stage-gate project management. IEEE Softw 22(3):43–49. https://​ plex Enterp 48(5):72–78. https://d​ oi.o​ rg/1​ 0.1​ 145/1​ 06071​ 0.1​ 0607​
doi.​org/​10.​1109/​MS.​2005.​59 12
56. Kendall RP, Mark A, Squires SE, Halverson CA (2010) Condor: 75. Nord RL, Ozkaya I, Kruchten P (2014) Agile in distress: architec-
case study of a large-scale, physics-based code development ture to the rescue. In: Dingsøyr T, Moe NB, Tonelli R, Counsell
project. Comput Sci Eng 12(3):22–27. https://​doi.​org/​10.​1109/​ S, Gencel C, Petersen K (eds) Agile methods. Large-scale devel-
MCSE.​2010.​59 opment, refactoring, testing, and estimation. XP 2014. Lecture
57. Kettunen P (2009) Adopting key lessons from agile manufactur- notes in business information processing, 199. Springer, Cham
ing to agile software product development - a comparative study. 76. Olszewska M, Heidenberg J, Weijola M, Mikkonen K, Porres I
Technovation 29(6–7):408–422. https://​doi.​org/​10.​1016/j.​techn​ (2016) Quantitatively measuring a large-scale agile transforma-
ovati​on.​2008.​10.​003 tion. J Syst Softw 117:258–273. https://​doi.​org/​10.​1016/j.​jss.​
58. Kettunen P, Laanti M (2008) Combining agile software projects 2016.​03.​029
and large-scale organizational agility. Softw Process Improv 77. Paasivaara M, Behm B, Lassenius C, Hallikainen M (2014)
Pract 13(2):183–193. https://​doi.​org/​10.​1002/​spip.​354 Towards rapid releases in large-scale xaas development at erics-
59. Khalid A, Butt SA, Jamal T, Gochhait S (2020) Agile scrum son: a case study. In: IEEE 9th international conference on global
issues at large-scale distributed projects: scrum project develop- software engineering. DOI: https://d​ oi.o​ rg/1​ 0.1​ 109/I​ CGSE.2​ 014.​
ment at large. Int J Softw Innov (IJSI) 8(2):85–94. https://​doi.​ 22
org/​10.​4018/​IJSI.​20200​40106 78. Petersen K, Wohlin C (2009) A comparison of issues and advan-
60. Kitchenham B (2004) Procedures for performing systematic tages in agile and incremental development between state of the
reviews. Keele UK Keele Univ 33(2004):1–26 art and an industrial case. J Syst Softw 82(9):1479–1490. https://​
61. Keele S (2007) Guidelines for performing systematic literature doi.​org/​10.​1016/j.​jss.​2009.​03.​036
reviews in software engineering (vol 5). Technical report, Ver. 79. Petersen K, Wohlin C (2010) The effect of moving from a plan-
2.3 EBSE Technical Report. EBSE driven to an incremental software development approach with
62. Kruchten P (2011) Contextualizing agile software development. agile practices: An industrial case study. Empir Softw Eng
J Softw Evol Process 25:351–361. https://​doi.​org/​10.​1002/​smr.​ 15:654–693. https://​doi.​org/​10.​1007/​s10664-​010-​9136-6
572 80. Power K (2014) A model for understanding when scaling agile
63. Kühner G, Bluhm T, Heimann P, Hennig C, Kroiss H, Krom J, is appropriate in large organizations. In: Dingsøyr T, Moe NB,
Laqua H, Lewerentz M, Maier J, Schacht J, Spring A, Werner A, Tonelli R, Counsell S, Gencel C, Petersen K (eds) Agile meth-
Zilker M (2012) Progress on standardization and automation in ods. large-scale development, refactoring, testing, and estimation.
software development on W7X. Fusion Eng Des 87(12):2232– XP 2014. Lecture notes in business information processing, 199.
2237. https://​doi.​org/​10.​1016/j.​fusen​gdes.​2012.​06.​003 Springer, Cham. https://​doi.​org/​10.​1007/​978-3-​319-​14358-3_8
64. Laanti M (2014) Characteristics and principles of scaled agile. 81. Qureshi MRJ, Hussain SA (2008) An adaptive software develop-
springer international publishing Switzerland - XP 2014 Work- ment process model. Adv Eng Softw 39(8):654–658. https://​doi.​
shops. Lect Notes Bus Inf Process 199:9–20 org/​10.​1016/j.​adven​gsoft.​2007.​08.​001
65. Lebdeh LA, Qasim A, Kharbat F (2020) Implementing agility 82. Qureshi MRJ (2012) Agile software development methodol-
in large software development projects. TEM Journal 9(3):1285. ogy for medium and large projects. IET Software 6(4):358–363.
https://​doi.​org/​10.​18421/​TEM93-​58 https://​doi.​org/​10.​1049/​iet-​sen.​2011.​0110

13

Content courtesy of Springer Nature, terms of use apply. Rights reserved.

134 Requirements Engineering (2022) 27:117–134

83. Ramesh B, Cao L, Baskerville R (2010) Agile requirements engi- 99. Siqueira R, Camarinha D, Wen M, Meirelles P, Kon F (2018)
neering practices and challenges: an empirical study. Inf Syst Continuous delivery: building trust in a large-scale, complex
J 20(5):449–480. https://​doi.​org/​10.​1111/j.​1365-​2575.​2007.​ government organization. IEEE Softw. https://​doi.​org/​10.​1109/​
00259.x MS.​2018.​11109​5426
84. Ramos-Rodríguez AR, Ruíz-Navarro J (2004) Changes in the 100. Šmite D, Moe NB, Šāblis A, Wohlin C (2017) Software teams
intellectual structure of strategic management research: A biblio- and their knowledge networks in large-scale software develop-
metric study of the Strategic Management Journal, 1980–2000. ment. Inf Softw Technol 86:71–86. https://​doi.​org/​10.​1016/j.​
Strateg Manag J 25(10):981–1004 infsof.​2017.​01.​003
85. Read K, Maurer F (2003) Issues in scaling agile using an archi- 101. Soldatenko D, Backer E (2019) A content analysis of cross-cul-
tecture-centric approach: a tool-based solution. In: Maurer F, tural motivational studies in tourism relating to nationalities. J
Wells D (eds) Extreme programming and agile methods - XP/ Hosp Tour Manag 38:122–139. https://​doi.​org/​10.​1016/j.​jhtm.​
Agile Universe 2003. XP/Agile Universe 2003. Lecture notes in 2018.​12.​004
computer science, 2753. Springer, Berlin, Heidelberg 102. Sweetman R, O’Dwyer O, Conboy K (2014) Control in soft-
86. Riaz MN, Mahboob A, Buriro A (2018) Social success factors ware project portfolios: a complex adaptive systems approach. In:
affecting implementation of agile software development meth- Dingsøyr T, Moe NB, Tonelli R, Counsell S, Gencel C, Petersen
odologies in software industry of pakistan: an empirical study. K (eds) Agile methods. Large-scale development, refactoring,
Int J Adv Comput Sci Appl. https://​doi.​org/​10.​14569/​IJACSA.​ testing, and estimation. XP 2014. Lecture notes in business infor-
2018.​090713 mation processing, p 199. Springer, Cham
87. Rigby DK, Sutherland J, Takeuchi H (2016) Embracing Agile. 103. Sweetman R, Conboy K (2018) Portfolios of agile projects: a
Harv Bus Rev 50:40–48 complex adaptive systems’ agent perspective. Proj Manag J
88. Rubin E, Rubin H (2011) Supporting agile software development 49(6):18–38. https://​doi.​org/​10.​1177/​87569​72818​802712
through active documentation. Requirements Eng 16(2):117– 104. Talby D, Keren A, Hazzan O, Dubinsky Y (2006) Agile software
132. https://​doi.​org/​10.​1007/​s00766-​010-​0113-9 testing in a large-scale project. IEEE Softw 23(4):30–37. https://​
89. SAFe® (2020) Scaled agile framework. https://​www.​scale​dagil​ doi.​org/​10.​1109/​MS.​2006.​93
efram​ework.​com/​about/ 105. Usman M, Britto R, Damm L-O, Börstler J (2018) Effort estima-
90. Saeeda H, Khalid H, Ahmed M, Sameer A, Arif F (2015) Sys- tion in large-scale software development: an industrial case study.
tematic literature review of agile scalability for large scale pro- Inf Softw Technol. https://​doi.​org/​10.​1016/j.​infsof.​2018.​02.​009
jects. Int J Adv Comput Sci Appl. https://​doi.​org/​10.​14569/​ 106. Van Haaster K (2016) Responding to change: agile-in-the-large,
IJACSA.​2015.​060908 approaches and their consequences. In: Sharp H, Hall T (eds)
91. Sahid A, Maleh Y, Belaissaoui M (2018) A practical agile frame- Agile processes, in software engineering, and extreme program-
work for IT service and asset management ITSM/ITAM through ming XP 2016. Lecture notes in business information processing,
a case study. J Cases Inf Technol. https://​doi.​org/​10.​4018/​JCIT.​ vol 251, pp 312–315. Springer, Cham. https://​doi.​org/​10.​1007/​
20181​00105 978-3-​319-​33515-5_​32
92. Saito S, Iimura Y, Massey AK, Antón AI (2018) Discovering 107. Wagstrom P, Herbsleb JD (2006) Dependency forecasting in the
undocumented knowledge through visualization of agile soft- distributed agile organization. Commun ACM 49(10):55–56.
ware development activities. Requirements Eng 23(3):381–399. https://​doi.​org/​10.​1145/​11644​20
https://​doi.​org/​10.​1007/​s00766-​018-​0291-4 108. Williams L, Cockburn A (2003) Agile Software Development:
93. Saltz JS, Heckman RR (2018) A scalable methodology to guide It’s about Feedback and Change. IEEE Comput Soc 36(6):39–43.
student teams executing computing projects. ACM Trans Comput https://​doi.​org/​10.​1109/​MC.​2003.​12043​73
Educ. https://​doi.​org/​10.​1145/​31454​77 109. Woodward EV, Bowers R, Thio VS, Johnson K, Srihari M, Bracht
94. Serrador P, Pinto JK (2015) Does agile work? - A quantitative CJ (2010) Agile methods for software practice transformation.
analysis of agile project success. Int J Project Manage 33:1040– IBM J Res Dev 54(2):1–12. https://​doi.​org/​10.​1147/​JRD.​2009.​
1051. https://​doi.​org/​10.​1016/j.​ijpro​man.​2015.​01.​006 20387​49
95. Seuring S, Müller M (2008) From a literature review to a con- 110. Yang OS, Park KR, Kim DH (2018) A study on cloud-based
ceptual framework for sustainable supply chain management. J project management system model: Focus on New-ICT project.
Clean Prod 16(15):1699–1710. https://​doi.​org/​10.​1016/j.​jclep​ro.​ J Theor Appl Inf Technol 96(5):1334–1346
2008.​04.​020 111. Zheng Y, Venters W, Cornford T (2011) Collective agility, para-
96. Shameem M, Kumar RR, Nadeem M, Khan AA (2020) Taxo- dox and organizational improvisation: the development of a par-
nomical classification of barriers for scaling agile methods in ticle physics grid. Inf Syst J 21(4):303–333. https://​doi.​org/​10.​
global software development environment using fuzzy analytic 1111/j.​1365-​2575.​2010.​00360.x
hierarchy process. Appl Soft Comput 90:106122. https://d​ oi.o​ rg/​
10.​1016/j.​asoc.​2020.​106122 Publisher's Note Springer Nature remains neutral with regard to
97. Sheffield J, Lemétayer J (2013) Factors associated with the soft- jurisdictional claims in published maps and institutional affiliations.
ware development agility of successful projects. Int J Project
Manage 31:459–472. https://​doi.​org/​10.​1016/j.​ijpro​man.​2012.​
09.​011
98. Schneider JG, Johnston L (2005) eXtreme programming––
helpful or harmful in educating undergraduates? J Syst Softw
74:121–132. https://​doi.​org/​10.​1016/j.​jss.​2003.​09.​025

13

Content courtesy of Springer Nature, terms of use apply. Rights reserved.

Terms and Conditions
Springer Nature journal content, brought to you courtesy of Springer Nature Customer Service Center GmbH (“Springer Nature”).
Springer Nature supports a reasonable amount of sharing of research papers by authors, subscribers and authorised users (“Users”), for small-
scale personal, non-commercial use provided that all copyright, trade and service marks and other proprietary notices are maintained. By
accessing, sharing, receiving or otherwise using the Springer Nature journal content you agree to these terms of use (“Terms”). For these
purposes, Springer Nature considers academic use (by researchers and students) to be non-commercial.
These Terms are supplementary and will apply in addition to any applicable website terms and conditions, a relevant site licence or a personal
subscription. These Terms will prevail over any conflict or ambiguity with regards to the relevant terms, a site licence or a personal subscription
(to the extent of the conflict or ambiguity only). For Creative Commons-licensed articles, the terms of the Creative Commons license used will
apply.
We collect and use personal data to provide access to the Springer Nature journal content. We may also use these personal data internally within
ResearchGate and Springer Nature and as agreed share it, in an anonymised way, for purposes of tracking, analysis and reporting. We will not
otherwise disclose your personal data outside the ResearchGate or the Springer Nature group of companies unless we have your permission as
detailed in the Privacy Policy.
While Users may use the Springer Nature journal content for small scale, personal non-commercial use, it is important to note that Users may
not:

1. use such content for the purpose of providing other users with access on a regular or large scale basis or as a means to circumvent access
control;
2. use such content where to do so would be considered a criminal or statutory offence in any jurisdiction, or gives rise to civil liability, or is
otherwise unlawful;
3. falsely or misleadingly imply or suggest endorsement, approval , sponsorship, or association unless explicitly agreed to by Springer Nature in
writing;
4. use bots or other automated methods to access the content or redirect messages
5. override any security feature or exclusionary protocol; or
6. share the content in order to create substitute for Springer Nature products or services or a systematic database of Springer Nature journal
content.
In line with the restriction against commercial use, Springer Nature does not permit the creation of a product or service that creates revenue,
royalties, rent or income from our content or its inclusion as part of a paid for service or for other commercial gain. Springer Nature journal
content cannot be used for inter-library loans and librarians may not upload Springer Nature journal content on a large scale into their, or any
other, institutional repository.
These terms of use are reviewed regularly and may be amended at any time. Springer Nature is not obligated to publish any information or
content on this website and may remove it or features or functionality at our sole discretion, at any time with or without notice. Springer Nature
may revoke this licence to you at any time and remove access to any copies of the Springer Nature journal content which have been saved.
To the fullest extent permitted by law, Springer Nature makes no warranties, representations or guarantees to Users, either express or implied
with respect to the Springer nature journal content and all parties disclaim and waive any implied warranties or warranties imposed by law,
including merchantability or fitness for any particular purpose.
Please note that these rights do not automatically extend to content, data or other material published by Springer Nature that may be licensed
from third parties.
If you would like to use or distribute our Springer Nature journal content to a wider audience or on a regular basis or in any other manner not
expressly permitted by these Terms, please contact Springer Nature at

[email protected]