Rezension: Agile Systems Engineering — The Modern Handbook (Volume 1)

Ein Marketing-Gag oder eine ernste Alternative? Flow Engineering positioniert dieses Handbook provokant als Ersatz für das INCOSE System Engineering Handbuch. Pari Singh hat in wenigen Tagen über 600 Anfragen für einen Preview des Handbuchs bei LinkedIn eingesammelt. Nun ist der erste Teil öffentlich (und kostenlos) verfügbar. Im Folgenden eine Rezension.

Zielgruppe: Alle am agilen Systems Engineering interessierte Menschen, vom Ingenieur bis zum Entscheider.

Bewertung: ★★★☆☆ Man darf auf keinen Fall ein Buch erwarten, dass mit dem INCOSE (oder NASA) SE-Handbuch vergleichbar ist. Wer das tut, wird enttäuscht werden. Das hier ein anderes Ziel verfolgt wird, zeigt sich schon an der Länge (ca. 25 Seiten für Volume 1). In diesem Buch geht es um Konzepte, nicht Details. Weiterhin ist diese Buch ein Vertriebswerkzeug für Flow Engineering. Das ist natürlich völlig in Ordnung.

Wer sich damit wohl fühlt und sich dann auf das Buch einlässt, bekommt inspirierende Fakten an die Hand, um sowohl das Management von agilem Systems Engineering zu überzeugen, also auch Checklisten für die Umsetzung und viele gute Ideen.

Erwerben: Das Buch ist kostenlos und zur Zeit ohne Registrierung bei Flow Engineering abrufbar. Eine PDF-Version konnte ich nicht finden, allerdings ist die Formatierung über die Browser-Druckfunktion in Ordnung (27 Seiten für Volume 1).

Autoren: Dieses Buch ist eine Gemeinschaftsarbeit von Autoren, die sich primär aus dem Kundenkreis von Flow Engineering zusammensetzen. Pari Singh hat an allen Kapiteln mitgewirkt.

Warum dieses Buch?

Über Pari Singh und Flow Engineering hatte ich hier schon mehrfach geschrieben. Mit seinem Werkzeug Flow Engineering hat er ein Produkt geschaffen, das agile Hardwareentwicklung ermöglichen soll. Werkzeuge sind zwar wichtig, doch ohne eine entsprechende Methodik und Rahmenbedingungen verpufft ein großer Teil des Mehrwerts eines Werkzeugs.

Die von Pari empfohlene (und im Buch beschriebene) Methodik ist unter verschiedenen Begriffen bekannt, zum Beispiel „Extreme Hardware“. Die Kernidee ist es, in kurzen Iterationen viele Versionen des Gesamtsystems zu bauen. Prominentester Vertreter dieses Ansatzes ist SpaceX. Mit diesem Ansatz hat das Unternehmen selbstlandende Raketen innerhalb von 2 Jahren entwickelt und Überarbeitet, baut und testet das Raptor-Triebwerk alle 2 Tage.

SE-Handbücher von INCOSE & NASA

Die Ansätze von INCOSE und NASA bezeichnet Pari abwertend als „Wasserfall“. Fair ist das nicht: Schließlich raten diese zwei Organisationen vom Wasserfall-Modell ab. Die linke Seite des V-Modells wird oft als Wasserfall missverstanden. Und leider manchmal auch fälschlicherweise als Wasserfall praktiziert.

RIP INCOSE und der Ansatz der 1990er Jahre.

Pari Singh

Missverständnisse und falsche Vorstellungen sind im Systems Engineering sowieso weit verbreitet. Hinzu kommt, dass INCOSE- und NASA-SE-Handbuch nicht unbedingt leicht verdauliche Kost sind.

Inhalt von Volume 1

Volume 1 wird auf einer einzigen Webseite zur Verfügung gestellt, der Inhalt ist mit Zitaten, Tabellen, Diagrammen und Case Studies aufgelockert. Der Band besteht aus 4 Kapiteln, die sich in einem Rutsch durchlesen lassen.

Vorweg: Im Handbook wird oft über „Hardware“ gesprochen. Gemeint sind damit Systeme, die eine Hardware-Komponente haben, wie Raketen oder Autos. Dass diese auch — oft große — Softwareanteile haben, ist für die Autoren eine Selbstverständlichkeit.

Kapitel 1: Wie es um das Hardware-Engineering steht

In diesem Kapitel legen die Autoren zunächst, warum eine grundlegende Veränderung im Systemengineering von der traditionellen „Wasserfall“-Methode hin zu einer iterativen und agilen Herangehensweise überlebenswichtig ist. Iterativ entwickelte Systeme sind schneller, kostengünstiger und anpassungsfähiger. Der Wandel wird durch die wachsende Komplexität von Systemen und die Notwendigkeit, schneller mit Änderungen umgehen zu können, angetrieben. Beispiele wie SpaceX verdeutlichen die Überlegenheit des iterativen Ansatzes.

Interessant sind die vier in diesem Kapitel identifizierten Treiber für Änderung: (1) Komplexität (2) Änderungen von Anforderungen, (3) Vermehrte Fixpreis-Projekte und (4) Neuentwicklungen („Green Teams“).

Kapitel 2: Die Kultur des Systems Engineering bei SpaceX

Das zweite Kapitel untersucht, wie Systems Engineering bei SpaceX-praktiziert wird. SpaceX definiert Systems Engineering neu, indem es Verantwortung an jeden Ingenieur delegiert und die herkömmliche Rolle des Systemingenieurs ersetzt. Entscheidungsfindung erfolgt schnell und direkt durch die verantwortlichen Ingenieure („Responsible Engineers“, REs). Cross-funktionale Zusammenarbeit und eine Netzwerkstruktur fördern Innovation und Effizienz, während die Rolle des Systemingenieurs zu einer unterstützenden und koordinierenden Funktion wird.

Iterativ ist nicht agil: Agil ist die Fähigkeit, auf Änderung zu reagieren. Iterativ ist die Fähigkeit, schnell neue Versionen zu produzieren.

Konkret enthält das Kapitel eine Liste von acht Praktiken, die auf anderen Unternehmen übertragen werden können (wenn die Kultur mitspielt). Manche davon sind weitläufig bekannt („Every Engineer is a Systems Engineer“). Andere weniger, zum Beispiel die Tatsache, dass es den Titel „Systems Engineer“ bei SpaceX eigentlich nicht gibt. Stattdessen gibt es den „Design Reliability Engineer“.

Spannend fand ich auch die Umbenennung von internen Anforderungen in „Design Critera“, mehr dazu in Kapitel 4.

Kapitel 3: Die fünf Reifestufen des Systems Engineerings

Dieses Kapitel beschreibt ein Reifemodell für Systems Engineering, das die Entwicklung von grundlegenden zu fortgeschrittenen Methoden aufzeigt. Es betont die Bedeutung iterativer Ansätze, die Risiken minimieren und die Effizienz steigern. Fallstudien zeigen, wie führende Unternehmen wie SpaceX neue Maßstäbe setzen und komplexe Probleme schneller lösen.

Dieses Kapitel ist sehr kurz gehalten — denn das Maturity Model gibt es nur gegen Registrierung (ich warte noch darauf, dass mich jemand von Flow diesbezüglich kontaktiert).

Kapitel 4: Design Criteria statt Anforderungen

Es gibt interne und externe Anforderungen, wobei externe Anforderungen primär die Aufgabe haben, eine Vertragserfüllung zu prüfen. Der größte Anteil von Anforderungen wird für die interne Zusammenarbeit benutzt und als flexible „Design Criteria“ gesehen, die kontinuierlich angepasst und optimiert werden. Dieser Ansatz fördert die Zusammenarbeit und ermöglicht es Ingenieuren, Verantwortung für die Anforderungen ihrer Projekte zu übernehmen. Diese Vorgehensweise führt zu einer Reduktion und Priorisierung von Anforderungen, welche Komplexität reduziert.

Auch an dieser Stelle gibt es, wie schon in Kapitel 3, einen Pitch für das Produkt von Flow Engineering, mit dem sich (laut Flow) moderes Anforderungsmanagement praktizieren lässt.

Aussicht auf Volume 2

Die Kapitelnamen stehen schon, sind aber noch nicht veröffentlicht:

• Kapitel 5 – Anforderungen und Entwurfskriterien
• Kapitel 6 – Rituale und Prozesse: Arbeitsabläufe für agile Teams
• Kapitel 7 – Änderungsmanagement in agilen Teams
• Kapitel 8 – Kontinuierliche Tests und V&V
• Kapitel 9 – Sicherheit und Regulierung

Fazit

In diesem Buch stecken eine Menge wirklich guter Ideen, die wir im Systems Engineering auch unbedingt brauchen. Aufgrund der Kürze und Zugänglichkeit (kostenlose Webseite) empfehle ich jedem Systems Engineer, zumindest mal durchzublättern. Abzüge gibt es durch den etwas unfairen Vergleich mit den INCOSE- und NASA-Handbüchern, sowie der dadurch entstandenen falschen Positionierung. Basierend darauf, wie das Buch aktuell von Flow beworben wird, hätte ich etwas anderes erwartet.

Bild: Wikimedia