SCALED AGILE @ SYSTEMS ENGINEERING...mentioned questions and explain them using the combined...
Transcript of SCALED AGILE @ SYSTEMS ENGINEERING...mentioned questions and explain them using the combined...
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
SCALED AGILE @ SYSTEMS ENGINEERING I September 2020
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
SCALED AGILE @ SYSTEMS ENGINEERING I September 2020
“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
SCALED AGILE @ SYSTEMS ENGINEERING I September 2020
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
SCALED AGILE @ SYSTEMS ENGINEERING I September 2020
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
Realization: Subsystem 3
Realization: Subsystem 2
Verification (Tests)
Validation
Integration
12
SCALED AGILE @ SYSTEMS ENGINEERING I September 2020
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
SCALED AGILE @ SYSTEMS ENGINEERING I September 2020
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
SCALED AGILE @ SYSTEMS ENGINEERING I September 2020
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
SCALED AGILE @ SYSTEMS ENGINEERING I September 2020
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
SCALED AGILE @ SYSTEMS ENGINEERING I September 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
SCALED AGILE @ SYSTEMS ENGINEERING I September 2020
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
SCALED AGILE @ SYSTEMS ENGINEERING I September 2020
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
SCALED AGILE @ SYSTEMS ENGINEERING I September 2020
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
SCALED AGILE @ SYSTEMS ENGINEERING I September 2020
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
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