Conference PaperPDF Available


For years, agile methods are considered the most promising route toward successful software development, and a considerable number of publications studies the (successful) use of agile methods and reports on the benefits companies have from adopting agile methods. Yet, since the world is not black or white, the question for what happened to the traditional models arises. Are traditional models replaced by agile methods? How is the transformation toward Agile managed, and, moreover, where did it start? With this paper we close a gap in literature by studying the general process use over time to investigate how traditional and agile methods are used. Is there coexistence or do agile methods accelerate the traditional processes' extinction? The findings of our literature study comprise two major results: Studies and reliable numbers on the general process model use are rare, i.e., we lack quantitative data on the actual process use and, thus, we often lack the ability to ground process-related research in practically relevant issues. Second, despite the assumed superiority of agile methods, our results clearly show that companies enact context-specific hybrid solutions in which traditional and agile development approaches are used in combination.
Is Water-Scrum-Fall Reality? On the Use of Agile and
Traditional Development Practices
Georgios Theocharis1, Marco Kuhrmann1, J¨
urgen M¨
unch2, Philipp Diebold3
1University of Southern Denmark, The Mærsk Mc-Kinney Møller Institute & Center for
Energy Informatics, Odense, Denmark,
2University of Helsinki, Department of Computer Science, Helsinki, Finland
3Fraunhofer Institute for Experimental Software Engineering, Kaiserslautern, Germany
Abstract. For years, agile methods are considered the most promising route to-
ward successful software development, and a considerable number of published
studies the (successful) use of agile methods and reports on the benefits compa-
nies have from adopting agile methods. Yet, since the world is not black or white,
the question for what happened to the traditional models arises. Are traditional
models replaced by agile methods? How is the transformation toward Agile man-
aged, and, moreover, where did it start? With this paper we close a gap in litera-
ture by studying the general process use over time to investigate how traditional
and agile methods are used. Is there coexistence or do agile methods accelerate
the traditional processes’ extinction? The findings of our literature study com-
prise two major results: First, studies and reliable numbers on the general process
model use are rare, i.e., we lack quantitative data on the actual process use and,
thus, we often lack the ability to ground process-related research in practically
relevant issues. Second, despite the assumed dominance of agile methods, our re-
sults clearly show that companies enact context-specific hybrid solutions in which
traditional and agile development approaches are used in combination.
Keywords: Development Practices, Agile Methods, Software Process, System-
atic Literature Review, Comparative Study, Scrum
1 Introduction
Software managers and developers are still on the quest for adequate methods to orga-
nize, plan, and direct software projects. Since the early 1970’s, software processes are
defined to capture and organize knowledge about software and systems development
and, since then, a continuously growing number of software development approaches
competes for the users’ favor. The software process comes in different shapes—be it as
rigid plan-driven approach or as slim agile method, and since the 2000’s, we find two
basic streams. Traditional (or rich) processes aim to address the whole software project
lifecycle, e.g., by providing comprehensive guidelines, standardized procedures, project
planning templates, and interfaces to further organization processes, while agile meth-
ods aim at reducing the software process to its minimum to avoid “bureaucracy”, and to
© Springer. PREPRINT. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings.
provide users with only this amount of rules and guidelines that is required to perform
a project. Over the past decades, we observed the “rise of agile methods” [8]. Appar-
ently, agile methods provide a better way to address practitioners’ needs, to accelerate
software development, and to improve quality and customer satisfaction. Several stud-
ies provide evidence regarding the benefits of agile methods, e.g., [6,9]. Yet, practice
shows the world not being fully “agilized”, as there exist settings in which agile methods
are either not (fully) applicable or cannot show their strengths. In such situations, the
software process is usually adopted to the current context, which, for instance, is shown
in our previously conducted study [21] in which we could identify different combina-
tion patterns showing a trend toward West’s “Water-Scrum-Fall” [40]. In particular, we
found combinations of traditional and agile software development approaches, which
was also found in another independently conducted study [39]. Furthermore, surveys on
the use of agile methods, such as [17,38], suggest that even the agile methods appear to
be rarely used in their “pure” form. For instance, Diebold et al. [7] conducted a study
in which they show how Scrum is used in practice (with a particular focus on variations
and respective rationale).
Problem Statement Available studies draw a picture of a diverse process ecosystem
in which different development approaches are combined with each other. Therefore,
knowledge of the project context, customization settings, and variability operators is
required to efficiently assemble a company- or project-specific process. However, dif-
ferent studies reveal considerable gaps in the body of knowledge [4,24, 25]. As men-
tioned by Dingsøyr et al. [8], current literature focuses on researching agile methods,
yet ignoring the other processes to a large extent. To identify useful strategies to sys-
tematically and efficiently combine development approaches for a particular context,
understanding of the state-of-the-practice is required. In particular, we miss empirical
data on the process use in general, about common combinations, and trends over time.
Objective To investigate the use of different software process models in practice, we
analyze published studies that provide data on software processes, their use, poten-
tial/implemented combinations, and trends by analyzing how the use of software pro-
cesses evolved over time. Our research aims to investigate practically applied processes
and combinations to lay the foundation for developing appropriate process customiza-
tion and configuration instruments.
Contribution This paper presents our findings from a literature study on the use of
process process models in practice. In a set of 22 selected papers, only five provided
quantitative data. Furthermore, data from the annually conducted VersionOne survey
[38] were used for comparison. Our findings show software processes mainly used as
hybrid approaches that either combine traditional and agile methods or compose project
processes from different practices. However, our findings also show absence of detailed
knowledge about which approaches are used in particular, how those are combined, and
how they relate to the respective company context. Studies that investigate the whole
process ecosystem are scarcely to find. Therefore, our study also concludes with the
call for more research to generate more and better data on process use to pave the way
for developing efficient instruments for process selection, tailoring, and combination.
© Springer. PREPRINT. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings.
Outline The reminder of the paper is organized as follows: Section 2 discusses related
work and gaps in the current body of knowledge. In Section 3, we describe our research
approach, present the results of our study in Section 4, and provide a discussion on the
results in Section 5. We conclude the paper in Section 6.
2 Related Work
Agile software development methods were introduced and used in the late 1990’s. They
gained attention and companies and developers worldwide increasingly adopted them.
In February 2001, the Agile Manifesto, was published and described the principles of
Agile Methods. Since then, agile methods gained increasing attention in practice as
well as in research and, consequently, a number of agile methods was proposed. In
2014, Tripp and Armstrong [37] investigated the “most popular” agile methods and
found, inter alia, Extreme Programming (XP), Scrum, Dynamic Systems Development
Method (DSDM), Crystal, Feature Driven Development (FDD), and Lean development
the most frequently used. Beyond such one-time studies, few studies investigate the
development over time. For example, a comprehensive perspective on the use of agile
methods is provided by Dingsøyr et al. [8], who summarized “a decade of agile soft-
ware development”, provided an overview of the publication body, and motivate further
research toward a sound theoretical framework of agile software development. Dyb˚
and Dingsøyr [9] conducted a literature review on empirical studies on agile software
development. They summarized the major approaches, but found most of the research
done in the context of XP (with immature teams) and concluded the strength of evi-
dence (still) low. Furthermore, they vote for more rigorous research in the field of agile
methods (especially on methods of particular relevance for industry). Such an industry
perspective is given by the VersionOne survey [38] that investigates the use of agile
methods over time and draws a slightly different picture4. Aggregating the VersionOne
data, Scrum became the most popular agile method. However, this study also points to a
certain trend toward using hybrid and customized approaches, which is also supported
by Diebold et al. [7], who study how Scrum is actually implemented in practice.
Going beyond aforementioned agile-focused studies and reviewing the available
scientific and “grey” literature on software processes in general, one may conclude that
agile methods took over from traditional processes. In fact, literature reflects this trend.
For instance, in their 1996-study, Khurana et al. [15] list more than 25 fine-grained
“techniques” for software engineering (mapped to different software engineering activ-
ities), e.g., prototyping, Fagan inspections, and SSADM [32]. Studies conducted in the
early 2000’s, e.g., [3,11] show several of the mentioned techniques still in use, but also
show them slowly disappearing and being replaced by (the new) agile methods.
However, within that diversity of traditional and agile methods, another trend came
to light: just in 1997, Fitzgerald [10] found 6 out of 8 companies in Ireland using
custom or non-formalized development processes—a trend that still can be observed
over time (e.g., Reifer [31]) and also in recent studies, e.g., [18]. Among other things,
those studies also show that the traditional process models are still of certain relevance.
4A similar study is available by the “Status Quo Agile 2014” study [17]. However, this study
does not provide as comprehensive historical data as the VersionOne survey series.
© Springer. PREPRINT. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings.
For example, Solinski and Petersen [36] found Scrum and XP the most popular and
adopted methodologies. They also found combinations of the classic Waterfall/XP, and
Scrum/XP the most common combinations. Recently published studies, e.g., [18, 39]
also indicate to a situation in which traditional and agile approaches coexist and make
the majority of practically used (mixed/hybrid) approaches.
Therefore, current literature on software processes and their application (patterns)
in practice leaves researchers and practitioners alone with a diffuse picture: agile meth-
ods gained popularity and the related (scientific) literature is dramatically increasing
(cf. [8]), e.g., understanding of benefits of certain practices and analyzing the impact of
agile methods. Traditional process models are seemingly vanished from the researchers’
to-do lists and, if at all, appear only in the context of process modeling, in domains
having special requirements to the software process, e.g., compliance, regulations, and
norms (safety & security, medical devices, etc.), as part of surveys, and as subject to
discussion why companies might be reluctant to buy-in agile methods (e.g., [26, 37]).
However, information about general software process use, local/global trends, and de-
tailed information about combination patterns is missing in literature. The present paper
thus aims to fill a gap in literature by providing first steps toward a more comprehensive
picture of process use to lay the foundation for further research.
3 Research Design
In this curiosity-driven and exploratory study, we opted for a research design in which
we applied instruments from Systematic Literature Review process [16]. The core study
was conducted by stepwise collecting information starting from a small set of refer-
ence publications to form the basic knowledge (snowballing). Based on the harvested
publications, we conducted an automatic search in different literature databases to find
further publications, which then were used for another snowballing iteration. Finally,
the VersionOne survey [38] was chosen for a broader analysis and discussion.
In subsequent section, we detail the research design and explain the different pro-
cedures to collect and analyze data.
3.1 Research Questions
To conduct the study, we defined the following research questions:
RQ 1 Which development approaches are used in practice? This research question
aims at developing a catalog of practically used development approaches (processes,
methods, or practices) and to investigate the approaches’ use over time.
RQ 2 Which development approaches are combined in practical use? In order to an-
swer this research question, we use the initial catalog to study how development ap-
proaches are combined in order to address specific software development contexts.
RQ 3 Are there patterns and trends observable? This research question aims to in-
vestigate patterns of process use to better support the adaptation of agile methods in
non-agile environments and trends of process use, i.e., does the region affect the pro-
cess selection (e.g., due to local standards), or is there any general trend to find.
© Springer. PREPRINT. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings.
Table 1: Inclusion and exclusion criteria for the study’s SLR parts.
No. Description
IC1The paper describes a longterm observation of the use of development methods.
IC2The paper surveys practitioners for the use of development methods.
IC3The paper reports on the use of development methods in general, e.g., as secondary study.
IC4The paper is on tools implementing certain methods (infer information about method use).
EC1The paper is a proposal only.
EC2The paper occurred multiple times in the result set.
EC3The paper is not on the use of development methods (out of scope).
EC4The paper is a workshop-, tutorial-, or poster summary.
EC5The paper is not in the domain of software engineering or computer science in general.
EC6The paper reports on teaching experiences using development methods only.
EC7The paper is not available in English (or German).
EC8The paper’s full text is not available for download.
3.2 Data Collection Procedures
To get information on the process use in general, we were especially interested into
primary studies that we collected using a multi-staged search and selection procedure.
The data collection procedure comprised the following steps:
1. Snowballing based on two manually selected reference publications [18,39].
2. Initial analysis of the found extra four publications: [3,11, 14, 30].
3. Automated search in five literature databases, complemented by a search using
Scopus and Google Scholar as meta-search engines.
4. Snowballing of the publications obtained in the automated search.
5. Using the VersionOne survey [38] to add extra perspectives to the discussion.
The manual paper selection (following the snowballing procedures [16]) was conducted
twice. The initial selection was performed on two reference publications [18, 39] and
aimed at extending the set of reference publications that built the foundation to construct
search queries to support the automated search in different literature databases. The
resulting six publications were read with the purpose of finding proper keywords to
initiate the automatic search. The second iteration was performed on the publications
obtained from the automated search with the purpose of completing the result set.
The automatic search was conduced using the following literature databases: ACM,
IEEE,Springer,Wiley, and Elsevier. To obtain the data, based on the reference publi-
cations and the initial snowballing results, we developed different search query candi-
dates that we stepwise tested and refined. We conducted the automated search using the
following simple search query: (((”method choice”) or ”method use”) and ”software
development”) and ”survey”)5
In order to confirm the search results, Scopus and Google Scholar were used. The
outcomes of the automatic search were treated in a rigorous and proven selection pro-
cess, as described in detail in [19] applying the in-/exclusion criteria from Table 1.
5We conducted several test runs finding this simple string producing the best results. Includ-
ing/adding keywords like “process” just inflated the result set, yet no extra publication provid-
ing quantitative data on process use could be found in these tests.
© Springer. PREPRINT. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings.
3.3 Analysis Procedures
For the analysis procedure, we implemented two different approaches. In general all
selected publications were included in a spreadsheet in which we classified the respec-
tive publications, e.g., for study type, applied instruments, context, and outcomes. We
then boiled down all initially selected studies to their essence to prepare the qualitative
analysis. For the primary studies (in which we were especially interested) we analyzed
the publications for quantitative detailed data on processes, use, combinations, and so
forth, and collected these data in a separate spreadsheet for an in-depth analysis.
Due to the low number of studies, we did not perform any statistical tests. Instead,
we rely on simple data tables and charts on which we base our discussion and interpre-
tation. Since we found a considerable number of process mentions, we also perform a
clustering and a categorization.
3.4 Validity Procedures
To improve the validity of our results, we opted for different strategies. The initial data
collection and study selection procedures were performed by two researchers adopting
the schematic procedures from previously conducted studies [19,20]. That is, data col-
lection and selection was initially performed independently using previously defined
spreadsheet templates, followed by a series of workshops to perform the final selec-
tion and classification. The finally selected papers and initial analysis results were then
given to another team of researchers to review, confirm and/or revise the results, and to
develop a joint conclusion.
4 Study Results
In this section, we present the results of the study. In Section 4.1, we give an overview
of the study population. Sections 4.2 – 4.4 present the results from the literature review
and, finally, Section 5 presents a discussion.
4.1 Study Polulation
In this section, we summarize the study population. The different search procedures
resulted into 473 papers from which 22 papers were selected for consideration. Finally,
five of the 22 papers provided quantitative data, i.e., survey results on process use, and
were selected for an in-depth analysis. These studies were conducted in Germany (2006,
2006, 2013), USA (2014), and Brunei (1998). The remaining papers were considered
for the qualitative analysis only. Table 2 provides a summary of the final result set.
4.2 RQ1: Which Development Approaches are used in Practice?
In this section, we provide an overview of the review findings. The five selected papers
mention 62 different development approaches in total6. Among the named methods,
6Due to space limitations, the study data set including the full list of mentioned processes is
available for download here:
© Springer. PREPRINT. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings.
Table 2: Overview of the papers obtained from the literature search (Instruments: “Q” – question-
naire, “I” – interview, “SLR” – systematic literature review, “M” – miscellaneous instruments).
Paper Year Scope in Time Study Type Instruments Quantitative
Snapshot Trend Primary Secondary Data
[39] 2014 7 7 Q3
[18] 2013 7(7)7Q3
[3] 2006 7 7 I, Q 3
[11] 2006 7 7 Q3
[14] 2003 7 7 M
[30] 2002 7 7 Q
[35] 2014 7 7 Q
[36] 2014 7 7 Q
[27] 2014 7 7 Q
[5] 2013 7 7 Q
[26] 2013 7 7 Q
[37] 2013 7 7 Q
[22] 2013 7 7 7 M
[34] 2013 7 7 SLR
[8] 2012 7 7 SLR
[23] 2010 7 7 7 Q, SLR
[28] 2009 7 7 M
[33] 2008 7 7 Q
[9] 2008 7 7 SLR
[12] 2003 7 7 SLR
[29] 1998 7 7 SLR 3
[2] 1983 7 7 Q
Table 3: Mentions of categorized process types (n: number of participants, mentions: number of
mentioned processes in total, *: incomplete/not available raw data).
Paper Year n Mentions Ratio Traditional Agile Technique Unclassified
[39] 2014 153 316* 2.07 66% 88% 52% 0%
[18] 2013 37 93 2.51 92% 119% 5% 35%
[11] 2006 65 199 3.06 109% 26% 103% 68%
[3] 2006 217* 180 0.83 28% 3% 3% 49%
[29] 1998 36 54 1.50 33% 0% 72% 44%
we find representatives of the traditional development models (e.g., Waterfall, RUP, V-
Model), a number of agile methods (e.g., Scrum, Kanban, XP), and also a considerable
share of non-standardized, very specific, and/or “legacy” approaches, such as SSADM
[32] or Jackson’s System Design [13].
As we found a large number of methods and also varying data presentation, we de-
cided to classify the mentioned approaches as traditional process model, agile method,
technique (self-contained method that is neither traditional nor agile, e.g., prototyp-
ing), unclassified (if an approach could not be assigned to one of the other classes, or
if the paper just states “other”, “custom”, or “don’t know”). Furthermore, due to the
© Springer. PREPRINT. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings.
heterogeneous data formats, we normalized the data as relative numbers (percentage
of mentions related to the respective n) that is shown in Table 3. This table shows that
companies usually use multiple development approaches, which becomes obvious due
to the percentage rate larger than 100%. However, the SUCCESS study [3] has to be
considered an outlier, as the total mentions are below 100%. As we don’t have access
to the raw data, we cannot reproduce this phenomenon, yet, since 49% of the mentions
are categorized as “unclassified”, we cannot conclude to what extent, e.g., agile and tra-
ditional approaches are used and/or combined. Especially the 3ProcSurvey [18] and the
IOSE-W2study [11] show that companies use multiple processes. For example, in the
3ProcSurvey, agile methods account for 119% of the mentions, i.e., even in one project
different agile methods are used in combination.
The most frequently mentioned development models across all studies are: Scrum
(61), the Waterfall (54), the Rational Unified Process (RUP; 44), and the Agile Unified
Process (43). V-shaped processes are present in different variants and account for 105
mentions in total. However, these numbers present the mentions without paying atten-
tion to the development over time. For example, in recent studies, RUP accounts for
5.9% [39] and 16.2% [18], whereas for the German context [21] we found a certain
trend: in 2006, RUP accounts for 41.5% of all mentions and in 2013, RUP made only
16.2%. Furthermore, and all mentions in 2013 referred to company-specific variants.
That is, available studies indicate that—although RUP contributes a high number of
mentions—the “classic” (standard/non-customized) RUP is losing its relevance. Fur-
ther trends are discussed together with observed pattern in Section 4.4.
4.3 RQ2: Which Development Approaches are combined in Practical Use?
In this section, we analyze the combination of the different approaches. The numbers
presented in Table 3 show that companies instrument different approaches and use
them in combination. However, only one study [18] provides data of sufficient detail
to present and discuss the combinations. Figure 1, based on [21], shows the combina-
tion of the different development approaches for Germany. It reveals two major clusters
and, when analyzing these clusters, shows that the German standard software process
V-Modell XT is often combined with Scrum, and Scrum itself is normally used in com-
bination with Kanban and XP. Therefore, based on [21], we can name the following
“standard” combination pattern for Germany: V-Modell XT + (Scrum + (Kanban +XP)).
In other words: companies use the national standard to provide a general management
framework (and to comply with certain compliance requirements), and embody the
generic process with concrete methods. Furthermore, as even Scrum is fairly generic
thus requiring some embodiment [7], companies use Kanban and XP practices for this
As mentioned before, we only have sufficient data from the 3ProcSurvey [18] to
allow for such a detailed analysis. However, the numbers from Table 3 suggest a similar
picture for other regions, e.g., for USA [39], the “classic” Waterfall, Scrum, and the
Agile Unified Process account for a high share of mentions thus suggesting a similar
picture in which the V-Modell XT (Germany) is replaced by the Waterfall model as
© Springer. PREPRINT. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings.
V-Modell XT (Standard)
V-Model XT (modified)
V-Modell 97
eXtreme Programming
V-Modell XT (Standard)
V-Model XT (modified) 3
V-Modell 97 1 4
Xtreme Programming 232
Scrum 512 59
Kanban 22138
Rational Unified
Process (Standard)
Rational Unified
Process (modified)
Open Unified Process
V-Modell XT (Standard)
V-Model XT (modified)
V-Modell 97
eXtreme Programming
Feature Driven
Development (FDD)
Fig. 1: Combination of development approaches (from [21]). The left part shows the use of ap-
proaches per respondent revealing two major clusters, and the right part illustrates the combina-
tion of the different approaches within these clusters.
overall management framework in which Scrum is embedded (this situation is often
referred to as the Water-Scrum-Fall [40])7.
In a nutshell, although we lack detailed information and raw data about the actual
combination of the different approaches, we find indication to a mixed application of
traditional and agile approaches. Based on our findings from [18] and available num-
bers from the other studies, we hypothesize that companies, especially large ones, use
a traditional process as reference model to define the basic management procedures
and interfaces to the other company- and business processes, while particular project
teams utilize a pool of (agile) methods and practices to run development projects. Yet,
confirmation of this hypothesis remains subject to future work.
7Although [27] supports this assumption, this study was excluded from the quantitative analysis,
as the authors rejected papers not explicitly dealing with agile methods, and summarized all
non-agile approaches under “custom or other”. We thus have insufficient information about
what processes are eventually meant and how those could affect our study results.
© Springer. PREPRINT. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings.
34 34
IOSE-W 3ProcSurvey
Traditional Agile
32,7% 36,6%
IOSE-W 3ProcSurvey
Traditional Agile
Fig. 2: In-/decrease in use of different process classes (based on the IOSE-W2study from 2006
and the 3ProcSurvey from 2013). The left part shows the absolute numbers and shows the de-
creased mentions regarding traditional processes and the “rise” of agile methods. However, the
right part shows that both kinds of processes are increasingly used (in combination).
4.4 RQ3: Are there Patterns and Trends Observable?
This research question aims at identifying trends in process use. Since software pro-
cesses are proposed for decades, the question for the relevance occurs. Are approaches
proposed in the mid 1990’s still relevant? Or are those approaches dispensable, as they
are increasingly replaced by agile methods. Again, due to the absence of longitudinal
studies that monitor process use over time, we hardly can provide reliable conclusions.
Only for Germany there are three independently conducted studies providing numbers
for a period of seven years. In [21], the results from [3,11, 18] were analyzed for trends
in process use. The analysis revealed that although agile methods gained popularity, at
the same time, traditional processes were increasingly used as well (Figure 2).
Extending this discussion to the other papers analyzed in the present study, this pic-
ture is consistent with the finding that companies usually use mixed-method approaches
to organize and operate their projects. For example, [18] showed that the RUP is—if at
all—only used in tailored variants. That is, the standard RUP is not used anymore.
Comparing this finding to the USA-based study [39], RUP accounts for only 5.9% of
all mentions (whereas we don’t have information if this number refers to the standard
RUP, tailored variants, or both). Nevertheless, we see “dinosaurs” like the Waterfall
model still in use (because of its simplicity regarding general project organization). Fur-
thermore, the combination of different approaches does not only happen between tradi-
tional and agile approaches. As, for example, the VersionOne survey [38] shows, even
agile methods are used in combination (an in-depth analysis, also consistent with [17],
shows that the building blocks used for combination are the individual practices). The
VersionOne data shows Scrum champion the other agile methods (56% in 2014), how-
ever, the data also shows a stable, yet slightly increasing, number of mixed approaches.
Moreover and in line with Diebold et al. [7], we further hypothesize that even the ma-
jority of the Scrum users does not apply Scrum by the letter rather than in a customized
© Springer. PREPRINT. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings.
Therefore, we conclude that hybrid approaches that include traditional and agile
approaches shape the today’s “standard process ecosystem.” The “traditional part” is
given by a (national) standard, or by a domain- or context-specific standard, e.g., norms
like ISO/IEC 26262. The remaining part is given by a context-specific combination
of different agile methods or practices. And here, all studies show one trend: Today,
Scrum, Kanban, and XP (practices) can be considered the dominating approaches.
5 Study Summary & Discussion
In this section, we summarize and discuss our findings. Furthermore, we review the
study with regards to the threats of validity.
Summary & Discussion Although only five papers from the result set provided suffi-
cient information to analyze the general use of software process models over the years
(cf. Table 2), the remaining papers provide useful insights as well. Aggregating all data
found, we can draw the following picture: in practice, we find hybrid approaches to be
the favored solutions. In particular, [7, 38] and [17] showed that even the agile methods
are used in combination, and our previously conducted study [18] as well as further
independently conducted research [39] provided extra evidence that agile and tradi-
tional approaches are used in a mixed-method approach. Among all reviewed studies,
we could find a clear trend toward adopting Scrum to the organization’s software devel-
opment [18, 38, 39]. However, we also found some indication that Scrum is often used
in combination with further methods [17, 38], and could provide a combination matrix
(Figure 1, cf. [21]). Other than expected, Lean Development and DevOps (so far) play
no role. However, the current data does not allow for any conclusions thus requiring
further research to integrate those new emerging movements into the analysis.
Several industry-related studies showed a certain reluctance of the management to
buy-in agile methods [26,37], which we use as basis to assume that the use of hybrid ap-
proaches is, inter alia, caused by this reluctance. For example, Tripp and Armstrong [37]
analyzed the motivation to adopt agile methods and found some relevant drivers. Fur-
thermore, they analyzed the perceived impact of 12 selected project management and
development-related practices finding those practices negatively correlating with (gen-
eral) project management, but positively correlating with software development (factor:
software quality). Murphy et al. [26] analyzed the use and perception of agile software
development at Microsoft. Their major findings include that Scrum is considered the
most favorite development approach. However, the study’s respondents also considered
the suitability of agile methods for large projects critical (substantial communication
effort and overhead, reluctance of the management to accept the agile approach). On
the other hand, Lagerberg et al. [22], and Solinski and Petersen [36] also found positive
impacts of adopting agile practices in large companies, e.g., improved knowledge shar-
ing, increased project visibility, and reduced need for other coordination instruments.
Melo et al. [5] conducted a study in Brazil in which they analyzed the evolution of agile
software development from the perspectives of education, research, and application in
industry and found that the management-related agile practices are either adopted to
a large extent or (completely) rejected, while the development-related practices made
their way into the projects.
© Springer. PREPRINT. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings.
Therefore, we assume that managers prefer the structured planning-oriented way of
working, which they need to perform estimation, planning, and controlling tasks, while
developers prefer the freedom that agile methods offer the teams. Furthermore, we con-
sider the often missing organizational interface of agile methods (e.g., procurement and
contracting procedures, sub-contractor management, and enterprise resource planning)
another reason for management’s reluctance toward agile methods. Agile methods usu-
ally focus on the system under development, management of features or requirements,
development and (code-related) quality assurance practices, and the management of
change. Organizational interfaces to the company level are, often provided by the tradi-
tional approaches.
Hence, integrating traditional and agile approaches into a mixed-method or hybrid
approach offers some benefits: managers get their “safe” environment and developers
get their freedom and slim development methods. Our study reveals some indication
[17, 38] that project teams increasingly compose a “best of” from different practices—
quite often on a per-project basis [18]. That is, practices became the building blocks
of assembling company- or project-specific software processes. However, information
about particular practices used in combination, their linking to the hosting organization,
or the exact way of performing those combinations is—if at all—barely available, and
reveals a significant gap in the current publication body.
Threats to Validity In the following, we critically discuss our study results regarding
these threats. The major threat emerges from the low number of papers selected for the
study, and the often low data quality (either due to blurry/reduced data presentation or
due to absence of raw data) of the studies analyzed. Therefore, we could present precise
data from only one region (Germany), but had to partially infer and normalize data from
other studies. Furthermore, since we rely on independently conducted studies, we have
no control about the respective data quality. We refer to studies that were conducted
using surveys and interviews, i.e., these studies may introduce extra threats to validity
by relying on subjective and potentially non-generalizable data. This situation results
in an assumption-based line of argumentation that we, however, backed-up by referring
to further independently conducted studies, and by performing data analysis and inter-
pretation independently in two teams of researchers. Although we found similar trends,
due to the eventually low number of analyzed studies, we therefore have to consider our
findings—especially their generalizability—critical.
Another threat to validity is the study selection as such. Due to the blurry termi-
nology that suffers from heterogeneity and massive overloading, after several test runs,
we limited the automatic search to “method” and related terms. Yet, the term “develop-
ment method” has to be considered of insufficient precision to address the entire field.
Therefore, even as this term is common in the researched field, limiting the search this
way introduces a threat that we addressed by manually conducted search and selection
procedures. However, according to Badampudi et al. [1], who found the efficiency of
snowballing comparable to automatic searches, we consider our result set suitable for
this study. Still, the finally selected result set needs to be considered with care, as we
have no knowledge about further publications not triggered by the search and selection
procedures applied in this study, and non-scientific studies, e.g., blog posts and forum
© Springer. PREPRINT. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings.
6 Conclusion
In this paper, we studied literature for the use of different software development ap-
proaches over time. For this, we conducted a literature study in which we applied dif-
ferent instruments from the SLR process to obtain relevant publications. From the dif-
ferent search and selection procedures, we selected 22 publications for inspection and,
furthermore, collected quantitative data from five papers from out of this set.
Our findings show a diverse picture in which a variety of different development ap-
proaches is used that range from “old-fashioned” traditional approaches to agile meth-
ods. Furthermore, our findings show different approaches usually used in combination,
i.e., mixed- or hybrid approaches represent the common model of use, and the com-
bination includes “traditional-agile” as well as “agile-agile” approaches. Among the
different combinations, Scrum, the classic Waterfall model, and V-shaped processes ac-
count for the majority of the mentions. Since we can rely our findings on a limited data
basis only, we also extended our investigation to further independently conducted stud-
ies from the field of agile methods. In particular, we reviewed the VersionOne survey
data and determined trends from the available data. These data confirm our findings that
Scrum became the most popular agile method, and that agile methods are adapted and
combined with other processes (traditional and agile) [7, 38].
From our findings, we conclude that the Water-Scrum-Fall or similar combinations
became reality. We discussed possible reasons and argue that the main driver for this
kind of integration is the expectations of different stakeholder groups toward the “op-
timal” software development approach. Project managers require some stability to per-
form the usual project management tasks, such as estimation, planning, or controlling.
Furthermore, project managers also have the responsibility to align projects with the
respective company strategy, i.e., projects must interface further (business) processes
like human resource management, sales, contracting, and so forth. Since agile methods
usually address only system- or development-related tasks, such interfaces are missing
often. Hence, traditional approaches are used to provide a basic structure and a frame-
work for project organization and to provide interfaces to the respective company. Then
again, developers ask for approaches that—on the one hand—support the development
related tasks, but—on the other hand—provide extensive freedom to select the best
practices for the respective situation. That is, the hybrid method in which traditional
and agile approaches are combined seemingly provides the “win-win” situation.
However, our findings give only indication. Although we could find some trend,
still, the limited data does not close the gap that we still miss a clear understanding
of how to perform such integration in a structured manner. In particular, the available
data does not allow for crafting detailed combination patterns, and the data does only
partially allow for investigating the rational behind the approaches’ combination, as for
instance in [18] we found project managers making the decision based on experiences
and preferences on a per-project base, but couldn’t confirm nor generalize this finding
by the other studies, as the required data was not available. Nonetheless, such an un-
derstanding is of growing importance, as current software development does not only
include fast development and release cycles, but increasingly addresses cyber-physical
systems that have high requirements, e.g., regarding safety and security. Thus, we must
pay special attention to the respective norms and standards that are of similar com-
© Springer. PREPRINT. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings.
plexity as traditional software process models. Therefore, discovering approaches to
systematically, efficiently, and reliably integrating agile and traditional software devel-
opment approaches, might also pave the way toward agile software development in
critical domains8.
Future Work Although based on limited data, our findings have some impact and show
some future research directions. The presented study reveals a gap in literature awaiting
more work—we ourselves were not able to fully answer all our research questions to
full extent. Therefore, our study is a call for action to conduct further research. For this
purpose, our study provides initial findings and an initial combination matrix showing
how different approaches are used in combination. Furthermore, our findings lay the
foundation for further empirical research to gain better insights into the practical appli-
cation and relevance of certain development approaches. Since we found some confir-
mation of the Water-Scrum-Fall combination pattern, we need to pay more attention to
this customization setting that will, eventually, also affect the field of software process
improvement (SPI). In [20], we could identify SPI in the context of small-to-medium
enterprises and agile software development as “hot topics” (also supported by the more
practitioner-oriented surveys on agile methods [17,38]). For this, a better understanding
about the different strategies to assemble hybrid approaches for software development
promises some benefits, e.g., better addressing and balancing stakeholder requirements,
efficient process design, and so forth.
In general the results of this exploratory study show that there is less material pub-
lished on the combination of software development approaches than expected. There-
fore, we would like to motivate the process community to start thinking of how to
address this issue, to collect more knowledge, and to build a database that allows for
theory development as well as for supporting practitioners in efficiently developing hy-
brid approaches best fitting their actual requirements. In addition, further data sources
and studies have to be collected and analyzed to round out the big picture of process
use and to collect more evidence.
This research was partially carried out and supported by a Software Campus project
(BMBF 01IS12053) funded by the German Ministry of Education and Research.
1. D. Badampudi, C. Wohlin, and K. Petersen. Experiences from using snowballing and
database searches in systematic literature studies. In International Conference on Evalu-
ation and Assessment in Software Engineering, pages 17:1–17:10. ACM, 2015.
8This need is also supported by the just recently published GULP study (
RciNpy) in which authors come to the conclusion that projects will be increasingly operated
following a hybrid approach in future (population: 114 IT experts, mainly freelancers and
project management consultants; study region: Germany).
© Springer. PREPRINT. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings.
2. L. Beck and T. Perkins. A survey of software engineering practice: Tools, methods, and
results. IEEE Transactions on Software Engineering, SE-9(5):541–561, 1983.
3. R. Buscherm¨
ohle, H. Eekhoff, and B. Josko. SUCCess and failurE of hard- and Software
projectS (SUCCESS). BIS-Verlag der Carl von Ossietzky Universit¨
at Oldenburg, 2006.
4. D. D. de Carvalho, L. F. Chagas, A. M. Lima, and C. A. L. Reis. Software process lines: A
systematic literature review. In Software Process Improvement and Capability Determina-
tion, volume 477 of CCIS, pages 118–130. Springer, 2014.
5. C. de O. Melo, V. Santos, E. Katayama, H. Corbucci, R. Prikladnicki, A. Goldman, and
F. Kon. The evolution of agile software development in brazil. Journal of the Brazilian
Computer Society, 19(4):523–552, 2013.
6. P. Diebold and M. Dahlem. Agile practices in practice: A mapping study. In International
Conference on Evaluation and Assessment in Software Engineering, EASE ’14, pages 30:1–
30:10, New York, NY, USA, 2014. ACM.
7. P. Diebold, J.-P. Ostberg, S. Wagner, and U. Zendler. What do practitioners vary in using
scrum? In International Conference XP, pages 40–51. Springer, 2015.
8. T. Dingsøyr, S. Nerur, V. Balijepally, and N. B. Moe. A decade of agile methodologies: To-
wards explaining agile software development. Journal of Systems and Software, 85(6):1213–
1221, 2012. Special Issue: Agile Development.
9. T. Dyb˚
a and T. Dingsøyr. Empirical studies of agile software development: A systematic
review. Information and Software Technology, 50(9–10):833 – 859, 2008.
10. B. Fitzgerald. The use of systems development methodologies in practice: a field study.
Information Systems Journal, 7(3):201–212, 1997.
11. M. Fritzsche and P. Keil. Kategorisierung etablierter vorgehensmodelle und ihre verbreitung
in der deutschen software-industrie. Research Report (in German) TUM-I0717, Technische
at M¨
unchen, 2007.
12. E. Georgiadou. Software process and product improvement: A historical perspective. Cy-
bernetics and Systems Analysis, 39(1):125–142, 2003.
13. M. A. Jackson. A system development method. In Tools and notions for program construc-
tion: An advanced course, pages 1–25. Cambridge University Press, 1982.
14. C. Jones. Variations in software development practices. IEEE Software, 20(6):22–27, 2003.
15. M. Khurana, Z. He, I. Court, M. Ross, G. Staples, and D. Wilson. Software quality practices
– an empirical study. Software Quality Journal, 5(2):75–85, 1996.
16. B. Kitchenham and S. Charters. Guidelines for performing systematic literature reviews in
software engineering. Technical Report EBSE-2007-01, Keele University, 2007.
17. A. Komus, M. Kuberg, C. Atinc, L. Franner, F. Friedrich, T. Lang, A. Makarova, D. Reimer,
and J. Pabst. Status quo agile 2014, 2014.
18. M. Kuhrmann and D. M. Fern´
andez. Systematic software development: A state of the prac-
tice report from germany. In International Conference on Global Software Engineering.
IEEE, 2015.
19. M. Kuhrmann, D. M. Fern´
andez, and M. Tiessler. A mapping study on the feasibility of
method engineering. Journal of Software: Evolution and Process, 26(12):1053–1073, 2014.
20. M. Kuhrmann, C. Konopka, P. Nellemann, P. Diebold, and J. M¨
unch. Software process
improvement: Where is the evidence? In International Conference on Software and Systems
Process. ACM, 2015.
21. M. Kuhrmann and O. Linssen. Vorgehensmodelle in deutschland: Nutzung von 2006-2013
im ¨
uberblick. MAW-Rundbrief, 39:32–47, 2015.
22. L. Lagerberg, T. Skude, P. Emanuelsson, K. Sandahl, and D. Stahl. The impact of agile
principles and practices on large-scale software development projects: A multiple-case study
of two projects at ericsson. In International Symposium on Empirical Software Engineering
and Measurement, pages 348–356. ACM, 2013.
© Springer. PREPRINT. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings.
23. G. Lee and W. Xia. Toward agile: An integrated analysis of quantitative and qualitative field
data. MIS Quarterly, 34(1):87–114, 2010.
24. T. Mart´
ınez-Ruiz, F. Garc´
ıa, M. Piattini, and J. M¨
unch. Modelling software process variabil-
ity: an empirical study. IET Software, 5(2):172–187, 2011.
25. T. Mart´
ınez-Ruiz, J. M¨
unch, and M. Piattini. Requirements and constructors for tailoring
software processes: A systematic literature rewview. Software Quality Journal, 20(1):229–
260, 2010.
26. B. Murphy, C. Bird, T. Zimmermann, L. Williams, N. Nagappan, and A. Begel. Have agile
techniques been the silver bullet for software development at microsoft. In International
Symposium on Empirical Software Engineering and Measurement. ACM/IEEE, 2013.
27. E. Papatheocharous and A. S. Andreou. Empirical evidence and state of practice of software
agile teams. Journal of Software: Evolution and Process, 26(9):855–866, 2014.
28. K. Petersen and C. Wohlin. A comparison of issues and advantages in agile and incremental
development between state of the art and an industrial case. Journal of Systems and Software,
82(9):1479–1490, 2009.
29. M. Rahim, A. H. Seyal, and M. A. Rahman. Use of software systems development methods
an empirical study in brunei darussalam. Information and Software Technology, 39(14–
15):949 – 963, 1998.
30. D. Reifer. How good are agile methods? IEEE Software, 19(4):16–18, 2002.
31. D. Reifer. Is the software engineering state of the practice getting closer to the of the art?
Software, IEEE, 20(6):78–83, 2003.
32. G. B. Rose. SSADM – the open methodology. In IEE Colloquium on an Introduction to
Software Design Methodologies, number Ref. No: 1991/181, pages 6/1–6/5. IET, Dec 1991.
33. O. Salo and P. Abrahamsson. Agile methods in european embedded software development
organisations: a survey on the actual use and usefulness of extreme programming and scrum.
IET Software, 2(1):58–64, 2008.
34. M. Senapathi and A. Srinivasan. Sustained agile usage: A systematic literature review. In In-
ternational Conference on Evaluation and Assessment in Software Engineering, pages 119–
124. ACM, 2013.
35. M. Senapathi and A. Srinivasan. An empirical investigation of the factors affecting agile
usage. In International Conference on Evaluation and Assessment in Software Engineering,
pages 1–10. ACM, 2014.
36. A. Solinski and K. Petersen. Prioritizing agile benefits and limitations in relation to practice
usage. Software Quality Journal, pages 1–36, 2014.
37. J. Tripp and D. Armstrong. Exploring the relationship between organizational adoption mo-
tives and the tailoring of agile methods. In Hawaii International Conference on System
Sciences (HICSS), pages 4799–4806, 2014.
38. VersionOne. State of agile survey. Available from:
agile-resources/more- resources/blogs/, 2006-2014.
39. L. Vijayasarathy and C. Butler. Choice of software development methodologies - do project,
team and organizational characteristics matter? IEEE Software, (99):1ff., 2015.
40. D. West. Water-Scrum-Fall is the reality of agile for most organizations today. Technical
report, Forrester, 2011.
© Springer. PREPRINT. This is the author's version of the work. It is posted here by permission of Springer for your personal use.
Not for redistribution. The definitive version was published in the conference/workshop proceedings.
... Recent studies show that companies often do not use only agile methods but rather a mix of agile and plan-based methods in order to combine the benefits of both approaches. [6][7][8][9] Approaches where different methods are combined are called hybrid development approaches (short: hybrid approaches) and have become state-of-the-practice. 10 Kuhrmann et al. 8, p. 2 define hybrid approaches as Conflict between up-front and continuous requirements engineering 51,52,54,63,68 Conflict between up-front and continuous architecture and design 42,48,67,71,72 Conflict between central decision making and self-organized teams 46,57,63,66,68 Difficulties by a separated testing phase 49,52,[73][74][75] Tension between the business and the development unit 51,57,68 Conflict between long-and short-term planning 52,57,75 Conflict between explicit documentation and tacit knowledge 50,68,75 ...
... Although hybrid approaches were discussed early on in the research community, there was no research about how far hybrid approaches are spread in the industry and which methods were used. To fill this gap, Theocharis et al. 6 performed a systematic literature review to examine which development approaches were used and combined in practice. The research questions of this publication are shown in Table 1 24 papers that the waterfall model and Scrum are among the most used methods and that they are often combined. ...
... With the increasing detection of the use of APH approaches in research, the question about the motives behind APH approaches raised. 6,8 The question is if companies have legitimate reasons to combine agile and plan-based methods or if they are stuck in a transition toward agility and if APH approaches are even feasible. 19,23,50,71 By the results from our first research question, we have a better understanding of what companies want to reach with APH approaches. ...
Full-text available
The number of companies that use agile methods increases steadily. However, these companies often do not implement a pure agile approach but combine agile and plan-based methods to so-called hybrid development approaches. However, the development of these approaches is rather difficult for the companies, since agile and plan-based approaches often follow opposite concepts. To benefit from agile and plan-based approaches at the same time, the companies have to identify and address the conflicts between agile and plan-based methods. The conflicts depend on the goals that are pursued with the implementation of agile and plan-based methods. However, there is no overview of the exact goals that are pursued in hybrid approaches and which challenges and conflicts arise with them. Therefore, we conducted a systematic mapping study to gather and analyze the goals and challenges in hybrid development approaches. The mapping study is focused on literature that presents the actual needs and goals of companies and projects. Based on our results, we present the influence factors that cause conflicts in hybrid approaches and discuss how these conflicts can be addressed.
... This method shows how combining classic and agile methodologies can lead to a win-win situation (Theocharis et al.,2016). The management, which wants a more fixed and structured method to perform their tasks, will be covered, and the development team, which needs a flexible and adaptive approach to complete its functions, will also be covered. ...
... The fall part will be controlling the frequency and quality of the product releases. The hypothesis created by D. West has been tested and researched by others such as in (Theocharis et al.,2016) and (Küpper et al.,2018). This claim is also tested and proved by a study conducted by Kuhrmann et al. (2017), where the results of the research undertaken show that nearly half of the participants use scrum, and near about one-third uses the waterfall/phase model. ...
Conference Paper
Full-text available
Digitalization move has motivated companies to adopt software for their business processes. This led to increase projects' complexity. Project management process plays a significant role in reaching a successful completion of IT-projects. It has been seen that management methodologies like waterfall and scrum are still not sufficient for every project. When it comes to complex projects where we need planning on the front part and agility on the developing part, a pure waterfall or agile is not sufficient. Thus, this study focuses on evaluating existing hybrid Methods as a useful alternative. A systematic literature review has been followed to select out the appropriate existing methodologies. Eleven different parameters have been selected for the evaluation on different measuring levels. It has been concluded based on a morphological analysis that a hybrid project management methodology is a good and efficient alternative.
... 20,21 The fact that a significant proportion of practitioners have a background in physics or mathematics rather than computer science can also be a source for reluctance about the introduction of SE practices such as higher abstraction level artifacts or the adoption of novel development/testing processes. 69 Secondly, the QaaS predictable future combined with the low abstraction level of artifacts can derive in low portability of models and code and solid dependency of the hardware providers. ...
Quantum computing is expected to exponentially outperform classic computing on a broad set of problems, including encryption, machine learning, and simulations. It has an impact yet to explore on all software lifecycle's processes and techniques. Testing quantum software raises a significant number of challenges due to the unique properties of quantum physics—such as superposition and entanglementand the stochastic behavior of quantum systems. It is, therefore, an open research issue. In this work, we offer a systematic mapping study of quantum software testing engineering, presenting a comprehensive view of the current state of the art. The main identified trends in testing techniques are (1) the statistic approaches based on repeated measurements and (2) the use of Hoare-like logics to reason about software correctness. Another relevant line of research is reversible circuit testing, which is partially applicable to quantum software unitary testing. Finally, we have observed a flourishing of secondary studies and frameworks supporting testing processes from 2018 onwards.
... This helped to determine a balanced method and, eventually, to achieve a hybrid sweet spot [35]. These balanced combinations have become reality as several studies show [36]- [40]. Traditional and agile approaches coexist and form the majority of practically used hybrid development methods [8], [41], [42]. ...
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.
... However, as a small step towards a future change in the business model, we introduced a method to resolve the methodological problems of the current stock assessment project. Not only technical but also cultural aspects are a major problem in the transformation of workflows (Pechau, 2011), even in the software industry (Kusters et al., 2017;Theocharis, 2015;Kuhrmann et al., 2017;Theobald, 2018;Clear, 2003). Build-based documentation requires a cultural shift for projects away from using a GUI word processor, and version-controlling and issue-tracking systems show a steep learning curve. ...
Considering that stock assessment requires iterative work including exploratory calculations and discussion, efficiency in completing projects is the key to a successful contribution to stock management. However, if the production speed of each process of the project is inconsistent, a faster process may be worse than a slower process because a large amount of information produced by a faster process induces human error. To coordinate the production speed of each process, we applied software development methodology to the whole assessment project, including small important tasks such as scenario selection, debugging, and yearly updates. First, we established a continuously integrated (CI) document system that monitors project files and triggers report generation when they are updated. The system is composed of four cloud services: a code hosting service, a cloud computing service, cloud storage, and a website hosting service. Because of the CI document system, all the following iterative work was reflected in the report without creating any unused output. The workflow benefited not only from the collaboration but also from the maintainability of the project because work progress and the discussion remained visible for all collaborators. We discuss the effectiveness of a workflow by Lean manufacturing that allows us to focus on the essential problem of the assessment project.
In the face of increasingly agile product development, new challenges arise for assembly planning due to growing complexity. Within this paper, we show that the complexity-dependent combination of agile methods and traditionally plan-driven assembly planning procedures holds great potential for mastering planning complexity. Thus, a methodology towards hybrid assembly planning is elucidated with a focus on selecting dominant planning methods for specific planning scopes within this paper. Based on a detailed model of assembly planning as a system, the complexity requirements of different planning modules are determined. Therefore, an integrative complexity measure is developed to quantitatively operationalise complexity in a quasistatic-structural and a dynamic-functional complexity dimension. In order to identify dominant planning methods, the complexity potentials of agile and plan-driven methods are examined in an Analytic Hierarchy Process expert study with 22 participants. Within a decision model, dominant planning methods are selected for specific planning modules by matching the quantified complexity requirements with the complexity potentials of agile and plan-driven methods. Based on the systematic method selection, dominant planning methods for specific planning scopes can be tailored into a project-specific hybrid process framework. The approach to hybrid assembly planning enables optimised planning results through the improved mastery of complexity.
There is currently the growing interest of business in the problem of shorten the total length of the construction projectConstruction project life cycle. At the same time, the number of dispersed teamsTeams increased. The level of technology development, including BIM, allows AEC teamsTeams to collaborate effectively. Due to environment turbulence and uncertainty, developers (customers) need to have an opportunity to react on market tendencies during the projectProject execution and implement changes in the projectProject. The group of adaptive PM approaches (agileAgile, hybrid) may help to solve this problem. The paper presents the comparison of typical construction projectConstruction project design phase and new product development. The system hybrid project managementProject management approach with mix of agileAgile and waterfall project managementProject management is proposed.
Full-text available
This paper aims to review internet banking adoption for customer satisfaction and success factors that influence customer who utilized internet banking in an 5 years period of between 2013 until 2018. This paper discusses the measurement or framework model of internet banking to fulfill customer satisfaction when they use internet banking. It also reviews the problems of previous researches, their objectives, methodology, related work, advantages and disadvantages, existing conceptual framework/model, results and discussion, contribution and future work.
Agile methods appeared in the 90s. Seen as a performance lever in the software industry, they have become a source of inspiration for a growing number of organizations. If the literature has shown a growing interest on questions of performance, little has been studied about the subjective experience of the actors practicing them. Our research aims at filling this gap while studying the category of actors playing the role of Product Owners who are supposed to be the voice of the outside world towards the agile team. This role puts the actors on the borders of possibly contradictory environments and the success of agile adoption in organizations often depends on them. The study we carried out in the Digital Factory of an industrial company allows to identify under what conditions actors can effectively endorse this role, thanks to the analysis of their psychosocial dynamics.
Full-text available
The objective of this report is to propose comprehensive guidelines for systematic literature reviews appropriate for software engineering researchers, including PhD students. A systematic literature review is a means of evaluating and interpreting all available research relevant to a particular research question, topic area, or phenomenon of interest. Systematic reviews aim to present a fair evaluation of a research topic by using a trustworthy, rigorous, and auditable methodology. The guidelines presented in this report were derived from three existing guidelines used by medical researchers, two books produced by researchers with social science backgrounds and discussions with researchers from other disciplines who are involved in evidence-based practice. The guidelines have been adapted to reflect the specific problems of software engineering research. The guidelines cover three phases of a systematic literature review: planning the review, conducting the review and reporting the review. They provide a relatively high level description. They do not consider the impact of the research questions on the review procedures, nor do they specify in detail the mechanisms needed to perform meta-analysis.
Conference Paper
Full-text available
Background: Systematic literature studies are commonly used in software engineering. There are two main ways of conducting the searches for these type of studies; they are snowballing and database searches. In snowballing, the reference list (backward snowballing - BSB) and citations (forward snowballing - FSB) of relevant papers are reviewed to identify new papers whereas in a database search, different databases are searched using predefined search strings to identify new papers. Objective: Snowballing has not been in use as extensively as database search. Hence it is important to evaluate its efficiency and reliability when being used as a search strategy in literature studies. Moreover, it is important to compare it to database searches. Method: In this paper, we applied snowballing in a literature study, and reflected on the outcome. We also compared database search with backward and forward snowballing. Database search and snowballing were conducted independently by different researchers. The searches of our literature study were compared with respect to the efficiency and reliability of the findings. Results: Out of the total number of papers found, snowballing identified 83% of the papers in comparison to 46% of the papers for the database search. Snowballing failed to identify a few relevant papers, which potentially could have been addressed by identifying a more comprehensive start set. Conclusion: The efficiency of snowballing is comparable to database search. It can potentially be more reliable than a database search however, the reliability is highly dependent on the creation of a suitable start set.
Conference Paper
Full-text available
Software process improvement (SPI) is around for decades: frameworks are proposed, success factors are studied, and experiences have been reported. However, the sheer mass of concepts, approaches, and standards published over the years overwhelms practitioners as well as researchers. What is out there? Are there new emerging approaches? What are open issues? Still, we struggle to answer the question for what is the current state of SPI and related research? In this paper, we present initial results from a systematic mapping study to shed light on the field of SPI and to draw conclusions for future research directions. An analysis of 635 publications draws a big picture of SPI-related research of the past 25 years. Our study shows a high number of solution proposals, experience reports, and secondary studies, but only few theories. In particular, standard SPI models like CMMI and ISO/IEC~15504 are analyzed, enhanced, and evaluated for applicability, whereas these standards are critically discussed from the perspective of SPI in small-to-medium-sized companies, which leads to new specialized frameworks. Furthermore, we find a growing interest in success factors to aid companies in conducting SPI.
Full-text available
This dataset contains the full raw data for the paper "Software Process Improvement: Where is the Evidence?", cf.
Full-text available
In der Praxis finden viele unterschiedliche Vorgehensmodelle Anwendung, was oft in Problemen resultiert, da sich z.B. Philosophie, Projektstruktur, Terminologie oder Rollenmodelle und Aufgabenzuordnung unterscheiden. Ziel dieses Beitrags ist es, eine Karte zu zeichnen, in welcher die in Deutschland aktuell verwendeten Vorgehensmodelle enthalten sind. Dieser Beitrag präsentiert die Ergebnisse einer Studie aus dem Jahr 2006 und stellt diesen die Ergebnisse gegen-über, welche als Teil des 3ProcSurvey im Jahr 2013 ermittelt wurden. Wir stellen dar, welche Vorgehensmodelle aktuell im Einsatz sind und wie sich die Anwendung von Vorgehensmodellen über die Zeit entwickelt hat. Die Studie hat gezeigt, dass eine Vielzahl von Vorgehensmodellen im Einsatz ist. Obwohl ein Trend weg von großen Standards zu beobachten ist, werden sowohl agile wie auch klassische Ansätze angewendet. Die Studie zeigt auch, dass die Auswahl und das Tailoring von Vorgehensmodellen in der Regel nur wenig systematisch und individuell durch Projektleiter erfolgen.
Conference Paper
Full-text available
The speed of innovation and the global allocation of resources to accelerate development or to reduce cost put pressure on the software industry. In the global competition, especially so-called high-price countries have to present arguments why the higher development cost is justified and what makes these countries an attractive host for software companies. Often, high-quality engineering and excellent quality of products, e.g., machinery and equipment, are mentioned. Yet, the question is: Can such arguments be also found for the software industry? We aim at investigating the degree of professionalism and systematization of software development to draw a map of strengths and weaknesses. To this end, we conducted as a first step an exploratory survey in Germany, presented in this paper. In this survey, we focused on the perceived importance of the two general software engineering process areas project- and quality management and their implementation in practice. So far, our results suggest that the necessity for a systematic software development is well recognized, while software development still follows an ad-hoc rather than a systematized style. Our results provide initial findings, which we finally use to elaborate a set of working hypotheses. Those hypotheses allow to steer the adaptation of our instrument in the future to eventually facilitate replications toward a more comprehensive theory on systematic globally distributed software development in practice.
Conference Paper
Full-text available
Background: Agile software development has become a popular way of developing software. Scrum is the most frequently used agile framework, but it is often reported to be adapted in practice. Objective: Thus, we aim to understand how Scrum is adapted in different contexts and what are the reasons for these changes. Method: Using a structured interview guideline, we interviewed ten German companies about their concrete usage of Scrum and analysed the results qualitatively. Results: All companies vary Scrum in some way. The least variations are in the Sprint length, events, team size and requirements engineering. Many users varied the roles, effort estimations and quality assurance. Conclusions: Many variations constitute a substantial deviation from Scrum as initially proposed. For some of these variations, there are good reasons. Sometimes, however, the variations are a result of a previous non-agile, hierarchical organisation.
Concern about the quality of software is widespread. Reliable data about current practice are hard to get as no one likes to admit that they are producing poor software. In a recent survey, Wilson has taken an approach to obtaining data about the practice of software quality assurance among companies in Australia. The same technique has been used here to investigate practice among companies in Europe and America. The survey aims to investigate quality systems used by the organizations, and the application of these systems by software developers. In this paper they are compared with the Australian experience and the results of the survey shown. The company's demographic data and overall response pattern from this survey are compared with Wilson's. Patterns in software quality assurance programs of organizations are suggested by comparing the management's perspective with that of the developers. The most popular software development techniques identified by the developers are prioritized in the order of their popularity by using a weighting scheme and their implications are discussed.
Conference Paper
Software Process Line (SPrL) has been claimed as a suitable paradigm for tailoring and reuse of software processes. However, despite its increasing importance, there is still a lack of research that systematically characterizes and analyzes the state of the art of SPrL approaches, in particular focusing on how such a paradigm has been used to improve software processes. This paper presents the method followed to perform a systematic literature review on SPrL in order to investigate the state of the art of this area, as well as the results of this review focusing especially on how variability is represented. We found 40 primary studies about this topic published from 1996 to 2013. Our results indicate that the software engineering community has increasingly invested effort in this area. However, it is still considered an immature area with many open issues such as the lack of the modeling of well-known process standards and models using SPrL concepts and the lack of empirical evaluations.
In recent years, there has been significant shift from rigid development (RD) toward agile. However, it has also been spotted that agile methodologies are hardly ever followed in their pure form. Hybrid processes as combinations of RD and agile practices emerge. In addition, agile adoption has been reported to result in both benefits and limitations. This exploratory study (a) identifies development models based on RD and agile practice usage by practitioners; (b) identifies agile practice adoption scenarios based on eliciting practice usage over time; (c) prioritizes agile benefits and limitations in relation to (a) and (b). Practitioners provided answers through a questionnaire. The development models are determined using hierarchical cluster analysis. The use of practices over time is captured through an interactive board with practices and time indication sliders. This study uses the extended hierarchical voting analysis framework to investigate benefit and limitation prioritization. Four types of development models and six adoption scenarios have been identified. Overall, 45 practitioners participated in the prioritization study. A common benefit among all models and adoption patterns is knowledge and learning, while high requirements on professional skills were perceived as the main limitation. Furthermore, significant variances in terms of benefits and limitations have been observed between models and adoption patterns. The most significant internal benefit categories from adopting agile are knowledge and learning, employee satisfaction, social skill development, and feedback and confidence. Professional skill-specific demands, scalability, and lack of suitability for specific product domains are the main limitations of agile practice usage. Having a balanced agile process allows to achieve a high number of benefits. With respect to adoption, a big bang transition from RD to agile leads to poor quality in comparison with the alternatives.