Agile Methoden in komplexen Aerospace & Defence-Projekten

Von Dr. Martin Kraus //

Der Ursprung agiler Methoden

Vor etwa 25 Jahren begann der Hype um „Lean“: Lean Management, Lean Production, Lean etc. Das Buzz-Word der heutigen Zeit ist „Agile“. Bei unseren Kunden und in der ge­samten Industrie finden wir Change-Projekte rund um Agilität: Agiles Unternehmen, agiles Management, agile Entwicklung, agile Pro­zesse usw. Aber wir sehen ein sehr diffuses Bild über das, was unter „agil“ verstanden und was mit diesen Veränderungsprojekten erreicht werden soll.

Seinen Ursprung, wenn man das überhaupt so sagen kann, hat „Agile“ Mitte der 90er Jahre im von Jeff Sutherland und Ken Schwaber im „Agile Manifesto“ beschrie­be­nen Prozess-Modell, das in seiner Anwend­ung allgemein als „Scrum“ bekannt ist. Im Fokus standen dabei Software-Ent­wicklungen, bei denen sowohl die Produkt­eigenschaften als auch der Weg der Realisierung am Projektbeginn nicht eindeutig sind.

Zur Klärung der Frage, wann ein Projekt mit einer agilen oder einer „klassischen“ Me­thode im Entwicklungsprozess und Projekt­management durchgeführt werden soll, wurde von Ralph Douglas Stacey ein Krite­rienkatalog erarbeitet, der als „Stacey-Matrix“ bekannt wurde.

Das Prozessmodell Scrum selbst ist einfach, aber in einer Weise so stringent, dass der Prozess als solcher keinesfalls als agil be­zeichnet werden kann. Außenstehende erlie­gen hier häufig schon dem ersten Missver­ständnis. Weiterhin ist Scrum nur ein Ansatz beim Versuch, Komplexität zu beherrschen. Verringern kann man sie damit nicht. Der Nachweis, dass Scrum in größeren, komple­xen Softwareprojekten erfolgreich umge­setzt wurde, ist m.E. bisher nicht erbracht.

Der Transfer agiler Methoden in den Bereich Aerospace & Defence

Zunehmend wird versucht, die Scrum-Methodik auch auf andere Produktentwick­lungsprojekte und dementsprechend auf das Projektmanagement zu übertragen. Hierfür gibt es gute Ansätze, allerdings erst dann, wenn man die Ideen und Prozess-Elemente aus dem „Agilen Manifest“ in geeigneter Weise adaptiert. Womit man sich, zumindest aus Sicht der „ideologischen Urväter“, von Scrum entfernt.

Den Scrum-Hype ausnützend bewerben manche Unternehmen ihre Produkte sogar damit, dass sie mit agilen Methoden entwi­ckelt wurden. Damit erheben sie Scrum und agile Methoden zu einem Qualitätsmerkmal, was sie aber definitiv nicht sind.

Die Aerospace & Defence-Welt unterscheidet sich von der Software-Industrie (z.B. Gaming, VR, App-Entwicklung) oder der Konsumgüter-Welt in vielen Punkten teil­weise grundlegend, z.B.:

• Die Vorhaben sind umfangreicher, d.h. sie involvieren große Teams, viele Personen, Partner und Lieferan­ten.
• Die Projekte sind oft multi-national mit Partnerfirmen in unterschiedli­chen Län­dern und Standorten. Das erfordert das Zusammenkommen unterschiedlicher Prozesswelten und – vor allem – Kultu­ren.
• Diese Komplexität ist das Spiegelbild der Kundenseite mit unterschiedli­chen Anfor­derungen an ein Produkt oder ein System sowie mit teils ge­genläufigen politischen und wirt­schaftlichen Interessen (z.B. „local workshare“).
• Die Entwicklungsprojekte sind kom­plex und beinhalten meistens Kom­ponenten, bei denen die Grenzen der Machbarkeit ausgereizt werden.
• Die Entwicklungs- und Produkt­lebenszyk­len sind viel länger als in den dynami­schen, verbraucher­nahen Industrien.
• Obwohl immer mehr Funktionalität durch Software realisiert wird, wird die Gesamt­performance durch die Integration von Hard- und Software und mit einer Platt­form erreicht.
• Komplexe Qualifikations- und Zulas­sungsvorgaben beeinflussen sowohl das Design selbst als auch alle Ent­wicklungs‑, Fertigungs- und Nach­weis-Prozesse.

Trotzdem sind agile Methoden und Denkwei­sen in der A&D-Welt anwendbar. In welchem Umfang und für welche Elemente eines Pro­dukts oder Systems sollte jedoch jeweils sorgfältig analysiert werden. Bestimmte Pha­sen eines Projekts sind möglicherweise bes­ser geeignet als andere. Z.B. ist die Konzept- oder auch die Definitionsphase eines Pro­jekts geeignet, mit Scrum-nahen Ansätzen bearbeitet zu werden. Voraussetzung ist, dass sich alle Partner und vor allem auch der Kunde bzw. die Kunden auf ein solches Vor­gehensmodell einlassen, das ein hohes Maß an Interaktion erfordert. So kann als Ergeb­nis eine von allen Seiten gleich verstandene und gemeinsam getragene Produktbeschrei­bung oder Spezifikation stehen.

Auch eine Software-Architektur oder spezifi­sche Software-Funktionen können mit Scrum oder zumindest davon abgeleitet entwickelt werden. Hierfür sind jedoch generell neue SW- und SW/HW-Architekturen erforderlich. „App“-nahe Anwendungen in einem funktio­nalen SW-Verbund ermöglichen nicht nur agile Entwicklungsmethoden, sie erlauben auch flexiblere Anpassungen während des Produktlebenszyklus.

Agile Methoden im Widerspruch zu anderen Vorgehensmodellen?

Für viele Projekte in unserer Branche ist die Anwendung des „V-Modells“ vertraglich ver­einbart. Das V-Modell hat sich seit seiner Ein­führung (übrigens durch den deutschen öf­fentlichen Auftraggeber) sehr bewährt und hat auch Eingang in nicht-militärische Berei­che gefunden. Heute hört oder liest man ge­legentlich, dass Unternehmen das V-Modell durch agile Methoden ersetzen wollen. Auch hier liegt ein Missverständnis vor. Die beiden Vorgehensmodelle stehen keineswegs im Wi­derspruch. Agile Methoden lassen sich mit dem V-Modell problemlos verbinden. Die Vorteile und die Logik des V-Modells sollten nicht ad acta gelegt werden. Auch als for­male Grundlage für die Qualifikation und die Zulassung ist es bewährt.

Ein gerne gewähltes Beispiel für eine Scrum-Anwendung in der jüngeren Luftfahrt ist die Gripen E von SAAB. Allerdings steht hierfür lediglich ein mit dem „Scrum-Institute“ ge­haltener Vortrag als öffentlich zugängliche Quelle zur Verfügung. Weitere Recherchen und persönliche Diskussionen mit SAAB zu­folge wurden alle Prozesse auf „agil“ umge­stellt und auch sicherheitskritische Software mit Scrum entwickelt. Allerdings lassen die Gripen-Programmverzögerungen zumindest gewisse Zweifel an der erfolgreichen Imple­mentierung zu.

In der A&D-Industrie stellen sich hybride Vorgehensweisen in der Entwicklung und im Projektmanagement als beste Lösung her­aus. Bei den agilen Methoden dürfte sowohl für das Management als auch den Kunden eine Herausforderung beispielsweise darin bestehen zu akzeptieren, dass beim Start des (Teil-)Projekts weder eine Zeit- noch eine Budgetplanung existieren und auch nicht bekannt ist, in welcher Abfolge welche Teillösungen und Zwischenprodukte verfüg­bar sind.

Unternehmensweite Agilität

Lenkt man den Fokus auf das Gesamtunter­nehmen, dann muss eine „Agilisierung“ ganzheitlich betrachtet und angegangen werden. Es ist per se nicht ausreichend zu fordern, die Entwicklung oder die Fertigung müsse agiler werden. Es müssen dann alle operativen Kernprozesse und die Manage­mentprozesse erst der Analyse und dann der Veränderung unterzogen werden.

Für ein größeres, vielleicht sogar unterneh­mensweites Veränderungsprojekt unter dem Leitsatz „Wir wollen agiler werden!“ müssen am Anfang vor allem ein übergreifendes, ge­meinsam getragenes Verständnis von „Agili­tät“ und „agil“ geschaffen sowie die überge­ordneten Ziele des Projektes klar und ver­ständlich vereinbart werden. Andernfalls ist schon das Veränderungsprojekt selbst das Gegenteil von agil und wird wirkungslos blei­ben.

Für eine Initialdiskussion und bei der Erar­beitung der Zielsetzungen eines „Agility“-Veränderungsprojekts steht Ihnen das ACTRANS-Team zur Verfügung.