SCALED AGILE @ SYSTEMS ENGINEERING...mentioned questions and explain them using the combined approach as an example. The potential economic benefits are also highlighted below. A balanced

SCALED AGILE @ SYSTEMS ENGINEERINGHow two seemingly different approaches to solving a problem create synergies in R&D and increase efficiency.

EFFECTIVENESS

REACTION

FLEXIBILITY

ADAPTIVITY

INNOVATION

Content

01 Introduction 6

02 What Do We Mean by Agility? 8

03 What Do We Mean by Systems Engineering? 10

04 The Synthesis, or: The Best of Both Worlds 14

05 The Agile Systems Engineering Transformation 24

06 Outlook 28

2 3

SCALED AGILE @ SYSTEMS ENGINEERING I September 2020

Agility and systems engineering are an integral part of responsive, flexible product development.

In recent decades, the business world has been character-ized by volatility, uncertainty, complexity and ambiguity – or “VUCA,” as the concept is known for short. Driven by climate change and the ongoing pandemic, this has recently been supplemented by an additional acronym – “BANI,” which stands for brittle, anxious, nonlinear and incomprehensible. It forms a new framework in which volatility and complexity no longer adequately describe the current shift from events that are difficult to predict toward those that are entirely unpre-dictable1. Together, the influencing factors of both thought models present companies with the central task of adapting to new framework conditions. This has a particular impact on the area of R&D, which is faced with the challenge of having to work increasingly effectively and efficiently, while at the same time, more responsive and flexible product developments are required.

An example of this is the increasing degree of complexity in the development of mechatronic systems – not only is the number of functional requirements increasing, but also the demand for interdisciplinarity. The main drivers of this trend are digi-tal technologies and the associated pressure to innovate. The market increasingly demands networking and data-driven business models. For system development, this means that tra-ditional structures and interface-optimized processes must be fundamentally reconsidered in favor of integrative approach-es. Among other things, this is reflected in the change from hardware-oriented development to a more function-oriented development. If companies have neglected this step in recent years, this can often now result in delays to product deliveries, high reworking costs for content relevant to certification, or even a complete lack of planned development scope.

In the search for a solution to these and other challenges such as short technology cycles, regulatory requirements and

employee motivation, R&D currently favors two models – sys-tems engineering (SE) or the Scaled Agile Framework (SAFe®). Both models have their own strengths, but also reveal areas that have not yet been taken into account and where further potential can be tapped.

The aim of this white paper is to present the profitable aspects of both models in a joint synthesis and thus present a systems engineering concept that is both agile (adaptive) and integra-tive. The central application for this lies in mastering techno-logically complex development projects that require fast and flexible adaptation options due to a dynamic or uncertain envi-ronment. The added value of this approach is also described in the standard reference work from INCOSE (International Coun-cil of Systems Engineering), which has set up its own working group to investigate agile systems engineering2.

1) Grabmeier, S. (2020): BANI vs. VUCA, Source: (https://stephangrabmeier.de/bani-vs-vuca/), as at: July 22, 2020

2) INCOSE (2015): Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, Fourth Edition, John Wiley & Sons

The transformation takes place at individual speeds but traditional organizations face similar obstacles, which must be overcome.

In the practice of transformation, many companies have begun to implement at least one of the two models. However, they are often stuck at individual stages. A non-representative sur-vey conducted by MHP in July 2020 of 20 clients from various sectors revealed five recurring questions with which companies are confronted when implementing and anchoring agility and/or systems engineering:

For what should we use SE/agility and how will we benefit from it?

We know the theory and roles – how does the practical implementation work?

How can our processes and tools be tailored to SE or agile methods?

Synchronization with organization – how do we solve the link to other areas?

Agility has only worked in software so far – how can we scale the model?

The consistent implementation of the system concept in the development and organization, and the scaling of team prin-ciples at program or portfolio level often fail due to the stan-dard processes and structures of a functional hierarchy (orga-nizational structure). In practice, it is not sufficient simply to describe the central roles such as System Architect, Function Owner or Agile Coach without enabling them to be integrated into the organization and incorporating them significantly into the processes. Therefore, this article will address the afore-mentioned questions and explain them using the combined approach as an example.

The potential economic benefits are also highlighted below.

A balanced combination of agile process models and sys-tems engineering allows potential savings of 10 to 50 per cent.

Three parameters are taken into account when focusing on potential savings: quality costs (potential savings due to elimi-nation of the need for improvements), time to market / cost of delay (revenue and competitive advantages due to earlier market entry of the systems) and innovation revenue (revenue from minimum viable products or unique features with innova-tive customer benefits). Of course, the potential depends on the respective sector as well as the system complexity and the market environment, and can only serve as a basic indication here. Further potential, such as higher employee satisfaction

(lower sickness rates, higher employer attractiveness and lower turnover), was not included due to inconsistent measurement methods used by the companies, but is a positive side effect. The following three main topics are distinguished for the implementation of the approach and will be described in more detail later in the white paper.

1) Use of agile and systems engineering methods at team levelIncrease in efficiency ~10 per cent [Source: MHP project database].

2) Transformation and scaling at organizational levelIncrease in productivity ~20–50 per cent [Source: www.scaledagileframework.com]3.

3) Introduction of an agile (adaptive) system architectureIncrease in efficiency in complex systems ~10–40 per cent[Source: MHP project database]

Before these aspects are considered in detail, a uniform under-standing of agility and systems engineering should be created.

3) Scaled Agile – SAFe 5.0 , source: (https://www.scaledagileframework.com/safe-for-lean-enterprises/), last updated July 22, 2020

01

Introduction

4 5


4

Dynamic markets require dynamic companies.

In the context of project and program management, the term “agility” is used to describe a wide range of approaches, meth-ods and tools, some of which are used with varying degrees of success. Used by 54% of respondents, SAFe® is the most com-monly used scaling framework, ahead of LeSS and in-house solutions4.

In essence, however, agility does not describe the use of a specific project management method, but refers to the basic ability to respond effectively and competently to an increas-ingly uncertain and unpredictable operational environment. To make this possible, two basic principles are of central impor-tance: Flexibility and adaptability.

Transferred to a project, this means that changes are perceived not as a disruption, but as part of the problem-solving process. However, in order to avoid arbitrary reactions and to ensure predictable project success, agile process models have been developed that reflect the work results and working methods by means of short iteration cycles and recurring routines, and

at regular intervals. In a competitive environment, agility is therefore the by-product of natural selection, based firstly on variation and secondly on “survival of the most adaptable,” or the most effective/efficient solution. Therefore, short iteration cycles enable partial solutions to be tested, developed incre-mentally or rejected as unsuitable. The result is a process of continuous adaptation, improvement and learning.

Hüsselmann5 has derived the central paradigms, principles and goals of agility from the two core principles of flexibility and adaptability (Figure 1). They can also be found in the traditional project management standards, but are often not used much in practice.

4) Komus, , A. et al. (2020): Study Status Quo (Scaled) Agile 2019/2020, Ko-blenz University of Applied Sciences February 2020

5) Hüsselmann, C.; Maibach, M. (2020): Agilisierung des Projektportfolioman-agements (Agilization of project portfolio management).Praktiken und Rollen für traditionelle Unternehmen (Practices and roles for traditional companies), WI [report] no. 012, Gießen/Friedberg: THM, ISSN 2568-0803

02

What Do We Mean by Agility?

Figure 1: Paradigms and goals of agility according to Hüsselmann

Communication

Simplicity Delegation

Adaptivityand

Flexibility

Rolling Planning Reflexion

Paradigms

Robustness

Effectiveness

Innovation

Reaction

Goals

76


“Agile process models support the application of agile values and principles. They promote communication and interaction, transfer responsibility to the affected employees and place great value on functional project items, good collaboration with the customer and willingness to change for the purposes of greater customer satisfaction or a better product.” GPM Deutsche Gesellschaft für Projektmanagement e.V. (Hg.) (German Association for Project Management) (2019): Competency-based project management (PM4). Handbuch für Praxis und Weiterbildung im Projektmanagement (Handbook for practice and training in project management).Nuremberg: GPM Deutsche Gesellschaft für Projektmanagement, p. 163

Paradigms in the change of disruption and ambiguity of time.

Based on our experience at MHP, we understand that many paradigms that have created structure and stability in recent decades are under scrutiny in a world characterized by VUCA & BANI. Instead, they must be replaced by adaptive and flexible basic attitudes combined with structured process models. This development relates to the following aspects:

Numerous agile procedures and approaches have been devel-oped on the basis of these principles in recent years. With SAFe®, a model has been established that is based on the system view and meets organizational needs, yet is adaptive, which is used here due to its prevalence.

From To

The management knows best The team knows best

Long-term strategies are irreplaceable Strategies contain adaptive components

Strategies are for the customer Strategies develop with the customer

The plan must be adhered to Adaptation to changes may modify the plan

No experiments or risks Change and error culture create innovation

98


Systems engineering not only helps companies to mas-ter the increasing complexity of product development; it also promotes interdisciplinary systems thinking.

Systems engineering is a tried and tested approach for devel-oping complex systems successfully – systems engineering is essentially as easy to define and understand as that.

Four building blocks are fundamental to systems engineering. They cannot always be distinctly separated from one another, but they provide a full picture of the extensiveness of this topic:

1) Systems engineering as a standardized discipline in a process model

At first glance, this approach seems obvious – it is largely derived from “common sense.” This perspective describes sys-tems engineering as an intuitive and practical discipline. The rise of systems engineering was motivated by the criticality of early space travel and systems whose complexity increased more than their development methods could handle. Systems engineering is used in particular when the complexity grows due to the combination of new technologies, cross-domain functionalities and software-based, automated control. This technical aspect – systems management – is standardized internationally as a process reference model for the develop-ment of complex systems and is defined in ISO 15288:2015 and other accompanying ISO standards.

2) Systems engineering as a modular method for the practical implementation of the discipline

The systems engineering approach includes a comprehensive set of methods and the technologies for their implementation. Both have continuously developed over the years. A distinction is made between methodological approaches developed from systems engineering and those originating in the area of qual-ity assurance. Modeling languages such as SysML or OPM have been developed in close connection with systems engineering. In addition, all methods from “Design for Six Sigma” can be combined profitably with a systemic approach.

3) Systems engineering as a valid science with univer-sally accepted criteria and principles

In addition, systems engineering also describes a scientific approach that can be understood as an engineering form of the system theory. The identification of principles that apply across the board helps to describe the systems engineering approach in a scientifically sound manner. This includes, for example, the identification of generally accepted system char-acteristics that support interdisciplinary exchange.

4) Systems engineering as a mindset of system thinkers

First of all, a systems engineering approach is often chosen via the concept of systems thinking. However, when it is detached from the other building blocks considered here, this concept often seems difficult to grasp. This creates an impression that

is far removed from an application in the actual project. System thinkers adopt a holistic approach when considering questions, and identify complex cause and effect relationships. Applied to systems, the relevance of this approach for the implementation of the other building blocks can be understood and introduced in such a way as to add value. The role of the System Engineer is an important part of this.

The systems engineering V model is also used outside of software development and provides the basis for agile product development.

In addition, the V model (Figure 2) is often used to represent systems engineering – in many instances it represents a doc-ument-heavy, sequential working method. However, if the V model is consistently embedded in the dimensions of time and degree of detail, and defining characteristics such as the width of the core area and the significance of the edges are taken seriously, a different perspective emerges. The V model leaves room for iterations, supports modern view-oriented documen-tation of results and forms the necessary framework for the timely mapping of system-critical aspects. The application of the core processes can be implemented almost as iteratively and recursively as required throughout the development cycle, which supports the agile concept.

Systems engineering is only successful if a uniform under-standing of systems and models is achieved and with a continuous culture change supported by management.

The communication of the four defined systems engineering building blocks must be adapted to specific roles. A balanced qualification of the elements is an essential prerequisite for system-relevant roles in order to realize the systemic concepts. In addition, the organization must be aligned along a level-oriented system structure and work with stakeholder-relevant, meaningful views must be established. Models are the devel-opment language in systems engineering.

These four building blocks are reflected in our understanding of systems engineering – and that is precisely the understand-ing that we combine with the aspects of agility to create the best possible approach to the challenges we face today and tomorrow.

03

What Do We Mean by Systems Engineering?

1110


Figure 2. Own representation based on: Dove R.; Schindel B. (2016): Introduction to the Agile Systems Engineering Life Cycle MBSE Pattern, 26th Annual INCOSE International Symposium, Edinburgh

Technical Processes

Implementation

System

Subsystem

System Element Design, Acquisition, Manufacturing

Leve

l of

Det

ail

Project Launch

System Design

Subsystems Design

ComponentDesign

Subsystems Realization

System Realization

Time

Project ProcessesRecursive and iterative application of the processes set out in

ISO 15288:2015 to the time-oriented V model

ProjectPlanning

Project assessment and control

Decision Management

Quality Assurance

Riskmanagement

Configuration Management

Information Management

Measurement

Business and Mission Analysis

Definition System

Requirements

Design Definition

Verification (Analysis & Simulation)

StakeholderNeeds and

Requirements

Validation Requirements

Definition Architecture

Analysis System

Design: Top System

ProjectPortfolio

Management

InfrastructureManagement

Life Cycle ModelManagement

QualityManagement

Knowledge-Management

Supply

Acquisition

Organisa-tional supportprocesses

Contractprocesses

Design: Subsystem 3

Design: Subsystem 2

Business and Mission Analysis

Definition System

Requirements

Design Definition

Verification (Analysis & Simulation)

Stakeholder Needs and

Requirements

Validation Requirements

Definition Architecture

Analysis System

Design: Subsystem 1

Verification (Tests)

Validation

Integration

Realization: Top System

Operation Maintenance

Disposal

Transition

Service: Top System

Realization: Subsystem 1



Verification (Tests)

Validation

Integration

12


13

The advantages of a joint implementation eliminate major weaknesses and promote the strengths of the individual models.

The following table shows the advantages of a synthesis of systems engineering and the SAFe® agile process model. This underlines the complementary compatibility of the two models.

The question remains, however, as to how the use of the com-bined approaches can be indicated?

The CURVE model provides a decision aid for the eco-nomic use of agile principles in systems engineering.

With the CURVE model, INCOSE6 provides a simple and uni-versally applicable indication for a meaningful implementation of both models in the program or product environment. The

letters of the acronym stand for Capriciousness, Uncertainty, Risk, Variation and Evolution. If clear evidence of these is iden-tified for a portfolio, program or product, INCOSE recommends the use of agile systems engineering.

To further describe this approach, we distinguish between three dimensions: methods and processes, organizational development and agile system architecture. This is discussed in detail below.

6) Dove, R.; Schindel W.; Hartney, R. (2017): Case Study: Agile Hardware/Firme-ware/Software Product Line Engineering at Rockwell Collins, 11th Annual IEEE International Systems Conference Montréal

Systems Engineering

SAFe® SAFe® and SE

Development processes ++ 0 ++

Control processes (process organization) 0 ++ ++

Organizational structure 0 + +

Role descriptions ++ ++ ++

Compliance assurance ++ 0 ++

Adaptability + ++ ++

Flexibility 0 ++ ++

Complexity management ++ 0 ++

Systemic approach ++ + ++

Tool support + + +

Comparison of systems engineering and SAFe®, based on the standards of the respective models (0 = not specified, + = well suited, ++ = very well suited)

04

The Synthesis, or: The Best of Both Worlds

1514


ConOp. Req. Arch. ConOp. Req. Arch. ConOp. Req. Arch.

Imp. Veri. Vali. Imp. Veri. Vali.

ConOp. Req. Arch.

Des. Im. Veri.

D. I. V.Sprint

Review

1 month

Review Review

D. I. V.Sprint

D. I. V.Sprint

Des. Im. Veri.

D. I. V.Sprint

Review

Synchronization points

Review Review

D. I. V.Sprint

D. I. V.Sprint

Des. Im. Veri.

D. I. V.Sprint

Review Review Review

D. I. V.Sprint

D. I. V.Sprint

SystemReview

SystemReview

Subsystems

System

System architecture and -requirements

Mechanics

Electrics / Electronics

Software

Continuous Subsystem Release

Continuous System Release

SubsystemIncrements

System

Iteration

System

Iteration

IncrementPlanning

3 month

Figure 3

Time

Processes and information flows in scaled agile systems engineering

16


17

4.1 Agile Systems Engineering – Methods and Processes

The establishment of agile and systems engineering methods and of process anchoring along the value stream form the foundation of a successful transformation.

We call the synthesis of agility and systems engineering “Scaled Agile @ Systems Engineering” (SA@SE) – it combines the strengths of both sub-disciplines. In short, systems engineer-ing provides the processes and structure for the interdisciplin-ary and holistic development of systems, while agile principles are used to structure collaboration at team and organizational level. Both topics offer extensive process and methodological knowledge for R&D, whereby – in simple terms – systems engi-neering focuses on what is developed and agility focuses on how it is developed.

Figure 3 shows an example of the combined working model according to SA@SE. This combines the process and method-ological knowledge from SE in the form of a V model with the adapted agile approaches according to SCRUM and SAFe®.

In detail, the development project – following the SE sys-tem concept – is divided into both a higher-level system and a lower-level subsystem. At system level, the processes and methods of the SE predominate as far as possible in terms of the process steps according to ISO 15288:2015. In this way, stakeholders’ needs are transformed into system requirements and architectures that serve as the basis for the division into subsystems and their specific requirements. Combined with the subsequent implementation of the subsystem increments to form a complete system and the verification and validation phases, this creates an effective framework for holistic system development.

At subsystem level, however, agile methods and routines pre-dominate, which, depending on the complexity of the subsys-tems, make it necessary to resort to several SE development teams. It makes sense to form specialist teams so that the respective requirements of the subsystem elements can be taken into account in the form of development, production and test time in different cycle lengths. The synchronization of the SE teams, with the help of overarching agile ceremonies such as review and increment planning, is of particular impor-tance for completing this division successfully. This ensures that transparency, communication and joint commitment are maintained outside the company’s own specialist domain. The other agile ceremonies, such as the daily or backlog refine-ment, continue to exist at team level. For this, each SE team has its own backlog, which transfers the corresponding system requirements at subsystem level.

This working model must be used to provide the function-ing subsystem increments for a system iteration at least every

three months. The rhythm of the entire model is based on this specification – both at system level and at subsystem level. This creates a parallelized, recurring routine which aims to continu-ously release subsystem increments and subsequent system iterations as minimal viable systems. On this basis, not only are the system requirements adapted to customer and stakeholder needs at regular intervals, but the findings from previous devel-opment cycles are also used for increased system maturity.

A success factor for the implementation of this working model is the preparation of adequate scalable organizational structures.

4.2 SAFe® – a Systems Engineering Organization

The scaling in SAFe® is oriented toward people and rec-reates optimum communication structures.

Conway7 describes the correlation between organization and system development as follows: “Organisationen die Systeme entwerfen […] sind gezwungen, Entwürfe zu produzieren, die Kopien der Kommunikationsstrukturen dieser Organisation sind.“

The underlying organization of communication flows is there-fore a central basis for the successful development of complex systems. SAFe® is used as the basis for the organizational form of SA@SE (Figure 4).

Different views – or levels of granularity – of the identical sys-tem backlog (list of pending system functionalities) are defined at each level of the scaled organizational structure, together with the respective roles and the comprehensive working mod-el for the scaling.

At the lowest level, different SE teams work on tasks relating to the subsystem – or function – backlog, depending on their domain, in working mode according to SA@SE. In accordance with the agile definition of the term “team,” all roles involved in independently achieving implementation of the subsystem – or function – development are integrated here. The SE teams are synchronized via the program or system level, which evalu-ates the progress in regular three-monthly cycles and plans ahead for the next three months in an increment plan. Experi-ence has shown that this approach allows teams of up to 125 people to be organized effectively as part of an agile system development. In larger development projects with multiple sys-tems and more than 150 participants, it may also be necessary to add a third level, the solution level, according to the identi-cal logical organization scheme (Figure 4, right-hand side).

7) Dove, R.; Schindel W.; Hartney, R. (2017): Case Study: Agile Hardware/Firm-ware/Software Product Line Engineering at Rockwell Collins, 11th Annual IEEE International Systems Conference Montréal

18 19


Example: Mapping of basic SE roles...

... to classic SAFe roles Basic responsibilities

“Facilitator”(Not explicitly described in SE)

Facilitator on each levelResponsible for the flow of the organisationSolves impediments

Project Lead / Product Manager

Define „What“ to doOwns the system budgetLong term view

System Engineer /System Architect

Defines „What“ to doOwns the systemFirmwide technical view

Requirement Owner

StakeholdersGive feedback on progressOwn the development budget

Function / Feature Owner / Sub Project Manager

Responsible for features/functionsDefine detailed Working PackagesGive feedback on development

Interdisciplinary Team

Define „How“ to reach the goalDeliver value orientedWork collaborative on one focus

Scrum Master

Business Owners

System Arch/Eng Solution Arch/Eng

RTE

Product Management

Product Owner Solution Management

STE

Program Iteration 3-4 months

Sprint Iteration 2-4 weeks

Solution Train

Team

Bac

klo

gs

Pro

gra

m B

ackl

og

Solu

tio

n B

ackl

og

Business Owners

ProductMgmt

System Arch/Eng

RTE

Su

b-S

ys

tem

Fe

atu

reS

ys

tem

So

luti

on

BacklogView RolesProcess /

Operating Model

Solution Mgmt

Solution Arch/Eng

STE

Scrum Master

Product Owner

Larg

e So

lutio

n SA

FeEs

sent

ial

SAFe

Team

Program

Solution>150

Individuals

5-11 Individuals

50-125 Individuals

n

n

1

1

Supplier

SE Team

Agile Release Train

Figure 4

Simplified representation of the roles and organization accordingto SAFe® in an adaptation to systems engineering

The roles of System Engineer and System Architect are elementary roles of both models and are further strengthened by the synthesis.

Despite some differences when it comes to names, the main systems engineering roles are identical in content to those in the SAFe® model (Figure 4, left-hand side). The striking thing about SAFe® is that at all stages of scaling, the three-way alli-ance of roles from a market perspective (Product Manager), technical perspective (System Engineer) and process perspec-tive (Release Train Engineer) is the key success factor in eco-nomic development.

The System Engineer has overall technical responsibility. At the solution level, the System Engineer coordinates with the Solu-tion Engineer to plan the next cycles based on the respective views of the shared backlogs. At the system level, the System Engineer breaks the technical system requirements down into comprehensible work packages for the subsystem level. Once the results have been processed by the SE teams, the System Engineer then accepts the results in the form of their subsys-tem increments.

In addition, the RTEs (Release Train Engineers) and STEs (Solu-tion Train Engineers) are available to assist with the successful

development process. At this point, it is important to highlight three fundamental tasks of the company-wide networked RTE:

1) Requiring and promoting continuous, short-cycle improve-ment process

2) Addressing and monitoring escalation issues

3) Moderating the overall planning and coordination dates

The need for this role was first identified and described in SAFe®. It does not currently exist in systems engineering. For a more detailed description of the specific tasks and responsibili-ties of the individual roles in SAFe®, please refer to the current SAFe 5.0 Framework8.

8) Scaled Agile – SAFe 5.0, Quelle: (https://www.scaledagileframework.com/), last updated: July 22, 2020


2120

4.3 The Agile System Architecture

The consistent implementation of an agile system archi-tecture enables maximum flexibility in the implementa-tion of new market and customer requirements for sys-tem and function design.

In order to be able to use the advantages of the agile working model within the framework of systems engineering, it is also necessary to lay the foundations for the development of agile systems and their functionalities. Otherwise, the development teams can adapt their approach to changing environmental conditions and requirements, but not the actual systems they develop.

The agility of a system is defined as the ability to survive in an uncertain and unpredictably evolving environment in order to respond effectively to both opportunities and threats. Agile systems are therefore designed for change and are optimized for a dynamic operating environment. They are characterized by the following attributes:9

Extensibility to include new functional capabilities Ability to restructure the internal relationships between the subsystems

Scalability up and down to provide functionality economically Ability to transform in order to regain compatibility or syn-ergy if the environment changes

The following three design elements are used to describe an agile architecture (Figure 5):

These types of change are structural in nature and require an agile architecture that takes into account structural change. The term “architecture” according to ISO 42010 is defined as the fundamental concepts or properties of a system in its environ-ment embodied in its elements, relationships, and in the prin-ciples of its design and evolution.

The agile system architecture is thus understood to be an out-of-the-box modular system with drag-and-drop and plug-and-play relationships. This can be illustrated using the example of LEGO construction sets. These kits consist of different types of compo-nents that can interact and be fitted together in a defined way. This enables the construction and modification of a wide variety of systems and their functionality. Although the kit is more suit-able for some types of construction than others, it is subject to a uniform architectural pattern. A pattern of this kind forms the basis for the construction of agile systems and is therefore called an agile system architecture.10

9),10), 11) Dove R.; LaBarge R. (2014): Fundamentals of Agile Systems Engineering, INCOSE Las Vegas 2014

The following three design elements are used to describe an agile architecture (Figure 5):11

1) Modules: Modules are independent, encapsulated and com-plete units with clearly defined interfaces. They can be joined together to form responsive system configurations or removed from these, and their relationship to other modules is deter-mined by the passive plug-and-play infrastructure. Modules are encapsulated in such a way that their functionality does not depend on that of other modules – unless the passive infrastruc-ture dictates this.

2) Passive infrastructure: The passive infrastructure describes the interaction and interface standards of the modules. They are defined in the form of standards and rules that relate to the physical connections, data connections, safety and secu-rity standards, and the service of the modules. The aim is to find a balance between the necessary diversity and economy to facilitate module connections while allowing innovative system configurations.

3) Active infrastructure: The active infrastructure defines the responsibilities and processes to maintain agile usability. It ensures that new system configurations can be created at any time as requirements change.

This agile system architecture involves a change from monolithic to systematic thinking based on the princi-ples of reusability, reconfigurability and scalability.

In the course of this, a suitable agile system architecture is the basic prerequisite for the use of agile process models in the devel-opment of hardware product systems. However, a large propor-tion of standard agile reference works neglect this connection, since their content focuses only on software development. Development techniques such as object-oriented programming (OOP) have the structural prerequisites for the adaptability of a system. In this way, they allow for easy replacement, expansion or reconfiguration of elements of software systems in successive sprints. Iterative learning is used to drive adaptation. This inher-ent adaptability is one of the main reasons for the acceptance and rapid spread of agile approaches in software development.12

The architecture of a complex system must also be aligned with many, often competing, criteria. The criterion of agility is only one aspect and often fades into the background due to crite-ria such as security, structural stability or cost. To return to the LEGO example mentioned earlier, there are certainly reasons why buildings and vehicles are not made of LEGO – although this would enable a high degree of system agility. A balanced weighting of the criteria in the architecture process is therefore a decisive factor for a successful system design.

12) Dove R.; LaBarge R. (2014): Fundamentals of Agile Systems Engineering, INCOSE Las Vegas 2014

Active InfrastructureResponsibility / Processes: Modules Readiness Assembly Infrastructure

Passive InfrastructureDefinition of standards: Sockets Signals Safety Security Service

ModulesUnits: independent encapsulated complete

For reactive System configurations

Principles:

Reusability

Reconfigurability

Scalability

Overview of the agile system architecture using the example of Lego construction sets

AGILE SYSTEMARCHITECTURE

AGILE SYSTEM

System configurationSystem configuration System configuration

Figure 5

22 23


05

The Agile Systems Engineering Transfor-mation

Finally, we shall discuss how this combined approach can be implemented in the company. As MHP, we offer a holis-tic approach with space for customer-specific conditions and requirements, as illustrated in Figure 6.

The transformation to Scaled Agile @ Systems Engineering takes place in three stages, the starting point of which depends on the individual customer situation and the concerns of the company.

The MHP R&D assessment can be used to determine where the individual transformation to scaled agile sys-tems engineering begins and where it can be accelerated.

In every company, systemic product development and agile working methods are anchored at different depths and widths. While there is usually a company-wide product development process, the agile principles vary greatly depending on the spe-cialist department or individual team. The first thing to do is to record the status. The MHP assessment has proven itself here: It records the structured target status, and the individual road-map can be derived in consultation with the customer.

The individual roadmap defines the implementation at dif-ferent speeds or maturity levels – depending on the existing project organization. The flexibility in the transformation speed of the three dimensions (agile working model, agile organiza-tion and agile system architecture) enables an adaptive adjust-ment of the stages in the versions of Scaled Agile @ Systems Engineering. For example, in an implementation project with already established agile project teams that do not have a sound SE approach, the agile elements of stage 2 and, pos-sibly, stage 3 are preferred. At the same time, the process and methodological foundations are laid in the SE core areas, such as requirements management, and in the system architecture. The goal is that the roadmap will enable the most efficient transformation path.

Stage 1: To achieve the transformation and accelerate the willingness to change, it is important to make the goal understandable to everyone involved and to pro-mote the new capabilities.

Once the roadmap has been approved by the stakeholders and communicated to the teams, stage 1 can begin. This involves establishing the agile principles and values. At the same time, the process and methodological SE foundations are ramped up in the team backlogs. Accompanying employee training and coaching are necessary. As a rule, the first teams start on projects that are already in progress. The prioritization of the SE processes is strongly oriented toward the current project phase in the system life cycle. Based on this, the standardiza-tion, qualification and application of the methods in the sprint plans are incorporated into the backlogs and implemented. At the same time, the processes and values of the agile SE organization are adapted and implemented. The support of all those involved – especially when it comes to the values of openness and transparency – as well as the managers in agile

leadership are the basis for sustainable implementation suc-cess. The implementation of the continuous improvement pro-cess as part of the retrospectives also optimizes the learning implementation.

This stage can take six months for the first five pilot teams, with little variation.

Stage 2: Once the new methods are anchored in the pro-cesses and the new capabilities are established among everyone involved, the transformation can be extended to system level.

After team implementation, stage 2 focuses on scaling at sys-tem level. The agile working model is extended to other teams and any other parts of the company, and the processes of the organizational structure are synchronized. In addition to soft-ware development, which usually follows agile process models already, and production, which already uses Shop Floor, other departments follow. QM, PM, Purchasing, Testing and also the company management are typically included in the roadmaps. Here, customized agile tools such as Scrumban or Kanban are established and supported. At the same time, the basics from stage 1 are further expanded in SE. From an organizational point of view, the combination of teams at an aggregated level is the crucial step to take for scaling.

With team scaling, it is imperative to establish the appropriate IT tool set. The transformation roadmap must contain the cor-responding activities with regard to IT architecture, implemen-tation of the development and deployment, synchronized with the overall approach.

The overall system architecture serves as a blueprint for the information flows and must be mapped in the division and def-inition of the teams and their interactions with each other. At the same time, the system architecture is geared more toward the criterion of agility by using complete, reusable, scalable and reconfigurable modules. Interfaces are standardized to maximize compatibility. The adaptation of the organization and the overall architecture is strongly correlated and can only be realized through a learning iterative process with retrospec-tives. Overall, the focus is on the mindset and on implementa-tion in the projects.

This stage takes about six to 24 months, depending on the complexity of the systems.

24 25


Stage 3: The goal of the transformation is to establish an adaptive agile systems engineering structure and pro-cess organization, and to achieve consistent implemen-tation of the agile system architecture.

In stage 2, the relevant course has already been set so that the final step can be implemented company-wide: the sustain-able networking of the various units and the synchronization of all SE teams. This level of maturity reveals the benefits of the continuous delivery of minimal viable systems in three-month

cycles. The agile and SE processes must also be fully adapted and implemented. In stage 3, the organizational structure is often adapted to the needs of SA@SE in order to take the pro-cesses and roles into account. However, this is not absolutely necessary for functional SA@SE, provided that the processes and mindset from the preceding stages are consistently imple-mented. From an SE perspective, the main focus is on further iterative adaptation of the organization and, above all, of the system architecture. The establishment of modularization, interface standardization and passive infrastructure, and the

Introduction agileWorking model

Team building and empowerment (SE Basics & Agile Framework)

Establishment of specific roles

Anchoring of agile routines

Introduction System Thinking

Development of requirements management

Definition of the “System of Inter-est” and the system architecture

Anchoring SE Methodology

Holistic Assessment

Kickoff at the customer (Workshop & Interviews)

Modular structure for each topic area (e.g. Agile or SE Check)

Analysis of the Status Quo (Potential & Challenges)

Definition of a target image and an individual customer journey (transformation path)

Expansion to System Development

Scaling of the teams (organizational structure)

Synchronization of the teams (process organization)

Empowerment Leadership

Introduction of Agile System Elements

Modules (reusable, scalable, reconfigurable)

Passive infrastructure (balance at interface standards)

Transformation of agile Organization

Project matrix in harmony with hierarchical Organization

Self-sustaining, adaptive Organization

Implementation of Agile System Architecture

Active infrastructure (processes and responsibility for agile deployment)

Establishment of the “Viable System” and a “Continuous Flow”

Stage 3 – OrganizationStage 2 – System levelStage 1 – Team levelR&D AssessmentConsulting phases

6 months 6 – 24 months from 24 months10 % 20 % 50 %

Figure 6

Complete transformation according to the MHP consulting approach

addition of an active infrastructure improve the agile usabil-ity in practice. The final result is a self-learning organization that can operate and survive flexibly and sustainably in the market within the complex environment of modern product development.

A successful implementation can be recognized by steady, continuous and permanent self-organization of the structure and process organization and of the systems.

Ag

ile O

rgan

izat

ion

Ag

ile w

ork

ing

mo

del

Ag

ile s

yste

m a

rch

itec

ture


2726

06

Outlook

We are convinced: Scaled Agile @ Systems Engineering can provide all the answers for a successful transformation in the area of R&D, especially in times when the focus is more on competitiveness and the ability to react and adapt, and when software opens up new opportunities and fields of action in previously mechanical and electrical products.

Our white paper demonstrates that agility and systems engi-neering are key components of responsive and adaptive prod-uct development. SA@SE can address the questions and chal-lenges that are reflected to us from the management level to the working level of our customers in a future-oriented manner.

The following three success factors should be emphasized once again at this point:

1) The establishment of agile and systems engineer-ing methods and of process anchoring along the value stream form the foundation of a successful change.

2) The agile systems engineering organization relies on the framework conditions for best practices of the estab-lished SAFe® framework.

3) The consistent implementation of an agile system architecture enables maximum flexibility in the imple-mentation of new market and customer requirements for system and function design.

There are currently many developments that further merge the future issues of agile and systems engineer-ing. In particular, the working groups of INCOSE and their German offshoots, the GfSE, are mentioned here. MHP is represented in the working groups of both insti-tutions (INCOSE Agile Systems and SE as well as GfSE Agile Systems Engineering) and plays a decisive role in shaping the topic.

Dr. Sebastian SchröterService Developer Systems Engineering

Andreas FeilService Developer Agile Engineering

Team of authors: Dr. Sebastian Schröter, Andreas Feil, Daniel Haase, Patrick Reimund

Contacts:

You too can pave the way for a sustainable and profit-able future. Our team of authors, consisting of agile sys-tems engineering coaches and experts, will be happy to answer any further questions you may have.

28 29


28

FotocreditsCover @shutterstock – sutadimagesPage 9 @shutterstock – Rawpixel.com Page 10 @shutterstock – GLYPHstockPage 19 @shutterstock – WHYFRAME Page 24 @shutterstock – Chan2545Page 30-31 @iStock – cicerocastro

Layoutdesign Freiland Design

http://www.freiland-design.de

http://www.freiland-design.de

MHP : DRIVEN BY EXCELLENCE

www.mhp.com

16 MHPOffices in Germany, United Kingdom, USA, China and Romania

Atlanta (USA)Birmingham (United Kingdom)Cluj-Napoca (Romania)Timișoara (Romania)Shanghai (China)Tel Aviv (Israel)

International

Ludwigsburg (Headquarters)BerlinEssen Frankfurt a. M.Ingolstadt MunichNurembergWolfsburg

Germany

Documents

SCALED AGILE @ SYSTEMS ENGINEERING...mentioned questions and explain them using the combined approach as an example. The potential economic benefits are also highlighted below. A balanced