Available online at www.sciencedirect.

com
Available online at www.sciencedirect.com

ScienceDirect
ScienceDirect
Available online atonline
Available www.sciencedirect.com
at www.sciencedirect.com
Procedia CIRP 00 (2020) 000–000
Procedia CIRP 00 (2020) 000–000
ScienceDirect
ScienceDirect
www.elsevier.com/locate/procedia
www.elsevier.com/locate/procedia

Procedia CIRP 00 (2017)

Procedia 000–000
CIRP 91 (2020) 464–471
www.elsevier.com/locate/procedia

30th CIRP Design 2020 (CIRP Design 2020)

30th CIRP Design 2020 (CIRP Design 2020)

Antagonizing
Antagonizing Ambiguity
Ambiguity –– Towards
Towards
28th CIRP Design aa May
Conference, Taxonomy
Taxonomy for Agile Development
forFrance
2018, Nantes, Agile Development
Alexander
Alexander Atzberger a*, Anne Wallischa, Simon Nicklasa, Kristin Paetzolda
a a a a
A new methodology Atzbergerto analyze
*, Anne the functional
Wallisch , Simon Nicklasand physical architecture of
, Kristin Paetzold
existing products forof thean assembly oriented product 39, Neubiberg, family identification
University of the Bundeswehr Munich, Werner-Heisenberg-Weg 39, Neubiberg, 85579, Germany
a
University
a
Bundeswehr Munich, Werner-Heisenberg-Weg 85579, Germany
* Corresponding author. Tel.: +49-89-6004-4426; fax: +49-89-6004-4426. E-mail address: alexander.atzberger@unibw.de
* Corresponding author. Tel.: +49-89-6004-4426; fax: +49-89-6004-4426. E-mail address: alexander.atzberger@unibw.de
Paul Stief *, Jean-Yves Dantan, Alain Etienne, Ali Siadat
Abstract École Nationale Supérieure d’Arts et Métiers, Arts et Métiers ParisTech, LCFC EA 4495, 4 Rue Augustin Fresnel, Metz 57078, France
Abstract

*Agile
Agile
development
Corresponding author.has
development has
become
Tel.: a standard
+33 3 87
become 37 54 30; procedure
a standard
in the
E-mail address:
procedure
software industry in the course of the past 20 years and is advancing into physical
paul.stief@ensam.eu
in the software industry in the course of the past 20 years and is advancing into physical
product development nowadays as well. When talking with peers and fellow experts from both academia and industry, ambiguities on the usage
product development nowadays as well. When talking with peers and fellow experts from both academia and industry, ambiguities on the usage
of the terms used in agile development becomes apparent. Therefore, this contribution aims at proposing a taxonomy for the field of agile
of the terms used in agile development becomes apparent. Therefore, this contribution aims at proposing a taxonomy for the field of agile
development by comparing its key elements to the traditional field of product development. The terms are well-grounded in scientific literature
development by comparing its key elements to the traditional field of product development. The terms are well-grounded in scientific literature
and by applying a systematic as well as a hierarchical approach, the terms are classified into the three layers of the St. Gallen management model
Abstract
and by applying a systematic as well as a hierarchical approach, the terms are classified into the three layers of the St. Gallen management model
proposed by Bleicher. In order to validate the taxonomy, comparisons to the field of traditional product development are given. In line with this,
proposed by Bleicher. In order to validate the taxonomy, comparisons to the field of traditional product development are given. In line with this,
Inthetoday’s
alignment of specific
business terms used
environment, the in ‘Scrum’
trend intomore
towards the taxonomy for agile
product variety anddevelopment
customization underpins its validity.
is unbroken. Due to this development, the need of
the alignment of specific terms used in ‘Scrum’ into the taxonomy for agile development underpins its validity.
agile and reconfigurable production systems emerged to cope with various products and product families. To design and optimize production
© 2020 as
systems The Authors.
well Published
as to choose theby Elsevier
optimal B.V. matches, product analysis methods are needed. Indeed, most of the known methods aim to
B.V.
product
©
This2020 The
is aan Authors.
open access Published by Elsevier B.V.
Peer-review
analyze under
product onearticle
orresponsibility
product under the on
of the
family CCthe
BY-NC-ND
scientific
physical license
committee
level. (http://creativecommons.org/licenses/by-nc-nd/4.0/)
Different
of the CIRPproduct .
families, however,
Design Conference may differ largely in terms of the number and
Peer-review under responsibility of the scientific committee ofof the CIRP Design Conference .
nature of components. This fact impedes an efficient comparison CIRP
Peer-review under responsibility of the scientific committee the Design
and choice ofConference
appropriate2020
product family combinations for the production
system.
Keywords:A new methodology
taxonomy; is proposed
agile; product to analyze
development; existingdevelopment;
agile product products inmanagement
view of their functional
model; and physical architecture. The aim is to cluster
methodologies
Keywords: taxonomy; agile; product development; agile product development; management model; methodologies
these products in new assembly oriented product families for the optimization of existing assembly lines and the creation of future reconfigurable
assembly systems. Based on Datum Flow Chain, the physical structure of the products is analyzed. Functional subassemblies are identified, and
a functional analysis is performed. Moreover, a hybrid functional and physical architecture graph (HyFPAG) is the output which depicts the
1. Introduction
similarity between product families by providing design support to both,‘Backlog’ productionorsystem
the ‘Scrum Board’
planners actually
and product tools, working
designers. aids or
An illustrative
1. Introduction ‘Backlog’ or the ‘Scrum Board’ actually tools, working aids or
example of a nail-clipper is used to explain the proposed methodology. Anmethods? industrial case study on two product families of steering columns of
methods?
Pushing the
thyssenkrupp boundaries
Presta of product
France is then development
carried out requires
to give a first industrialto evaluation
Thisof ambiguity
the proposed orapproach.
fuzziness is apparent in both academia as
Pushing
©reflect
2017 The the boundaries ofbyproduct development requires to This ambiguity or fuzziness is apparent in both academia as
its Authors.
potentialsPublished
and limitationsElseviertowards
B.V. new challenges, well as practice. Therefore, this contribution aims at unravelling
reflect its under
Peer-review potentials and limitations
responsibility towards
of the scientific new challenges,
committee well as practice. Therefore, this contribution aims at unravelling
taking into account its historical growing and ofcultural
the 28th CIRP whatDesign
agileConference
development 2018.
and its so-called agile methods actually
taking into account its historical growing and cultural what agile development and its so-called agile methods actually
embedding [1]. When following the latest reports and are (by definition) in comparison to ‘traditional product
embedding
Keywords: [1]. Design
Assembly; Whenmethod;
following the latest
Family identification reports and are (by definition) in comparison to ‘traditional product
discussion on the topic of agile development, its application in development’ and how those can be differentiated. Since these
discussion on the topic of agile development, its application in development’ and how those can be differentiated. Since these
the software has become a standard procedure in most terms are not used precisely, the question on how to transfer the
the software has become a standard procedure in most terms are not used precisely, the question on how to transfer the
companies. When shifting to the field of physical product knowledge of the definitions comes into play. Furthermore, the
companies. When shifting to the field of physical product knowledge of the definitions comes into play. Furthermore, the
1.development,
Introductionmany
development,
uncertainties and hindrances still remain.
many uncertainties and hindrances still remain. of
adequate usagerange
the product
adequate
of the terms
usage of theand terms
within the community
characteristics manufactured
within the community
needsand/or
to be
needs to be
One of the biggest issues is the topic of the mindset and, in line assembled addressed.inTherefore,
this system. the contribution aims at answering
challengethe
One of the biggest issues is the topic of the mindset and, in line addressed. Therefore, theIncontribution
this context,aims
the main
at answering in
the
with
Due that,
to training
the fast and education.
development This
in the is what
domain agile
of following
modelling research
and question:
analysis is now not only to cope with single
with that, training and education. This is what agile following research question:
development is currently
communication still lacking,
and an ongoing trendsinceof it is considered to products,
How can the terms used range
in agile
or development be compared
development is currently still lacking, since itdigitization
is considered andto How cana limited
the terms product
used in agile existing product
development families,
be compared
still be very
digitalization, fuzzy for many
manufacturing people up
enterprises until
are now.
facing When taking
important to
but the ones
also to used
be able intotraditional
analyze product
and to development
compare products literature?
to define
still be very fuzzy for many people up until now. When taking to the ones used in traditional product development literature?
a look at theinfield
challenges of agile
today’s product
market development, aboth
environments: software new product families. It can be observed that classical existing
continuing
a look at the field of agile product development, both software
and physical
tendency product
towards development,
reduction of productthe corresponding
development times termsandare 2. Coping with areambiguity
and physical product development, the corresponding terms are product
2. Copingfamilies
with ambiguityregrouped in function of clients or features.
also used
shortened relatively
product fuzzy.
lifecycles.OneIn popular
addition, example
there is for
an the inherent
increasing However, assembly oriented product families are hardly to find.
also used relatively fuzzy. One popular example for the inherent
ambiguity
demand of is ‘Scrum’. It isbeing
customization, referred
at to as
the samean agile
time method
in a [2],
global Motivated
On the by the
product misuse
family of several
level, productsterms,
differthe goal in
mainly of this
ambiguity is ‘Scrum’. It is referred to as an agile method [2], Motivated by the misuse of several terms, the goal of two this
methodology
competition [3], framework [4] or a process model [5]. Going contribution is to come up with a taxonomy for the field of
(ii)agile
methodologywith [3], competitors
framework [4] allorover the world.
a process modelThis [5]. trend,
Going main characteristics:
contribution is to come (i)up
thewith
number of components
a taxonomy and of
for the field the
agile
further,isare
which the elements
inducing the incorporatedfrom
development in Scrum,
macro such
to as the type
micro product
of development.
components Bymechanical,
(e.g. doing so, the ambiguity
electrical, of specific
electronical).
further, are the elements incorporated in Scrum, such as the product development. By doing so, the ambiguity of specific
markets, results in diminished lot sizes due to augmenting terms shall be
Classical reduced. A taxonomy
methodologies considering is mainly
a classification schema
single products
terms shall be reduced. A taxonomy is a classification schema
product varieties (high-volume to low-volume production) [1]. or solitary, already existing product families analyze the
To cope with
2212-8271
2212-8271
© 2020
©under
this
Theaugmenting variety
Authors. Published
2020responsibility
The Authors. of
Published
as wellB.V.
by Elsevier
by Elsevier
as to be able to product structure on a physical level (components level) which
B.V. of the CIRP Design Conference 2020.
Peer-reviewpossible
identify optimizationthe scientific committee
potentials in the existing causes 2020.
difficulties regarding an efficient definition and
Peer-review under responsibility of the scientific committee of the CIRP Design Conference
production system, it is important to have a precise knowledge comparison of different product families. Addressing this
2212-8271 © 2020 The Authors. Published by Elsevier B.V.
This is an©open
2212-8271 2017access article Published
The Authors. under theby CC BY-NC-ND
Elsevier B.V. license (http://creativecommons.org/licenses/by-nc-nd/4.0/)
Peer-review
Peer-review under
under responsibility
responsibility of scientific
of the the scientific committee
committee of the of theCIRP
28th CIRP Design
Design Conference
Conference 2020
2018.
10.1016/j.procir.2020.02.200
 Alexander Atzberger et al. / Procedia CIRP 91 (2020) 464–471
2 Author name / Procedia CIRP 00 (2020) 000–000
is intended to display a system of ordering. By doing so, a
certain field can be itemized into sub groups which are
(intended to be) mutually exclusive. Typical examples for
taxonomies are e.g. dendrograms. Whereas a glossary is a
simple list of terms with the respective definitions, a taxonomy
can be described as a hierarchical structure to aid the process of
classifying information and thereby systematizing a gamma of
various elements in a hierarchic structure [6]. Going further, an
ontology is an agreed and formal description of shared concepts
in domain has the objective of enabling shared understanding
and communication. It acts as a standardized reference model
to support information integration and knowledge sharing [7].
In short, it provides a set of concepts from a certain field or
domain that are well-specified [6]. For the sake of clarification,
an ontology does mostly contain a subclass-based taxonomic
hierarchy. Since this is a first attempt to come up with a
classification, aiming at a taxonomy seems most promising,
which could lead to an overall ontology in the future.
Requirements regarding a well-accepted taxonomy are the
following six items: Concise, robust, comprehensive,
extendible, explanatory, and useful [8], [9]. These are the
aspects under which the quality of taxonomy should be
evaluated. Both academia and industry can benefit from such a
taxonomy. Its findings are well-situated in product
development literature, yet its appearance is displayed in a
meaningful and understandable way.
To date, only few attempts have been undertaken to either
come up with a clarification or classification scheme. Most of
the work has been done in the software discipline, either coming
up with a dependency taxonomy [10], a taxonomy of scale [11],
a taxonomy of the competency of a project manager [12] or
when shifting to the field of manufacturing, an agility taxonomy
regarding agile manufacturing strategies [13], which subdivides
the strategies into quick, responsive or proactive. The only
framework aiming at the field of agile development of physical
products to be found was by [2] and aims at classifying artifacts.
Yet, no concise and comprehensive taxonomy for the field of
agile product development has been come up with, to the best
of the authors’ knowledge.
3. Research approach
In the present research, a comprehensive structured literature
review has been undertaken. Key terms have been defined, and
the most-cited books in product development literature have
been chosen for a first investigation. Based on that, the
definitions of the respective terms have been extracted and
compared to each other. Furthermore, additional sources have
been identified that already display certain interrelations
between those terms. This being the source of literature, a
suitable framework has been chosen to classify the terms on
three levels. The findings have been analyzed and merged into
an overall scheme to display its linkages as well as its
distinctions. This scheme represents the foundation of the
taxonomy. Its validity for the field of product development in
general has been checked by drawing comparisons to traditional
development philosophies. In order to validate its suitability,
the alignment of the terms used in ‘Scrum’ into the taxonomy
has been confirmed exemplary.
465
4. Definition of terms and setup
In this research, the most common terms used in traditional
and agile product development have been investigated overall.
In the course of the reappraisal, two strategies have been
consulted: First, a systemic approach has been chosen. In total,
a method can be understood as a system for the technical
assistance in the execution of development activities. Each
system consists of a sum of elements that are connected by
relations and shows a dualism of behavior and structure.
Ultimately this means that methods contain a basic structure,
whereby a certain behavior in the sense of supporting the
(development) activities is generated. Vice versa, a suitable
structure is required to generate a defined support behavior.
Due to this dualism, terms from the context of methods can be
assigned, which in turn provide very precise starting points for
a context-specific adaptation of these methods.
Second, a hierarchical approach has been used for the sake
of classification. Therefore, the hierarchical approach by
Bleicher [14] has been chosen as a basis. Whereas methods are
intended to give clear answers on how to proceed in the course
of problem solving and thus show a rather operative character,
methodologies express a strategic character, since the methods
are summarized in the sense of fulfilling an overarching
objective. Superordinate development goals, on the other hand,
show a rather normative character due to the fact that all
activities in the development are aligned and evaluated based
on these. All terms used in the product development context
regarding methods can be either classified normatively,
strategically or operatively in such a hierarchical structure. Yet,
several terms cannot be classified distinctively and their
transitions are partly fluent. Such a classification into a
hierarchical structure, however, has the advantage of the
situation-specific use of methods. Due to this, indications for
the adaption can be derived and concrete recommendations for
action can be given.
These two strategies shall serve as a kind of classification
criteria, on the bases of which the following terms are classified
and evaluated. In the following subchapters, the terms on the
respective layers are described and their interrelations are
highlighted.
4.1. Operative layer
Lindemann [15, p. 48] defines methods as “the description
of a rule-based and planned procedure, according to which
certain activities are to be carried out in order to achieve a
certain objective”. Whereas the term method may differ in the
linguistic use in various disciplines or contexts – even in
product development literature slightly different definitions are
given – yet these are fundamentally identical in general [16],
[17]. Methods are prescriptive, i.e. they describe how to
approach a problem and are of operative nature [15], [18]. From
a systemic point of view, methods have a process-like
character, which is also manifested in a method model
proposed by [19], since a logical sequence of activities and
tasks is suggested.
466 Alexander Atzberger et al. / Procedia CIRP 91 (2020) 464–471
Author name / Procedia CIRP 00 (2020) 000–000
Fig. 1. Process-oriented method model (adapted from [19])
Methods are used if the purposeful and systematic execution
of activities has to be supported [20]. They contain action
prescriptions. Thus, they have an operational character since
they illustrate how to proceed in order to find solutions. In this
model, methods show an internal structure: a method consists
of sequences of action, which transform an initial state
(problem or task) into a final state (solution). Therefore, a
certain structure is required as well as the information about the
necessary input and the expected output, respectively. The type
of input, i.e. the data, information, documents, materials,
workings aids, etc., required depends on the objective of the
method. The same applies to the output, yet the user can deduct
from the description of the output whether the method is
suitable for the specific problem statement or to what extent an
adaptation is necessary to achieve the desired result. In their
method model, Birkhofer et al. [19] assign information on the
user requirements, possible aids, boundary conditions and
explanatory descriptions on the application to the method
description.
An essential characteristic is the degree of concreteness.
While some methods give very clear instructions, others are a
rather generic recommendation for action. This displays the
fractal character of methods: Methods that are more generic in
character are, in principle, structured according the description
given by [19], just like those that provide concrete instructions.
With the help of the process-orientated method model, a clear
rule is given as to how the concretization and adaptation of
more generic methods to the context can be carried out to
generate situation-specific instructions. Summing up, methods
are rather operative in nature. The more generic the
recommendations for action are within the method description,
the more adaptation is required, which, in turn, makes the
method appear to be rather generic. For an effective usage of
the methods concretizations depending on the activity and the
situation are necessary.
The goal of the application of tools is “to make the
application of methods more effective and efficient” [18].
Tools support and facilitate the practical application of
methods [21]. They are supportive and range from simple
checklists or forms to complex software tools. This means they
are resources for the application of the methods. Tools can be
provided method-specific (e.g., a tool for the meshing of
3
geometries) or universally for the use with various methods
(e.g., a CAD system). The trigger for the tool selection is the
method chosen, since it describes, how and for which purpose
a certain tool is used. This becomes evident considering the
versatility of, e.g., Microsoft® Office Excel™ in product
development. If the method requires a specific tool, which does
not exist in the company, this could lead to a rejection of the
method because its migration into the existing tool landscape
can be very time- and resource-inefficient. On the other hand,
if the tools needed are available, this can have a rather positive
effect on the method acceptance.
While the terms method and tool are well-defined in product
development literature, which is interpreted comparatively
interdisciplinary, this is not the case for the following terms.
Aside from tools, (working) aids are often mentioned in the
context of method application. Ehrlenspiel and Meerkamm
[16] summarize all the objects that are used to carry out the
activities under the term aids. Examples are paper and pen, a
plotting table, a 3D mouse or an Apple Pencil®. Reinicke [22]
supplements this description from a rather social-scientific
perspective and summarizes all materials and instruments that
support the achievement of the objective of the method
application (e.g., templates, presentation documents). In
computer science, aids serve to implement methods more
efficiently. These definitions highlight that aids are interpreted
very manifold in many fields, which is related to the subject-
specific nature of the problem solution. Due to this, it is
imperative to focus on the understanding of what is considered
a working aid and to achieve a consensus in their identification,
especially when collaborating in interdisciplinary teams, which
is demanded by an agile way of working.
4.2. Strategic layer
Strategies are understood as long-term plans in order to
achieve fundamental goals [15]. They translate the goals and
boundary conditions predefined by the chosen development
philosophy or selected approach into concrete procedures for
implementation. In other words, on behalf of the strategy
building, one needs to consider which process models or
methodologies and methods appear to be effective, as well as
the identification of suitable tools. The focus is not directly on
the support of development activities, but rather on issues
regarding how an approach can be implemented in the
company from an organizational point of view. Thus, they form
the link to break down the normative demands on the strategic
implementation. That involves thinking about the
organizational design and integration of development
processes into the business processes. Strategies specify how
the behavior of all personnel involved and the alignment of all
actions towards the objectives can be orientated as holistically
as possible. They have a procedural character in the systemic
sense and support the organization of processes along their
concretization.
The main goal of applying methods is to support the product
development activities. The aggregation of the support results
in a systematic approach to the achievement of the objectives
[16], [17]. The sum of all methods used is also referred to as
 Alexander Atzberger et al. / Procedia CIRP 91 (2020) 464–471
4 Author name / Procedia CIRP 00 (2020) 000–000
methodology. Reinicke emphasizes that methods and tools to
support product development activities are functionally linked
[22]. In this light, the focus for the application of
methodologies extends the one of methods: whereas methods
are intended to support individual development activities,
methodologies aim at supporting overarching objectives which
can only be achieved by coupling individual activities. Gericke
et al. [23, p. 105] extend the term methodology specifically for
development (i.e. a design methodology) and give an overview
of its components: “In design, a clearly and explicitly
articulated approach to producing designs for a class of
systems, that specifies in more or less detail the activities to be
carried out, the relationship and sequencing of the activities,
the methods to be used for particular activities, the information
artefacts to be produced by the activities and used as inputs to
other activities, and how the process is to be managed, as well
as (tacitly or explicitly) the paradigm for thinking about the
design problem and the priorities given to particular decisions
or aspects of the design or ways of thinking about the design.”.
Comparing the content of this definition to the process-oriented
method model description by Birkhofer, similarities are clearly
recognizable, as displayed in Fig. 2. Simply put, a methodology
summarizes multiple methods and process models into one
body [24]. By doing so, it aims at concretizing normative
approaches (which are described in the following). From a
systemic point of view, methodologies involve both structural
and behavioral aspects: the linking of activities and methods
form the structure of the methodology. Coherences, on the
other hand, are used to specify relationships and execution
instructions that generate the desired behavior. Methodologies
are more strategic in nature than methods, since they do not
focus on the support of individual activities, but on
summarizing individual activities in such a way that a holistic
description on how to achieve an overall objective is available.
Even though the usage of methodologies pursues a specific
objective, the respective development tasks in the concrete
application vary due to their context- and decision-making
conditions. Because of these conditions it is necessary for the
methodology to be able to adapt goal-oriented and context-
specific.
Fig. 2. Methodology as the sum of methods (adapted from
[19])
467
The predefined combination and sequence of methods,
procedures and tools must therefore always be interpreted and
adapted task-specifically. The strategic character of a
methodology also emerges from another aspect. In the
definition of methods it has been stated that they possess a
fractal character. Therefore, from a generic point of view,
methodologies can be understood as methods which are
abstracted to such an extent that the aspect of how to achieve
the objective is no longer clearly recognizable. However, the
question of what to do in order to solve the problem can be
substantially answered. The operational applicability is
determined by the context- and task-specific concretization. In
its appearance methodologies are quite diverse, which hampers
its classification, yet a more detailed analysis shows that,
regardless of the field of application, a methodology maps the
complete problem-solving cycle, that is the combination of
methods for the analysis, synthesis, and evaluation.
A procedure is the sequence of actions in the development
process [21]. Procedure or process models display the essential
elements of a sequence of actions as a descriptive
characterization of a prescriptive specification of working steps
[21]. According to Ponn [18], the intended use of process
models includes the planning of future processes, the
navigation or orientation in current processes and the reflection
of completed processes. As a consequence, process models in
the context of product development have to be understood as
the process-describing element of methodologies. Due to the
arrangement and linking of methods certain sequences to
support the activities are discussed, which serve as aids for the
planning and controlling of the processes. Thus, they provide
the basis for the method usage in product development. Within
the field of product development, several process models have
been developed in the past decades, which can essentially be
grouped into two categories: operative and strategic process
models.
Operative process models describe the processes in product
development at the level of concrete problem-solving, which
should support the systematic processing of sub-problems [20].
Lindemann [20] refers to this as the micrologic in product
development. An example of such micrological process models
is the problem-solving cycle according to Ehrlenspiel [25]. In
its structure, it is based on psychological models of how
humans proceed in problem-solving tasks according to Miller.
Since this type of process model has a descriptive character, i.e.
it describes how to proceed, and it can be used independently
of the domain.
Strategic process models depict fundamental patterns of
action for specific development situations. Their focus lies on
the description of the temporal-logical sequence [20]. By
laying out the product development process from idea to
product in its entirety, it describes a strategy for product
development. Typical representatives of such process models
are the procedure according to VDI 2206 for the development
of mechatronic systems [26] or VDI 2221 for the development
of complex technical systems [27]. These process models
display what to do in the development and thus have a
prescriptive character. Due to their focus on logical-temporal
processes, these types are also referred to as macrological
process models [20]. They are highly domain-specific, and
468 Alexander Atzberger et al. / Procedia CIRP 91 (2020) 464–471
Author name / Procedia CIRP 00 (2020) 000–000
mathematical-physical laws for solution finding and its
description characterize their procedures. Even though the
temporal-logical processes are very distinct in detail for the
different subject domains, the phases ‘planning’,
‘conceptualizing’, ‘designing’ and ‘elaborating’ can be
identified again on a meta-level [28].
So which benefits can be derived from such considerations?
Micrological process models primarily tend to explain which
of the developer’s activities can be supported (regarding the
analysis, synthesis, and evaluation) and what the specific
challenges are (e.g. creative blocks, handling with large
amounts of information, mastery of complex relationships).
Which methods are to be used depends on the development task
at hand and the objectives pursued, as well as the current
development phase. Especially in the early phases of the
development the information base is commonly quite
incomplete and uncertain. Therefore other methods are needed
for the micrological support compared to the integration phase,
where solutions are brought together or the design phase, where
solutions are detailed on a more sophisticated information base.
Macrological process models, however, help to integrate
temporal-logical relationships of development into the process
organization and to coordinate the multitude of activities
required for product development. For operational applicability
the level of granularity and specificity of the process models in
general is too low [21]. Process models require a context-
specific adaptation or concretization in order to find purposeful
use in development.
Moreover, the term framework is increasingly used in the
context of implementing development approaches. Ultimately,
a framework is nothing more than a ‘body of order’ whose
purpose is to provide a structural overview of components of a
system. In this way, by classifying the elements and their
relationships at hierarchically subordinate levels, the relation
between each other are revealed. In contrast to a process, the
framework has no sequence, but represents an artificial and
arbitrarily created order [29]. Thus, from a systemic
perspective, the framework complements the strategy: while
the strategy defines how to proceed with the development
approach, the framework defines which elements to consider
and to adapt. As a consequence, frameworks have a more
strategic character in terms of the integration of development
processes into the enterprises (and less in terms of supporting
the development goals). They summarize the elements and
relationships required to generate the desired support behavior.
Frameworks are always characterized by a certain generic
entity, since the peculiarity of the elements, along with their
arrangement as well as their integration can be adapted to the
contexts and objectives pursued.
4.3. Normative laver
The method selection on an operational level as well as the
chosen methodologies for the achievement of objectives are not
selected in a haphazard way. They follow entrepreneurial
behavior and its underlying corporate development vision. This
is summarized under the term (development) philosophy. It
displays certain values, which the company is obliged to follow
5
in order to achieve the long-term vision and that reflect the
ambitions of the company. Additionally, the philosophy is
backed by a foresight of the future. Inside the company, that
vision is broken down into a shorter-scale mission and thus
concretized into objectives for both the organization and
product development. A philosophy needs to be understood as
a motif for product development, which defines all other
methodologies, process models, methods and tools [22].
Development philosophies therefore describe fundamental
assumptions about how to organize the development as well as
how to build knowledge in the respective field. Philosophies
are context-independent, i.e. not limited to a specific product
family or industrial branch. Besides considerations and value
statements on product development processes and their holistic
organizational procedures at the strategic level, they also
consider human thinking and operating principles at a more
operational level [30]. This elucidates the normative character
of development philosophies. Decisions on that always have a
long-term character and require holistic considerations as to
how this should be anchored inside the company. A philosophy
can be described as the ethics, general values and convictions
a company is committed to follow.
The development philosophies described above affect a
large number of influencing factors. At first sight they are kept
generic so that there is room for interpretation which is also
necessary in order to be able to transfer it to different contexts.
By transforming the philosophy into specific fields of
application, different approaches emerge. These approaches
may differ due to their varying field of application or the
interpretation of details, yet they still pursue the same
objectives in their basic idea. Approaches can be understood as
perspectives or manifestations of development philosophies.
Therefore, approaches appertain to a rather normative
character, yet they already contain strategic elements since
specific concretizations are made on a selective basis.
5. Consolidation of findings
According to the differentiated description and definition of
the individual terms, these are now summarized in order to
emphasize the relations between them. In turn, this seems
helpful to be able to subsequently provide information on the
adaptation and application in the specific development context.
The previously described dimensions, namely systemic and
hierarchical classification, are confronted with each other
creating a matrix, into which the individual terms can be sorted.
The result is a scheme which contains all the terms discussed
above, in a comprehensive and simplified manner.
5.1. Structure
The classification scheme proposed is displayed in Fig. 3. In
the normative level of the scheme development philosophies
and approaches are to be classified. With these, the company
vision is reduced to the concrete level of development. It is
defined why decisions are made in subsequent levels. These
decisions taken at the normative level need to be concretized at
the strategic level. The actions necessary to implement the
philosophy are determined, yet also the necessary components
 Alexander Atzberger et al. / Procedia CIRP 91 (2020) 464–471
6 Author name / Procedia CIRP 00 (2020) 000–000
for the development processes are identified. While the setting
of the strategies are more of an organizational character, the
choice of the process models and their further elaboration and
concretization address the content-related aspect. This
elucidates what is needed to bring a philosophy into practical
use. In turn, selected methodologies and process models are
further detailed by selecting and adapting methods for action
support. The operative level describes how individual
development activities can be supported. The concretization
and adaptation of the methods takes place through the choice
of tools and working aids.
5.2. Validation of the scheme
The following paragraph aims at validating the classification
scheme. When taking a look at the definitions in the respective
sources, a certain lack of conceptual clarity remains in some of
them, which this classification aims to reduce. Starting at the
normative layer, Vajna defines the Integrated Product
development (IPD) to be a development philosophy [30].
Having its root in the work by Olsson, it has been constantly
further developed by multiple authors, resulting in a variety of
approaches, such as the IPD according to Meerkamm, the IPD
according to Burchardt and Vajna, the Dynamic Product
Development by Ottosson, etc., as illustrated explicitly in [30].
In this respect, Simultaneous / Concurrent Engineering [31] or
Systems Engineering [32] are also to be understood as
development philosophies or approaches, as these author refer
to it. When shifting to the field of agile development, it also
needs to be classified as a development philosophy. The
Manifesto for Agile Software development, incorporating the
core values of what the agile or lightweight processes share,
has a normative character. When taking software development
as the starting point 1 , this approach has spread into the
development of physical products, production, as well as other
fields such as human resource management.
On the strategic layer the agile methodologies are located.
Here, e.g. Scrum 2 , Kanban, eXtreme Programming (XP),
Design Thinking can be considered methodologies, since all of
them contain more than one method. Therefore, when referring
Fig. 3. Classification scheme of the terms used in traditional
product development
1
For the sake of explanation. In terms of time, agile development in its core
was applied long before its appearance in the software industry.
469
to the definition of a methodology, none of them can be
classified as a method by itself. None of them are frameworks
either since based on the information available publicly, the
interrelations between the elements in the respective
methodology are known. The Scrum Guide as the basic outline
of Scrum already provides linkages between the different
elements, which is why it cannot be considered a framework.
One example of a framework is the Business Model Canvas
with its nine fields – the important components of what the
business model has to consist of are visualized, yet its
interrelations are not visible. Scrum, Kanban, XP, or Design
Thinking are also process models since the procedure of how
to proceed in the respective methodology is apparent 3. Shifting
back to traditional product development, the VDI 2221 or VDI
2204 are typical representatives of product development
methodologies, since they display the different process steps
which are needed for the development of technical or
mechatronic systems and products, respectively. The
illustration of the VDI 2206 – the V-model, is a well-known
representative of a process model on the strategic layer [26].
Another example for a process model from project
management is the Stage-Gate model by Cooper [33].
The difference in the levels of abstraction between process
models becomes evident when taking a look at Fig. 4 (operative
layer). Here, the procedure of how to proceed in Scrum during
one sprint is visualized by the two cycles (or spirals), which is
a typical representation of a sprint. This representation can be
considered a process model on the operative layer or micro-
logic. Important to mention here is the granularity of the
different process models, which is not distinct, as already
argued by Lindemann [20]. On the operative layer, examples
for methods from traditional product development are the 635
method or gallery method. Tools are e.g. different software
applications such as Microsoft® Excel or a CAD program, or a
drafting table, whereas working aids are e.g. a whiteboard, a
flip chart, basically anything that facilitates the execution of
methods. Techniques on the other hand are of behavioral
nature, such as the ‘point evaluation’, ‘questioning technique’
or ‘scenario technique’.
Fig. 4. Classification scheme of the terms used in agile
product development
2
In the first publications about Scrum in the late 90s, Ken Schwaber did refer
to Scrum as a methodology.
3
Based on the information available publicly in the literature or internet.
470 Alexander Atzberger et al. / Procedia CIRP 91 (2020) 464–471
Author name / Procedia CIRP 00 (2020) 000–000
In agile development, actions on the operative layer are
commonly referred to as practices. When taking a look at the
definition of Birkhofer, the activities in Scrum such as sprint,
sprint planning, daily scrum and retrospective are actually
methods. The artifacts used in Scrum such as user stories,
backlogs, task boards, burnup/burndown charts are tools.
Scrum’s practices Timeboxing, planning poker, point
estimates and the Definition of Done (DoD) are of behavioral
nature and therefore techniques. The classification has been
done for elements of the methodology Scrum, however it is also
valid for the other methodologies, since e.g. the Kanban Board
is also a tool or the Work in Progress (WIP) limit a technique.
When shifting to the right side of Fig. 4, the philosophies
incorporate different core values. In the case of agile
development, the basic set of values every methodology shares
are the ones stated in the Agile Manifesto, such as
interdisciplinary collaboration, transparency or people
empowerment. These motifs are embedded in the overall vision
of why to pursue a certain philosophy.
The concrete translation into practice is then acted out on the
operative level. The task board, daily Scrum or burnup charts
are used to generate transparency among the team. The
collaboration is enhanced by the daily Scrum meetings and the
retrospectives. The same is valid for the empowerment of the
individuals since the retrospectives are intended to reflect on
what went well or not so well and what needs to be changed in
order to constantly improve the team performance.
6. Key learnings
Increasing complexity and technological advances keep
disciplines constantly changing. Growing thematically and
methodically beyond the traditional boundaries of the own field
requires an attitude of critical reflection on the application of
traditional terms and conceptualizations. The definitions of the
respective terms have been published by several authors
already, yet an overall big picture and a comparison to the field
of agile product development has been missing until now.
Therefore, the results of the work at hand are evaluated and its
relevance for both practice and academia are examined.
The classification of the common terms in product
development has been done in order to (a) show the
interrelations and overlaps of the terms in one condensed
scheme and (b) to classify the terms used in agile development
into this scheme. By doing so, the similarities between the
terms used in the field of agile development (artifacts,
activities, practices) are compared to the ones used in
traditional development approaches. It is shown that even
though several terms are named differently, they can be
classified into the same scheme, which is well-grounded in
scientific product development literature. Therefore, the
ambiguity of the agile elements is reduced since their
counterparts from traditional development are displayed. After
all, agile development may be new from its philosophy and
therefore behavioral shift in the mindset. The so-called
practices however, are actually methods, according the
definition of Birkhofer.
This contribution aims to provide all useful information on
the topic in one document so that the interrelations between
7
these (partially closely related) terms are displayed and briefly
explained. The grounding in product development literature
enables the comparisons between traditional development
philosophies and agile development, as well as a comparison
between different agile methodologies, which were the two
main objectives of the work at hand. Regarding the
requirements for a taxonomy, it can be summarized that the
taxonomy presented in this contribution is both concise and
comprehensive. Due to the use of the management model by
Bleicher it is also self-explanatory. Moreover it is extendible,
in terms of the aspects that can be grouped into the taxonomy.
Therefore it appears to be useful for both academia and industry
from the authors’ perspective. Future discussions will give
insight about the robustness of the taxonomy as well as its
usefulness in practice.
In this respect, one important aspect is to teach the new style
of working and to comprehensively explain how it
differentiates from the status quo (traditional development
approaches). This is exactly what this contribution is aiming at,
to display that agile development is nothing more than a
development philosophy at its core, just like many others.
Every philosophy shares certain values. These are concretized
by several methodologies, which are unique to the respective
contexts in practical application. In order to translate these
methodologies into practice, specific methods and tools are
used. This is also valid for agile development. However, when
the core values change, the methods and tools have to change
accordingly – and this is what practice experiences first-hand
as a major shift. The actual shift however has its roots in a
change in the core values. The embedding of these core values
into the organizational and operational structure is the
challenging part. In order for the transition to succeed, it is
necessary to explicitly state how a new approach differs from
the currently used one – it is necessary to show the differences
from the current reference point. The reduction of fuzziness
results in transparency, which can lead to clarity, if
communicated well. This is what academia should strive for –
to unveil what agile development is capable of handling and
what not by providing useful and readily understandable
measures.
7. Conclusion and Limitations
Motivated by the current ambiguity of the terms used in
agile product development, the authors have developed a
taxonomy in order to classify the terms used in agile product
development and to display the relations between them. Based
on the management model by Bleicher [14], the most
significant terms regarding a common understanding have been
classified on the layers normative, strategic and operative. The
definitions of the terms used in traditional product development
literature are given and its agile ‘counterparts’ are displayed
accordingly.
However, some limitations also need to be addressed. First
of all, the number of terms which are mentioned with its
definitions is relatively small. On the one hand this leads to a
lucid and comprising overview. On the other hand it is lacking
a comprehensive compendium of all related terms. Second, the
database of the definitions is mostly based on German literature
 Alexander Atzberger et al. / Procedia CIRP 91 (2020) 464–471
8 Author name / Procedia CIRP 00 (2020) 000–000
sources since the methodological perspective of product
development is thoroughly investigated in this region [13]
compared to a rather project management related perspective
in the North American region. Needless to say, the authors are
Europe-based and therefore have a stronger focus on the [14]
methodological perspective. Another aspect that needs to be
mentioned is the linguistic difference in usage and common [15]
understanding. From a methodological perspective, the correct
usage of terms is of utmost importance. Yet, some terms do [16]
have ambiguous meanings, which non-natives are unable to
refer to or reconstruct. In addition to that, many practitioners
[17]
prefer to use the terms which the vast majority is using, even if
they may not be completely accurate. [18]
However, and this is what this contribution is aiming at, its
statements and the taxonomy derived is valid independent of [19]
the country of origin.
References
[20]
[1] A. Wallisch, O. Sankowski, D. Krause, and K. Paetzold, “Kaleidoscope
of User Involvement – Product Development Methods in an [21]
Interdisciplinary Context,” in Human Systems Engineering and Design
II, vol. 1026, T. Ahram, W. Karwowski, S. Pickl, and R. Taiar, Eds.
Cham: Springer International Publishing, 2020, pp. 8–14. [22]
[2] A. I. Böhmer, M. Meinzinger, R. Hostettler, A. Knoll, and U.
Lindemann, “Towards a framework for agile development of physical
products influence of artifacts and methods,” in 2017 International [23]
Conference on Engineering, Technology and Innovation (ICE/ITMC),
2017, pp. 237–245, doi: 10.1109/ICE.2017.8279895.
[3] S. Nerur, R. Mahapatra, and G. Mangalaraj, “Challenges of migrating [24]
to agile methodologies,” Commun. ACM, vol. 48, no. 5, pp. 72–78,
May 2005, doi: 10.1145/1060710.1060712.
[4] N. Ovesen, “The challenges of becoming agile,” Aalborg University, [25]
2012.
[5] T. P. Klein, “Agiles Engineering im Maschinen- und Anlagenbau,”
Technische Universität München, München, 2015. [26]
[6] R. van Rees, “Clarity in the usage of the terms ontology, taxonomy and
classification,” CIB Report 284, 2003. [27]
[7] A. Zwegers, M. Hannus, M. Tølle, J. Gijsen, and R. van den Berg, “An
architectural framework for virtual enterprise engineering,” E-Work E-
Commer. Nov. Solut. Pract. Glob. Networked Econ., 2001. [28]
[8] K. Bailey, Typologies and Taxonomies. 2455 Teller Road, Thousand
Oaks California 91320 United States of America: SAGE Publications,
Inc., 1994. [29]
[9] R. C. Nickerson, U. Varshney, and J. Muntermann, “A method for
taxonomy development and its application in information systems,”
Eur. J. Inf. Syst., vol. 22, no. 3, pp. 336–359, May 2013, doi:
10.1057/ejis.2012.26. [30]
[10] D. E. Strode, “A dependency taxonomy for agile software development
projects,” Inf. Syst. Front., vol. 18, no. 1, pp. 23–46, Feb. 2016, doi:
10.1007/s10796-015-9574-1. [31]
[11] T. Dingsøyr, T. E. Fægri, and J. Itkonen, “What Is Large in Large-
Scale? A Taxonomy of Scale for Agile Software Development,” in
Product-Focused Software Process Improvement, vol. 8892, A.
Jedlitschka, P. Kuvaja, M. Kuhrmann, T. Männistö, J. Münch, and M. [32]
Raatikainen, Eds. Cham: Springer International Publishing, 2014, pp.
273–276. [33]
[12] K. Sutling, Z. Mansor, S. Widyarto, S. Letchmunan, and N. H. Arshad,
“Agile project manager behavior: The taxonomy,” in 2014 8th.
471
Malaysian Software Engineering Conference (MySEC), Langkawi,
Malaysia, 2014, pp. 234–239, doi: 10.1109/MySec.2014.6986020.
D. Z. Zhang, “Towards theory building in agile manufacturing
strategies—Case studies of an agility taxonomy,” Int. J. Prod. Econ.,
vol. 131, no. 1, pp. 303–312, May 2011, doi:
10.1016/j.ijpe.2010.08.010.
K. Bleicher, Das Konzept integriertes Management. Frankfurt ; New
York: Campus, 1991.
U. Lindemann, Methodische Entwicklung technischer Produkte:
Methoden flexibel und situationsgerecht anwenden. Berlin: Springer,
2005.
K. Ehrlenspiel and H. Meerkamm, Integrierte Produktentwicklung:
Denkabläufe, Methodeneinsatz, Zusammenarbeit, 6., vollständig
überarbeitete und erweiterte Auflage. München Wien.
J. Feldhusen and K.-H. Grote, Eds., Pahl/Beitz Konstruktionslehre.
Berlin, Heidelberg: Springer Berlin Heidelberg, 2013.
J. Ponn and U. Lindemann, Konzeptentwicklung und Gestaltung
technischer Produkte. Berlin, Heidelberg: Springer Berlin Heidelberg,
2008.
H. Birkhofer, H. Kloberdanz, B. Berger, and T. Sauer, “Cleaning up
design methods - describing methods completely and standardised,”
presented at the International Design Conference, Dubrovnik, 2002,
pp. 17–22.
U. Lindemann, Methodische Entwicklung technischer Produkte:
Methoden flexibel und situationsgerecht anwenden, 3., korrigierte
Aufl. Berlin: Springer, 2009.
J. C. Ponn, “Situative Unterstützung der methodischen
Konzeptentwicklung technischer Produkte,” Technische Universität
München, München, 2007.
T. Reinicke, “Möglichkeiten und Grenzen der Nutzerintegration in der
Produktentwicklung : eine Systematik zur Anpassung von Methoden
zur Nutzerintegration,” Technische Universität Berlin, Berlin, 2004.
K. Gericke, C. Eckert, and M. Stacey, “What do we need to say about
a design method?,” presented at the 21th International Conference on
Engineering Design (ICED 2017), Vancouver, Canada, 2017.
U. Pulm, “Eine systemtheoretische Betrachtung der
Produktentwicklung,” Technische Universität München, München,
2004.
K. Ehrlenspiel, Integrierte Produktentwicklung: Denkabläufe,
Methodeneinsatz, Zusammenarbeit, 3., aktualisierte Aufl. München:
Hanser, 2007.
VDI, “VDI-Richtlinie 2206 - Entwicklungsmethodik für
mechatronische Systeme,” VDI-Verlag, Düsseldorf, Jun. 2004.
VDI, “VDI-Richtlinie 2221 - Methodik zum Entwickeln und
Konstruiere technischer Systeme und Produkte,” VDI-Verlag,
Düsseldorf, May 1993.
S. Biffl, A. Lüder, and D. Gerhard, Eds., Multi-Disciplinary
Engineering for Cyber-Physical Production Systems. Cham: Springer
International Publishing, 2017.
V. Meise, “Ordnungsrahmen zur prozessorientierten
Organisationsgestaltung: Modelle für das Management komplexer
Reorganisationsprojekte,” Westfälische Wilhelms-Universität
Münster, Münster, 2000.
S. Vajna, Ed., Integrated Design Engineering: ein interdisziplinäres
Modell für die ganzheitliche Produktentwicklung. Berlin: Springer
Vieweg, 2014.
W. Eversheim, W. Bochtler, R. Gräβler, and W. Kölscheid,
“Simultaneous engineering approach to an integrated design and
process planning,” Eur. J. Oper. Res., vol. 100, no. 2, pp. 327–337, Jul.
1997, doi: 10.1016/S0377-2217(96)00293-7.
B. Blanchard and W. Fabrycky, Systems Engineering and Analysis.
Englewood Cliffs, New Jersey: Prentice Hall, 1990.
R. G. Cooper, Winning at new products: creating value through
innovation, Fifth edition. New York: Basic Books, 2017.