Description of Constituent Characteristics of Agile Development
Processes for Technical Systems
Günther Schuh
1*
, Stephan Schröder
2
, Florian Vogt
2
,
and Michael Franz
2
1
Laboratory for Machine Tools and Production Engineering (WZL) RWTH Aachen University Aachen, Germany
2
Department of Technology Management Fraunhofer-Institute for Production Technology IPT Aachen, Germany
michael.franz@ipt.fraunhofer.de
Keywords: agile product development, supplier integration; hardware development.
Abstract: The transformation of the market environment with an increasing demand for customer-specific products
and shortened product life- and innovation cycles confronts manufacturing companies with new challenges.
In order to meet these challenges, iterative and flexible agile product development processes are
increasingly being implemented. These tend to accelerate product development and achieve a higher degree
of fulfilment of customer requirements. At the same time the increasing complexity of technical products
and the decreasing depth of added value of manufacturing companies due to a major focus on core
competencies have led to the fact that the integration of suppliers in product development has become a
critical success factor. The increasing use of agile development processes has resulted in new requirements
for the design of supplier integration, as there is a divergence from the established plan-oriented approaches.
The aim of the paper is to concretize this divergence by identifying constituent characteristics of agile
development processes for technical systems.
1 INTRODUCTION
Companies are confronted with complex market
conditions. The market environment is especially
characterized by globalization and shorter product
life cycles. Also product complexity increases, in
order to meet all customer requirements
(Dombrowski et al. 2015; Schuh 2012). Meeting
these customer needs is one of the main tasks of
product development. However, volatile market
requirements make it difficult for companies to
anticipate them, forcing them to act under
uncertainty. The increasing customer orientation in
the dynamic business environment favours this
uncertainty and creates an innovation pressure on
companies (Cooper, 2014). Plan-driven processes
based on a sequential structure can no longer meet
the requirements of short development times and
high flexibility (Cooper, 2014; Schuh et al. 2017).
Agile development processes are therefore being
used in product development, as they enable faster
development at lower costs (Backblaze 2015). They
are hereby characterized by an empirical-adaptive
character. The processes are less prescriptive than
plan-driven processes and are distinguished above
all by their high flexibility (Kniberg and Skarin
2010). Within agile development processes there is
no fine-granular predetermination of the contents,
but a continuous adaptation.
Takes place during the execution of the project,
whereby a consideration of changing customer
requirements can be guaranteed (Böhmer, 2016).
The high level of uncertainty and complexity in
the development of mechatronic systems places new
demands on processes, which must also be adapted
to the high flexibility of agile models.
Manufacturing companies are also mainly focusing
on their own core competencies and increasingly
outsourcing development services to suppliers,
which reduces the depth of value added and makes
the integration of external partners a critical success
factor (Spath and Dangelmaier 2017; Groher 2003).
In this context, cooperation between companies and
their suppliers continues to increase in intensity
(Dombrowski, 2015). The supplier integration in
product development faces companies with the
challenge of the efficient and effective design of this
integration. The design has to be adapted for agile
product development processes since designs for
Schuh, G., Schroder, S., Vogt, F. and Franz, M.
Description of Constituent Characteristics of Agile Development Processes for Technical Systems.
DOI: 10.5220/0010311100003051
In Proceedings of the International Conference on Culture Heritage, Education, Sustainable Tourism, and Innovation Technologies (CESIT 2020), pages 333-339
ISBN: 978-989-758-501-2
Copyright
c
2022 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
333
plan-driven approaches are no longer applicable
owed to divergence (Schuh and S. Schröder, 2019).
In order to enable the adaptation of supplier
integration to the boundary conditions of agile
development processes in the development of
technical systems, a precise knowledge of the nature
of agile development processes is necessary. This
paper therefore presents a description model of agile
development processes, in which constituent
characteristics of disseminated processes are
identified to concretize the discrepancy between
plan-driven and agile processes. The analysis is part
of an overall solution approach for the demand-
oriented design of supplier integration in agile
development projects (Takeuchi and I. Nonaka,
1986).
The framework comprises different
characteristics of agile development processes used
for the development of technical systems and
represents one of five partial models of an overall
solution hypothesis for the development of type-
based supplier integration forms for agile
development processes (Takeuchi and I. Nonaka,
1986). The overall solution concept aims to provide
a model that allows companies to choose the best
possible cooperation with development partners. The
core of this work is therefore to identify constituent
characteristics of agile development processes for
technical systems, which then can be used to derive
the resulting new requirements for the design of
supplier integration forms.
2 LITERATURE REVIEW
In this paper agile development processes are
analysed by identifying their constituent
characteristics. Since agile development processes
originate from software development and are
predominantly in this area, they are optimized for
these specific boundary conditions. However, agile
processes are increasingly used and adapted for the
development of technical systems. The literature
does not yet describe any agile product development
processes for technical systems, which is why the
analysis in this paper is based on agile software
development processes.
In 1986 the first agile development concept from
TAKEUCHI & NONAKA was created in order to
make product development faster and more flexible
(Takeuchi and I. Nonaka, 1986). Since then, a
multitude of different agile models have been
established in software development. All agile
methods are based on the values and principles of
the agile manifesto
(Komus et al, 2016/2017) .The Agile Manifesto
was designed in 2001 by 17 software developers. It
sets out the basic ideas and principles on which agile
development is based (Komus et al, 2016/2017).
Core elements of agility, which are highlighted in
the agile manifesto and define agility in the sense of
software development, are early implementation,
strong interaction with the customer and permanent
testing (Schwaber, 1997).
Thus, not all agile development processes can be
transferred to the development of technical systems.
However, the proportion of IT-related and non-IT
activities in which agile methods are used is growing
(Rubin, 2013). Rather than rejecting agile methods
for hardware development because they are not
designed for it, individual values and elements
benefiting the product development are identified.
These elements have to be adapted and implemented
in order to match the individual requirements.
(Backblaze, 2015). They make development
processes more flexible and do justice to the volatile
business environment (Schuh et al. 2017). Due to the
possibility of quick reaction to unforeseen events or
changing requirements, their application is also
possible under extreme uncertainty (Schwaber,
1997).
Due to the multitude of agile process models,
this paper concentrates on the most widely used
models in industrial practice. Only those models are
considered which are suitable for the development of
technical systems. These are Scrum, Kanban and
Design Thinking, whose distribution in industrial
practice is shown in Figure 1. The three mentioned
agile product development processes are briefly
explained in the following.
2.1 Scrum
Scrum is an agile management framework whose
main field of application is the development of
innovations (Rubin, 2013). It is strongly process-
focused and provides rigid framework conditions for
the development process. However, it does not
define concrete development practices and methods.
Instead, it focuses on the project management
aspects of development. (Hanser, 2010) For this
reason, it is often combined with other agile models
that offer concrete methods for the development
process. Characteristic are an incremental-iterative
development methodology as well as self-organizing
and interdisciplinary teams (Rubin, 2013). Within
this framework the development team is given a
CESIT 2020 - International Conference on Culture Heritage, Education, Sustainable Tourism, and Innovation Technologies
334
high degree of freedom regarding the design of the
product as well as the development process itself,
which is open for adaption in order to achieve
optimization (Kniberg and Skarin 2010;
Abrahamsson et al, 2003).
2.2 Kanban
Kanban was introduced to the Japanese automotive
industry in the 1950s and is a flow control
mechanism for just-in-time production using pull
control. Upstream processing activities are triggered
by the downstream demand signals (Proceedings,
2003). Since Toyota's first industrial application,
where it was used for efficient production control,
Kanban has evolved into a generic process that has
been transferred to other business areas (Ahmad et
al, 2013). It should be noted that Kanban is not a
development methodology, but a process
improvement methodology by which a system can
be understood and optimized. Due to its nature, an
initial system is required that can be optimized.
(Stellman and Greene, 2015).
2.3 Design Thinking
Design Thinking can be described as a human-
centred design process that identifies problems and
generates ideas for them. These ideas are quickly
transformed into tangible solutions using prototypes.
The aim is to reconcile the needs of the customer
taking into account the technological feasibility and
a viable business strategy. (Cole and Scotcher, 2015)
The iterative character of the design thinking process
enables a steady increase in knowledge as well as a
continuous improvement of the solution
(Freudenthaler-Mayrhofer and Sposato, 2017). With
regard to idea generation, there are initially no
restrictions in the process (Stellman and Greene,
2015). The design thinking process is always subject
to an individual design, and is adapted according to
the working method, problem definition and general
conditions. Thus, there is a multitude of different
Design Thinking process models.
2.4 Interim Conclusion
The empirical nature is characterized by the fact that
the processes of the methods are individually
adapted to the requirements of the project and thus
the methods do not specify the process in total. They
provide a basic set of tools for process optimization
and are widely used due to their general
applicability. (Kniberg and Skarin, 2010) Even if the
considered agile development processes differ in
their approach, all methods are based on common
constituent features, which can thus be assumed to
be generally valid for agile development processes.
These are identified and described in the following
section.
Figure 1: Use of agile development processes ( Komus et
al,
2017).
3 RESEARCH METHODOLOGY
This paper is part of a doctoral thesis, which is
developed for the integration of supplier in agile
development processes. The research methodology
of applied science according to ULRICH (Schallmo,
2018) is the basis of the research design (see Fig. 2).
In order to derive potential solutions, a structural
approach is used to identify a practical problem with
its theoretical deficit and to examine existing
approaches to literatures. Chapter I names and
structures a relevant practical problem as well as the
underlying theoretical problem in accordance with
the process of applied sciences according to
ULRICH. The necessity of research in this area is
also pointed out. Chapter II includes a literature
search and identifies existing relevant approaches
that correspond to steps B and C of the model based
on ULRICH. Chapter IV presents the results,
followed by a conclusion. In the context of the
process of applied science, this includes steps D and
E (Schallmo, 2018).
Description of Constituent Characteristics of Agile Development Processes for Technical Systems
335
Figure 2: Structure of this paper according to Ulrich
(Schallmo, 2018).
4 RESULTS
The aim of this paper is to identify constituent
features that enable agile product development
processes to be described in general and to
distinguish them from plan-driven methods. Two
successive steps were carried out for this purpose.
First, the selected three agile product development
processes were analysed by means of a literature
review and process-specific characteristics for each
individual process were identified. Subsequently, the
general characteristics for agile product development
processes were derived from these process-specific
characteristics and the model was formed. For the
derivation, the following criterion of universal
applicability was established: Characteristics that
can be identified in at least two of the most
frequently used agile development processes are
assumed to be universal applicable, as they can be
transferred to the majority of the analysed
development models.
For this purpose, the intersection of agile
characteristics was formed and congruent
characteristics for the model were identified. The
constituent characteristics and their derivation from
the respective agile development processes are listed
in Figure 3.
4.1 Incremental Processing using
Time-boxed Iterations
A fundamental feature of all considered agile
development processes is the implementation of the
project by means of time-boxed iterations. During
the implementation of the development project, an
incremental processing of the requirements is
pursued. For each iteration loop, a specific focus is
defined at the beginning, which is then processed in
a previously defined time frame. (Abrahamsson et
al, 2013; Cole and Scotcher, 2015; Ulrich, 1984).
In Scrum these temporally defined iterations are
named sprints (Abrahamsson et al, 2003). All sprints
have an identical duration in which the previously
defined dedicated task planning is processed. After
each of these sprints, the results are validated, and
the product requirements adjusted if necessary. The
next sprint is then planned using this adjusted target
direction for setting the focus and the scope.
(Anderson, 2010).
4.2 Low Specification of the Product at
the Beginning
The product is only roughly defined at the beginning
and has a low degree of specification, which gives a
lot of freedom in the design of the process and the
design of the product. This is the reason for the
creative freedom of agile processes. At the
beginning of a development project, general
requirements are set for the product, but the way in
which the requirements are going to be fulfilled is
kept completely undefined. (Backblaze, 2015; Cole
and Scotcher, 2015).
Looking at the design thinking process, it shows
that the tasks and problems to be solved, which are
the basis for the subsequent process, are formulated
initially (Freudenthaler-Mayrhofer and Sposato,
2017). Comprehensive and complex problems are
broken down into manageable problems in order to
make processing easier (Cole and Scotcher, 2015).
In order to first determine the direction of the
development, a basic understanding of the needs of
the target group is built up.
4.3 Early Delivery of Intermediate
Results
Through the incremental processing of the
requirements and a precisely defined development
scope in time-limited iteration loops, results can be
shown early in the development project when using
agile development processes. These are functional at
the beginning and do not claim to be complete or
perfect. (Backblaze, 2015; Proceedings, 2003;
Schwaber, 2004).
When using Scrum, individual increments are
created in the sprints. In agile process models, an
increment is a result, which is constantly extended
and supplemented (Lewrick, and Leifer, 2018).
These increments are aligned to the specific
development focus defined for the sprint and only
consider specific requirements
(Backblaze, 2015).Thus, an increment is
completed after each iteration, i.e. each sprint (Rubin,
CESIT 2020 - International Conference on Culture Heritage, Education, Sustainable Tourism, and Innovation Technologies
336
2013). This can be defined as new functionality and
should be theoretically directly implementable after
the sprint (Anderson, 2010). That result must be
directly linkable with the previously created and
existing results and functional for tests
4.4 Early and Continuous Testing of
Development Result
Due to the early availability of intermediate results,
the requirements processed in the iteration loops can
be validated early. The intermediate results are
oriented to the incremental development focus,
meaning they only fulfil the narrowed product
requirements defined for the sprint. Thus they can be
tested and further developed after each iteration.
(Backblaze, 2015; Schwaber, 2004).
When applying the Design Thinking
methodology, the solution idea is tested under real
conditions and in the context of the final product.
The aim is to gain new insights into the needs of end
users and to further optimize the prototypes by
developing an understanding of these needs. For this
purpose, several iteration loops are performed,
gaining further insights into the interaction between
humans and prototypes, which are then incorporated
and tested again. The aim is to develop a precise
concept which can then be quickly implemented as a
solution. (Cole and Scotcher, 2015).
4.5 User Stories Instead of
Requirement Specifications
The customer requirements for the product are
recorded in user stories. In contrast to defined
requirements in specifications, these are kept as
general as possible. They define what benefits the
customer has and thus determine the direction of
development without specifying requirements in
detail. (Ahmad et al, 2013; Ulrich, 1984).
In Scrum, a user story is defined as a short
sentence that represents part of a functionality. This
story does not contain any information about the way
the requirements are fulfilled, but should trigger a
discussion in the development team, which then
solves the design questions for each story. The
totality of the user stories represents all required
product functionalities. (Kusay-Merkle, 2018).
4.6 Strong and Constant Involvement
of the Target Group in the Process
The user will be involved in the development by the
team in the best possible way. He serves as most
relevant information source in the development
project regarding the product requirements but is not
necessarily the customer and therefore not financially
involved. The early feedback of the users can be
implemented into the process and support a target-
oriented development and optimization of the
prototypes. (Cole and Scotcher, 2015; Lewrick et al,
2018).
In Design Thinking, the target group is strongly
involved into the validation of physical prototypes.
These can be constantly tested by the target group.
Through rapid prototyping and direct testing by the
target group, optimization potential and
misalignment of the product specifications can be
identified early on. Furthermore, different versions
of the solution can be tested. The prototypes mature
by an iterative advancement of rough solution
concepts to matured products, which fulfil the
customer requirements in the best possible way.
(Cole and Scotcher, 2015).
4.7 High Personal Responsibility and
Interdisciplinarity of the
Participants
The development team, which is responsible for the
technical development of the product, has the task to
apply agile development processes. It is
interdisciplinary and self-responsible, which means
that each team member has competences in several
areas and not every task is delegated by the
manager, but planned by the team member itself
(Backblaze, 2015; Kniberg and Skarin, 2010). The
team members hereby have the responsibility for
initiating changes as well as for the general task
planning and execution. The empowerment of the
project team reduces the development time, as long
decision paths with the involvement of the
management are avoided and fast decisions are made
possible (Proceedings, 2003).
4.8 High Adaptivity of the Process
Within agile models there is no fine-granular
predetermination of the contents, but characteristic is
an adaptation during the execution of the project
(Böhmer, 2016). The exact design of the
development process and the product requirements
are adaptive and can be changed by the participants
after each iteration (Rubin, 2013). Changes are
considered good and are part of the culture. This
culture promotes early feedback which leads to rapid
development of important specifications and
Description of Constituent Characteristics of Agile Development Processes for Technical Systems
337
effective process improvement. (Stellman and
Greene, 2015; Schwaber, 2004).
In design thinking, for example, the process
structure is open to dynamics and changes, which
enables continuous further development. Only the
basic structure of six phases (Understand,
Empathize, Define, Ideate, Prototype, Test) is fixed.
The design within the framework can be redesigned
and is flexible during the development process.
(Cole and Scotcher, 2015; Schwaber, 2004).
4.9 Individual Design of the Process
Regarding the high adaptivity of agile processes the
restrictions for the adaptions are low. The empirical
character of agile development processes permits
individual adaptation and gives developers freedom
in process design. Only basic specifications are
mentioned as process frameworks, but the specific
process design is not defined. Therefore, the process
can be adapted during the whole process (see
characteristic 8) with a high degree of freedom
regarding the design. (Backblaze, 2015; Kniberg and
Skarin, 2010; Abrahamsson et al, 2003).
The example of Kanban shows, that processes
designed using Kanban can differ within the same
company. Every team is required to find the optimal
process for the individual development project.
Kanban only provides the tools enabling the design
of the process. Nevertheless, all processes are
derived from the same principles, therefore every
team member is capable of adapting when
reassigned from one team to another. (Ulrich, 1984).
4.10 Continuous Improvement of the
Process
In addition to the product to be developed, in agile
development processes the process itself is adapted
and continuously improved through feedback
mechanisms anchored in the method. This is
possible because of the individual process design as
well as the high adaptivity in agile development
processes. (Kniberg and Skarin, 2010; Rubin, 2013;
Cole and Scotcher, 2015; Anderson, 2010;
Anderson, 2010; Gloger, 2013).
Thus, when using Scrum, feedback loops are
performed after each iteration. These feedback loops
focus on the product and the degree of fulfilment of
the product requirements as well as on the process.
The generated lessons learned should lead to an
optimization of the process and enable a higher
degree of product requirement fulfilment as well as
an optimized process for subsequent sprints. (Rubin,
2013).
Figure 3: Literature mention of constituent characteristics
of agile development processes.
5 CONCLUSIONS
More and more companies implement agile
development processes to meet the challenges of the
increasing pressure to innovate. In the world of
physical product development, with its significantly
lower depths of value creation in recent decades,
however, the implementation of agile approaches
can only be of benefit if suppliers are successfully
integrated into these new processes. As mentioned in
this paper, it is imperative to adapt the design of the
customer-supplier relationship and the integration
form according to the needs of this new process for
effective and efficient supplier integration. The
constituent characteristics of agile development
processes presented in this paper are intended to
provide a clear differentiation from plan-driven
development approaches and thus identify the needs
for adaption in supplier integration. Based on a
consideration of existing agile development
processes with the widest distribution in industrial
practice, the paper summarizes the characterization
of agile development and therefore, which
constraints are set for the supplier integration. The
developed description model of agile development
processes is a partial model of an overall method for
the situational design of supplier integration forms.
In order to conclude this method, future research
must derive requirements for supplier integration
from the characteristics presented in this paper.
Furthermore, a logic for the design of a suitable
design of supplier integration should be developed.
CESIT 2020 - International Conference on Culture Heritage, Education, Sustainable Tourism, and Innovation Technologies
338
REFERENCES
Dombrowski, U., Ebentreich, D., Krenkel,, P., Meyer, D.,
Schmidt, S., 2015. Lean Development: Aktueller
Stand und zukünftige Entwicklungen. Berlin,
Heidelberg: Springer Vieweg.
Schuh, G., Ed 2012. Innovationsmanagement: Handbuch
Produktion und Management 3, Heidelberg: Springer.
Berlin, 2
nd
edition.
Cooper, R. G., 2014. Research-Technology Management,
vol. 57, no. 1, pp. 20–31.
Schuh, G., Riesener, C., Diels, F., Schröder, S., 2017.
Agile Produktentwicklung. In Aachener
Werkzeugmaschinen-Kolloquium 2017,
Werkzeugmaschinenlabor WZL der RWTH Aachen
and Fraunhofer-Institut für Produktionstechnologie.
Backblaze Inc., 2015. Application of Scrum Methods to
Hardware Development: An overview on how to run a
hardware development project using the Scrum
framework within the Agile software development
methodology.
Kniberg, H., and Skarin, M., 2010. Kanban and Scrum:
Making the most of both, s. l.: C4Media.
Böhmer, A., 2016. Agile Innovation – Challenges while
implementing agile approaches within complex
mechatronic processes of large corporations.
Spath, D., Dangelmaier, M., 2016. Produktentwicklung
Quo Vadis in Handbuch Produktentwicklung, U.
Lindemann, Ed., pp. 3–7 München: Hanser.
Groher, E. J., 2003. Gestaltung der Integration von
Lieferanten in den Produktentstehungsprozess, 1st ed.,
München: TCW, Transfer-Centrum für Produktions-
Logistik und Technolgie-Management.
Kampker, A., Gerdes, J., Schuh, G., Schaeben, H., Eds
2017. Think Big, Start Small: Streetscooter -
die e-mobile Erfolgsstory: Innovationsprozesse
radikal effizienter: the e-mobile success story:
radically more efficient innovation processes, 1st ed.,
Berlin, Heidelberg: Springer.
Dombrowski, U., Karl, A., Schmidtchen, K., 2015.
Lieferantenintegration in Produktentstehungsprozess,
ZWF, vol. 110, no. 10, pp. 625–629.
Schuh, G., Schröder, S., 2017. Agil innovieren mit
Entwicklungspartnern - Lieferantenintegration in agile
Entwicklungsprozesse in Verlagsschriftenreihe des
Heinz Nixdorf Instituts, Band 374, Vorausschau und
Technologieplanung: 13. Symposium für Vorausschau
und Technologieplanung: 23. And 24. November 2017
Berlin, J. Gausemeier, Ed., Paderborn: Heinz Nixdorf
Institut, Universität Paderborn, pp. 203–2019.
Takeuchi, H., Nonaka, I., 1986. The new new product
development game, Harvard Business Review, vol. 64,
no. 1, pp. 137–146.
Stellman, A., Greene, J., 2015. Learning Agile, Beijing:
O'Reilly.
Hanschke, I.., 2017. Agile in der Unternehmenspraxis:
Fallstricke erkennen und vermeiden, Potenziale heben.
Wiesbaden: Springer Vieweg.
Komus et al, A., Mar. 2017. Studie Status Quo Agile
2016/2017: Zweite Studie des BPM-Labors der
Hochschule Koblenz, Prof. Dr. Ayelt Komus, über die
Verwendung agiler Methoden, Hochschule Koblenz,
Koblenz. [Online] Available: www.status-quo-
agile.de.
Schwaber, K., 1997. SCRUM Development Process, in
Business Object Design and Implementation, J.
Sutherland, C. Casanave. J. Miller, P. Patel, and G.
Hollowell, Eds., London: Springer London, pp. 117–
134.
Rubin, K. S., 2013. Essential Scrum: A practical guide to
the most popular agile process. Upper Saddle River,
NJ: Addison-Wesley.
Hanser, E., 2010. Agile Prozesse: Von XP über Scrum bis
MAP”, Berlin,Heidelberg: Springer Berlin Heidelberg.
Abrahamsson, P., Warsta, M. T., Ronkainen, J., 2003.
New directions on agile methods: a comparative
analysis in 25
th
International Conference on
Software Engineering, Proceedings, Portland, OR,
USA, May. 2003 - May. 2003, pp. 244– 254.
Ahmad, M. O., Markkula, J., Oivo, M., Sep. 2013 - Sep.
2013. Kanban in software development: A systematic
literature review. In 2013 39th Euromicro Conference
on Software Engineering and Advanced Applications,
Santander. pp. 9–16.
Cole, R., Scotcher, E., 2015. Brilliant Agile project
management: A practical guide to using Agile, Scrum
and Kanban, Harlow England:Pearson.
Freudenthaler-Mayrhofer, D., Sposato, T., 2017.
Corporate Design Thinking, Wiesbaden: Springer
Fachmedien Wiesbaden.
Schallmo, D.R.A., 2018. Jetzt Design Thinking anwenden,
Wiesbaden:Springer Fachmedien Wiesbaden.
Ulrich, H. (1984): Management. In: T. Dyllick and G.
Probst (Hg.): Die Betriebswirtschaftslehre als
Anwendungsorientierte Sozialwissenschaft. Stuttgart:
Paul Haupt Publishing House, pp. 168-199.
Anderson, D. J., 2010. Kanban: Successful evolutionary
change in your software business, Sequim, Wash.:
Blue Hole Press.
Schwaber, K., 2004. Agile Project Management with
Scrum, Sebastopol:O'Reilly Media, Inc.
Lewrick, M., Link, P., Leifer, L. J., 2018. The design
thinking playbook: Mindful digital transformation of
teams, products, services, businesses and ecosystems,
Hoboken: Wiley.
Kusay-Merkle, U., 2018. Agiles Projektmanagement im
Berufsalltag, Berlin, Heidelberg: Springer Berlin
Heidelberg.
Womack, J. P., Jones, D. T., 2013. Lean Thinking: Ballast
abwerfen, Unternehmensgewinn steigern, 3rd ed.
Frankfurt am Main: CampusVerlag.
Description of Constituent Characteristics of Agile Development Processes for Technical Systems
339