0% found this document useful (0 votes)

21 views16 pages

What Makes Agile Software Development Agile

What_Makes_Agile_Software_Development_Agile

Uploaded by

thiprodutos

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

21 views16 pages

What Makes Agile Software Development Agile

What_Makes_Agile_Software_Development_Agile

Uploaded by

thiprodutos

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 16

This article has been accepted for publication in a future issue of this journal, but has not been

fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TSE.2021.3099532, IEEE
Transactions on Software Engineering
1

What Makes Agile Software Development Agile?

Marco Kuhrmann, Paolo Tell, Regina Hebig, Jil Klünder, Jürgen Münch, Oliver Linssen, Dietmar Pfahl,
Michael Felderer, Christian R. Prause, Stephen G. MacDonell, Joyce Nakatumba-Nabende, David Raffo,
Sarah Beecham, Eray Tüzün, Gustavo López, Nicolas Paez, Diego Fontdevila, Sherlock A. Licorish,
Steffen Küpper, Günther Ruhe, Eric Knauss, Özden Özcan-Top, Paul Clarke, Fergal McCaffery,
Marcela Genero, Aurora Vizcaino, Mario Piattini, Marcos Kalinowski, Tayana Conte, Rafael Prikladnicki,
Stephan Krusche, Ahmet Coşkunçay, Ezequiel Scott, Fabio Calefato, Svetlana Pimonova,
Rolf-Helge Pfeiffer, Ulrik Pagh Schultz, Rogardt Heldal, Masud Fazal-Baqaie, Craig Anslow,
Maleknaz Nayebi, Kurt Schneider, Stefan Sauer, Dietmar Winkler, Stefan Biffl, Maria Cecilia Bastarrica,
and Ita Richardson

Abstract—Together with many success stories, promises such as the increase in production speed and the improvement in
stakeholders’ collaboration have contributed to making agile a transformation in the software industry in which many companies want
to take part. However, driven either by a natural and expected evolution or by contextual factors that challenge the adoption of agile
methods as prescribed by their creator(s), software processes in practice mutate into hybrids over time. Are these still agile? In this
article, we investigate the question: what makes a software development method agile? We present an empirical study grounded in a
large-scale international survey that aims to identify software development methods and practices that improve or tame agility. Based
on 556 data points, we analyze the perceived degree of agility in the implementation of standard project disciplines and its relation to
used development methods and practices. Our findings suggest that only a small number of participants operate their projects in a
purely traditional or agile manner (under 15%). That said, most project disciplines and most practices show a clear trend towards
increasing degrees of agility. Compared to the methods used to develop software, the selection of practices has a stronger effect on the
degree of agility of a given discipline. Finally, there are no methods or practices that explicitly guarantee or prevent agility. We conclude
that agility cannot be defined solely at the process level. Additional factors need to be taken into account when trying to implement or
improve agility in a software company. Finally, we discuss the field of software process-related research in the light of our findings and
present a roadmap for future research.

Index Terms—Agile Software Development, Hybrid Development Methods, Survey Research, Software Development, Software
Process.
F

1 I NTRODUCTION
higher, stronger—the Olympic motto1 could also
F ASTER ,
be the motto for today’s software development practice.
Software development needs to be creative, conducted by
are software development processes that are associated with
the term “agile software development”, and there are meth-
ods and practices that are perceived as “agile”. However,
self-organizing cross-functional teams. Collaboration is key the use of many of these methods in practice is limited
and working software is in the spotlight. This aspiration, by contextual factors and in certain settings, practices often
which is also reflected in the “Agile Manifesto” [1], has associated with agile may have been in use prior to the agile
become an ideal pursued by many companies. Agile software manifesto [7]. In response, projects compose their individual
development has now been around for 20 years, and there is processes to address the respective needs (we refer to these
no denying that it has led to several improvements [2] such as hybrid methods [8]). Still, companies want to participate
as increased speed of software development and intensified in the “Agile Transformation” for various reasons and,
collaboration between different stakeholders. therefore, there is also interest in creating “agile” methods.
However, when asking project managers and developers This motivates the primary question of this article: What
what agile software development means, the answer is makes a software development method agile?
likely: Scrum or XP [3]. Refining the question and adding In this article, we present an empirical study grounded
further contextual factors, e.g., globally distributed software in a large-scale international survey2 , which identified meth-
development or software development in regulated do- ods and practices that either enable or impede agility of
mains, the answer is not that simple anymore [4]–[6]. Due to software development methods. Based on 556 data points,
the hype and numerous (partially) contradicting definitions, we analyze the degree of agility in the implementation of
there is much confusion regarding the terminology and the eleven standard project disciplines, which are based on the
concepts. However, quite often, people only think that they
work agile or even pretend to work agile [3]. That is, there 2. This research is based on the HELENA study (Hybrid dEveLop-
mENt Approaches in software systems development, online: https:
//helenastudy.wordpress.com), which is a large-scale international
Manuscript received April 19, 2005; revised August 26, 2015. (Corresponding survey in which 75 researchers and practitioners from 25 countries
author: Marco Kuhrmann, University of Passau, [email protected]) participated. We give further details on the implementation of the
1. from Latin: “Citius, Altius, Fortius” HELENA study in Section 3.2.

0098-5589 (c) 2021 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: Pontificia Universidade Catolica do Rio Grande do Sul (PUC/RS). Downloaded on December 08,2021 at 12:24:03 UTC from IEEE Xplore. Restrictions apply.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TSE.2021.3099532, IEEE
Transactions on Software Engineering
2

SWEBOK categories [9], such as requirements engineering requirements (e.g., regulations and norms), or in discussions
and testing as perceived by the survey participants. We link why certain companies do not use agile methods [19], [21],
these reports to the 24 methods and 36 practices used by the [22]. This trend can also be observed in many surveys that
participants to run their projects and we study if methods aim to collect evidence on agile methods, but barely put it
and practices affect the degree of agility. into context. For instance, the State of Agile survey [23] on a
Our findings indicate that few participants run their global scale, and several regional surveys such as the Swiss
projects in a purely agile or a purely traditional manner, Agile Study [24], the Status Quo Agile study [25], and [26] pro-
and most of them use home-grown hybrid development vides a snapshot of the status of agile methods being used in
methods. Out of 660 cases (pairwise combinations of 60 industry. However, these studies cover traditional processes
methods and practices with 11 project disciplines), 146 show only marginally—if at all. Furthermore, the perception of
a significant shift in the perceived degree of agility when what “agile” actually means is fairly diffuse. For instance,
using specific methods and practices. Of these 146 changed Jalali et al. [27] conclude that agility is judged differently
perceptions, 88 cases show a trend of moving from tradi- and is not a well-defined concept. This is also reflected in the
tional to agile. Another 29 cases show a significant shift with considerable effort that is spent on defining agile maturity,
no explicit tendency towards agile or traditional. Hence, we e.g., [20], [28], [29]. Yet, so far, there is no standardized
conclude that about half of the shifts found are towards agile maturity model that is comparable with and as widely
agile, even though we acknowledge that some shifts exist accepted as CMMI or ISO/IEC 15504. The results of these
that are neutral regarding the perceived degree of agility. studies thus generate an incomplete picture, and numerous
The remainder of this article is organized as follows: companies and project teams remain—or even become—
Section 2 presents related work. Section 3 describes the skeptical and do not consider agile methods as the “Silver
research design before we present the results in Section 4. Bullet” [17], [22], [30], [31].
Section 5 provides a summary and a discussion of our In 2011, West et al. [32] stated that modern software
findings. Furthermore, we derive a roadmap to steer future development evolved again. They coined the term Water-
research before we conclude the paper in Section 6. Scrum-Fall to reflect that software processes are in fact
combinations of different traditional and agile methods and
2 R ELATED W ORK practices. Supporting this claim, Aitken and Ilango [33] state
that “there is nothing really incompatible” with applying agility
The development of software process models dates back to
along with most traditional methods. A balanced combi-
the 1960s and, over time, numerous different approaches
nation is needed, an assertion already stated by Boehm
have been published. From the very beginning, the different
and Turner [34], who aimed to overcome the situation-
approaches used to organize software development have
specific shortcomings of agile and traditional development
been critically discussed. These discussions have begun with
by defining five dimensions that describe a project envi-
Royce [10] stating that strict sequential models do not3 prop-
ronment. This helped to determine a balanced method and,
erly reflect the needs of software development. In response,
eventually, to achieve a hybrid sweet spot [35]. These balanced
shorter iterations and incremental approaches became pop-
combinations have become reality as several studies show
ular, such as Boehm’s Spiral model [11] representing an
[36]–[40]. Traditional and agile approaches coexist and form
iterative, risk-driven process, and Mills [12] and Dyer [13]
the majority of practically used hybrid development methods
suggesting incremental development processes in the 1970s
[8], [41], [42]. Specifically, Tell et al. [8] found hundreds
and 1980s. In the following years, more software processes
of process variants which are composed of different agile
emerged. They included more methods, practices, and tools,
and traditional methods and practices, concluding that, for
becoming increasingly “heavy-weighted”, for example the
instance, there is no “one and only” correct implementation
Rational Unified Process (RUP; [14]). Over time, developers
of Scrum, and that agile methods and practices are not
began to reject these approaches as being too large, with too
implemented by the book [43]. Noll and Beecham [42]
few degrees of freedom, or too much focus on documenta-
hypothesize that the mindset of the company determines
tion rather than on producing working software. A counter-
whether a project will adopt a purely agile approach.
movement started to move away from documentation- and
specification-based software development towards making Even though current literature provides an increasing
software, which culminated in Beck’s Extreme Programming amount of research focusing on agile methods and practices,
[15] and, eventually, in the Agile Manifesto in 2001 [1]. it is still unclear what “agile” means. Is it the process model?
Complementing all these developments in practice, a Is it a mindset or a cultural question? Beck describes the
considerable body of research has been accumulated on the driving concept of the process modeling behind Extreme
software process. However, since researchers are naturally Programming as: “crank up all the knobs to 10 on the things
interested in “modern” software development [2], especially I thought were essential and leave out everything else”4 , which
in the past two decades, research has been overloaded points to a more behavioral perspective. Hence, we take the
with results regarding drivers, challenges, benefits, prac- position that agile is a mindset, i.e., the degree of agility is a
tices, case studies, popularity and so on of agile processes personal perception of the managers and developers involved in
(e.g., [2], [16]–[20]). This generates the impression that the a project [27]. In this article, we seek to study this personal
“traditional” processes have been entirely replaced, only perception of agility through a data-driven characterization
playing a role in process modeling in domains with special
4. Taken from an interview by informIT, March 23, 2001: http://
3. Royce is often considered the “inventor” of the Waterfall model, www.informit.com/articles/article.aspx?p=20972, last access: February
but, in fact, the term was coined later by Boehm. 6, 2019.

of reality, which captures details about individual processes Stage 0: Initial instrument development
reported by practitioners, as well as their perceived de- (2015, 3 researchers, test: 15 subjects in Germany)
gree of agility [44]. We aim to overcome subjectivity as
- Team extension
mentioned by Jalali et al. [27] and, therefore, to objectively - Instrument revision and quality assurance
identify those process elements that are more likely to be
associated with agility. Our work does not aim to provide a Stage 1: Public instrument test, initial data collection
(2016, 11 researchers, collection: May-July 2016 in Europe, 69 data points)
precise definition of the term “agile software development”.
Instead, we provide information about individual percep- - Team extension
- Instrument revision and quality assurance
tions and characterizations of agility which we quantify to - Instrument translation (4 languages)
determine their relation to software development processes.
Stage 2: Final instrument and data collection
(2017, 75 researchers, collection: May-November 2017 worldwide, 1,467 data points)

3 R ESEARCH D ESIGN
We describe our research design by presenting the research Fig. 1. Overview of the multi-staged data collection approach
questions in Section 3.1, the instrument development and
data collection procedures in Section 3.2, the detailed de-
The public test of the revised questionnaire, that included
scription of the data analysis procedures in Section 3.3, and
up to 25 questions, was conducted in 2016 in Europe and
the validity threats in Section 3.4.
yielded 69 data points [39], which were analyzed and used
to initiate the next stage. In Stage 2, the team was extended,
3.1 Research Objective and Research Questions with 75 researchers and practitioners from all over the
Research on agility and software processes is focused largely world. The revision of the questionnaire for Stage 2 focused
on frameworks, methods, and practices. However, does that on the improvement of structure and scope, e.g., relevance
mean that methods and practices are the (only) building blocks for and precision of the questions, value ranges for variables,
agility? In this paper, we aim to better understand whether and relevance of the topics included. Furthermore, the ques-
and how the degree of agility derives from the methods and tionnaire, which was available at that stage in English only,
practices used. We pose the following research questions: was translated to German, Spanish, and Portuguese. Further
RQ 1: What is the degree of agility in implementing typical details of the instrument are available in [44].
project disciplines in software companies? Software de-
velopment consists of a variety of activities grouped 3.2.2 Instrument Structure
in project disciplines, such as project and quality man- The final questionnaire consisted of five parts: Demographics
agement, architecture and design, implementation, (group/question code D, 10 questions), Process Use (code
and so forth [9]. Our first question addresses the PU, 13 questions), Process Use and Standards (code PS, 5
degree of agility across these project disciplines. We questions), Experiences (code EX, 2 questions), and Closing
aim to identify setups having either consistently low (code C, 8 questions). In total, the questionnaire consisted of
or consistently high degree of agility in their imple- up to 38 questions including the conditional questions that
mentation of the project disciplines, which serve as depend on previously given answers [44]. The questions on
input for studying the second research question. Process Use covered 24 methods and 36 practices that were
RQ 2: Which methods and practices influence the degree of derived from literature.
agility of implementing the project disciplines in soft-
ware companies? The first research question provides 3.2.3 Data Collection
an overview of the implementation of the different The data collection period was May to November 2017
project disciplines, but it provides no details about following a convenience sampling strategy [45]. The survey
the influence of specific methods and practices on was promoted through personal contacts of the 75 par-
the degree of agility. The second research question ticipating researchers and practitioners, through posters at
aims at statistically analyzing which methods and conferences, and through posts to mailing lists, social media
practices increase or decrease the degree of agility. channels (Twitter, Xing, LinkedIn), professional networks
and websites (ResearchGate and personal home pages). In
3.2 Instrument Development and Data Collection total, the survey yielded 1,467 responses (every response is
a data point used for analyses). While the raw dataset and
We used the survey method [45] to collect our data. We
a basic characterization of the population can be obtained
designed an online questionnaire to collect data from prac-
from [44], Section 4.1 provides a summary of the 556 data
titioners about the processes they use in their projects. The
points selected for this study after cleaning and reducing
unit of analysis was either a project or a software product.
the data (cf. Section 3.3.1).
3.2.1 Instrument Development
We used a multi-staged approach to develop the survey 3.3 Data Analysis Procedures
instrument [41], which is illustrated in Fig. 1. Initially, three This section describes the analysis procedures in detail. We
researchers developed the questionnaire and tested it with present the data cleaning and data reduction procedures,
15 German practitioners to evaluate its suitability. Based on introduce our overall analysis model and provide detailed
the findings and feedback presented in [46], a team of 11 information on the procedures implemented to study our
researchers from across Europe revised the questionnaire. research questions.

3.3.1 Data Cleaning and Data Reduction the “rarely” or “sometimes” used methods and practices to
Due to the analysis model adopted as shown in Fig. 2, avoid noise introduced by exceptional cases. As we wish to
we had to discard some data points and aggregate data analyze if the use of a method or practice has an influence on
to support the different analyses. Hence, we execute the the degree of agility of the project disciplines (PU05), we test
analyses with varying reported n-values. whether both data sets (consisting of all data points having
To clean the dataset, we analyzed the data for NA and reported on the degree of agility of the respective project
-9 values captured by the online survey tool. While NA val- discipline and on not or rarely using a specific method or
ues indicate that participants did not provide information practice and those data points that use this method often or
for optional questions, -9 values indicate that participants always) belong to the same population.
skipped a question. The base dataset consisted of all data We use the χ2 test to compare the distributions for
points that provided information for at least one of the each of the 24 methods and the 36 practices and their
project disciplines in PU05 (see Fig. 2), leading to a sample respective use per project discipline (11 disciplines). That
size of n=556. In the different analysis steps, we analyzed is, we performed (24 + 36) × 11 = 660 χ2 tests (one test
varied data sets (emerging from this base dataset), depend- per case where a case is a pair (method/practice, project
ing on (a) the project disciplines covered in the data points discipline)). Each test analyzes the null hypothesis Hi,j,0 ,
(analyses per project discipline for RQ1 and RQ2) and (b) where i ∈ {1, . . . , 60} represents a specific method or
the awareness that a specific method or practice is used practice and j ∈ {1, . . . , 11} represents one of the 11 project
(analyses per method or practice for RQ2). disciplines in a software-producing organization. In cases
where we have few data points, we used Fisher’s exact test,
3.3.2 Development of the Analysis Model which can be applied instead of the χ2 test for small sample
Figure 2 shows the analysis model which we developed to sizes. However, as the χ2 test—if applicable—is stronger
provide a framework for the analysis. It consists of three than Fisher’s exact test, we decided to use Fisher’s exact
questions in the questionnaire. In the rest of the paper, we test only if the χ2 test is inapplicable. Eventually, our null
use short versions of the questions from Fig. 2 (together with hypotheses have the form:
the question ID to allow the mapping).
Hi,j,0 : P (Xi,j ) = P Xī,j (3)
11 project disciplines to categorize as:
For the following standard activi- That is, we test if the distribution Xi,j belongs to the same
1. Fully Traditional Category:
ties (project disciplines) in the 2. Mainly Traditional Traditional
development, please indicate to 3. Balanced
population as the distribution Xī,j . Hence, Xi,j is the set
which degree... 4. Mainly Agile Category:
5. Fully Agile Agile
of data points having reported on the degree of agility
PU05 Select ALL
Select PER ACTIVITY
for project discipline j and using method or practice i
often or always (Fig. 2). Likewise, Xī,j is the set of data
Hypothesis Hi,j,o

Which of the following

24 methods to categorize as:
1. Do not know the framework
points having reported on the degree of agility for project
frameworks and methods do you 2. Do not know if we use it discipline j and not or rarely using method or practice i.
use? 3. We never use it
Category:
4. We rarely use it
No Frequent Use
Since we performed 660 tests analyzing the same hy-
PU09 5. We sometimes use it
6. We often use it Category: pothesis (with adjustments), we apply the Bonferroni cor-
7. We always use the framework Frequent Use
rection to adjust the p-value accordingly. Compared to other
36 practices to categorize from:
1. Do not know the practice
corrections, e.g., Holm’s step-down or Hochberg’s step-up
Which of the following practices
2. Do not know if we use it procedures, the Bonferroni correction is, according to Strass-
do you use? 3. We never use it
Category:
4. We rarely use it
5. We sometimes use it
No Frequent Use burger and Bretz [47], the most pessimistic option leading
PU10
6. We often use it Category: to the smallest (less or equal) adjusted p-value, which is in
7. We always use the practice Frequent Use −5
our study pcorr = 0.05
660 ≈ 7.57 × 10 . We clearly highlight
differences in the results if the correction is (not) applied.
Fig. 2. Analysis model. The model shows the three questions (incl.
question IDs), the value ranges and the linked hypotheses
3.3.3 Specific Analysis Procedures for RQ 1
To analyze the degree of agility (RQ1) in the different Using our analysis model (Fig. 2), we first study the state
project disciplines (PU05, following the SWEBOK categories of practice regarding the degree of agility of the project
[9]), we reduced the categories by merging and creating two disciplines (PU05) in software producing organizations. We
new sets: study, for instance, if project management is implemented
Straditional (p) = Sfully trad (p) ∪ Smainly trad (p) (1) in a more agile or in a more traditional fashion. For this,
we calculate the distribution of the degree of agility per
Sagile (p) = Sfully agile (p) ∪ Smainly agile (p) (2)
project discipline using all data points reporting the degree
S is the selection of the participants indicating whether of agility in the respective project discipline. This results in
they implement a specific project discipline p in a “more” 11 distributions of the degree of agility.
traditional or agile fashion. All analyses use the two new From our previous studies [8], [41] we know that ap-
selection sets Sagile (p) and Straditional (p). proximately 75% of the participants use hybrid methods
To answer RQ2, and in contrast to our previous studies to run their projects. In this regard, in the second step, we
[8], [41], we do not consider all methods (PU09) and prac- study how many participants state that they implement all
tices (PU10) independent from their respective frequency of project disciplines in a “purely” traditional or agile manner.
use (Fig. 2). Instead, we only use those methods and prac- To get this specific distribution, we increase the strictness of
tices that have been used “often” or “always”. We discard the data point selection, i.e., analyze those data points only

Authorized licensed use limited to: Pontificia Universidade Catolica do Rio Grande do Sul (PUC/RS). Downloaded on December 08,2021 at 12:24:03 UTC from IEEE Xplore. Restrictions apply.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TSE.2021.3099532, IEEE
Transactions on Software Engineering
5

that claim to implement all project disciplines either fully or 100

significant shift

mainly agile or, respectively, fully or mainly traditional.

80
68 Not V-Model for Risk Management
60
3.3.4 Specific Analysis Procedures for RQ 2 51 50 V-Mo del for Risk Management

40 Poly. (Not V-Model for Risk

The different project disciplines are to a large extent imple- 24
29
Ma nagement)
19 19
Poly. (V-Model for Risk Management)
mented by a combination of different methods and practices 20
9
3 2
[8], [41]. Therefore, an investigation of the impact on a 0
Fully Traditional Ma inly Balanced Ma inly Agile Fully Agile
project discipline’s implementation needs to start with the Tra ditional

question if a method or practice is used in that project

discipline. Our data does not provide such a direct mapping, Fig. 4. Integrated histogram for the project discipline Risk Management
as an assessment of these details would have unacceptably (n=462) and for the method V-shaped Process (V-Model) (n=62) within
the Risk Management discipline
increased the length of the questionnaire. Yet, we can derive
such information from the data using two assumptions:
Assumption 1: A method or practice that has no influ- Since a visual inspection is not sufficient, we use sta-
ence on the degree of agility of the project tistical tests to compare the distributions of the degree of
discipline of interest will not change the agility for a project discipline between the cases that use
distribution of cases with different degrees and that do not use a practice or method (Eq. 3). For this,
of agility compared to the project discipline we calculate the frequencies of different degrees of agility
in general. per project discipline of the data points using a specific
Assumption 2: A method or practice that has an effect on method or practice, e.g., Scrum or Pair Programming. For the
agility, but is not used in the context of a examples in Fig. 3 and Fig. 4, the χ2 test results are:
project discipline is not likely to correlate • Project discipline Architecture and Design using Feature-
with a shift in the distribution of degrees of Driven Development: p-value=0.827 > 7.57×10−5 . That
agility of that project discipline. is, the use of Feature-Driven Development does not sig-
Figure 3 illustrates Assumption 1. The figure provides two nificantly change the degree of agility of the discipline
integrated histograms, which show (a) the distribution of Architecture and Design, as there is no significant differ-
the degree of agility in the project discipline Architecture ence in the distributions.
and Design among all data points that use Feature-Driven • Project discipline Risk Management using V-shaped Pro-
Development (FDD), and (b) the distribution of the degree cess (V-Model): p-value=1.28×10−5 < 7.57×10−5. That is,
of agility in the discipline Architecture and Design among all the use of the V-Model significantly changes the degree
data points that do not use FDD to embody this discipline. of agility of the discipline Risk Management, as there is
The two trend-lines in Fig. 3 indicate that FDD appears to a significant difference in the distributions.
be relevant in this discipline, yet, FDD seems to have no These results support the impressions taken from the visual
impact on the degree of agility, as the distribution shows inspection of Fig. 3 and Fig. 4. In the case of significant
the tendency, revealing only marginal differences. results, i.e., a p-value<7.57×10−5 for the scenario in Fig. 4,
the test indicates only that a specific method or practice
100
no significant shift leads to a shift. However, we cannot characterize this shift,
92
85 i.e., whether this is a shift towards agile or traditional. We
80

61
only know that a specific method or practice is likely to
60
45
Not FDD for Arch. and Design have an impact on the degree of agility. That is, in a first
FDD for Arch. and Design
40 Poly. (Not FDD for Arch. and Design) step, we identify the influencing methods and practices without
25
Poly. (FDD for Arch. and Design)
20
10 13
21
10
quantifying the actual influence.
5
0
To analyze and quantify the influence (the shifts) in
Fully Traditional Ma inly
Tra ditional
Balanced Ma inly Agile Fully Agile
more detail, we compared the median degrees of agility
for the distribution limited to the rare use, if at all, of the
Fig. 3. Integrated histogram for the project discipline Architecture and respective method or practice with the distribution limited
Design (n=536) and for the method Feature-Driven Development (n=59) to the use of the respective method or practice. For example,
within the Architecture and Design discipline (note that, even though we for Risk Management (Fig. 4), the median degree of agility
illustrate this as a curve, the applied test works on categorical data)
is 3 for data points not working with the V-Model and 2
for those working with the V-Model, thus indicating a ten-
Figure 4 illustrates Assumption 2. The figure shows the
dency towards a more traditional development approach.
distribution of the degree of agility for the project discipline
In other words, using the V-Model makes Risk Management
Risk Management among all data points, and the distribution
in a project “more traditional”. In several cases the median
of the degree of agility in the discipline Risk Management
does not change despite a significant difference in the dis-
among all data points that use the V-shaped Process (V-
tribution. In these cases, we assume that the extent of the
Model) to embody this discipline. The integrated histogram
difference is negligible.
indicates a shift in the distribution, i.e., the V-Model is a
relevant method in Risk Management, but its use causes
a shift towards a lower degree of agility. However, the 3.4 Threats to Validity
second assumption has to be taken with care, as a spurious We discuss the threats to validity following the classification
correlation might exist due to confounding factors. presented in Wohlin et al. [48].

Construct validity: The dataset analyzed in this paper same hypothesis and using the same dataset (Section 3.3.2),
emerged from a survey. One of the main threats of survey- we applied the Bonferroni correction leading to an adjusted
based research is the risk of misunderstood questions lead- significance level of pcorr ≈ 7.57×10−5 (we highlight re-
ing to incomplete or wrong responses. To mitigate this risk, sults still significant using the adjusted p-value instead of
several researchers were involved in designing and revising the normal p-value of 0.05). To analyze the effect of the
the questionnaire, including pre-tests, internal and external significant results, we compared the median values of the
reviews as described in Section 3.2.1. In addition, native respective distributions, assuming that the effect size of
speakers from the team translated the English version of the difference is negligible for same median values. In the
the questionnaire into German, Spanish, and Portuguese other cases, the shift in the median indicates the direction of
to reduce the risk of misunderstandings due to language the effect of a specific method or practice towards agile or
issues. We distributed the questionnaire using the conve- towards traditional. Nonetheless, the identified significant
nience sampling strategy [45] as described in Section 3.2.3. results have to be confirmed in future studies.
This introduced the risk of losing control in terms of sam- External Validity: Our data analysis is based on a dataset
pling, response rate and so forth. To ensure that the partici- comprised of 1,467 data points. Nevertheless, due to the
pants still represent our target population, we implemented data collection strategy (Section 3.2.3) and its impact on the
rigorous data pre-processing including consistency checks. population, we cannot claim generalizability. In some cases,
Analyzing free-text questions in the questionnaire led to we find statistically significant differences between two sub-
reasonable results [41]. Hence, we are confident that this sets. However, as we lack sufficient data to provide a solid
threat can be considered mitigated. conclusion, we consider these observations as candidates for
Software engineering is challenged with terminological which further research is necessary to confirm the results.
confusion [49]. Study participants will as a result have
somewhat varying understandings of agile software devel-
opment, however, the practices included in this research are 4 R ESULTS
widely used (as demonstrated by the survey responses),
they support agile principles as identified in the Agile This section is structured according to the two research
Manifesto [1], and as such support an examination of hybrid questions as introduced in Section 3.1. The interpretation
software engineering. We mitigated that threat by analyzing and discussion of the results are provided in Section 5.
a large population and quantifying the perceptions using
an explicit metric (Likert scale, Section 3.3.2). However,
4.1 Demographics
even the aggregated results could be biased and, therefore,
require independent research for confirmation. Before we present the study results, in this section, we
Internal Validity: Threats to internal validity were po- briefly describe the study population. As described in Sec-
tentially introduced while preparing and cleaning the data. tion 3.2.3, the survey yielded 1,467 data points of which we
Also, the selection of the statistical tests can threaten internal selected 556 for this study (Section 3.3.1). Among the 556
validity. To mitigate these risks, all analysis steps have been participants, 555 provided information about their company
performed by at least two researchers and reviewed by size: 133 (23.92%) work in micro or small companies with
at least two other researchers not involved in the actual less than 51 employees, 137 (24.64%) work in medium-sized
analyses. The remaining researchers in the team were asked companies (≤250 employees), 156 (28.06%) work in large
to provide quality assurance. Implementing these rigorous companies with up to 2.500 employees, and 129 (23.20%)
review processes, we are confident that our research method work in very large companies with more than 2.500 em-
is reliable and can be reproduced. Another threat to internal ployees. In total, 351 out of 556 participants (63.13%) state
validity might have been introduced by the dataset itself. that they are involved in distributed development (region-
Analyzing the overall degree of agility in the dataset, we ally, nationally, and globally). Finally, 336 (60.43%) of the
find a general tendency towards agile that is potentially participants state that they work on very large software
caused by the data collection procedure. Hence, every sub- projects, i.e., projects that have a staffing level of more
set used in the data analysis can be biased towards this than one person year. Another 189 participants (33.99%) are
direction. We discuss potential effects in Section 5. involved in medium to large projects with staffing levels of
The implementation of the analysis model (Section 3.3.2) two person months to one person year.
might introduce another threat: we include data points in
multiple analyses, e.g., when analyzing the influence in
6-10 years

>10 years
1-2 years

3-5 years
<1 year

dependence of the industry target domain. If a participant

selected multiple industry target domains, this data point Role / Experience
Analyst/Requirements Engineer 1 3 3 4 18
was considered for each analysis. Consequently, the applied Architect 0 2 3 8 35
statistical tests are executed on a potentially biased dataset C-level Management 0 1 2 4 31
Developer 5 13 37 38 49
(base population) and, thus, the impact of specific methods Product Manager/Owner 1 2 5 11 31
and practices could have been underestimated. As the statis- Project/Team Manager 2 3 10 22 76
Quality Manager 0 0 1 2 26
tical tests analyze differences in the distributions of specific Scrum Master/Agile Coach 3 3 3 2 28
Tester 1 0 2 1 3
datasets, this bias may have influenced the results. However, Trainer 0 0 1 0 5
as we do not claim generalizability, we discuss potential Other 2 2 9 6 36

effects in Section 5.
Conclusion Validity: Since we perform 660 tests for the Fig. 5. Participant roles and experience (alphabetically sorted)

the environment, which underlines the critical role software

We b Applications and Services (e.g.,… 157
Financial Services (Banking, Insurance,… 144
has gained today.
Mo bile Applications 102
Cloud Applications and Services 88
4.2 RQ 1: Degree of Agility of Project Disciplines
Other Information Systems (ERP, SAP etc.) 83
Public Sector/Public Contracting 67 To answer the first research question, we evaluate the degree
Automotive Software and Systems 61 of agility per project discipline as reported by the study
Me dical Devices and Health Care 57 participants.
Other Embedded Systems and Services 43
Logistics and Transportation 42
a) Project Management (n=551) b) Quality Management (n=515)
Telecommunication 36
200 173 200
Energy (Smart Grid etc.) 29 149 142 144
150 150
Space Systems 25 117 119

Me dia and Entertainment 24 100

71
100
52 58
Defense Systems 22 41 50
50

Aviation 20
0 0
Games 17 fully
Fully ma inly balanced
Mainly Balanced ma inly fully
Mainly agile
Fully fully
Fully ma inly balanced
Mainly Balanced ma inly
Mainly fully agile
Fully
tra ditional tra
Traditional ditional
Traditional agile
Agile Agile tra ditional tra
Traditional ditional
Traditional agile
Agile Agile
Home Automation and Smart Buildings 15
c) Risk Management (n=462) d) Configuration Management (n=489)
Robotics (incl. UAVs/drones) 14
200 200
Other 60 154
150 150 134 135
0 40 80 120 160 200 112
94 99
100 100
64 59 62
50 38 50
Fig. 6. Overview of the application domains of the project/products
0 0
fully
Fully ma inly balanced
Mainly Balanced ma inly
Mainly fully agile
Fully fully
Fully ma inly balanced
Mainly Balanced ma inly
Mainly fully agile
Fully
tra ditional tra
Traditional ditional
Traditional agile
Agile Agile tra ditional tra
Traditional ditional
Traditional agile
Agile Agile

e) Change Management (n=513) f) Requirements Engineering (n=536)

…impact your company's reputation 418
200 200 182
…impact your company's business 401 159
138
…lead to financial loss 359 150
115
150
107
…lead to system (service) degradation 309 90 94
100 100
65
55
…have legal consequences (civil law) 225 44
50 50
…have legal consequences (criminal law) 101
0 0
…lead to a complete system loss 92 fully
Fully ma inly balanced
Mainly Balanced ma inly fully
Mainly agile
Fully fully
Fully ma inly balanced
Mainly Balanced ma inly fully
Mainly agile
Fully
Traditional Traditional
tra ditional tra ditional Agile
agile Agile Traditional Traditional
tra ditional tra ditional Agile
agile Agile
…threaten human heatlh or life 82
g) Architecture and Design (n=536) h) Implementation/Coding (n=552)
…impact the environment 36
200 200 198
Other 22 164
150 156
150 150 125
0 150 300 450 111
100 100
69
42 49
50 50 24
Fig. 7. Overview of the different criticality levels of the project/products
0 0
fully
Fully ma inly balanced
Mainly Balanced ma inly fully
Mainly agile
Fully fully
Fully ma inly balanced
Mainly Balanced ma inly fully
Mainly agile
Fully
tra ditional tra
Traditional ditional
Traditional agile
Agile Agile Traditional Traditional
tra ditional tra ditional Agile
agile Agile

The study participants have different roles reflecting a i) Integration and Testing (n=546) j) Transition and Operation (n=453)

200 198 200

good bandwidth of skills combined with a high level of ex-
150 150 129
perience (Fig. 5). Developers (142; 25.54%) and project/team 127
114 116 112
100
managers (113; 20.32%) are the largest participant groups, 100 77
51
45
and a majority of the participants (338; 60.79%) has more 50 30 50

than 10 years of professional experience. 0

fully
Fully ma inly balanced
Mainly Balanced ma inly
Mainly fully agile
Fully
0
fully
Fully ma inly balanced
Mainly Balanced ma inly fully
Mainly agile
Fully
The survey’s unit of analysis was a project or product in Traditional Traditional
tra ditional tra ditional Agile
agile Agile Traditional Traditional
tra ditional tra ditional Agile
agile Agile

which the participants are involved. The projects/products k) Maintenance and Evolution (n=510)
200
address different application domains, which are sum- 166
150 134
marized5 in Fig. 6. The figure shows that Web Appli- 96
100
cations and Services (157; 28.24%), Financial Services (144; 71
43
50
25.90%), and Mobile Applications (102; 18.35%) are the
0
most frequently mentioned application domains. Also, 60 fully
Fully ma inly balanced
Mainly Balanced ma inly fully
Mainly agile
Fully
tra ditional tra
Traditional ditional
Traditional agile
Agile Agile
participants (10.79%) mentioned they work in other do-
mains such as Agriculture, Geo-Information Systems or
CAD/Electronic Design. Furthermore, participants were Fig. 8. Number of data points in dependence of the degree of agility per
project discipline (n=556)
asked about the importance of software and systems de-
velopment, i.e., the criticality of software to their company.
Figure 8 provides an integrated perspective by pre-
Figure 7 shows that an impact on reputation and business
senting one histogram for each project discipline. The his-
are the most frequently mentioned risks. Yet, 82 participants
tograms show that there is no general trend evident towards
(14.75%) state that issues of the software could impact
purely agile or traditional development. Instead, a general
human health or life and another 36 (6.47%) see risks to
tendency towards a hybrid development approach can be
5. Please note that the participants could choose multiple options for noted (as already observed in [8], [39], [41]). The disci-
the application domains (Fig. 6) and the criticality levels (Fig. 7). plines Project Management, Change Management, Requirements

Engineering, Architecture and Design, Implementation/Coding, the degrees of agility (blue numbers). For example, using
Integration and Testing, and Maintenance show a tendency Waterfall or Scrum changes the distribution for all project
towards a more agile implementation. disciplines. Yet, other methods and practices seem to have
Yet, Fig. 8 does not provide information about the con- no influence, e.g., Nexus, DSDM, and RUP. Furthermore,
sistent implementation of the respective project disciplines, Fig. 10 shows that practices seem to have a greater influence
i.e., if a project is undertaken in a consistently traditional or on the degree of agility than the methods, as they are
agile way. In Fig. 9, we provide an aggregated perspective more likely to result in a significant shift. Compared to
on the consistent use of agile or traditional methods and the methods, we observe more significant differences in the
practices. We selected all data points for which we found a distributions of the degrees of agility, i.e., p < 7.57×10−5 .
consistent selection of the degree of agility, i.e., for all project Specifically, from the 24 methods, two (Scrum and Water-
disciplines, participants selected the same category, e.g., fall) have an impact on all disciplines, and from the 36
Fully Agile or Mainly Agile. The figure shows that few partic- practices, one (Formal Specification) has an impact on all
ipants implement their projects consistently traditional (7) disciplines. These numbers change to five methods and 15
or consistently agile (9). Another 14 participants claim to practices influencing all project disciplines at a significance
consistently implement their projects in a balanced manner. level of p < 0.05 (black numbers in Fig. 10). Furthermore,
Figure 9 shows that 46 participants implement their projects the disciplines are impacted differently. For instance, 20
in an agile style and, of these, nine participants do it “fully out of 60 methods and practices have an impact on the
agile”, 21 “mainly agile”, and another 16 participants imple- discipline Implementation and Coding, followed by Integration
ment their projects either fully or mainly agile, i.e., at least and Testing (18), and Architecture and Design (15).
mainly agile. In total, from the 556 analyzed data points,
83 (14.93%) claim to consistently implement the different Finding 2: Compared to the selection of methods used, the
project disciplines fully or mainly agile or traditional, or in a selection of practices used has a stronger effect on the degree
balanced fashion. With some 15% of the studied population, of agility of a given discipline.
the “pure doctrine” accounts for a small share only.

50 Finding 3a: Few methods and practices affect the degree of

agility of all project disciplines. These are marked in Fig. 10
40
16
Mixed
in green (3; p<7.57×10−5 ) and yellow (17; p<0.05).
30
Ma inly Finding 3b: The project discipline Implementation and Coding
20 6 21 Fully is most likely to be affected in its degree of agility by changes
10 Balanced
10
14
in the selected methods and practices, followed by Inte-
7 9 gration and Testing, and Architecture and Design. The project
0
Tra ditional Balanced Agile discipline least likely to be affected is Risk Management.

Fig. 9. Aggregated degree of agility for participants implementing all

project disciplines consistently (n=83)
4.3.2 Quantifying Influencing Methods and Practices
While Fig. 10 summarizes significant differences in the de-
Finding 1a: Most project disciplines show a clear trend gree of agility depending on method and practice selection,
towards an agile implementation. Exceptions are the three the figure does not show how these differences are mani-
project disciplines Quality Management, Configuration Man- fested. For this, as described in Section 3.3.4, we study the
agement and Transition and Operation, which are balanced,
median values of the degrees of agility per project discipline
as well as the discipline Risk Management that has a trend
towards traditional development. as reported by the participants. This comparison includes
the frequency of use of a specific method or practice and
Finding 1b: A small share of approx. 15% of the participants
implement all project disciplines consistently, either agile, targets participants that use or do not use a method or
traditional, or balanced. practice. As differences occur at different levels of signif-
icance, and even non-significant trends can be found, we
integrated these information pieces into a color-coded and
flagged representation. Figure 11 provides a guideline on
4.3 RQ 2: Influence on the Degree of Agility
how to read the resulting charts.
To answer the second research question, we compare the The color code shows the “starting state” of those partic-
distributions of the degrees of agility in relation to the ipants that use a specific method or practice, i.e., what the
frequency of use of a specific method or practice. For this, median degree of agility is for this group. The flag shows
we first identify those methods and practices causing a shift, the “trend” when comparing this group to the other group
before we characterize the found shifts. that does not use this method or practice. While the flags
tr and ag stand for traditional and agile (see also Fig. 4),
4.3.1 Identifying Influencing Methods and Practices the flag n requires an extra explanation. This flag indicates
Figure 10 presents the results of the χ2 tests and, if there that there is a significant difference. However, this difference
were too few data points, the results of the Fisher’s exact does not indicate a specific trend as also explained by Fig. 3.
tests (as described in Section 3.3.2). In the following section, we first discuss the significant
Figure 10 shows 146 cases where the frequent use of results found in Section 4.3.1, before we present the findings
a specific method or practice changes the distribution of regarding observed trends that are not significant.

Requirements
Project Quality Risk Configuration Change Architecture and Implementation Integration and Transition and Maintenance
Analysis/
Management Management Management Management Management Design and Coding Testing Operation and Evoution
Engineering
Methods Waterfall 0.00E+00 8.00E-13 1.42E-08 1.92E-05 5.71E-13 1.44E-13 2.87E-13 3.24E-16 1.74E-15 3.92E-08 1.85E-12
Crystal
DevOps 1.67E-08 4.71E-06 5.90E-05 5.65E-10 2.51E-07 1.44E-04 4.61E-08 8.75E-08 2.51E-08 3.57E-10 1.06E-04
Domain-Driven Design 2.23E-02 3.53E-02 3.62E-02
DSDM
Extreme Programming 5.40E-05 1.66E-05 1.19E-03 4.83E-05 2.98E-05 5.76E-03 1.08E-02 1.93E-06 8.68E-10 1.26E-08 2.74E-05
Feature-driven Development 3.45E-02
Iterative Development 4.34E-03 2.66E-02 3.37E-02 1.69E-03 3.18E-04 1.84E-05 2.62E-04 1.96E-02 8.71E-03
Kanban 2.49E-02 4.66E-02 1.19E-02 4.55E-02 9.74E-03 1.03E-02 5.17E-04 5.95E-03
Large-scale Scrumm (LeSS) 3.41E-02 9.82E-03 4.00E-02
Lean Software Development 1.36E-02 3.84E-02 6.87E-03 1.27E-02 1.30E-02 9.56E-05 1.03E-03 1.59E-04 8.48E-05 5.19E-03
Model-Driven Architecture (MDA) 3.10E-02
Nexus
Personal Software Process (PSP)
Phase / Stage-gate model 9.78E-04 9.85E-04 9.85E-03 2.53E-02 3.81E-02 9.19E-03
PRINCE2
Rational Unified Process (RUP)
Scaled Agile Framework (SAFe) 9.91E-03
Scrum 3.10E-10 4.90E-05 5.23E-05 4.73E-08 3.73E-08 2.85E-08 4.80E-07 2.97E-14 8.03E-12 3.52E-07 6.36E-07
ScrumBan 5.13E-03 4.01E-02 4.51E-02 1.08E-03 9.20E-04 3.10E-02 4.32E-02 1.43E-03
Spiral Model 1.76E-02 1.11E-02
SSADM 4.69E-02 2.69E-02 2.01E-03 4.10E-03 2.48E-03 2.71E-03 2.68E-02
Team Software Process (TSP) 1.77E-02 1.43E-02
V-Shaped Process (V-Model) 5.50E-05 6.03E-09 1.28E-05 1.44E-04 3.58E-04 1.66E-05 1.01E-05 1.22E-04 4.54E-03 4.00E-04 1.36E-05
Practices Architecture Specifications 1.09E-02 3.24E-02 3.28E-02 2.22E-02 7.75E-03 2.30E-02 6.83E-04 1.03E-02 3.61E-02
Automated Code Generation
Automated Theorem Proving 1.75E-02
Automated Unit Testing 4.09E-04 2.87E-03 3.12E-03 2.74E-02 2.83E-06 2.18E-06 7.31E-03 1.10E-02
Backlog Management 7.13E-10 3.28E-06 7.84E-05 2.00E-04 1.87E-07 4.52E-07 5.43E-09 8.26E-12 8.91E-09 1.00E-05 1.41E-07
Burn-Down Charts 1.59E-03
Code Reviews 1.47E-03 2.15E-02 7.17E-03 8.74E-03 6.06E-04 4.31E-04 8.13E-03
Coding Standards 2.69E-02 8.36E-03 4.16E-02
Collective Code Ownership 8.35E-05 2.24E-04 2.07E-03 1.26E-06 9.39E-08 5.29E-04 5.44E-06 6.58E-07 1.15E-04 2.41E-03 5.65E-05
Continuous Deployment 2.75E-04 5.35E-05 1.32E-04 6.23E-06 1.10E-05 6.31E-05 1.71E-03 9.09E-05 5.34E-09 2.24E-09 1.66E-04
Continuous Integration 5.36E-06 6.97E-06 1.77E-04 2.47E-05 8.70E-06 1.52E-07 1.63E-06 1.05E-07 6.26E-11 2.20E-05 6.86E-06
Daily Standup 8.02E-07 7.42E-04 2.72E-02 2.13E-03 9.96E-06 1.86E-06 3.48E-05 6.49E-11 2.41E-09 4.68E-05 3.37E-04
Def. of Ready/Done 1.17E-05 2.01E-04 2.17E-04 7.57E-06 1.27E-06 1.22E-05 1.28E-04 3.67E-09 2.00E-07 4.38E-07 2.50E-06
Design Reviews 3.59E-03 3.14E-02
Destructive Testing 1.16E-02
Detailed Designs 6.22E-03 3.80E-04 2.06E-03 5.71E-03 4.30E-03 3.78E-04 1.67E-07 1.23E-07 2.07E-05 4.26E-02 1.17E-03
Limit Work-in-Progress 1.59E-02 1.17E-02 1.66E-02 5.11E-03 1.08E-02 3.38E-03 1.45E-03 6.92E-04
End-to-End (System) Testing
Expert/Team based estimation 1.77E-02 2.12E-03 6.53E-03 3.96E-05 2.80E-03 2.02E-03 5.41E-04 1.66E-05 2.81E-03 1.18E-03 3.34E-02
Formal estimation 1.49E-02 2.44E-02 3.88E-03 4.49E-05 2.70E-04 8.89E-03 1.44E-02
Formal Specification 8.68E-07 9.36E-07 4.34E-05 2.57E-06 7.12E-08 8.41E-09 1.40E-09 4.42E-07 7.47E-07 6.91E-05 1.69E-08
Iteration Planning 1.27E-02 4.53E-02 3.30E-02 6.19E-05 1.08E-02 3.78E-02
Iteration / Sprint Reviews 4.31E-09 2.06E-04 1.85E-04 4.82E-04 4.49E-05 4.95E-08 8.32E-07 1.13E-10 3.16E-07 8.82E-06 3.80E-06
Model Checking 2.86E-02 4.39E-02
On-Site Customer 3.59E-02 1.15E-02 2.63E-02
Pair Programming 1.42E-02 2.95E-03 1.51E-02 2.11E-02 5.65E-04 1.01E-02 4.01E-03
Prototyping 1.19E-02 8.35E-03
Refactoring 9.36E-05 2.12E-05 5.91E-03 1.97E-06 8.01E-06 7.56E-06 1.30E-07 1.55E-09 1.87E-12 5.19E-05 1.80E-04
Release planning
Retrospectives 3.54E-06 2.36E-04 3.05E-02 2.08E-04 2.11E-06 1.19E-06 2.92E-05 3.92E-12 1.37E-09 4.89E-04 4.59E-05
Scrum of Scrums 1.33E-02 4.79E-02 5.60E-03 1.27E-02
Security Testing
Test-driven Development 1.06E-02 4.56E-03 5.93E-03 5.94E-04 1.64E-02 3.77E-02 4.66E-04 2.03E-02 5.11E-06 7.49E-07 2.62E-03
User Stories 5.17E-04 4.39E-04 1.04E-03 3.21E-03 1.03E-03 4.15E-07 2.07E-04 2.71E-05 2.43E-05 2.35E-02 1.89E-03
Velocity-based Planning 1.16E-04 6.35E-06 1.26E-05 1.63E-05 8.37E-04 1.05E-06 4.03E-06 7.84E-10 3.14E-06 2.99E-04 1.56E-03
Use Case Modeling 1.91E-02 1.71E-02 4.09E-03

Fig. 10. Summary of the significant results with p < 0.05 (black) and p < pcorr = 7.57×10−5 (blue) of the χ2 tests. A green background indicates
methods and practices on all project disciplines at a significance level of p < pcorr = 7.57×10−5 and, likewise, the yellow background indicates a
significance level of p<0.05. Gray-colored cells indicate the use of Fisher’s exact test as described in Section 3.3.2

practices for which no significant trend could be found at

Discipline

all (gray-italic items). In total, of the 660 cases, 146 (22.12%)

show a significant difference, i.e., a potential shift in the
Method/Practice tr ag n ag ag … … …
degree of agility. Figure 12 shows that most of the trends
Starting State
- fully agile
Participants using this method/practice identified cause an agile shift (88 out of 146, 60.27%). That
implement this discipline typically balanced
- mainly agile (white) and the difference to participants that is, applying a specific method or practice increases the
don’t use this method/practice cannot be
- Balanced (neutral)
associated to a trend (n) degree of agility. This effect can be especially observed for
- mainly traditional
Participants using this method or practice implement cases that already have an agile starting state. Likewise,
- fully traditional this discipline typically mainly agile (light blue) and
Trend they are more agile than participants not using this if a shift towards traditional occurs, the starting state is
method or practice (ag)
tr - trend towards traditional either balanced or traditional. Yet, a few methods only show
ag - trend towards agile Participants using this method or practice implement this
discipline typically fully traditional (yellow) and they are a shift towards traditional, such as Waterfall and Formal
n - trend towards neutral more traditional than participants not using this method or
- nothing to report… practice (tr)
Specifications.

Finding 4: Most practices are associated with an increase in

Fig. 11. Reading guideline for the trend analysis in Figures 12 – 14 the degree of agility.

Figure 12 also shows that there is no “radical” shift. That

4.3.2.1 Corrected Significance: Figure 12 summa- is, there is no case that, for instance, is usually traditional and
rizes the trends and the shifts for the significant differences shifts to agile when using a specific method or practice. This
(using pcorr ). The figure also shows those methods and is in line with Noll and Beecham [42], who found method

Implementation and Coding

Configuration Management

Configuration Management
Maintenance and Evoution

Maintenance and Evoution

Transition and Operation

Architecture and Design

Requirements Analysis/

Requirements Analysis/
Integration and Testing

Integration and Testing

Change Management

Change Management
Project Management

Quality Management

Project Management

Quality Management
Risk Management

Risk Management
Engineering

Engineering
Waterfall tr tr tr tr tr tr tr tr tr tr tr Waterfall
Crystal Crystal
DevOps ag ag ag ag ag ag n n ag DevOps ag ag
Domain-Driven Design Domain-Driven Design ag n ag
DSDM DSDM
Extreme Programming ag ag ag ag ag ag ag ag Extreme Programming ag ag ag
Feature-driven Development Feature-driven Development ag
Iterative Development n Iterative Development ag n n n ag ag n ag
Kanban Kanban ag n n ag n n n ag
Large-scale Scrumm (LeSS) Large-scale Scrumm (LeSS) ag n n
Lean Software Development Lean Software Development ag n ag ag ag ag n n ag ag
Model-Driven Architecture (MDA) Model-Driven Architecture (MDA) n
Nexus Nexus
Personal Software Process (PSP) Personal Software Process (PSP)
Phase / Stage-gate model Phase / Stage-gate model n tr tr tr tr n
PRINCE2 PRINCE2
Rational Unified Process (RUP) Rational Unified Process (RUP)
Scaled Agile Framework (SAFe) Scaled Agile Framework (SAFe) ag
Scrum ag n ag ag ag ag n ag ag ag ag Scrum
ScrumBan ScrumBan ag ag ag ag ag ag n n
Spiral Model Spiral Model n tr
SSADM SSADM tr tr tr tr tr tr tr
Team Software Process (TSP) Team Software Process (TSP) n tr
V-Shaped Process (V-Model) tr tr tr tr tr tr V-Shaped Process (V-Model) tr tr tr tr tr
Architecture Specifications Architecture Specifications tr n tr n tr tr tr n tr
Automated Code Generation Automated Code Generation
Automated Theorem Proving Automated Theorem Proving tr
Automated Unit Testing n ag Automated Unit Testing ag n n n n ag
Backlog Management ag ag ag ag ag ag ag n ag Backlog Management ag n
Burn-Down Charts Burn-Down Charts n
Code Reviews Code Reviews ag n ag n n ag ag
Coding Standards Coding Standards n ag ag
Collective Code Ownership ag ag ag n ag Collective Code Ownership ag n n ag n n
Continuous Deployment ag ag ag ag ag ag Continuous Deployment ag ag ag n ag
Continuous Integration ag n ag ag ag ag n ag n ag Continuous Integration ag
Daily Standup ag ag ag ag ag ag n Daily Standup n ag n ag
Def. of Ready/Done ag ag ag ag n ag n ag Def. of Ready/Done n n ag
Design Reviews Design Reviews tr n
Destructive Testing Destructive Testing tr
Detailed Designs tr tr tr Detailed Designs tr n tr tr tr tr n tr
Limit Work-in-Progress Limit Work-in-Progress ag n ag ag n n n ag
End-to-End (System) Testing End-to-End (System) Testing
Expert/Team based estimation n n Expert/Team based estimation ag n ag ag ag n n n ag
Formal estimation n Formal estimation n tr n n tr n
Formal Specification n tr tr tr tr tr tr tr tr n tr Formal Specification
Iteration Planning n Iteration Planning ag ag n ag n
Iteration / Sprint Reviews ag ag ag n n ag n ag Iteration / Sprint Reviews n ag n
Model Checking Model Checking tr n
On-Site Customer On-Site Customer ag ag n
Pair Programming Pair Programming ag ag ag ag ag n ag
Prototyping Prototyping n n
Refactoring ag ag ag ag ag n ag n Refactoring ag ag ag
Release planning Release planning
Retrospectives ag ag ag ag n ag ag Retrospectives n ag n n
Scrum of Scrums Scrum of Scrums n n n n
Security Testing Security Testing
Test-driven Development n ag Test-driven Development ag ag n ag ag ag ag n ag
User Stories ag n ag User Stories ag n ag n ag ag n ag
Velocity-based Planning ag ag ag ag ag ag n Velocity-based Planning ag ag n ag
Use Case Modeling Use Case Modeling n n n
- fully traditional - balanced - fully agile - fully traditional - balanced - fully agile
- mainly tradtional - mainly agile - mainly tradtional - mainly agile

Fig. 12. Significant shifts (p<7.57×10−5 ) in the degree of agility Fig. 13. Significant shifts (p<0.05) in the degree of agility.

combinations tend to “stay in their class”, e.g., findings be found (all entries in Figure 12 with entry “n”). These
are confirmatory, that projects that mainly use agile methods 29 cases represent methods and practices that show no
are more likely to use agile practices. Yet, no single practice tendency in the context of a specific project discipline only,
determines whether a project is agile or not. e.g., Scrum (Quality Management and Architecture and Design).
This means that using these methods or practices makes no
Finding 5a: Methods and practices have a stable influence difference, this method or practice is not impacting agility
towards either a high or low degree of agility, which does in general or in specific contexts.
not change with the project discipline.
Finding 5b: No method or practice determines whether a Finding 6: Some methods and practices are “neutral”. That
project is traditional or agile, i.e., any method or practice is, they are not associated with a changing perception of the
can be found in traditional and agile development. degree of agility. These are marked gray in Fig. 12.

Figure 12 also shows that 36 methods and practices, 4.3.2.2 Non-Corrected Significance: Figure 13 sum-
seemingly, have no significant impact at all (using pcorr ). marizes the trends and shifts for the differences at a signifi-
Furthermore, for 29 cases, a significant difference could be cance level of p<0.05 that do not satisfy the adjusted p-value
found, but no tendency towards agile or traditional could pcorr . In total, of the 660 studied cases, 209 (31.67%) show a

context of the project discipline Implementation and Coding,

Implementation and Coding

Configuration Management

Maintenance and Evoution

Transition and Operation
Architecture and Design
Requirements Analysis/

Integration and Testing

Change Management
Project Management

Quality Management

Risk Management
but with no explicit tendency.

Engineering
Finding 8: Combining all results at a significance level of
p < 0.05, we find 10 methods and practices that have no
impact at all. This strengthens Findings 5a and 5b.
Waterfall
Crystal ag ag ag ag ag
DevOps 4.3.2.3 Non-Significant Trends: Besides the tenden-
Domain-Driven Design ag ag ag
DSDM ag ag ag ag ag cies presented above, further tendencies which are not sig-
Extreme Programming
Feature-driven Development ag ag ag
nificant can be identified. These tendencies are shown in
Iterative Development ag Fig. 14, which also uses the notation described in Fig. 11.
Kanban ag ag
Large-scale Scrumm (LeSS) ag ag ag ag These non-significant results point to candidate methods or
Lean Software Development ag
Model-Driven Architecture (MDA) tr tr practices that cannot be decided based on the available data.
Nexus ag ag ag
Personal Software Process (PSP) tr tr tr
However, these candidate methods and practices point to
Phase / Stage-gate model tr tr tr further subjects worth investigating. For instance, for the
PRINCE2 tr tr tr
Rational Unified Process (RUP) tr tr practice Model Checking, we see a trend towards traditional
Scaled Agile Framework (SAFe) ag ag ag ag ag
Scrum with a mainly agile starting state—a trend that we have not
ScrumBan ag ag ag observed in the significant results. Also, compared to the
Spiral Model tr tr tr tr
SSADM tr significant results, Fig. 14 makes “clear statements”, i.e.,
Team Software Process (TSP) tr tr tr tr
V-Shaped Process (V-Model) we do not find one n-label, which means that the potential
Architecture Specifications
Automated Code Generation tr tr trends have a clear direction towards agile or traditional.
Automated Theorem Proving ag ag ag tr tr Figure 14 also fills some gaps mentioned above. For
Automated Unit Testing ag ag ag
Backlog Management instance, while Fig. 12 lacks information about agile scaling
Burn-Down Charts ag
Code Reviews ag ag frameworks, e.g., LeSS, Nexus, and SAFe, Fig. 14 provides
Coding Standards ag
Collective Code Ownership
this information. Linking this information to Fig. 10 that
Continuous Deployment
Continuous Integration
shows that Fisher’s exact test was used for these methods
Daily Standup due to low numbers of selections of these methods, we can
Def. of Ready/Done
Design Reviews tr conclude that these methods are either barely used or have
Destructive Testing tr
Detailed Designs
not yet been implemented extensively in practice. Analyzing
Limit Work-in-Progress ag this observation requires further research.
End-to-End (System) Testing ag
Expert/Team based estimation
Formal estimation tr tr
Formal Specification
Finding 9: There are methods and practices for which we
Iteration Planning ag ag find an initial, yet not significant, indication for having an
Iteration / Sprint Reviews
Model Checking tr tr tr tr
impact on the degree of agility. These candidate methods
On-Site Customer ag ag and practices warrant further research.
Pair Programming ag
Prototyping
Refactoring
Release planning ag
Retrospectives
Scrum of Scrums ag ag ag ag 5 S UMMARY, D ISCUSSION , AND R OADMAP
Security Testing tr
Test-driven Development We summarize our key findings, which are used to steer
User Stories
Velocity-based Planning a discussion that aims at identifying key issues in current
Use Case Modeling tr tr
research to develop a roadmap for future research.
- fully traditional - balanced - fully agile
- mainly tradtional - mainly agile

5.1 Answering the Research Questions

Fig. 14. Shifts in the degree of agility (without significant shifts)
The first research question defined in Section 3.1 was: What
is the degree of agility in implementing typical project disciplines
difference. Figure 13 shows that most of the trends identified in software companies? A purely agile or traditional imple-
cause an agile shift (89 out of 209, 42.58%) and that 84 out mentation of all project disciplines is seldom evident (Sec-
of 209 (40.19%) do not show a notable trend. It can also be tion 4.2, Finding 1b). This finding shows an even lower share
observed that there is still no “radical” shift. That is, even at than a previous study in the area of global software devel-
this more coarse-grained level of abstraction (compared to opment that found that the number of predominantly agile
Fig. 12), there is no case that started in traditional and shifts projects is around 25% [50]. Finding 1a together with Fig. 8
to agile. also shows that there is a clear trend towards operating
projects in an agile manner. However, the more traditional
Finding 7: Using the weaker significance level of p < 0.05, implementation of Risk Management indicates that agility is
we find many more tendencies compared to Finding 4, but not implemented all the time. We argue that this points to
we still find no radical shift. a potential limitation of agile software development when
dependable system development is the primary subject of a
Figure 13 shows only one special case: Design Reviews. project. In addition, this may indicate a lack of explicit risk
In the project discipline Risk Management, this practice is management techniques in agile methods.
considered fully traditional and shows a trend towards tradi- The second research question was: Which methods and
tional. Yet, the same practice is considered mainly agile in the practices influence the degree of agility of implementing the project

disciplines in software companies? Figure 10 shows that two to create theories [42], yet, future research must put more
methods and one practice are associated with a significant emphasis on theorizing software engineering.
change of the degree of agility (using pcorr , and five methods Agile Teams in Traditional Settings: There are specific work
and 15 practices with the unadjusted p-value), while the scenarios where agile teams have to work within more tradi-
practices show a stronger association with changing degrees tional structures that are influenced by traditional methods
of agility (Finding 2). Also, a subgroup of methods and and practices [54]. It is important to understand the chal-
practices affect the degree of agility of all project disciplines, lenges that exist within such contexts [51], [52]. More work
while the Implementation and Coding discipline is the most is necessary to understand how agile teams can work within
affected one (Finding 3). Most practices are associated with traditional settings and in the various industry domains.
an increase in the degree of agility (Finding 4 and 7), and Agile Teams in Globally Distributed Settings: Recent re-
once a method or practice has such an impact (high or low), search [42] suggests that hybrid organizations have in av-
this impact holds for all project disciplines (Finding 5 and erage a lower degree of agility. Most distributed software
8). For instance, Test-driven Development is associated with a projects are neither purely agile or purely traditional in
trend towards agile within all project disciplines (Fig. 12). their approach to software development, but rather combine
Nevertheless, methods and practices are not exclusive, i.e., agile and traditional methods. Also, projects adopting agile
any method or practice can be found in traditional and agile scaling frameworks such as SAFe [55] or LeSS [56], nearly
software development alike. Finally, there are also methods always employ traditional methods. Future research thus
and practices that are considered neutral with regards to the needs to provide more studies that investigate whether
degree of agility (Finding 6, Fig. 12 and Fig. 14). Further- the mindset determines the adoption of a (purely) agile
more, for several methods and practices, the data does not approach. This would help the community to learn whether
allow for drawing final conclusions. Finding 9 and Fig. 14 agile is really a mindset, and shifting away from the Water-
summarize these methods, which indicate some trend and fall, or becoming mainly agile in any transition, is unlikely
call for further research on their influence. to occur unless there is a change in outlook and attitude
[50]. This investigation of agile scaling frameworks and their
comparison with traditional methods and “core” agile meth-
5.2 Discussion and Roadmap
ods is necessary to determine if these scaling frameworks
We discuss our findings in light of current research on are really predominantly agile.
software processes and derive a roadmap of future research
activities. We present a non-exhaustive list of topics, which 5.2.2 Development Methods in new Contexts
emerged from discussing our findings in the context of the Based on the general challenges discussed above, this the-
different research profiles of the author team. To provide matic cluster is concerned with the engineering activities as
some structure, the resulting topics are grouped by thematic such—notably with their evolution in the context of recent
clusters, which are provided as consecutive subsections. technological advances.
New Technologies: Recent research shows that develop-
5.2.1 General Challenges in Software Engineering ment methods have to change with emerging technologies
The first thematic cluster is concerned with general chal- such as machine learning (ML; [57], [58]). These changes will
lenges of software and systems engineering with a partic- impact several—if not all—project disciplines. In this regard,
ular focus on the organization of software projects. It must Finding 3 is of particular interest as it shows how the differ-
be noted that the topics in this section are well-known and ent project disciplines are affected by development methods
subject to research for many years. However, especially in and practices, i.e., whether to develop ML applications in
the context of the new application domains discussed in an agile or traditional manner. Given [59]–[61], Finding 6
Section 5.2.2, these challenges are still relevant. becomes relevant as specific domain-relevant items can be
Software Engineering Theory: Aligning software engineer- added to a process without impacting the perception of
ing practices with evolving contexts is a detail-oriented and agility. ML-research mainly focuses on the stages to build
highly complex undertaking. Contexts are subject to regular the ML model as part of software development, but meth-
change [51] and process adaptation in response to this is ods and practices used in ML-based software development
perhaps even more complex than some software engineers are rarely discussed. More research is required to collect,
appreciate [52]. One of the conclusions from this research structure, and understand how software and system devel-
is that different practitioners have different views on what opment methods need to change in the context of new tech-
agility is in practice, and there is quite a significant spectrum niques such as ML. Furthermore, in application domains
of interpretation (findings 1, 2, 3, and 4). This leads to such as safety-critical systems or the Internet of Things [62]–
what might be considered an inconvenient truth for the [65], companies already face pressure to become more agile.
broader community: there is insufficient theory in software More research is necessary to understand the particularities
engineering, this being acknowledged in earlier published of these domains and to design suitable methods and proper
material [53]. This insufficiency of theory contributes to developer support for these contexts.
a lack of clarity around key concepts such as agility, as Agile Model-driven Engineering: Still, there is the open
highlighted in this research. Clarity is not always readily question of whether Model-driven Engineering (MDE) can
available in philosophy, and the agile manifesto [1] is cer- be agile. These two concepts are traditionally considered
tainly a philosophical artifact. But software engineering is not incompatible, which has been questioned in previous work
a philosophy, it is a concrete part of our day-to-day lives, [66], [67]. The same discussion can be found when it comes
we depend on it. The HELENA data research has started to architecture-centric methods. Some researchers argued

that architectural design does not align well with agile prac- of agility is impacted by common deviations from practice,
tices [68], [69], while others start to combine architecture- and to develop strategies for mitigating these deviations and
centric with agile approaches [70]. The findings 2, 4, and potential negative effects. Furthermore, new process model-
7 imply that the question of a process’ degree of agility ing tools need to be developed that provide sophisticated
is relatively independent of the method chosen. This is in design-support mechanisms, notably for the management
line with first results on MDE-processes, indicating that of variants and for analyzing the effects of deviations.
agile MDE processes are feasible. These results open the
potential for future research to investigate how practices can 5.2.4 Human Factors in Software Engineering Practice
be deliberately chosen to create agile MDE-processes. Processes (Section 5.2.3) are instantiated in projects and,
thus, project teams have to be enabled to undertake projects
5.2.3 Challenges in Process Design and Evolution as efficiently and effectively as possible. This thematic clus-
While the first two thematic clusters motivate a change in ter is therefore concerned with the human dimension.
the engineering of modern software-intensive systems in General Human Factors: Projects and their progress are
general, this cluster is concerned with the process as such. strongly affected by human and social factors [78]. Forecasts
Future SPI and Agile Transitions: In recent research, we can support teams with information required to improve
found that Software Process Improvement (SPI) changed their performance in future iterations [79]. Especially, find-
due to the increasing presence of agile methods. In [71], ings 2 and 3 highlight the influence of the used methods and
we found that (i) SPI is still conducted, but under different practices on human perception. The chosen development
names, and (ii) the way SPI is conducted in the context of methods and practices likely affect social aspects in the team
agile software development has changed towards the con- such as communication behavior, which potentially influ-
tinuous learning paradigm, and also includes the various ences the likelihood of social conflicts [80]. It is necessary
tools used in project environments [72]. In addition, many to further study this relationship to improve the quality of
questions regarding the agile transition are left open, e.g., forecasting instruments.
with respect to understanding an agile flavor of project dis- Specialists in Software Teams: Research on software teams
ciplines such as requirements [73]. In this regard, findings 4, composed of interdisciplinary specialists becomes more cru-
6, and 7 are relevant in setting up and steering SPI activities. cial as development goes agile. How this affects the process,
They concern the perception of project teams regarding an what new tasks are emerging, and the role of team maturity
increased agility (Finding 4 and 7) or introduce the risk of are subject to research [58], [81]. Team members who are not
dissatisfaction due to an unchanged degree of agility (Find- software developers cannot be expected to find their place in
ing 6). Methods and practices as identified in the findings the process without process change. Noll et al. [82] observed
5 and 8 provide the “low-hanging fruit”. More research is an emerging theme in literature: the original balance of
required to collect, structure, and understand factors that scrum master, product owner and team roles are being
positively or negatively affect projects and organizations, adapted, conflated, and possibly corrupted, to suit the needs
and to link these factors to methods and practices. It is of organizations transitioning from waterfall to Scrum, or
imperative to understand under which conditions a high scaling Scrum to large scale organizations. Therefore, it be-
degree of agility is desirable and when a high degree of comes crucial to distinguish between methods and practices
agility is counter-productive or even dangerous. that are neutral with regards to agility, and methods and
Process Evolution: We investigated how technology and practices that are not (findings 5, 6, and 8). Future research
processes co-evolve over time [74], [75]. A main finding is on integrating such team members will benefit from the
that technological changes are likely to change processes as insights in this paper by classifying observed or necessary
well. Also, processes are changing continuously for various process changes according to their impact on agility. This
reasons. Especially in the context of regulated software further leads to research on enabling teams to maintain their
development, awareness about evolving processes is critical, agility while integrating specialists into their workflow.
since it needs to be ensured that updated process variants Teaching Processes and Project Disciplines: The knowledge
remain compliant with standards [76]. Findings 5, 6, and 8, level of students and their readiness for the software indus-
are of special importance as they enable practitioners and try are subject to regular discussions among practitioners,
researchers for the first time to investigate the implications educators, and researchers. There exist studies, e.g., [83],
that process changes have on the degree of agility. Future [84] to measure and improve the knowledge gap between
research must focus on developing new prediction methods software engineering education and industrial needs. Find-
that allow practitioners to assess early on how the evolution ing 3 provides us with the new insight that the different
of technologies and processes will affect agility. software engineering disciplines/tasks are not isolated from
Process Deviations and Process Variants: Process deviations the question of whether development happens in an agile
and process variants seem to be common [76], [77]. We or traditional way. We need to investigate how teaching the
found them on the method- and practice-level. Furthermore, software engineering disciplines, e.g., quality management
we know that deviations and variants can negatively impact or maintenance and evolution, should incorporate and ad-
goal achievement and teamwork [41]. Finding 2 confirms dress the question of how tasks change when different agile
that agility is affected more strongly by practices than by and traditional processes are applied.
methods. If a company does not reach the desired degree
of agility, process deviations and variants at the level of 6 C ONCLUSIONS
practices should be considered as a potential cause. Future Throughout the progress of this extensive industrial study,
research requires more studies to identify how the degree much consideration and reflection have been focused on the

broader state of software engineering in general and this has distributed) software teams. In a world that vitally relies on
suggested that there are some axioms that we would do well software and increasingly on remote working to produce
to acknowledge and work on. The fact that no one software software, as we have seen with the Covid19 pandemic, we
development process or set of practices is universally and need a clear understanding of how to organize the success-
perfectly suited to all software development settings [51] ful and sustainable development of high-quality software.
should be more than just an inconvenience to those evan- This research has discovered important new information
gelists of certain processes and practices. Rather, this reality about what practitioners consider agility to mean (expressed
seems to reflect a basic principle: software engineering is through association with various practices/methods). This
highly applied across a very large range of situational has raised our sophistication of understanding of the agile
contexts [85], [86]. Just as civil engineering uses different concept, but, in-so-doing, has also crystallized aspects of our
materials, processes and techniques for bridges, houses and thinking regarding some more general realities in software
roads, so too should we expect software engineers to use engineering. The observations above could—and we sug-
different tools, practices and hardware for nuclear power gest should—be transformed into research questions to be
plants, computer games and customer relationship man- worked on by the broader research community.
agement. Advocating continuous software engineering [87]
for nuclear reactor control software makes no more sense ACKNOWLEDGMENTS
than evangelizing the practices for bridge builders as being HELENA is a huge endeavor in which many people par-
perfectly suited to house builders. Therefore, we find that it ticipated and helped improve the understanding of modern
is not necessarily a question of whether a context requires software and system development. We would like to thank
agility or not, it is a question of what type of agility is all persons who directly or indirectly supported HELENA.
suitable in different contexts: which practices? Which parts Notably, the authors would like to thank Philipp Diebold,
of which practices? Which practices in combination? Eckhart Hanser, Simon Oberthür, Sabrina Marczak, Guilherme
Horta Travassos, Vahid Garousi, Kai Petersen, Nauman Ali,
We studied the question: What makes agile software de- Abdur Razzak, Casper Lassenius, Nicole Novielli, Giuseppe
velopment agile? To answer that question, based on 556 Iaffaldano, Dan Houston, Ian De Silva, Martin Kropp, Ben-
data points obtained in a large-scale international online jamin Kanagwa, Mushtaq Raza, João Pascoal Faria, Julian Bass,
survey, we studied the participants’ perception of agility Filippo Lanubile, Andreas Meier, and John Noll. Our special
and whether this perception changes depending on the thanks goes to Rory V. O’Connor, who sadly left us and will be
used methods and practices. Our findings show that (i) a missed as a great colleague and friend.
clear trend towards agile software development can be ob- D. Pfahl and E. Scott are partly funded by the Estonian
served, (ii) purely agile or traditional software development Centre of Excellence in ICT Research (EXCITE). S. Beecham,
happens in rarely, (iii) most practices are associated with I. Richardson, Ö. Özcan-Top, P. Clarke, and F. McCaffery were
“being agile” and practices have a stronger impact on the partially supported with the financial support of the Science
perception of agility compared to methods, and (iv) there Foundation Ireland grant 13/RC/2094 2 and co-funded un-
are methods and practices that are considered neutral. der the European Regional Development Fund through the
However, our findings also clearly show that “agility” Southern & Eastern Regional Operational Programme to Lero
is in the eye of the beholder and, therefore, is a subjective - the Science Foundation Ireland Research Centre for Software
concept. For instance, if people know that the base process (www.lero.ie). M. Genero, A. Vizcaino and M. Piattini research
is the V-Model or the Waterfall, everything is considered is partly funded by ECLIPSE Project (Ministerio de Ciencia,
“traditional”, while everything that is connected to Scrum or Innovación y Universidades—FEDER, RTI2018-094283-B-C31,
XP is considered “agile”, regardless of whether the process Spain). E. Knauss has partially been funded through the Soft-
of interest is the (objectively) best choice for the respective ware Center research network (https://www.software-center.
context [88]. Taking into account that the methods and se) and the Vinnova FFI NGEA project (https://www.vinnova.
practices are not used stand-alone, but to a large extent se). R. Prikladnicki is partially funded by CNPq and Fapergs.
in combination with other methods and practices [8], we D. Winkler and S. Biffl are supported by the Christian Doppler
argue that there is no agile software development process. Agile Research Association, the Austrian Federal Ministry for Dig-
software development has to be considered a cultural topic ital and Economic Affairs and the National Foundation for
of project teams and software-producing organizations and Research, Technology and Development.
how these choreograph collaboration, rather than a process
modeling topic. This conclusion is supported by our finding R EFERENCES
that practices, i.e., the actual description of how the work is [1] K. Beck, M. Beedle, A. Van Bennekum, A. Cockburn, W. Cunning-
done, have a bigger impact than methods on the perception ham, M. Fowler, J. Grenning, J. Highsmith, A. Hunt, R. Jeffries
et al., “Manifesto for agile software development,” 2001.
as to whether a process is agile.
[2] T. Dingsøyr, S. Nerur, V. Balijepally, and N. B. Moe, “A decade of
We have presented our findings and outlined routes for agile methodologies: Towards explaining agile software develop-
future research. We consider it imperative to objectively ment,” Journal of Systems and Software, vol. 85, no. 6, pp. 1213–1221,
discuss development in the context of emerging trends and 2012.
[3] P. Hohl, J. Klünder, A. van Bennekum, R. Lockard, J. Gifford,
technologies, which have nothing to do with being agile or J. Münch, M. Stupperich, and K. Schneider, “Back to the future:
not being agile in the first place. We argue that more emphasis origins and directions of the “agile manifesto”–views of the orig-
must be put on process modeling and evolution to provide inators,” Journal of Software Engineering Research and Development,
a meaningful methodological “backend” for the challenges vol. 6, no. 1, p. 15, 2018.
[4] P. Lous, M. Kuhrmann, and P. Tell, “Is scrum fit for global software
in software and system development. Finally, we call for engineering?” in 2017 IEEE 12th International Conference on Global
action in intensifying interdisciplinary research on (globally Software Engineering (ICGSE), May 2017, pp. 1–10.

[5] B. Fitzgerald, K.-J. Stol, R. O’Sullivan, and D. O’Brien, “Scal- ing agile maturity models and practitioners’ experience,” Journal
ing agile methods to regulated environments: An industry case of Systems and Software, vol. 156, pp. 1–20, 2019.
study,” in International Conference on Software Engineering, ser. ICSE. [30] A. Begel and N. Nagappan, “Usage and perceptions of agile soft-
Piscataway, NJ, USA: IEEE Press, 2013, pp. 863–872. ware development in an industrial context: An and exploratory
[6] M. McHugh, F. McCaffery, and V. Casey, “Barriers to adopting study,” in International Symposium on Empirical Software Engineering
agile practices when developing medical device software,” in and Measurement, ser. ESEM. IEEE/ACM, 2007, pp. 255–264.
Software Process Improvement and Capability Determination, A. Mas, [31] G. van Waardenburg and H. van Vliet, “When agile meets the
A. Mesquida, T. Rout, R. V. O’Connor, and A. Dorling, Eds. Berlin, enterprise,” Information and Software Technology, vol. 55, no. 12, pp.
Heidelberg: Springer Berlin Heidelberg, 2012, pp. 141–147. 2154–2171, Dec 2013.
[7] P. Clarke, R. V. O’Connor, and M. Yilmaz, “In search of the [32] D. West, M. Gilpin, T. Grant, and A. Anderson, “Water-Scrum-
origins and enduring impact of agile software development,” in Fall is the reality of agile for most organizations today,” Forrester
Proceedings of the International Conference on Software and System Research Inc., Tech. Rep., July 2011.
Process, ser. ICSSP. ACM, 2018, pp. 142–146. [33] A. Aitken and V. Ilango, “A comparative analysis of traditional
[8] P. Tell, J. Klünder, S. Küpper, D. Raffo, S. G. MacDonell, J. Münch, software engineering and agile software development,” in Hawaii
D. Pfahl, O. Linssen, and M. Kuhrmann, “What are hybrid devel- International Conference on System Sciences, ser. HICSS. IEEE,
opment methods made of?: An evidence-based characterization,” March 2013, pp. 4751–4760.
in Proceedings of the International Conference on Software and System [34] B. Boehm and R. Turner, “Using risk to balance agile and plan-
Processes, ser. ICSSP. IEEE Press, 2019, pp. 105–114. driven methods,” IEEE Computer, vol. 36, no. 6, pp. 57–66, 2003.
[9] P. Bourque and R. E. Fairley, Eds., Guide to the Software Engineering [35] ——, “Management challenges to implementing agile processes
Body of Knowledge, Version 3.0. IEEE Computer Society, 2014. in traditional development organizations,” IEEE Software, vol. 22,
[10] W. W. Royce, Managing the development of large software systems. no. 5, pp. 30–39, September 2005.
IEEE Wescon, 1970. [36] G. Theocharis, M. Kuhrmann, J. Münch, and P. Diebold, “Is Water-
[11] B. W. Boehm, “A spiral model of software development and Scrum-Fall reality? On the use of agile and traditional develop-
enhancement,” Computer, vol. 21, no. 5, pp. 61–72, 1988. ment practices,” in International Conference on Product Focused Soft-
[12] H. D. Mills, “The management of software engineering, part i: ware Development and Process Improvement, ser. Profes. Springer,
Principles of software engineering,” IBM Systems Journal, vol. 19, 2015, pp. 149–166.
no. 4, pp. 414–420, 1980. [37] M. Cusumano, A. MacCormack, C. F. Kemerer, and B. Crandall,
[13] M. Dyer, “The management of software engineering, part iv: “Software development worldwide: the state of the practice,” IEEE
Software development practices,” IBM Systems Journal, vol. 19, Software, vol. 20, no. 6, pp. 28–34, Nov 2003.
no. 4, pp. 451–465, 1980. [38] L. R. Vijayasarathy and C. W. Butler, “Choice of software de-
[14] P. Kruchten, The rational unified process: an introduction. Addison- velopment methodologies: Do organizational, project, and team
Wesley Professional, 2004. characteristics matter?” IEEE Software, vol. 33, no. 5, pp. 86–94,
[15] K. Beck, Extreme programming explained: embrace change. addison- 2016.
wesley professional, 2000. [39] M. Kuhrmann, P. Diebold, J. Münch, P. Tell, V. Garousi,
[16] L. Vijayasarathy and D. Turk, “Drivers of agile software develop- M. Felderer, K. Trektere, F. McCaffery, O. Linssen, E. Hanser,
ment use: Dialectic interplay between benefits and hindrances,” and C. R. Prause, “Hybrid software and system development in
Information and Software Technology, vol. 54, no. 2, pp. 137–148, 2012. practice: Waterfall, scrum, and beyond,” in International Conference
[17] S. Nerur, R. Mahapatra, and G. Mangalaraj, “Challenges of migrat- on Software and System Process, ser. ICSSP. ACM, 2017, pp. 30–39.
ing to agile methodologies,” Communications of the ACM, vol. 48, [40] A. Solinski and K. Petersen, “Prioritizing agile benefits and limita-
no. 5, pp. 73–78, 2005. tions in relation to practice usage,” Software Quality Journal, vol. 24,
[18] T. Dyba and T. Dingsoyr, “What do we know about agile software no. 2, pp. 447–482, 2016.
development?” IEEE Software, vol. 26, no. 5, pp. 6–9, Sep. 2009. [41] J. Klünder, R. Hebig, P. Tell, M. Kuhrmann, J. Nakatumba-
[19] J. F. Tripp and D. J. Armstrong, “Exploring the relationship be- Nabende, R. Heldal, S. Krusche, M. Fazal-Baqaie, M. Felderer,
tween organizational adoption motives and the tailoring of agile M. F. G. Bocco, S. Küpper, S. A. Licorish, G. Lopez, F. McCaffery,
methods,” in Hawaii International Conference on System Sciences. Ö. Ö. Top, C. R. Prause, R. Prikladnicki, E. Tüzün, D. Pfahl,
IEEE, 2014, pp. 4799–4806. K. Schneider, and S. G. MacDonell, “Catching up with method and
[20] A. Qumer and B. Henderson-Sellers, “An evaluation of the degree process practice: An industry-informed baseline for researchers,”
of agility in six agile methods and its applicability for method in International Conference on Software Engineering, ser. ICSE (SEIP).
engineering,” Information and Software Technology, vol. 50, no. 4, IEEE, May 2019, pp. 255–264.
pp. 280–295, 2008. [42] J. Noll and S. Beecham, “How agile is hybrid agile? an analysis of
[21] S. Balaji and M. S. Murugaiyan, “Waterfall vs. v-model vs. agile: the helena data,” in Product-Focused Software Process Improvement,
A comparative study on sdlc,” International Journal of Information X. Franch, T. Männistö, and S. Martı́nez-Fernández, Eds. Cham:
Technology and Business Management, vol. 2, no. 1, pp. 26–30, 2012. Springer International Publishing, 2019, pp. 341–349.
[22] B. Murphy, C. Bird, T. Zimmermann, L. Williams, N. Nagappan, [43] P. Diebold, J.-P. Ostberg, S. Wagner, and U. Zendler, “What do
and A. Begel, “Have agile techniques been the silver bullet for practitioners vary in using scrum?” in International Conference on
software development at microsoft?” in International Symposium Agile Software Development, ser. XP. Springer, May 2015, pp. 40–51.
on Empirical Software Engineering and Measurement, ser. ESEM. [44] M. Kuhrmann, P. Tell, J. Klünder, R. Hebig, S. A. Licorish, and S. G.
IEEE/ACM, 2013, pp. 75–84. MacDonell, “Complementing materials for the HELENA Study
[23] VersionOne, “State of agile survey,” Available from: http://www. (Stage 2),” [online] https://www.researchgate.net/publication/
versionone.com, 2006-2014. 329246439 HELENA Stage 2 Results, 2018.
[24] A. Meier and M. Kropp, “Swiss agile study,” Online http://www. [45] C. Robson and K. McCartan, Real World Research. John Wiley &
swissagilestudy.ch, 2019. Sons, 2016.
[25] GPM Dt. Gesellschaft f. Projektmanagement, “Status quo agile,” [46] M. Kuhrmann, J. Münch, P. Diebold, O. Linssen, and C. R. Prause,
2017. “On the use of hybrid development approaches in software and
[26] V. Garousi, A. Coşkunçay, A. Betin-Can, and O. Demirörs, “A systems development: Construction and test of the helena survey,”
survey of software engineering practices in turkey,” Journal of in Special Interest Group Meeting Projektmanagement und Vorgehens-
Systems and Software, vol. 108, pp. 148–177, 2015. modelle. Gesellschaft für Informatik (GI), 2016, pp. 59–68.
[27] S. Jalali, C. Wohlin, and L. Angelis, “Investigating the applicability [47] K. Strassburger and F. Bretz, “Compatible simultaneous lower
of agility assessment surveys: A case study,” Journal of Systems and confidence bounds for the holm procedure and other bonferroni-
Software, vol. 98, pp. 172–190, 2014. based closed tests,” Statistics in medicine, vol. 27, no. 24, pp. 4914–
[28] O. E. Adalı, Ö. Özcan-Top, and O. Demirörs, “Evaluation of 4927, 2008.
agility assessment tools: A multiple case study,” in Software Pro- [48] C. Wohlin, P. Runeson, M. Höst, M. C. Ohlsson, B. Regnell, and
cess Improvement and Capability Determination, P. M. Clarke, R. V. A. Wesslén, Experimentation in software engineering. Springer
O’Connor, T. Rout, and A. Dorling, Eds. Cham: Springer Inter- Science & Business Media, 2012.
national Publishing, 2016, pp. 135–149. [49] P. M. Clarke, A. L. Mesquida, D. Ekert, J. J. Ekstrom, T. Gornostaja,
[29] I. Nurdiani, J. Börstler, S. Fricker, K. Petersen, and P. Chatzipetrou, M. Jovanovic, J. Johansen, A. M. Picahaco, R. Messnarz, B. N.
“Understanding the order of agile practice introduction: Compar- Villar, A. O’Connor, R. V. O’Connor, M. Reiner, G. Sauberer,

K. Schmitz, and M. Yilmaz, “An investigation of software develop- [70] C. Yang, P. Liang, and P. Avgeriou, “A systematic mapping study
ment process terminology,” in Proceedings of the 16th International on the combination of software architecture and agile develop-
Conference on Software Process Improvement and Capability Determina- ment,” Journal of Systems and Software, vol. 111, pp. 157–184, 2016.
tion, ser. Communications in Computer and Information Science, [71] M. Kuhrmann and J. Münch, “SPI is dead, isn’t it?: clear the stage
vol. 609. Springer, June 2016, pp. 351–361. for continuous learning!” in International Conference on Software and
[50] M. Marinho, J. Noll, I. Richardson, and S. Beecham, “Plan-driven System Processes, ser. ICSSP. IEEE, May 2019, pp. 9–13.
approaches are alive and kicking in agile global software develop- [72] E. Tüzün, c. Üsfekes, Y. Macit, and G. Giray, “Towards unified soft-
ment,” in International Symposium on Empirical Software Engineering ware project monitoring for organizations using hybrid processes
and Measurement, ser. ESEM. IEEE/ACM, 2019, pp. 1–11. and tools,” in Proceedings of the International Conference on Software
[51] P. Clarke, R. V. O’Connor, B. Leavy, and M. Yilmaz, “Exploring and System Processes, ser. ICSSP. IEEE Press, 2019, pp. 115–119.
the relationship between software process adaptive capability [73] E. Knauss, “The missing requirements perspective in large-scale
and organisational performance,” IEEE Transactions on Software agile system development,” IEEE Software, vol. 36, no. 3, pp. 9–13,
Engineering, vol. 41, no. 12, pp. 1169–1183, 2015. 2019.
[52] P. Clarke, R. V. O’Connor, and B. Leavy, “A complexity theory [74] R. Hebig, A. I. Schmied, and I. Weisemöller, “Lessons learned from
viewpoint on the software development process and situational co-evolution of software process and model-driven engineering,”
context,” in Proceedings of the International Conference on Software in Managing software process evolution. Springer, 2016, pp. 257–280.
and Systems Process, ser. ICSSP. ACM, 2016, pp. 86–90. [75] R. Hebig and J. Derehag, “The changing balance of technology
[53] M. Ekstedt, P. Johnson, and I. Jacobson, “Where’s the theory for and process: A case study on a combined setting of model-driven
software engineering?” IEEE Software, vol. 29, no. 05, p. 96, 2012. development and classical c coding,” Journal of Software: Evolution
[54] R. Kasauli, E. Knauss, J. Nakatumba-Nabende, and B. Kanagwa, and Process, vol. 29, no. 11, 2017.
“Agile islands in a waterfall environment: Challenges and strate- [76] M. Kuhrmann, T. Ternité, J. Friedrich, A. Rausch, and M. Broy,
gies in automotive,” in Evaluation and Assessment in Software Engi- “Flexible software process lines in practice,” Journal of Systems and
neering, ser. EASE. ACM, 2020, pp. 31–40. Software, vol. 121, no. C, pp. 49–71, Nov. 2016.
[55] M. Paasivaara, “Adopting safe to scale agile in a globally dis- [77] M. Mortada, H. Michael Ayas, and R. Hebig, “Why do software
tributed organization,” in IEEE 12th International Conference on teams deviate from scrum? reasons and implications,” in Interna-
Global Software Engineering, ser. ICGSE. IEEE, 2017, pp. 36–40. tional Conference on Software and System Processes, ser. ICSSP. ACM,
[56] C. Larman and B. Vodde, Large-Scale Scrum: More with Less. 2020, pp. 71–80.
Addison-Wesley Professional, 2016. [78] J. Klünder, F. Kortum, T. Ziehm, and K. Schneider, “Helping teams
[57] Z. Wan, X. Xia, D. Lo, and G. C. Murphy, “How does machine to help themselves: An industrial case study on interdependencies
learning change software development practices?” IEEE Transac- during sprints,” in International Conference on Human-Centred Soft-
tions on Software Engineering, 2019 (in press). ware Engineering. Springer, 2018, pp. 31–50.
[58] H. Liu, S. Eksmo, J. Risberg, and R. Hebig, “Emerging and [79] F. Kortum, J. Klünder, and K. Schneider, “Behavior-driven dynam-
changing tasks in the development process for machine learning ics in agile development: the effect of fast feedback on teams,” in
systems,” in International Conference on Software and Systems Process, International Conference on Software and System Processes, ser. ICSSP.
ser. ICSSP. ACM, 2020, pp. 125–134. IEEE, May 2019, pp. 34–43.
[80] J. Klünder, K. Schneider, F. Kortum, J. Straube, L. Handke, and
[59] P. Tell, J. Klünder, S. Küpper, D. Raffo, S. G. MacDonell, J. Münch,
S. Kauffeld, “Communication in teams-an expression of social con-
D. Pfahl, O. Linssen, and M. Kuhrmann, “Towards the statistical
flicts,” in Human-Centered and Error-Resilient Systems Development.
construction of hybrid development methods,” Journal of Software:
Springer, 2016, pp. 111–129.
Evolution and Process, vol. 33, no. 1, 2021.
[81] L. Gren, A. Goldman, and C. Jacobsson, “Group-development
[60] S. Amershi, A. Begel, C. Bird, R. DeLine, H. C. Gall, E. Kamar,
psychology training: The perceived effects on agile software-
N. Nagappan, B. Nushi, and T. Zimmermann, “Software engineer-
development teams,” IEEE Software, vol. 37, no. 3, pp. 63–69, 2020.
ing for machine learning: a case study,” in International Conference
[82] J. Noll, M. A. Razzak, J. M. Bass, and S. Beecham, “A study
on Software Engineering. IEEE/ACM, May 2019, pp. 291–300.
of the scrum master’s role,” in Product-Focused Software Pro-
[61] E. de Souza Nascimento, I. Ahmed, E. Oliveira, M. P. Palheta,
cess Improvement, M. Felderer, D. Méndez Fernández, B. Turhan,
I. Steinmacher, and T. Conte, “Understanding development pro-
M. Kalinowski, F. Sarro, and D. Winkler, Eds. Cham: Springer
cess of machine learning systems: Challenges and solutions,”
International Publishing, 2017, pp. 307–323.
in International Symposium on Empirical Software Engineering and
[83] M. Kuhrmann, J. Nakatumba-Nabende, R.-H. Pfeiffer, P. Tell,
Measurement, ser. ESEM. IEEE, September 2019, pp. 1–6.
J. Klünder, T. Conte, S. G. MacDonell, and R. Hebig, “Walking
[62] G. Giray, B. Tekinerdogan, and E. Tüzün, Internet of Things: Chal- through the method zoo: does higher education really meet soft-
lenges, Advances, and Applications. CRC Press/Taylor & Francis, ware industry demands?” in International Conference on Software
January 2018, ch. IoT System Development Methods, pp. 141–159. Engineering, ser. ICSE (SEET). IEEE, May 2019, pp. 1–11.
[63] D. X. Houston, “Agility beyond software development,” in Pro- [84] V. Garousi, G. Giray, E. Tuzun, C. Catal, and M. Felderer, “Closing
ceedings of the International Conference on Software and System Pro- the gap between software engineering education and industrial
cess, ser. ICSSP. ACM, 2014, pp. 65–69. needs,” IEEE Software, vol. 37, no. 02, pp. 68–77, mar 2020.
[64] J.-P. Steghöfer, E. Knauss, J. Horkoff, and R. Wohlrab, “Challenges [85] P. Clarke and R. V. O’Connor, “The situational factors that affect
of scaled agile for safety-critical systems,” in International Confer- the software development process: Towards a comprehensive
ence on Product-Focused Software Process Improvement. Springer, reference framework,” Information and Software Technology,
2019, pp. 350–366. vol. 54, no. 5, pp. 433–447, May 2012. [Online]. Available:
[65] R. Kasauli, E. Knauss, B. Kanagwa, A. Nilsson, and G. Calikli, http://dx.doi.org/10.1016/j.infsof.2011.12.003
“Safety-critical systems and agile development: a mapping study,” [86] J. Klünder, D. Karajic, P. Tell, O. Karras, C. Münkel, J. Münch, S. G.
in 2018 44th Euromicro Conference on Software Engineering and MacDonell, R. Hebig, and M. Kuhrmann, “Determining context
Advanced Applications (SEAA). IEEE, 2018, pp. 470–477. factors for hybrid development methods with trained models,”
[66] R. Hebig and R. Bendraou, “On the need to study the impact of in Proceedings of the International Conference on Software and System
model driven engineering on software processes,” in International Processes, ser. ICSSP. ACM, 2020, pp. 61–70.
Conference on Software and System Process, ser. ICSSP. ACM, May [87] R. V. O’Connor, P. Elger, and P. M. Clarke, “Continuous software
2014, pp. 164–168. engineering: A microservices architecture perspective,” Journal of
[67] U. Eliasson, R. Heldal, J. Lantz, and C. Berger, “Agile model- Software: Evolution and Process, vol. 29, no. 11, p. e1866, 2017.
driven engineering in mechatronic systems - an industrial case [88] O. Armbrust and D. Rombach, “The right process for each context:
study,” in Model-Driven Engineering Languages and Systems, J. Din- Objective evidence needed,” in International Conference on Software
gel, W. Schulte, I. Ramos, S. Abrahão, and E. Insfran, Eds. Cham: and Systems Process, ser. ICSSP. ACM, 2011, pp. 237–241.
Springer International Publishing, 2014, pp. 433–449.
[68] C. R. Prause and Z. Durdik, “Architectural design and documenta-
tion: Waste in agile development?” in 2012 International Conference
on Software and System Process (ICSSP), 2012, pp. 130–134.
[69] P. Abrahamsson, M. A. Babar, and P. Kruchten, “Agility and
architecture: Can they coexist?” IEEE Software, vol. 27, no. 2, pp.
16–22, 2010.

IET Wiring Regulation 18th Edition A2-2023 July 27
No ratings yet
IET Wiring Regulation 18th Edition A2-2023 July 27
30 pages
Witherby Seamanship2014 PDF
67% (3)
Witherby Seamanship2014 PDF
92 pages
Agile Ebook Segue PDF
No ratings yet
Agile Ebook Segue PDF
70 pages
Unit 1
100% (3)
Unit 1
13 pages
Agile Notes
100% (1)
Agile Notes
109 pages
Antarang Foundation
No ratings yet
Antarang Foundation
25 pages
Background of The Study: Manual System in Generating Reports of Inventory and Check-Up
No ratings yet
Background of The Study: Manual System in Generating Reports of Inventory and Check-Up
5 pages
Report On Rural Haat
83% (6)
Report On Rural Haat
22 pages
QC Yorp Forms
No ratings yet
QC Yorp Forms
4 pages
#9 - RA 9028 As Amended by RA 10364
100% (1)
#9 - RA 9028 As Amended by RA 10364
3 pages
Data Mining Cat
No ratings yet
Data Mining Cat
6 pages
Business Communication Report
No ratings yet
Business Communication Report
15 pages
National Liberty Alliance CLGJ Letter To District Court Judges
No ratings yet
National Liberty Alliance CLGJ Letter To District Court Judges
20 pages
Digital Signatures: CCA Controller of Certifying Authorities
No ratings yet
Digital Signatures: CCA Controller of Certifying Authorities
18 pages
Project Team Building, Conflict, and Negotiation
No ratings yet
Project Team Building, Conflict, and Negotiation
9 pages
CLobazam
No ratings yet
CLobazam
7 pages
Agile Software Development Methods 2010 e Ga Co
100% (1)
Agile Software Development Methods 2010 e Ga Co
76 pages
Acc Tutorial Topic 8
No ratings yet
Acc Tutorial Topic 8
9 pages
Practical Asessment - 3.2022
No ratings yet
Practical Asessment - 3.2022
303 pages
Republic Act No 11479
No ratings yet
Republic Act No 11479
2 pages
Puente Arizona Et Al v. Arpai Arizona MOTION For Summary Judgment
100% (1)
Puente Arizona Et Al v. Arpai Arizona MOTION For Summary Judgment
31 pages
Chapter 3 - Agile Development-1
No ratings yet
Chapter 3 - Agile Development-1
67 pages
Project Methodology Case Study
No ratings yet
Project Methodology Case Study
32 pages
Corporate Structure and Culture
No ratings yet
Corporate Structure and Culture
4 pages
To Agile or Not To Agile A Comparison of Software
No ratings yet
To Agile or Not To Agile A Comparison of Software
12 pages
Research Report: Impact of Agile Methodology On Software Development Process
No ratings yet
Research Report: Impact of Agile Methodology On Software Development Process
12 pages
Housing For The Middle Income Group in Dhaka, Bangladesh
No ratings yet
Housing For The Middle Income Group in Dhaka, Bangladesh
8 pages
SE Lecture3A Chapter3
No ratings yet
SE Lecture3A Chapter3
21 pages
IIM KZ EPGP Combine Brochure Batch 17 32c718e31a
No ratings yet
IIM KZ EPGP Combine Brochure Batch 17 32c718e31a
20 pages
Chapter1 Corporation and Corporate Governance
No ratings yet
Chapter1 Corporation and Corporate Governance
4 pages
Perceived Guest House Brand Value The Influence of Web Interactivity On Brand Image and Brand Awareness
No ratings yet
Perceived Guest House Brand Value The Influence of Web Interactivity On Brand Image and Brand Awareness
29 pages
Unit 1 Ase
No ratings yet
Unit 1 Ase
23 pages
Comparison Between Agile and Traditional Software Development Methodologies
No ratings yet
Comparison Between Agile and Traditional Software Development Methodologies
9 pages
Software Architecture and Design Assignment #3: University of Lahore, Sargodha Campus
No ratings yet
Software Architecture and Design Assignment #3: University of Lahore, Sargodha Campus
13 pages
Sri Siddhartha Academy of Higher Education
No ratings yet
Sri Siddhartha Academy of Higher Education
31 pages
Technical Seminar On Agile Methodology
No ratings yet
Technical Seminar On Agile Methodology
32 pages
Comparative Study of Agile Methods and Their Comparison With Heavyweight Methods in Indian Organizations
No ratings yet
Comparative Study of Agile Methods and Their Comparison With Heavyweight Methods in Indian Organizations
8 pages
AULA INAUGURAL - Metodologia Agile
No ratings yet
AULA INAUGURAL - Metodologia Agile
9 pages
Sri Siddhartha Academy of Higher Education
No ratings yet
Sri Siddhartha Academy of Higher Education
31 pages
Agile Software Development
No ratings yet
Agile Software Development
39 pages
Evalution of Agile
No ratings yet
Evalution of Agile
7 pages
Empiricalstudiesagiledevelopment Postprint
No ratings yet
Empiricalstudiesagiledevelopment Postprint
58 pages
Agile Software Development Methods
No ratings yet
Agile Software Development Methods
7 pages
Impact of Agile Methodology On Software Development Process: August 2012
No ratings yet
Impact of Agile Methodology On Software Development Process: August 2012
6 pages
10 v3n1 2021
No ratings yet
10 v3n1 2021
10 pages
Agile Software Development
No ratings yet
Agile Software Development
4 pages
Agile
No ratings yet
Agile
12 pages
Detailed Study On Agile Software Development Methodologies
No ratings yet
Detailed Study On Agile Software Development Methodologies
4 pages
(Article) New Directions On Agile Methods (2003)
No ratings yet
(Article) New Directions On Agile Methods (2003)
11 pages
Impact of Agile
No ratings yet
Impact of Agile
6 pages
ZRO Chennai Notification Sol Tech NA 2025 - 26
No ratings yet
ZRO Chennai Notification Sol Tech NA 2025 - 26
23 pages
2 RDM Agile Approaches
No ratings yet
2 RDM Agile Approaches
22 pages
V3i609 PDF
No ratings yet
V3i609 PDF
6 pages
Samsung Manual-ACI3PR16001 R2
No ratings yet
Samsung Manual-ACI3PR16001 R2
32 pages
Agile Methodology
No ratings yet
Agile Methodology
6 pages
The Analysis of Current State of Agile S
No ratings yet
The Analysis of Current State of Agile S
12 pages
Agile Software Development: An Overview & Methodologies: Hitik Patel Vishv Patel Arpit Rabadiya
No ratings yet
Agile Software Development: An Overview & Methodologies: Hitik Patel Vishv Patel Arpit Rabadiya
19 pages
Agile SDLC (Wiki)
No ratings yet
Agile SDLC (Wiki)
12 pages
Lecture 3 Agile
No ratings yet
Lecture 3 Agile
47 pages
Papatheocharous 2014
No ratings yet
Papatheocharous 2014
12 pages
Module 3.1 - Training Certificate - Folayeni - Awosika
No ratings yet
Module 3.1 - Training Certificate - Folayeni - Awosika
1 page
Improvement Opportunity in Agile Methodology and A Survey On The Adoption Rate of The Improved Methodology
No ratings yet
Improvement Opportunity in Agile Methodology and A Survey On The Adoption Rate of The Improved Methodology
7 pages
Agile Background
No ratings yet
Agile Background
31 pages
CH 02. Agile Development
No ratings yet
CH 02. Agile Development
8 pages
Agile Software Development Methodologies
No ratings yet
Agile Software Development Methodologies
25 pages
Polymerization of Alkenes... Final..fizza...
No ratings yet
Polymerization of Alkenes... Final..fizza...
19 pages
What Do You Mean by Agile Development of A S/W Proj.? Explain Best Practice For Agile Development With Example?
No ratings yet
What Do You Mean by Agile Development of A S/W Proj.? Explain Best Practice For Agile Development With Example?
6 pages
AGILE
No ratings yet
AGILE
10 pages
Aglie Introduction
No ratings yet
Aglie Introduction
28 pages
Lecture 1b Introduction To Agile Methods
No ratings yet
Lecture 1b Introduction To Agile Methods
20 pages
Module 3 SE
No ratings yet
Module 3 SE
98 pages
Selfstudys Com File
No ratings yet
Selfstudys Com File
18 pages
Case Study of Agile Methodologies in Field of Software Development IJERTV6IS110104
No ratings yet
Case Study of Agile Methodologies in Field of Software Development IJERTV6IS110104
6 pages
IndividualAssignment (Mek625) (2022487736)
No ratings yet
IndividualAssignment (Mek625) (2022487736)
2 pages
A Survey On Success Factors and Obstacle
No ratings yet
A Survey On Success Factors and Obstacle
14 pages
2013-A Survey Study of Critical Success Factors in Agile Software Projects
No ratings yet
2013-A Survey Study of Critical Success Factors in Agile Software Projects
16 pages
SFG117V Satur 15th Feb v2
No ratings yet
SFG117V Satur 15th Feb v2
45 pages
The Hippocampus in Clinical Neuroscience Frontiers of Neurology and Neuroscience Vol 34
No ratings yet
The Hippocampus in Clinical Neuroscience Frontiers of Neurology and Neuroscience Vol 34
306 pages
Agile Software Development Model Methods Advantages and Disadvantages
No ratings yet
Agile Software Development Model Methods Advantages and Disadvantages
7 pages
CS IMMIGRATION LTD. Financial Statements 2023
No ratings yet
CS IMMIGRATION LTD. Financial Statements 2023
7 pages
Software Notes
No ratings yet
Software Notes
12 pages
Software Development Lifecycle Made Simple: A Practical Guide with Examples
From Everand
Software Development Lifecycle Made Simple: A Practical Guide with Examples
William E. Clark
No ratings yet
DevOps Revolution: Transforming Software Delivery for High-Performance Teams
From Everand
DevOps Revolution: Transforming Software Delivery for High-Performance Teams
Ryan Campbell
No ratings yet
"Careers in Information Technology: DevOps Engineer": GoodMan, #1
From Everand
"Careers in Information Technology: DevOps Engineer": GoodMan, #1
Patrick Mukosha
No ratings yet
30 Days to DevOps Proficiency
From Everand
30 Days to DevOps Proficiency
Prachi Tembhekar
No ratings yet
SECURING THE PIPELINE: Modern DevSecOps Journey: A Comprehensive Guideline For Integration Of Tools In Devsecops.
From Everand
SECURING THE PIPELINE: Modern DevSecOps Journey: A Comprehensive Guideline For Integration Of Tools In Devsecops.
Muhammad Amman Zaheer
No ratings yet
DevOps Beginners to Advanced with Projects
From Everand
DevOps Beginners to Advanced with Projects
Adil Khan
No ratings yet
Agile Product Management
From Everand
Agile Product Management
DeEtta Jennings - Balthazar
No ratings yet
Adapting Software Development for Innovation and Efficiency
From Everand
Adapting Software Development for Innovation and Efficiency
Ayebakuro Ngonamondi
No ratings yet
Agile Testing: An Overview
From Everand
Agile Testing: An Overview
Florian Heuer
4/5 (10)

What Makes Agile Software Development Agile

Uploaded by

What Makes Agile Software Development Agile

Uploaded by

This article has been accepted for publication in a future issue of this journal, but has not been

What Makes Agile Software Development Agile?

Which of the following

that claim to implement all project disciplines either fully or 100

mainly agile or, respectively, fully or mainly traditional.

40 Poly. (Not V-Model for Risk

question if a method or practice is used in that project

dependence of the industry target domain. If a participant

the environment, which underlines the critical role software

Me dia and Entertainment 24 100

e) Change Management (n=513) f) Requirements Engineering (n=536)

200 198 200

than 10 years of professional experience. 0

50 Finding 3a: Few methods and practices affect the degree of

Fig. 9. Aggregated degree of agility for participants implementing all

practices for which no significant trend could be found at

all (gray-italic items). In total, of the 660 cases, 146 (22.12%)

Finding 4: Most practices are associated with an increase in

Figure 12 also shows that there is no “radical” shift. That

Implementation and Coding

Implementation and Coding

Maintenance and Evoution

Transition and Operation

Architecture and Design

Integration and Testing

context of the project discipline Implementation and Coding,

Implementation and Coding

Maintenance and Evoution

Integration and Testing

5.1 Answering the Research Questions

You might also like