SCALED AGILE @ SYSTEMS ENGINEERING How Two Seemingly Different Approaches to Solving a Problem Create Synergies in R&D and Increase Efficiency

SCALED AGILE @ SYSTEMS ENGINEERING How two seemingly different approaches to solving a problem create synergies in R&D and increase efficiency. SCALED AGILE @ SYSTEMS ENGINEERING I September 2020

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 INNOVATION 05 The Agile Systems Engineering Transformation 24 06 Outlook 28

FLEXIBILITY

REACTION

EFFECTIVENESS ADAPTIVITY

2 3 SCALED AGILE @ SYSTEMS ENGINEERING I September 2020 01 Introduction

Agility and systems engineering are an integral part of employee motivation, R&D currently favors two models – sys- We know the theory and roles – how does the (lower sickness rates, higher employer attractiveness and lower responsive, flexible product development. tems engineering (SE) or the Scaled Agile Framework (SAFe®). practical implementation work? turnover), was not included due to inconsistent measurement Both models have their own strengths, but also reveal areas How can our processes and tools be tailored to SE methods used by the companies, but is a positive side effect. In recent decades, the business world has been character- that have not yet been taken into account and where further or agile methods? The following three main topics are distinguished for the ized by volatility, uncertainty, complexity and ambiguity – or potential can be tapped. Synchronization with organization – how do we implementation of the approach and will be described in more “VUCA,” as the concept is known for short. Driven by climate solve the link to other areas? detail later in the white paper. change and the ongoing pandemic, this has recently been The aim of this white paper is to present the profitable aspects Agility has only worked in software so far – how can supplemented by an additional acronym – “BANI,” which of both models in a joint synthesis and thus present a systems we scale the model? 1) Use of agile and systems engineering methods at stands for brittle, anxious, nonlinear and incomprehensible. It engineering concept that is both agile (adaptive) and integra- team level forms a new framework in which volatility and complexity no tive. The central application for this lies in mastering techno- The consistent implementation of the system concept in the Increase in efficiency ~10 per cent longer adequately describe the current shift from events that logically complex development projects that require fast and development and organization, and the scaling of team prin- [Source: MHP project database]. are difficult to predict toward those that are entirely unpre- flexible adaptation options due to a dynamic or uncertain envi- ciples at program or portfolio level often fail due to the stan- dictable1. Together, the influencing factors of both thought ronment. The added value of this approach is also described in dard processes and structures of a functional hierarchy (orga- 2) Transformation and scaling at organizational level models present companies with the central task of adapting the standard reference work from INCOSE (International Coun- nizational structure). In practice, it is not sufficient simply to Increase in productivity ~20–50 per cent to new framework conditions. This has a particular impact on cil of Systems Engineering), which has set up its own working describe the central roles such as System Architect, Function [Source: www.scaledagileframework.com]3. the area of R&D, which is faced with the challenge of having to group to investigate agile systems engineering2. Owner or Agile Coach without enabling them to be integrated work increasingly effectively and efficiently, while at the same into the organization and incorporating them significantly into 3) Introduction of an agile (adaptive) system time, more responsive and flexible product developments are the processes. Therefore, this article will address the afore- architecture required. 1) Grabmeier, S. (2020): BANI vs. VUCA, Source: (https://stephangrabmeier.de/ mentioned questions and explain them using the combined Increase in efficiency in complex systems ~10–40 per cent bani-vs-vuca/), as at: July 22, 2020 approach as an example. [Source: MHP project database] An example of this is the increasing degree of complexity in the 2) INCOSE (2015): Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, Fourth Edition, John Wiley & Sons development of mechatronic systems – not only is the number The potential economic benefits are also highlighted below. Before these aspects are considered in detail, a uniform under- of functional requirements increasing, but also the demand standing of agility and systems engineering should be created. for interdisciplinarity. The main drivers of this trend are digi- tal technologies and the associated pressure to innovate. The The transformation takes place at individual speeds but A balanced combination of agile process models and sys- market increasingly demands networking and data-driven traditional organizations face similar obstacles, which tems engineering allows potential savings of 10 to 50 3) Scaled Agile – SAFe 5.0 , source: (https://www.scaledagileframework.com/ safe-for-lean-enterprises/), last updated July 22, 2020 business models. For system development, this means that tra- must be overcome. per cent. ditional structures and interface-optimized processes must be fundamentally reconsidered in favor of integrative approach- In the practice of transformation, many companies have begun Three parameters are taken into account when focusing on es. Among other things, this is reflected in the change from to implement at least one of the two models. However, they potential savings: quality costs (potential savings due to elimi- hardware-oriented development to a more function-oriented are often stuck at individual stages. A non-representative sur- nation of the need for improvements), time to market / cost development. If companies have neglected this step in recent vey conducted by MHP in July 2020 of 20 clients from various of delay (revenue and competitive advantages due to earlier years, this can often now result in delays to product deliveries, sectors revealed five recurring questions with which companies market entry of the systems) and innovation revenue (revenue high reworking costs for content relevant to certification, or are confronted when implementing and anchoring agility and/ from minimum viable products or unique features with innova- even a complete lack of planned development scope. or systems engineering: tive customer benefits). Of course, the potential depends on the respective sector as well as the system complexity and the In the search for a solution to these and other challenges For what should we use SE/agility and how will we benefit market environment, and can only serve as a basic indication such as short technology cycles, regulatory requirements and from it? here. Further potential, such as higher employee satisfaction

4 5 SCALED AGILE @ SYSTEMS ENGINEERING I September 2020

Dynamic markets require dynamic companies. at regular intervals. In a competitive environment, agility is therefore the by-product of natural selection, based firstly on In the context of project and program management, the term variation and secondly on “survival of the most adaptable,” or “agility” is used to describe a wide range of approaches, meth- the most effective/efficient solution. Therefore, short iteration ods and tools, some of which are used with varying degrees of cycles enable partial solutions to be tested, developed incre- success. Used by 54% of respondents, SAFe® is the most com- mentally or rejected as unsuitable. The result is a process of 02 monly used scaling framework, ahead of LeSS and in-house continuous adaptation, improvement and learning. solutions4. Hüsselmann5 has derived the central paradigms, principles and In essence, however, agility does not describe the use of a goals of agility from the two core principles of flexibility and specific project management method, but refers to the basic adaptability (Figure 1). They can also be found in the traditional ability to respond effectively and competently to an increas- project management standards, but are often not used much ingly uncertain and unpredictable operational environment. To in practice. make this possible, two basic principles are of central impor- tance: Flexibility and adaptability. What Do 4) Komus, , A. et al. (2020): Study Status Quo (Scaled) Agile 2019/2020, Ko- blenz University of Applied Sciences February 2020 Transferred to a project, this means that changes are perceived not as a disruption, but as part of the problem-solving process. 5) Hüsselmann, C.; Maibach, M. (2020): Agilisierung des Projektportfolioman- agements (Agilization of project portfolio management).Praktiken und Rollen However, in order to avoid arbitrary reactions and to ensure für traditionelle Unternehmen (Practices and roles for traditional companies), predictable project success, agile process models have been WI [report] no. 012, Gießen/Friedberg: THM, ISSN 2568-0803 developed that reflect the work results and working methods We Mean by by means of short iteration cycles and recurring routines, and Agility? Paradigms Goals

Communication Robustness

Simplicity Delegation Effectiveness Adaptivity and Flexibility Innovation

Rolling Planning Reflexion Reaction

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

6 7 SCALED AGILE @ SYSTEMS ENGINEERING I September 2020

Paradigms in the change of disruption and ambiguity of Numerous agile procedures and approaches have been devel- time. oped on the basis of these principles in recent years. With SAFe®, a model has been established that is based on the Based on our experience at MHP, we understand that many system view and meets organizational needs, yet is adaptive, “Agile process models paradigms that have created structure and stability in recent which is used here due to its prevalence. decades are under scrutiny in a world characterized by VUCA & BANI. Instead, they must be replaced by adaptive and flexible support the application of basic attitudes combined with structured process models. This development relates to the following aspects: agile values and principles. From  To They promote communication The management knows best  The team knows best and interaction, transfer Long-term strategies are irreplaceable  Strategies contain adaptive components Strategies are for the customer  Strategies develop with the customer responsibility to the affected The plan must be adhered to  Adaptation to changes may modify the plan employees and place great No experiments or risks  Change and error culture create innovation 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

8 9 SCALED AGILE @ SYSTEMS ENGINEERING I September 2020

Systems engineering not only helps companies to mas- is far removed from an application in the actual project. System ter the increasing complexity of product development; it thinkers adopt a holistic approach when considering questions, also promotes interdisciplinary systems thinking. and identify complex cause and effect relationships. Applied to systems, the relevance of this approach for the implementation Systems engineering is a tried and tested approach for devel- of the other building blocks can be understood and introduced oping complex systems successfully – systems engineering is in such a way as to add value. The role of the System Engineer 03 essentially as easy to define and understand as that. is an important part of this.

Four building blocks are fundamental to systems engineering. The systems engineering V model is also used outside of They cannot always be distinctly separated from one another, software development and provides the basis for agile but they provide a full picture of the extensiveness of this topic: product development.

1) Systems engineering as a standardized discipline in a In addition, the V model (Figure 2) is often used to represent process model systems engineering – in many instances it represents a doc- What Do ument-heavy, sequential working method. However, if the V At first glance, this approach seems obvious – it is largely model is consistently embedded in the dimensions of time and derived from “common sense.” This perspective describes sys- degree of detail, and defining characteristics such as the width tems engineering as an intuitive and practical discipline. The of the core area and the significance of the edges are taken rise of systems engineering was motivated by the criticality seriously, a different perspective emerges. The V model leaves of early space travel and systems whose complexity increased room for iterations, supports modern view-oriented documen- more than their development methods could handle. Systems tation of results and forms the necessary framework for the We Mean engineering is used in particular when the complexity grows timely mapping of system-critical aspects. The application of due to the combination of new technologies, cross-domain the core processes can be implemented almost as iteratively functionalities and software-based, automated control. This and recursively as required throughout the development cycle, technical aspect – systems management – is standardized which supports the agile concept. internationally as a process reference model for the development of complex systems and is defined in ISO 15288:2015 Systems engineering is only successful if a uniform under- by Systems and other accompanying ISO standards. standing of systems and models is achieved and with a continuous culture change supported by management. 2) Systems engineering as a modular method for the practical implementation of the discipline The communication of the four defined systems engineering building blocks must be adapted to specific roles. A balanced The systems engineering approach includes a comprehensive qualification of the elements is an essential prerequisite for Engineering? set of methods and the technologies for their implementation. system-relevant roles in order to realize the systemic concepts. Both have continuously developed over the years. A distinction In addition, the organization must be aligned along a level- is made between methodological approaches developed from oriented system structure and work with stakeholder-relevant, systems engineering and those originating in the area of qual- meaningful views must be established. Models are the devel- ity assurance. Modeling languages such as SysML or OPM have opment language in systems engineering. been developed in close connection with systems engineering. In addition, all methods from “Design for Six Sigma” can be These four building blocks are reflected in our understanding combined profitably with a systemic approach. of systems engineering – and that is precisely the understanding that we combine with the aspects of agility to create the 3) Systems engineering as a valid science with univer- best possible approach to the challenges we face today and sally accepted criteria and principles tomorrow.

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 characteristics 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

10 11 SCALED AGILE @ SYSTEMS ENGINEERING I September 2020

Project Project assessment Decision Quality Planning and control Management Assurance Project Recursive and iterative application of the processes set out in Risk Configuration Information Processes Measurement ISO 15288:2015 to the time-oriented V model management Management Management

Organisa- Project System Subsystems Component Subsystems System Launch Design Design Design Realization Realization tional Time support Design: Top System processes Realization: Top System Service: Top System Business and Mission Analysis Verification Project Validation Transition Stakeholder (Tests) Portfolio Validation Needs and Management Requirements Requirements Integration Operation Maintenance Infrastructure Management Definition System Disposal Life Cycle Model Requirements Management Definition Analysis Architecture System Quality Management Design Definition Knowledge- Level of Detail Management Verification (Analysis & Simulation)

System

Subsystem Design: Subsystem 3 Realization: Subsystem 3 Design: Subsystem 2 Contract Realization: Subsystem 2 Design: Subsystem 1 processes Realization: Subsystem 1 Business and Verification Mission Analysis Validation (Tests) Stakeholder Acquisition Validation Needs and Requirements Integration Requirements Supply Definition System Requirements

Definition Analysis System Element Architecture System Design, Acquisition, Manufacturing Design Definition Implementation Technical Verification (Analysis & Simulation) Processes

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, 12 Edinburgh 13 SCALED AGILE @ SYSTEMS ENGINEERING I September 2020

The advantages of a joint implementation eliminate letters of the acronym stand for Capriciousness, Uncertainty, major weaknesses and promote the strengths of the Risk, Variation and Evolution. If clear evidence of these is iden- individual models. tified for a portfolio, program or product, INCOSE recommends the use of agile systems engineering. The following table shows the advantages of a synthesis of systems engineering and the SAFe® agile process model. To further describe this approach, we distinguish between 04 This underlines the complementary compatibility of the two three dimensions: methods and processes, organizational models. development and agile system architecture. This is discussed in detail below. The question remains, however, as to how the use of the combined approaches can be indicated? 6) Dove, R.; Schindel W.; Hartney, R. (2017): Case Study: Agile Hardware/Firme- ware/Software Product Line Engineering at Rockwell Collins, 11th Annual The CURVE model provides a decision aid for the eco- IEEE International Systems Conference Montréal nomic use of agile principles in systems engineering.

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

Systems SAFe® SAFe® and SE Engineering The Best of Development processes ++ 0 ++ Control processes (process organization) 0 ++ ++

Organizational structure 0 + + Both Worlds 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)

14 15 SCALED AGILE @ SYSTEMS ENGINEERING I September 2020

Processes and information flows in scaled agile systems engineering

Continuous System Release 3 month System System System Iteration Iteration Time

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

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

System System Review Review Subsystem Increments System architecture and -requirements

Subsystems Continuous Subsystem Release

Mechanics Des. Im. Veri. Des. Im. Veri. Des. Im. Veri.

Electrics / Electronics D. I. V. D. I. V. D. I. V. D. I. V. D. I. V. D. I. V. D. I. V. D. I. V. D. I. V. Sprint Sprint Sprint Sprint Sprint Sprint Sprint Sprint Sprint

Software

Increment Review Review Review Review Review Review Review Review Review Planning

1 month Synchronization points

Figure 3

16 17 SCALED AGILE @ SYSTEMS ENGINEERING I September 2020

4.1 Agile Systems three months. The rhythm of the entire model is based on this specification – both at system level and at subsystem level. This Engineering – Methods and creates a parallelized, recurring routine which aims to continuously release subsystem increments and subsequent system Processes 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- The establishment of agile and systems engineering opment cycles are also used for increased system maturity. methods and of process anchoring along the value stream form the foundation of a successful transformation. A success factor for the implementation of this working model is the preparation of adequate scalable organizational We call the synthesis of agility and systems engineering “Scaled structures. Agile @ Systems Engineering” (SA@SE) – it combines the strengths of both sub-disciplines. In short, systems engineering provides the processes and structure for the interdisciplin- 4.2 SAFe® – a Systems ary and holistic development of systems, while agile principles are used to structure collaboration at team and organizational Engineering Organization level. Both topics offer extensive process and methodological knowledge for R&D, whereby – in simple terms – systems engineering focuses on what is developed and agility focuses on The scaling in SAFe® is oriented toward people and rec- how it is developed. reates optimum communication structures.

Figure 3 shows an example of the combined working model Conway7 describes the correlation between organization according to SA@SE. This combines the process and method- and system development as follows: “Organisationen die ological knowledge from SE in the form of a V model with the Systeme entwerfen […] sind gezwungen, Entwürfe zu adapted agile approaches according to SCRUM and SAFe®. produzieren, die Kopien der Kommunikationsstrukturen dieser Organisation sind.“ In detail, the development project – following the SE system concept – is divided into both a higher-level system and The underlying organization of communication flows is there- a lower-level subsystem. At system level, the processes and fore a central basis for the successful development of complex methods of the SE predominate as far as possible in terms of systems. SAFe® is used as the basis for the organizational form the process steps according to ISO 15288:2015. In this way, of SA@SE (Figure 4). stakeholders’ needs are transformed into system requirements and architectures that serve as the basis for the division into Different views – or levels of granularity – of the identical sys- subsystems and their specific requirements. Combined with tem backlog (list of pending system functionalities) are defined the subsequent implementation of the subsystem increments at each level of the scaled organizational structure, together to form a complete system and the verification and validation with the respective roles and the comprehensive working mod- phases, this creates an effective framework for holistic system el for the scaling. development. At the lowest level, different SE teams work on tasks relating At subsystem level, however, agile methods and routines pre- to the subsystem – or function – backlog, depending on their dominate, which, depending on the complexity of the subsys- domain, in working mode according to SA@SE. In accordance tems, make it necessary to resort to several SE development with the agile definition of the term “team,” all roles involved teams. It makes sense to form specialist teams so that the in independently achieving implementation of the subsystem – respective requirements of the subsystem elements can be or function – development are integrated here. The SE teams taken into account in the form of development, production are synchronized via the program or system level, which evalu- and test time in different cycle lengths. The synchronization of ates the progress in regular three-monthly cycles and plans the SE teams, with the help of overarching agile ceremonies ahead for the next three months in an increment plan. Experi- such as review and increment planning, is of particular impor- ence has shown that this approach allows teams of up to 125 tance for completing this division successfully. This ensures people to be organized effectively as part of an agile system that transparency, communication and joint commitment are development. In larger development projects with multiple sys- maintained outside the company’s own specialist domain. The tems and more than 150 participants, it may also be necessary other agile ceremonies, such as the daily or backlog refine- to add a third level, the solution level, according to the identi- ment, continue to exist at team level. For this, each SE team cal logical organization scheme (Figure 4, right-hand side). has its own backlog, which transfers the corresponding system requirements at subsystem level. 7) Dove, R.; Schindel W.; Hartney, R. (2017): Case Study: Agile Hardware/Firm- ware/Software Product Line Engineering at Rockwell Collins, 11th Annual This working model must be used to provide the function- IEEE International Systems Conference Montréal ing subsystem increments for a system iteration at least every

18 19 SCALED AGILE @ SYSTEMS ENGINEERING I September 2020

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

Process / View Backlog Roles Operating Model

Example: Mapping of ... to classic SAFe roles Basic responsibilities basic SE roles... Solution Train

Solution Solution >150 Facilitator on each level Arch/Eng Mgmt Supplier Solution Individuals “Facilitator” Responsible for the flow of the organisation Solution (Not explicitly described in SE) Solves impediments Scrum Master RTE STE STE 1

Define „What“ to do Solution Backlog Project Lead / Owns the system budget Long term view SAFe Product Manager Program Iteration Product Management

3-4 months Large Solution Business Owners n Defines „What“ to do Owns the system Agile Release Train System Engineer / 50-125 Firmwide technical view Program System Architect Individuals System Arch/Eng Solution Arch/Eng

System System Product Arch/Eng Mgmt 1 Stakeholders Give feedback on progress Requirement Owner Own the development budget Backlog Program RTE Business Owners SAFe Sprint Iteration Essential Responsible for features/functions 2-4 weeks Function / Feature Owner / Define detailed Working Packages n Sub Project Manager Give feedback on development Product Owner Solution Management Product 5-11 Owner Team Individuals

Define „How“ to reach the goal Feature SE Team

Deliver value oriented Sub-System Interdisciplinary Team Work collaborative on one focus Scrum Master Team Backlogs Team

Figure 4

The roles of System Engineer and System Architect The System Engineer has overall technical responsibility. At the development process. At this point, it is important to highlight The need for this role was first identified and described in are elementary roles of both models and are further solution level, the System Engineer coordinates with the Solu- three fundamental tasks of the company-wide networked RTE: SAFe®. It does not currently exist in systems engineering. For a strengthened by the synthesis. tion Engineer to plan the next cycles based on the respective more detailed description of the specific tasks and responsibili- views of the shared backlogs. At the system level, the System 1) Requiring and promoting continuous, short-cycle improve- ties of the individual roles in SAFe®, please refer to the current Despite some differences when it comes to names, the main Engineer breaks the technical system requirements down into ment process SAFe 5.0 Framework8. systems engineering roles are identical in content to those in comprehensible work packages for the subsystem level. Once the SAFe® model (Figure 4, left-hand side). The striking thing the results have been processed by the SE teams, the System 2) Addressing and monitoring escalation issues about SAFe® is that at all stages of scaling, the three-way alli- Engineer then accepts the results in the form of their subsys- 8) Scaled Agile – SAFe 5.0, Quelle: (https://www.scaledagileframework.com/), last updated: July 22, 2020 ance of roles from a market perspective (Product Manager), tem increments. 3) Moderating the overall planning and coordination dates technical perspective (System Engineer) and process perspective (Release Train Engineer) is the key success factor in eco- In addition, the RTEs (Release Train Engineers) and STEs (Solu- nomic development. tion Train Engineers) are available to assist with the successful

20 21 SCALED AGILE @ SYSTEMS ENGINEERING I September 2020

4.3 The Agile System The following three design elements are used to describe an agile architecture (Figure 5):11 Overview of the agile system architecture using the example Architecture of Lego construction sets 1) Modules: Modules are independent, encapsulated and complete units with clearly defined interfaces. They can be joined The consistent implementation of an agile system archi- together to form responsive system configurations or removed tecture enables maximum flexibility in the implementa- from these, and their relationship to other modules is deter- Principles: tion of new market and customer requirements for sys- mined by the passive plug-and-play infrastructure. Modules are Reusability tem and function design. encapsulated in such a way that their functionality does not depend on that of other modules – unless the passive infrastruc- Reconfigurability Modules In order to be able to use the advantages of the agile working ture dictates this. Scalability Units: model within the framework of systems engineering, it is also  independent necessary to lay the foundations for the development of agile 2) Passive infrastructure: The passive infrastructure describes  encapsulated systems and their functionalities. Otherwise, the development the interaction and interface standards of the modules. They  complete teams can adapt their approach to changing environmental are defined in the form of standards and rules that relate to conditions and requirements, but not the actual systems they the physical connections, data connections, safety and secu- For reactive develop. rity standards, and the service of the modules. The aim is to System configurations find a balance between the necessary diversity and economy to The agility of a system is defined as the ability to survive in facilitate module connections while allowing innovative system an uncertain and unpredictably evolving environment in order configurations. to respond effectively to both opportunities and threats. Agile systems are therefore designed for change and are optimized 3) Active infrastructure: The active infrastructure defines AGILE SYSTEM for a dynamic operating environment. They are characterized the responsibilities and processes to maintain agile usability. It by the following attributes:9 ensures that new system configurations can be created at any ARCHITECTURE time as requirements change. Extensibility to include new functional capabilities Ability to restructure the internal relationships between the This agile system architecture involves a change from subsystems monolithic to systematic thinking based on the princi- Active Passive Scalability up and down to provide functionality economically ples of reusability, reconfigurability and scalability. Infrastructure Infrastructure Ability to transform in order to regain compatibility or syn- ergy if the environment changes In the course of this, a suitable agile system architecture is the Responsibility / Processes: Definition of standards: basic prerequisite for the use of agile process models in the devel-  Modules  Sockets The following three design elements are used to describe an opment of hardware product systems. However, a large propor-  Readiness  Signals agile architecture (Figure 5): tion of standard agile reference works neglect this connection,  Assembly  Safety since their content focuses only on software development.  Infrastructure  Security These types of change are structural in nature and require an Development techniques such as object-oriented programming  Service agile architecture that takes into account structural change. The (OOP) have the structural prerequisites for the adaptability of a term “architecture” according to ISO 42010 is defined as the system. In this way, they allow for easy replacement, expansion fundamental concepts or properties of a system in its environ- or reconfiguration of elements of software systems in successive ment embodied in its elements, relationships, and in the prin- sprints. Iterative learning is used to drive adaptation. This inher- ciples of its design and evolution. ent adaptability is one of the main reasons for the acceptance and rapid spread of agile approaches in software development.12 The agile system architecture is thus understood to be an out-of- the-box modular system with drag-and-drop and plug-and-play The architecture of a complex system must also be aligned with relationships. This can be illustrated using the example of LEGO many, often competing, criteria. The criterion of agility is only construction sets. These kits consist of different types of compo- one aspect and often fades into the background due to crite- nents that can interact and be fitted together in a defined way. ria such as security, structural stability or cost. To return to the This enables the construction and modification of a wide variety LEGO example mentioned earlier, there are certainly reasons AGILE SYSTEM of systems and their functionality. Although the kit is more suit- why buildings and vehicles are not made of LEGO – although able for some types of construction than others, it is subject to this would enable a high degree of system agility. A balanced a uniform architectural pattern. A pattern of this kind forms the weighting of the criteria in the architecture process is therefore basis for the construction of agile systems and is therefore called a decisive factor for a successful system design. an agile system architecture.10

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

Figure 5

22 23 SCALED AGILE @ SYSTEMS ENGINEERING I September 2020

Finally, we shall discuss how this combined approach can leadership are the basis for sustainable implementation suc- be implemented in the company. As MHP, we offer a holis- cess. The implementation of the continuous improvement pro- tic approach with space for customer-specific conditions and cess as part of the retrospectives also optimizes the learning requirements, as illustrated in Figure 6. implementation.

The transformation to Scaled Agile @ Systems Engineering This stage can take six months for the first five pilot teams, 05 takes place in three stages, the starting point of which depends with little variation. on the individual customer situation and the concerns of the company. Stage 2: Once the new methods are anchored in the processes and the new capabilities are established among The MHP R&D assessment can be used to determine everyone involved, the transformation can be extended where the individual transformation to scaled agile sys- to system level. tems engineering begins and where it can be accelerated. After team implementation, stage 2 focuses on scaling at sys- The Agile In every company, systemic product development and agile tem level. The agile working model is extended to other teams working methods are anchored at different depths and widths. and any other parts of the company, and the processes of the While there is usually a company-wide product development organizational structure are synchronized. In addition to soft- process, the agile principles vary greatly depending on the spe- ware development, which usually follows agile process models cialist department or individual team. The first thing to do is to already, and production, which already uses Shop Floor, other record the status. The MHP assessment has proven itself here: departments follow. QM, PM, Purchasing, Testing and also the It records the structured target status, and the individual road- company management are typically included in the roadmaps. Systems map can be derived in consultation with the customer. Here, customized agile tools such as Scrumban or Kanban are established and supported. At the same time, the basics from The individual roadmap defines the implementation at dif- stage 1 are further expanded in SE. From an organizational ferent speeds or maturity levels – depending on the existing point of view, the combination of teams at an aggregated level project organization. The flexibility in the transformation speed is the crucial step to take for scaling. of the three dimensions (agile working model, agile organiza- Engineering tion and agile system architecture) enables an adaptive adjust- With team scaling, it is imperative to establish the appropriate ment of the stages in the versions of Scaled Agile @ Systems IT tool set. The transformation roadmap must contain the cor- Engineering. For example, in an implementation project with responding activities with regard to IT architecture, implemen- already established agile project teams that do not have a tation of the development and deployment, synchronized with sound SE approach, the agile elements of stage 2 and, pos- the overall approach. sibly, stage 3 are preferred. At the same time, the process and Transfor- methodological foundations are laid in the SE core areas, such The overall system architecture serves as a blueprint for the as requirements management, and in the system architecture. information flows and must be mapped in the division and def- The goal is that the roadmap will enable the most efficient inition of the teams and their interactions with each other. At transformation path. 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 mation Stage 1: To achieve the transformation and accelerate maximize compatibility. The adaptation of the organization the willingness to change, it is important to make the and the overall architecture is strongly correlated and can only goal understandable to everyone involved and to pro- be realized through a learning iterative process with retrospec- mote the new capabilities. tives. Overall, the focus is on the mindset and on implementation in the projects. Once the roadmap has been approved by the stakeholders and communicated to the teams, stage 1 can begin. This involves This stage takes about six to 24 months, depending on the establishing the agile principles and values. At the same time, complexity of the systems. 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 standardization, 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

24 25 SCALED AGILE @ SYSTEMS ENGINEERING I September 2020

Stage 3: The goal of the transformation is to establish cycles. The agile and SE processes must also be fully adapted addition of an active infrastructure improve the agile usabil- an adaptive agile systems engineering structure and pro- and implemented. In stage 3, the organizational structure is ity in practice. The final result is a self-learning organization cess organization, and to achieve consistent implemen- often adapted to the needs of SA@SE in order to take the pro- that can operate and survive flexibly and sustainably in the tation of the agile system architecture. cesses and roles into account. However, this is not absolutely market within the complex environment of modern product necessary for functional SA@SE, provided that the processes development. In stage 2, the relevant course has already been set so that and mindset from the preceding stages are consistently imple- the final step can be implemented company-wide: the sustain- mented. From an SE perspective, the main focus is on further A successful implementation can be recognized by steady, able networking of the various units and the synchronization iterative adaptation of the organization and, above all, of the continuous and permanent self-organization of the structure of all SE teams. This level of maturity reveals the benefits of the system architecture. The establishment of modularization, and process organization and of the systems. continuous delivery of minimal viable systems in three-month interface standardization and passive infrastructure, and the

Complete transformation according to the MHP consulting approach

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

Consulting phases R&D Assessment Stage 1 – Team level Stage 2 – System level Stage 3 – Organization

Holistic Assessment Introduction agile Expansion to System Transformation of agile Working model Development Organization  Kickoff at the customer (Workshop & Interviews)  Team building and empowerment  Scaling of the teams  Project matrix in harmony with (SE Basics & Agile Framework) (organizational structure) hierarchical Organization  Modular structure for each topic area (e.g. Agile or SE Check)  Establishment of specific roles  Synchronization of the teams  Self-sustaining, adaptive (process organization) Organization  Analysis of the Status Quo  Anchoring of agile routines (Potential & Challenges)  Empowerment Leadership

 Definition of a target image and Agile working model an individual customer journey Introduction System Thinking Introduction of Agile System Implementation of Agile (transformation path) Elements System Architecture  Development of requirements management  Modules (reusable, scalable,  Active infrastructure (processes and reconfigurable) responsibility for agile deployment)  Definition of the “System of Inter- est” and the system architecture  Passive infrastructure (balance at  Establishment of the “Viable interface standards) System” and a “Continuous Flow”  Anchoring SE Methodology Agile Organization Agile system architecture

Figure 6

26 27 SCALED AGILE @ SYSTEMS ENGINEERING I September 2020 06 Outlook

We are convinced: Scaled Agile @ Systems Engineering can The following three success factors should be emphasized You too can pave the way for a sustainable and profit- provide all the answers for a successful transformation in the once again at this point: able future. Our team of authors, consisting of agile sys- area of R&D, especially in times when the focus is more on tems engineering coaches and experts, will be happy to competitiveness and the ability to react and adapt, and when 1) The establishment of agile and systems engineer- answer any further questions you may have. software opens up new opportunities and fields of action in ing methods and of process anchoring along the value previously mechanical and electrical products. stream form the foundation of a successful change. Contacts: Our white paper demonstrates that agility and systems engi- 2) The agile systems engineering organization relies on neering are key components of responsive and adaptive prod- the framework conditions for best practices of the estab- uct development. SA@SE can address the questions and chal- lished SAFe® framework. lenges that are reflected to us from the management level to the working level of our customers in a future-oriented manner. 3) The consistent implementation of an agile system architecture enables maximum flexibility in the implementation 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 engineering. 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 Dr. Sebastian Schröter Andreas Feil shaping the topic. Service Developer Service Developer Systems Engineering Agile Engineering

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

28 29 Fotocredits Cover @shutterstock – sutadimages Page 9 @shutterstock – Rawpixel.com Page 10 @shutterstock – GLYPHstock Page 19 @shutterstock – WHYFRAME Page 24 @shutterstock – Chan2545 Page 30-31 @iStock – cicerocastro

Layoutdesign Freiland Design MHP : DRIVEN BY EXCELLENCE

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

International

Atlanta (USA) Germany Birmingham (United Kingdom) Cluj-Napoca (Romania) Ludwigsburg Timișoara (Romania) (Headquarters) Shanghai (China) Berlin Tel Aviv (Israel) Essen Frankfurt a. M. Ingolstadt Munich Nuremberg Wolfsburg