Review: Agile Systems Engineering - The Modern Handbook (Volume 1)

A marketing gimmick or a serious alternative? Flow Engineering is provocatively positioning this handbook as a replacement for the INCOSE System Engineering Handbook. Pari Singh has collected over 600 requests for a preview of the handbook on LinkedIn in just a few days. Now the first part is publicly available (and free of charge). Below is a review.

Target group: Anyone interested in agile systems engineering, from engineers to decision-makers.

Rating: ★★★☆☆ Under no circumstances should you expect a book that is comparable to the INCOSE (or NASA) SE manual. If you do, you will be disappointed. The length of the book (approx. 25 pages for Volume 1) shows that it has a different aim. This book is about concepts, not details. Furthermore, this book is a sales tool for flow engineering. That is of course perfectly fine.

Anyone who feels comfortable with this and then gets involved with the book will be provided with inspiring facts to convince management of agile systems engineering, as well as checklists for implementation and lots of good ideas.

Acquire: The book is free and currently without registration available at Flow Engineering. I could not find a PDF version, but the formatting using the browser print function is fine (27 pages for Volume 1).

Authors: This book is a collaborative effort by authors primarily from Flow Engineering's customer base. Pari Singh has contributed to all chapters.

Why this book?

About Pari Singh and Flow Engineering I have already written about here several times. With his Flow Engineering tool, he has created a product that is designed to enable agile hardware development. Tools are important, but without an appropriate methodology and framework, much of the added value of a tool is lost.

The methodology recommended by Pari (and described in the book) is known under various terms, for example "Extreme Hardware". The core idea is to build many versions of the overall system in short iterations. The most prominent representative of this approach is SpaceX. With this approach, the company has Self-landing rockets within 2 years developed and revised, builds and tests the Raptor engine every 2 days.

SE manuals from INCOSE & NASA

Pari pejoratively refers to the INCOSE and NASA approaches as a "waterfall". This is not fair: after all, these two organizations advise against the waterfall model. The left side of the V-model is often misunderstood as a waterfall. And unfortunately sometimes wrongly practiced as a waterfall.

RIP INCOSE and the approach of the 1990s.

Pari Singh

Misunderstandings and misconceptions are widespread in systems engineering anyway. In addition, the INCOSE and NASA SE manuals are not necessarily easy to digest.

Contents of Volume 1

Volume 1 is made available on a single website and the content is interspersed with quotes, tables, diagrams and case studies. The volume consists of 4 chapters that can be read in one go.

First of all: The handbook often talks about "hardware". This refers to systems that have a hardware component, such as rockets or cars. The fact that these also have - often large - software components is a matter of course for the authors.

Chapter 1: The state of hardware engineering

In this chapter, the authors first explain why a fundamental change in system engineering from the traditional "waterfall" method to an iterative and agile approach is essential for survival. Iteratively developed systems are faster, more cost-effective and more adaptable. Change is driven by the growing complexity of systems and the need to be able to deal with change more quickly. Examples such as SpaceX illustrate the superiority of the iterative approach.

The four drivers for change identified in this chapter are interesting: (1) complexity, (2) changes to requirements, (3) an increase in fixed-price projects and (4) new developments ("green teams").

Chapter 2: The culture of systems engineering at SpaceX

The second chapter examines how systems engineering is practiced at SpaceX. SpaceX is redefining systems engineering by delegating responsibility to each engineer and replacing the traditional role of the systems engineer. Decisions are made quickly and directly by the Responsible Engineers (REs). Cross-functional collaboration and a network structure promote innovation and efficiency, while the role of the systems engineer becomes a supporting and coordinating function.

Iterative is not agile: Agile is the ability to react to change. Iterative is the ability to produce new versions quickly.

Specifically, the chapter contains a list of eight practices that can be transferred to other companies (if the culture plays along). Some of these are widely known ("Every Engineer is a Systems Engineer"). Others less so, such as the fact that the title "Systems Engineer" does not actually exist at SpaceX. Instead, there is the "Design Reliability Engineer".

I also found the renaming of internal requirements to "Design Critera" exciting, more on this in chapter 4.

Chapter 3: The five maturity levels of systems engineering

This chapter describes a maturity model for systems engineering that shows the development from basic to advanced methods. It emphasizes the importance of iterative approaches that minimize risk and increase efficiency. Case studies show how leading companies such as SpaceX are setting new standards and solving complex problems faster.

This chapter is very short - because the Maturity Model is only available against registration (I'm still waiting for someone from Flow to contact me about this).

Chapter 4: Design criteria instead of requirements

There are internal and external requirements, whereby external requirements primarily have the task of checking contract fulfillment. The majority of requirements are used for internal collaboration and are seen as flexible "design criteria" that are continuously adapted and optimized. This approach encourages collaboration and enables engineers to take responsibility for the requirements of their projects. This approach leads to a reduction and prioritization of requirements, which reduces complexity.

Here too, as in Chapter 3, there is a pitch for Flow Engineering's product, with which (according to Flow) modern requirements management can be practiced.

View of Volume 2

The chapter names are already available, but have not yet been published:

• Chapter 5 - Requirements and design criteria
• Chapter 6 - Rituals and processes: Workflows for agile teams
• Chapter 7 - Change management in agile teams
• Chapter 8 - Continuous testing and V&V
• Chapter 9 - Security and regulation

Conclusion

There are a lot of really good ideas in this book that we really need in systems engineering. Due to its brevity and accessibility (free website), I recommend that every systems engineer at least leaf through it. The somewhat unfair comparison with the INCOSE and NASA manuals, as well as the resulting incorrect positioning, are deductions. Based on how the book is currently advertised by Flow, I would have expected something different.

Image: Wikimedia