See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/325277468

Defining Scaling Strategies for the Improvement of Agility Performance in

Product Development Projects

Article · May 2018

DOI: 10.1016/j.procir.2018.01.006

CITATION READS

1 46

6 authors, including:

Christian Dölle Christian Mattern

RWTH Aachen University RWTH Aachen University
39 PUBLICATIONS   36 CITATIONS    14 PUBLICATIONS   12 CITATIONS   

SEE PROFILE SEE PROFILE

Alexander Menges
RWTH Aachen University
6 PUBLICATIONS   1 CITATION   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Agile Product Development View project

Industrie 4.0 in Product Development View project

All content following this page was uploaded by Christian Mattern on 09 January 2019.

The user has requested enhancement of the downloaded file.

 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 (2017) 000–000
ScienceDirect
Procedia CIRP 00 (2017) 000–000
ScienceDirect www.elsevier.com/locate/procedia
www.elsevier.com/locate/procedia

Procedia CIRP 00 (2017)

Procedia CIRP 000–000
70 (2018) 29–34
www.elsevier.com/locate/procedia

28th
28th CIRP
CIRP Design
Design Conference,
Conference, May
May 2018,
2018, Nantes,
Nantes, France
France

Defining
Defining Scaling
Scaling28th Strategies
Strategies for
CIRP Designfor
the
the Improvement
Improvement
Conference,
of
of Agility
May 2018, Nantes, Agility
France
Performance
Performance
in Product Development
in Product Development Projects Projects
A new methodology to analyze the functional and physical architecture aof
Günther Schuh a, Eric Rebentisch b, Christian Dölle a, Christian Mattern a*, Georgiy Volevach a,
a b a a
existing products
Günther Schuh for an assembly
, Eric Rebentisch , Christianoriented
Alexander Mengesproduct
Dölle , Christian
a family
Mattern identification
*, Georgiy Volevach ,
a
Alexander Menges
a
a Paul
Laboratory for Machine
Laboratory for Machine
ToolsStief *, Jean-Yves
and Production
Tools and Production
Engineering Dantan,
WZL at RWTHAlain
Engineering WZL at RWTH Etienne,
Aachen University,
Aachen University, Ali Siadat
Steinbachstr.
Steinbachstr.
19, 52074 Aachen, Germany
19, 52074 Aachen, Germany
Sociotechnical Systems Research Center, Massachusetts Institute of Technology, 77 Massachusetts Avenue (E38-408), Cambridge, MA 02139-4307, USA
b
Sociotechnical Systems Research Center, Massachusetts Institute of Technology, 77 Massachusetts Avenue (E38-408), Cambridge, MA 02139-4307, USA
b
Écoleauthor.
* Corresponding Nationale
Tel.:Supérieure d’Arts et fax:
+49 241 80-28205; Métiers, Arts80-628205.
+49 241 et Métiers ParisTech, LCFCC.Mattern@wzl.rwth-aachen.de
E-mail address: EA 4495, 4 Rue Augustin Fresnel, Metz 57078, France
* Corresponding author. Tel.: +49 241 80-28205; fax: +49 241 80-628205. E-mail address: C.Mattern@wzl.rwth-aachen.de

* Corresponding author. Tel.: +33 3 87 37 54 30; E-mail address: paul.stief@ensam.eu

Abstract
Abstract
Increasingly uncertain market requirements and faster-paced innovation cycles have led to a paradigm shift towards Agile product development,
Abstract
Increasingly uncertain market requirements and faster-paced innovation cycles have led to a paradigm shift towards Agile product development,
which are based on the Agile Manifesto. Although initially developed for small-sized software development, recent studies focus on scaling Agile
which are based on the Agile Manifesto. Although initially developed for small-sized software development, recent studies focus on scaling Agile
Project
In today’sManagement (APM) practices
business environment, for larger
the trend towardsprojects
moreand complex,
product physical
variety product architectures.
and customization is unbroken. Due to this development, the need of
Project Management (APM) practices for larger projects and complex, physical product architectures.
However,
agile existing research
and reconfigurable lacks impact
production assessments
systems emerged to of cope
scaling decisions
with variouson the uncertainty
products reduction
and product efficiency
families. of aand
To design project, summarized
optimize productionas
However, existing research lacks impact assessments of scaling decisions on the uncertainty reduction efficiency of a project, summarized as
Agility Performance
systems as well as to (AP). This
choose thepaper presents
optimal producta framework to strategically
matches, product analysisscale Agileare
methods practices
needed.based on targeted
Indeed, most of project outcomes.
the known methods Using
aimthe
to
Agility Performance (AP). This paper presents a framework to strategically scale Agile practices based on targeted project outcomes. Using the
productaarchitecture
analyze and product
product or one organizational
family structures as input
on the physical parameters,
level. Differentthe initialfamilies,
product degree ofhowever,
project uncertainty
may differ is evaluated.
largely Next,
in terms of athe
setnumber
of scalable
and
product architecture and organizational structures as input parameters, the initial degree of project uncertainty is evaluated. Next, a set of scalable
Agile project
nature design parameters
of components. is derived.
This fact impedes an Individual scaling operations
efficient comparison are then
and choice correlated product
of appropriate to assess
with APfamily the chosenfor
combinations scaling strategy’s
the production
Agile project design parameters is derived. Individual scaling operations are then correlated with AP to assess the chosen scaling strategy’s
combined
system. effects on project cost, quality and schedule. The framework therefore equips project managers with aarchitecture.
decision support tool for strategic
combined effects on project cost, quality and schedule. The framework therefore equips project managers with a decision support tool fortostrategic
A new methodology is proposed to analyze existing products in view of their functional and physical The aim is cluster
project
these design in
products optimization
new assembly efforts.
oriented product families for the optimization of existing assembly lines and the creation of future reconfigurable
project design optimization efforts.
assembly systems. Based on Datum Flow Chain, the physical structure of the products is analyzed. Functional subassemblies are identified, and
©functional
a© 2018 The
2017 Theanalysis
Authors.isPublished
Authors. Published
performed.by Elsevier
by Elsevier B.V.
Moreover, Ltd. This is functional
a hybrid an open access article under
and physical the CC BY-NC-ND
architecture licenseis the output which depicts the
graph (HyFPAG)
© 2017 The Authors. Published by Elsevier B.V.
(http://creativecommons.org/licenses/by-nc-nd/3.0/)
Peer-review under responsibility of the scientific committee of the 28th CIRP Design Conference 2018.
similarity between product families by providing design support to both, production system planners and product designers. An illustrative
Peer-review under responsibility of the scientific committee of the 28th CIRP Design Conference 2018.
example of a nail-clipper is used to explain the proposed methodology. An industrial case study on two product families of steering columns of
Keywords: Agile
thyssenkrupp Project
Presta Management,
France Agility out
is then carried Performance,
to give a New
first Product Development,
industrial evaluationScaling
of the Agile, Sociotechnical
proposed approach.Systems Design
Keywords: Agile Project Management, Agility Performance, New Product Development, Scaling Agile, Sociotechnical Systems Design
© 2017 The Authors. Published by Elsevier B.V.
Peer-review under responsibility of the scientific committee of the 28th CIRP Design Conference 2018.

1. Introduction
Keywords: Assembly; Design method; Family identification Scrum or XP are currently the global standard in software
1. Introduction Scrum or XP are currently the global standard in software
development [4].
development [4].
Managing product development projects has become Emphasizing Agility in project design and management is
Managing product development projects has become Emphasizing Agility in project design and management is
characterized by increased volatility, uncertainty, complexity commonly referred to as Agile Project Management (APM). In
characterized
1.and
Introduction by increased volatility, uncertainty, complexity commonly
of referred toand
as Agile Project Management (APM). In
ambiguity, which has been popularized under the acronym thisthe product
context, therange
concept is characteristics
not seen as a setmanufactured and/or
of tools or methods,
and ambiguity, which has been popularized under the acronym this context,
assembled the
in this concept
system. is not seen as a
In this context, set of tools
the which or methods,
main challenge in
VUCA [1]. A recent study with managers across multiple but rather as a team performance indicator, reflects the
VUCA
Due [1].
to A
the recent
fast study with managers
development in theacross
domainmultiple
of but rather as
modelling and a team performance
analysis is now indicator,
not only to which
cope reflects
with the
single
regions and industries revealed that this trend is expected to processing efficiency of newly discovered project information
regions and industriesanrevealed
communication that this of trend is expectedand to processinga limited
efficiency of newly discovered project information
keep increasing,and ongoing
emphasizing the trend
need for digitization
project designs products,
[5]. A recent study product
analyzing range
856or existing
projects product
revealed families,
that APM
keep increasing,
digitalization, emphasizing
manufacturing the need
enterprises for
are project
facing designs
important [5].
but A
alsorecent
to be study
able toanalyzing
analyze 856
and to projects
compare revealed
products that
to APM
define
capable of adaptivity and change [2]. continuously gains interest in non-software domains.
capable
challenges of adaptivity and
in today’s market change [2].
environments: continuously gains interest in non-software domains.
Project management paradigms and product adevelopment
continuing new product families.
Furthermore, APM isIt can be observed
especially that classical
popular in new existing
product
Projecttowards
tendency managementreduction paradigms
of product anddevelopment
product development
times and Furthermore,
product APM is especially popular in new features.
product
methodologies proposing solutions for these obstacles have development (NPD) projects with a high degree of or
families are regrouped in function of clients innovation
methodologies
shortened proposing
productaround
lifecycles. solutions
In addition,for these
there A obstacles
is wide
an increasinghave development
However, (NPD)
assembly projects with a high degree of innovation
oriented product families are hardly to find.
been introduced the concept of Agility. range of (see Fig. 1) [6].
been introduced
demand of around thebeing
customization, conceptat of Agility.
the same A wide
time in arange of
global (see
On Fig.
the 1)product
[6]. family level, products differ mainly in two
methods and tools surrounding the term have evolved One major reason for the Agility concept’s increasing
methods and tools
competition surrounding thetheterm haveThisevolved One major reason for the Agility concept’s and increasing
especially inwith the competitors
field of softwareall over world.
development, initiatedtrend,
by main characteristics:
popularity in NPD for(i)architectures
the number of physical
of components products(ii) liesthe
in
especially
which is in the
inducing field
the of software
development development,
from macro initiated
to by
micro popularity
type of in
componentsNPD for architectures
(e.g. mechanical, of physical
electrical, products lies in
electronical).
values and principles provided by the “Manifesto for Agile shorter product lifecycles and uncertain requirements. These
values and principles
markets, provided lot by the “Manifesto for Agile shorter product lifecycles and uncertain requirements. These
Software results in diminished
Development” [3]. Drivensizes due to augmenting
by continuous, iterative Classical
trends methodologies
put pressure considering
on concurrent mainly
engineering single products
development
Software
product Development” [3]. Driven by continuous, iterative trends put pressure on concurrent engineering development
deliveryvarieties
of a (high-volume
working product, to low-volume production) like
Agile frameworks [1]. or solitary,
activities andalready
continuousexisting product families
synchronization [7]. analyze the
delivery
To cope withof this
a working
augmenting product,
varietyAgile
as wellframeworks
as to be ablelike to activities
product and continuous
structure synchronization
on a physical [7].
level (components level) which
identify
2212-8271 possible optimization
© 2017 The Authors. Publishedpotentials in the existing
by Elsevier B.V. causes difficulties regarding an efficient definition and
2212-8271 © 2017 The Authors. Published by Elsevier B.V.
production system,
Peer-review under it is important
responsibility to have
of the scientific a precise
committee knowledge
of the comparison
28th CIRP Design Conference 2018.of different product families. Addressing this
Peer-review under responsibility of the scientific committee of the 28th CIRP Design Conference 2018.
2212-8271 © 2018 The Authors. Published by Elsevier Ltd. This is an open access article under the CC BY-NC-ND license
(http://creativecommons.org/licenses/by-nc-nd/3.0/)
2212-8271 © 2017 The Authors. Published by Elsevier B.V.
Peer-review
Peer-review under
under responsibility
responsibility of scientific
of the the scientific committee
committee of the of theCIRP
28th 28thDesign
CIRP Conference
Design Conference
2018. 2018.
10.1016/j.procir.2018.01.006
30 Günther Schuh et al. / Procedia CIRP 70 (2018) 29–34
2 Author name / Procedia CIRP 00 (2018) 000–000
35%
Traditional Methods Agile Methods
Share of n = 856 projects
30%
25%
20%
15%
10%
5%
0%
Totally new Some components Totally new
product to market new to market product to
company
Fig. 1. Project Management approach depending on the degree of innovation
To face these challenges, current studies propose to replace
parts the common waterfall project design with APM methods
by applying rapid prototyping techniques to continuously
gather and incorporate customer feedback [8].
However, while designing projects for maximum Agility
Performance (AP) has been studied for small-scale software
projects, there is little research on the applicability of APM for
multi-team NPD projects of complex, physical product
architectures. In particular, the scalability of Agile practices
and the impact of scaling on project outcomes is of high interest
for APM. Furthermore, the implications of scaling on AP are
insufficiently studied [9].
Therefore, this paper aims at developing project design
strategies for application in large NPD projects and complex
product architectures, with the goal of improving AP and
project outcomes. The developed Agile Scaling Strategy
framework consolidates uncertainty-caused challenges in
large-scale product development with best practices in APM.
Initial project uncertainty is assessed using mapping techniques
for sociotechnical systems. Afterwards, scalable project design
parameters are derived from research on Agility, before
operationalizing their impact on uncertainty reduction. This
impact is lastly converted into implications for project
outcomes.
2. Current state of research
This research examines the impact of Agile methods on
NPD projects for complex product architectures. Therefore,
existing studies on the quantitative scalability of AP are
introduced. Additionally, current efforts to design Agile NPD
and to map uncertainty in product architectures are presented.
2.1. Scalability of Agile Project Management
The scalability of APM methods and tools have been studied
for multiple applications. To achieve Agility throughout the
entire organization in the layers program, portfolio and team,
LEFFINGWELL introduces the Scaled Agile Framework (SAFe)
[10]. While the framework itself does not include measures of
AP, further studies develop quantitative adoption levels of
SAFe to assess an organization’s Agile maturity [11]. A set of
discrete scaling parameters on a project level is derived within
the Disciplined Agile Delivery (DAD) framework. However,
no AP metrics are provided [12].
While SAFe and DAD target entire organizations, other
research focuses on scaling Agility on a project level. To
provide guidance in scaling Scrum, the most popular Agile
framework, regardless of the number of teams or their
geographical distribution, LARMAN AND VODDE introduce the
Large-Scale Scrum (LeSS) framework. Instead of entirely
changing the principles of Scrum, the authors scale up the
responsibilities of Product Owners (POs) to enable
practitioners to implement the framework in a multi-team
Some new project [13]. Analyzing the implications of seven typical
components to
company characteristics of Agile projects on the factors cost, quality and
time, GLAIEL introduces the System Dynamics based Agile
Project Dynamics (APD) model. Focusing on single-team
software projects, the impact of increased Agility on project
outcomes is simulated and quantified [14].
All major frameworks targeting the scalability of Agility do
not take product-specific characteristics into account. To
quantify AP as uncertainty reduction, initially present
uncertainties in the functional requirements need to be
addressed. This is studied in Agile NPD systems design.
2.2. Agile NPD Systems Design
To adequately differentiate uncertainty in the design of
Agile NPD systems, GARTZEN ET AL. introduce the three
dimensions market, product and process as independent scales
of uncertainty [15]. SCHUH ET AL. expand this approach by
introducing indicators to evaluate the feasibility of iterative
development of certain product parts [16]. DIELS ET AL.
consolidate the two studies by defining a rating system for the
uncertainty dimensions to validate the suitability of iterative
development. Based on the results for individual product
modules, a measure for the overall suitability of iterative
development for the entire architecture is derived [17]. The
need for a suitability evaluation is derived from the main
differences and requirements between the development of
software and physical products [18].
To execute the development of modular product
architectures using Agile methods, DIELS ET AL. introduce the
highly iterative product development (HIPD) process for
physical products. Work packages are derived using Module
Indication Matrices (MIM), before being prioritized by the
supervisor using a comparison of pairs [19].
A well-established method to design NPD sociotechnical
systems with an emphasis on modeling interactions between
the layers product, process and organization are combinations
of Design Structure Matrices (DSM). To map additional work
or rework, caused by the interdependency of development
tasks, SMITH AND EPPINGER introduce the DSM based Work
Transformation Matrix (WTM) method (see Fig. 2) [20]. The
iterative increase in scope due to additional work and rework is
mapped in a (𝑛𝑛 𝑥𝑥 𝑛𝑛) matrix using fractions of the remaining
scope in task 𝑛𝑛.
Legend
T1 T2
T1 Task Number/Description: Task No. 1
T1 4 0.2 4 Task Duration: 4 Time Units
20% of work transferred after
T2 0.4 7 0.2 Work Transformation:
every iteration.
Fig. 2. Work Transformation Matrix (WTM) method
 Günther Schuh et al. / Procedia CIRP 70 (2018) 29–34 31
Author name / Procedia CIRP 00 (2017) 000–000 3

Addressing the need for customer-focused iteration design
for Agile NPD of highly innovative systems, TERHO ET AL.
introduce the Minimum Viable Product (MVP) concept. The
goal of MVPs is to prioritize development based on the most
beneficial uncertainty reduction through feedback after every
iteration. Ideal MVPs are product versions that are just above a
viable level to yield reliable learning effects [21]. Learning in
Agile sociotechnical systems is the continuous improvement of
team performance through less rework and faster development.
Consolidating current efforts in designing Agile NPD projects
with scalability studies of AP, there is a clear literature gap
between mapping project uncertainty and the implications of
APM techniques on the project’s AP.
3. The Agile Scaling Strategy framework
Deriving modular product architectures has been studied for
various use-cases. To allow for iterative adjustments of the
architecture based on initially uncertain information, the
functional requirements from the product backlog are
translated into Mechatronic Function Modules (MFM). These
describe basic modules of a mechatronic product and are
connected through physical links and signals [22].
The main advantages of using MFMs for the Agile Scaling
Strategy framework lie in the ease of application on a product
backlog, the possibility to iteratively adjust the architecture and
the specific focus on mechatronic systems development, as
opposed to solely software. The initially derived MFMs are
clustered in a second step with the goal to derive a set of MVPs,
that make up the entire product when combined (see Fig. 4).
Product

To provide guidance for project managers, who aim at MVPs

designing large, complex NPD projects using APM, the Agile
Scaling Strategy framework has been developed. By applying
the framework’s principles, uncertainty is strategically
decreased in different project sub-systems. This is achieved by
targeted scaling of Agile project design parameters and a
resulting improvement of the project’s AP and project
outcomes. The input parameters are derived from product-
related as well as organizational characteristics. These
parameters are evaluated, and an initial mapping of uncertainty
is achieved. Based on the uncertainty evaluation, Agile project
design parameters are individually scaled. In a last step, the
achieved benefit from improved AP is compared to
impediments and costs associated with implementing a scaling
strategy (see Fig. 3).
Product
Characteristics
Agility
Performance
Agile Project Design Parameters
Product Backlog Transformation MFMs
Fig. 4. Product Architecture Design using MFMs and MVPs
The proposed approach is to cluster the derived MFMs into
MVPs to maximize learning effects after every iteration, when
a set of MFMs is jointly presented as a MVP to the customer.
This is achieved by aid of the DSM method on the derived
MFMs. A relationship between two MFMs 𝑖𝑖 and 𝑗𝑗 is mapped if
a joint release of 𝑖𝑖 and 𝑗𝑗 yields better feedback than an
individual release of MFM 𝑖𝑖 . MVPs are then derived by
applying a clustering algorithm on the mapped relationships.
Finally, the initial degree of uncertainty within and between
every MFM of a MVP needs to be assessed. To do so, three
categories for intra-module uncertainty and one category for
inter-module uncertainty are proposed (see Table 1).

Table 1. Intra-module and inter-module uncertainty measures

Organizational Uncertainty Category Module Characteristic Uncertainty

Project Outcomes
Characteristics
Entirely new High
Type of Construction
Adjustment Medium
(Intra-Module)
Repetitive Low
Radical High
Degree of Innovation
Fig. 3. The Agile Scaling Strategy Framework Incremental/Modular Medium
(Intra-Module)
Architectural Low
This section introduces the methods used and tools applied
High High
to derive the framework’s core elements. Technological Novelty
Interdependent Medium
(Intra-Module)
3.1. Mapping of initial project uncertainty Low Low
Mechanical and Information High
To adequately assess the need for a specific scaling strategy, Type of Interaction
Mechanical Medium
(Inter-Module)
the project’s initial uncertainty must be mapped. As identified Information Low
before, the product poses the main source of uncertainty. In
traditional APM, all customer requirements are summarized in Highly innovative modules, who are estimated to feature
a product backlog. The goal of describing product new technology, without the potential to reuse existing
characteristics in the Agile Scaling Strategy framework is to constructions, have the highest degree of internal uncertainty
transfer uncertain requirements onto uncertain product and, thus, require the highest emphasis on AP. In addition,
modules. Therefore, the product backlog is used in an initial MFMs can be connected by multiple mechanical or
step to derive a preliminary modular product architecture. information connectors. Strong physical or information-based
interconnectivity fosters the propagation of uncertainty. If a
32 Günther Schuh et al. / Procedia CIRP 70 (2018) 29–34
4 Author name / Procedia CIRP 00 (2018) 000–000
design change is decided in a module after an iteration, it also
affects the further scope of every module connected to it.
To map uncertainty within and between MVP modules, the
WTM method is used. For every MVP, two WTMs are set up,
with the corresponding modules M featured on the matrices’
rows and columns. The Additional Work WTM is used to map
the impact of uncertainty on every module’s remaining scope
after a development iteration. The Rework WTM expresses the
uncertainty-caused rework in every module during a
development iteration (see Fig. 5).
Additional Work WTM Rework WTM
MVP1 M1 M2 M3 M4 MVP1 M1 M2 M3
M1 0.1 0.2 0.3 0.2 M1 0.1 0 0.2
M2 0 0.1 0 0.1 M2 0 0.1 0 0
M3 0 0 0.3 0 M3 0.3 0 0.2
M4 0.2 0 0 0.1 M4 0 0.1 0 0
Fig. 5. Additional Work and Rework WTM
In the provided example, cell (3,3) of the Additional Work
WTM indicates a high degree of intra-module uncertainty in
module M3. This is expressed as a 30% increase in scope after
every iteration due to additional work. Additionally, 20% of the
developed module features are estimated to require rework
(cell (3,3) of the Rework WTM). Row 1 of the Additional Work
WTM indicates high interactions between module M1 and the
other modules, leading to uncertainty-caused work transfer.
The qualitative assessment of uncertainty according to
Table 1 and the transfer of qualitative values into quantitative
estimations in the two WTMs is conducted jointly with the all
module development teams and the customer during an initial
release planning phase, which replaces the first iteration. In this
release planning phase, every module’s scope is estimated
through measurable and comparable units. Comparability is
facilitated through Agile estimation techniques like Planning
Poker, where development scope is estimated using a point
system. After the quantitative scope assessment for every
module, uncertainty-caused transformation of scope is mapped
in the WTMs. Based on this assessment, project execution is
designed to specifically address the initially identified areas of
uncertainty. The project design parameters available to
individually scale Agility based on every development team’s
needs are presented in the following section.
3.2. Derivation of scalable APM techniques
To derive a list of scalable APM techniques that address the
previously defined uncertainties within a NPD project, a
systematic literature review was conducted. The goal was to
identify and categorize proven methods in the field of APM,
that are applicable to multi-team NPD projects of any size.
Using the literature search engines Google Scholar, IEEE
Xplore and SpringerLink, the following terms were searched in
literature titles and abstracts to extract potentially applicable
project design parameters: “Agile Action”, “Agile Enabler”,
“Agile Method”, “Agile Practice”, “Agile Principle”, “Agile
Technique”, and “Agile Tool”. The review has yielded a total
of 164 sources that explicitly mention one of the terms and
provide at least one detailed example for an Agile project
design parameter.
The extracted list of project design parameters has been
found to contain more than 100 entries. Before identifying and
applying filter criteria to extract the final Agile Scaling
Strategy components, the list was consolidated by combining
entries that imply the same action, but are named differently
depending on the examined literature source. For instance, the
practice “Customer Involvement” implied similar actions as the
practices “Customer Integration” or “Customer Collaboration”.
Similarly, “Stand-Up Meetings” implied similar project design
M4 decisions as “Face-to-Face Meetings” or “Face-to-Face
0.1 Communication”.
After manually summarizing the list of parameters by
comparing the definitions in the corresponding literature
0
sources, the remaining project design parameters were further
narrowed down using a set of three filter criteria:
 Parameters focusing specifically on software development
 Parameters only applicable in specific frameworks
(e.g. Scrum, SAFe, XP)
 Parameters that are not scalable for specific project sizes
As the Agile Scaling Strategy framework focuses on
complex, physical NPD projects, all parameters that are strictly
related to software development (e.g. “Coding Standards” and
“Unit Tests”) were withdrawn from further consideration.
Secondly, all parameters that are only applicable in specific
frameworks such as Scrum or XP (e.g. “Refactoring”) are
excluded as well. Lastly, the focus of this research is to
examine the scalability of project design parameters based on
initial product uncertainty. Therefore, all parameters that imply
the use of specific aids (e.g. “Utilizing Kanban Boards”) are
excluded. In the presented framework, these aids are
implementation support tools for certain project design
parameter scales.
The overall systematic literature analysis has yielded a final
set of four categories and 14 project design parameters
constituting the basis of an Agile Scaling Strategy (see Table
2). AP is increased with efficient customer involvement, which
can be scaled based on four project design parameters.
Increased customer and development team co-location as well
as customer dedication to the project facilitate feedback quality
and efficiency. Furthermore, the number of POs and their
degree of involvement need to increase with increased
uncertainty and demand for technological expertise.
APM stresses the importance of collaboration and
knowledge exchange within and between teams to foster
uncertainty reduction, which was also reflected by multiple
examined project design parameters [23]. Therefore, in the
second scaling category, the resources allocated to
collaboration and information exchange within and between
teams need to be scaled. In this context, the project design can
vary depending on the time each team spends on development
or on supporting activities to distribute information and
knowledge within a team or between different teams.
Moreover, the literature review revealed a distinction between
information distribution and gathering efficiencies. Only if
both sending and receiving parties process the information
 Günther Schuh et al. / Procedia CIRP 70 (2018) 29–34 33
Author name / Procedia CIRP 00 (2017) 000–000 5

correctly, AP is improved. To implement the scaling of goal is to scale up project design parameters in MVP module
collaboration for multiple teams and stakeholders, Scrum of teams where intra-team or inter-team uncertainty are especially
Scrums for POs, Scrum Masters and lead developers become high, which leads to a decrease in additional work or rework.
feasible within MVPs with multiple modules. An example of the impact of a scaling strategy is provided
In a third category, the design of every Agile team needs to in Fig. 6, which illustrates the Additional Work and Rework
address its AP requirements. Fully self-organized, small, co- WTM for the MVP described in Fig. 5. The project manager
located and multidisciplinary teams are key components of scaled up both intra-team and inter-team AP in module M3 to
successful Agile projects [3,13]. In addition, high initial reduce uncertainty. This results in a projected decrease in
uncertainty implies the need for team members who are additional work from 30% to 10% and a decrease in rework
experienced with iterative NPD projects. If the expected scope transfer from M1 to M3 from 30% to 20% (see cell (3,3) and
of a module widely exceeds all other scopes within a MVP, the cell (3,1) respectively). The quantitative impact of a scaling
module needs to be further divided and developed by multiple operation on uncertainty is assessed by the same parties that
teams if additional scaling of the team’s size would require too agreed on and set up the initial degree of uncertainty.
much coordination effort. Additional Work WTM - Scaled Rework WTM - Scaled
Lastly, the durations of development iterations and MVP MVP1 M1 M2 M3 M4 MVP1 M1 M2 M3 M4
releases need to reflect the individual degrees of initially
M1 0.1 0.2 0.3 0.2 M1 0.1 0 0.2 0.1
estimated uncertainty. Both parameters should not be altered
M2 0 0.1 0 0.1 M2 0 0.1 0 0
for all teams to keep the time-boxed nature of Agile product
development. The length of both the iteration and the release M3 0 0 0.1 0 M3 0.2 0 0.2 0

cycle depends on various factors like the ease of getting M4 0.2 0 0 0.1 M4 0 0.1 0 0
feedback, the amount of uncertainty within the project and,
most importantly, how often the project manager is willing to Fig. 6. Impact of higher AP on additional work and rework
allow for refinement of the current course of the project. The
scaling of iterations typically ranges from one to six weeks, This decrease in additional work and rework during the
with releases consisting of multiple iterations and total following development iterations directly results in faster
durations between eight and twelve weeks [13,14]. Time-to-Market. Furthermore, product quality is increased due
to early reduction of uncertain customer requirements. In
Table 2. Agile Scaling Strategy Project Design Parameters addition, faster releases reduce variable project costs.
However, depending on the chosen strategy, costs of scaling
Category Project design parameter
the project design parameters incur, which results in an increase
Number of Product Owners in total project costs. Ideally, all module development teams
Location of and Tools for Customer are co-located and designed with the highest degrees of
Customer Involvement Collaboration experience, dedication and multidisciplinarity. However,
Customer Influence practically implementing such strategies for large NPD projects
Customer Dedication results in implementation costs throughout the entire project.
Product Feature Development
These effects may outweigh the achieved improvements.
Project managers and stakeholders therefore need to carefully
Intra-Team Collaboration
Work and Resource Allocation assess the quantitative and qualitative impediments when
Inter-Team Information Distribution introducing a strategy. While quantitative impediments are
Inter-Team Information Acquisition assessable through monetary projections, qualitative impacts of
Number of Team Members the chosen strategy depend on the project’s parent organization
Team Member Experience
(see Fig. 1). Experienced organizations with a projectized
structure allow for more flexibly adjustable project designs
Workforce Allocation Team Member Location
than functional organization structures with low management
Team Member Dedication support. Furthermore, organizations that facilitate cultural
Team Multidisciplinarity Agile values, such as team motivation and empowerment,
Iteration Duration perform better when APM principles are scaled. Project
Release Planning
Release Duration managers always need to include the parent organization when
choosing an Agile Scaling Strategy for a NPD project.
After the systematic derivation of scalable project design
To validate the framework’s approach, a case study was
parameters, individual scales for every module development
performed. The results are presented in the following section.
team can be chosen to strategically increase AP in modules
where uncertainty is particularly high. The outcomes of a
4. Applicability study
strategy are presented in the following section.
A first validation of the framework has been conducted
3.3. Agility Performance and project outcomes measurement
through a case study in a German start-up company, which
applies APM techniques for NPD in the e-mobility sector. The
In the framework’s third and final step, the derived Agile
goal was to assess the applicability of the framework by
project design parameters of an Agile Scaling Strategy are
determining how the company evaluates uncertainty and
individually scaled to reach the most feasible degree of AP. The
34 Günther Schuh et al. / Procedia CIRP 70 (2018) 29–34
6 Author name / Procedia CIRP 00 (2018) 000–000
correlates it with the product architecture. Furthermore, one
specific NPD project was evaluated regarding the applicability
and scalability of the presented project design parameters.
The start-up operationalizes product-related uncertainty by
transforming User Stories into questions, which are gradually
answered by developing parts of the product structure. After
transforming uncertainty into questions, they are prioritized by
the PO and attributed to development teams. Prioritization is
done based on the estimated development effort and the
expected customer feedback benefit from a prototype, that
presents an answer to the question. The goal is to find an
optimum between effort and feedback benefit. The product
development organization is structured based on the product
architecture into a total of six so-called Lead Engineering
Groups (LEGs) of 8-12 people, which are responsible for
generic product assemblies such as “Powertrain” or “Battery”.
Prototyping is done by applying the MVP concept. The
previously prioritized questions are clustered into MVPs such
as “Design-MVP” or “Drivetrain-MVP”. The initial product
architecture is adapted from proven product architectures from
the automotive industry. While the overall responsibility of
every LEG does not change during the project, the assemblies,
sub-assemblies and individual parts, that are attributed to every
LEG, are subject to change throughout the course of the project.
Subsequently, the product architecture is continuously adjusted
and further specified. The progress on answering questions and
reducing uncertainty within and between teams is assessed
through weekly Stand-up Meetings between developers, Scrum
of Scrums of LEG leaders, and monthly meetings with all
stakeholders. Co-location is empowered through an office
design containing open-space areas, collaboration areas and
team offices.
The overall case study results support the framework’s
potential. The start-up already clusters the product architecture
into MVPs and prioritizes development based on uncertainty.
Multiple parameters from the categories Work and Resource
Allocation and Workforce Allocation are individually scaled.
While the other two categories are currently not adjusted to
uncertainty, the start-up experts indicate that the parameters
will become relevant once the company grows. Co-location and
flexible collaboration meetings are currently not associated
with scaling costs, which will change with increased scope.
5. Conclusion
Rising complexity and shorter product life cycles have led
to the adoption of APM practices in NPD projects of complex,
physical product architectures. This paper introduces a
framework to assess the need for improved AP based on the
degree of initially present uncertainty. The increase in AP is
achieved by strategically scaling up Agile project design
parameters. Uncertainty and the impact of scaling strategies are
mapped using WTMs. By collaborating with all stakeholders,
implementation costs are relatable to project outcome
improvements in schedule and quality.
After deriving the theoretical relevance, a case study
revealed the framework’s applicability. Future research needs
to apply the framework in a project with larger scope and
View publication stats
different degrees of uncertainty. The additional data facilitates
the derivation of ideal and most cost-efficient strategies for
individual project scenarios and input parameters.
References
[1] Mack O, Khare A. Perspectives on a VUCA World. In: Mack O et al.,
editors. Managing in a VUCA World, Cham: Springer; 2016. p. 3-19.
[2] The Scaled Agile Institute. The VUCA Report; 2016. Available at:
http://www.strategicagilityinstitute.com/vucareport/.
[3] Beck K et al. Manifesto for Agile Software Development. 2001.
[4] Dingsøyr T, Brede Moe N. Towards Principles of Large-Scale Agile
Development. In: Dingsøyr T et al., editors. Agile Methods. Springer:
Cham. 2014. p. 1-8.
[5] Conforto E C et al. The agility construct on project management theory.
In: International Journal of Project Management. 2016;34:660-674.
[6] Conforto E C, Rebentisch E, Amaral D C. Project Management Agility
Global Survey. Cambridge: Consortium for Engineering Program
Excellence, Massachusetts Institute of Technology; 2014.
[7] Müller-Stewens B, Möller K. Performance in new product development:
a comprehensive framework, current trends, and research directions.
In: Journal of Management Control. 2017;28:157-201.
[8] Cooper R G. Agile-Stage-Gate Hybrids: The Next Stage for Product
Development. In: Research Technology Management. 2016;59:21-29.
[9] Dingsøyr T, Brede Moe N. Research challenges in large-scale agile
software development. In: SIGSOFT Software Engineering Notes.
2013;38:38-39.
[10] Leffingwell D. SAFe® 4.0 for Lean Software and Systems Engineering.
2016; Available at: http://www.scaledagileframework.com/
[11] Turetken O, Stojanov I, Trienekens J J M. Assessing the adoption level
of scaled agile development: a maturity model for Scaled Agile
Framework. In: Journal of Software: Evolution and Process.
2016;26:1172-1192.
[12] Ambler S, Lines M. Disciplined Agile Delivery. Boston: Pearson
Education, Inc.; 2012.
[13] Larman C, Vodde B. Practices for Scaling Lean & Agile Development.
Boston, MA: Addison-Wesley; 2010.
[14] Glaiel F, Moulton A, Madnick S E. Agile Project Dynamics: A System
Dynamics Investigation of Agile Software Development Methods.
Engineering Systems Division Working Paper Series, Massachusetts
Institute of Technology. 2013;31.
[15] Gartzen T, Brambring F, Basse F. Target-oriented Prototyping in Highly
Iterative Product Development. In: Procedia CIRP. 2016;51:19-23.
[16] Schuh G, Riesener M, Diels F. Structuring highly iterative product
development projects by using HIP-indicators. IEEE International
Conference on Industrial Engineering and Engineering Management.
2016;12:1171-1175.
[17] Diels F, Riesener M, Schuh G. Methodology for the Suitability
Validation of a Highly Iterative Product Development Approach for
Individual Segments of an Overall Development Task. In: Advanced
Materials Research. 2016;1140:513-520.
[18] Schuh G, Rudolf S, Riesener, Kantelberg J. Application of Highly-
Iterative Product Development in Automotive and Manufacturing
Industry. In: ISPIM Innovation Forum. Boston, MA: The International
Society for Innovation Management. 2016.
[19] Diels F, Rudolf S, Schuh G. Highly Iterative Product Development
Process for Engineering Projects. In: Applied Mechanics and Materials.
2015;794:532-539.
[20] Smith R P, Eppinger S D. Identifying Controlling Features of
Engineering Design Iteration. In: Management Science.
1997;43:276–293.
[21] Terho H, Suonsyrjä S, Systä K. The Developers Dilemma: Perfect
Product Development or Fast Business Validation? In: Product-Focused
Software Process Improvement; 2016. p. 571-579.
[22] Schuh G, Rudolf S, Breunig S. Modular Platform Design for
Mechatronic Systems using Axiomatic Design and Mechatronic
Function Modules. Procedia CIRP. 2016;50:701-706.
[23] Bick S, Scheerer A, Spohrer K. Inter-Team Coordination in Large Agile
Software Development Settings. In: XP2016 Proceedings; 2016. p. 1-5.