Scrum in der Hardware: Agile Hochleistungsflugzeuge

[caption id="attachment_24741" align="aligncenter" width="666"]

Saab Gripen - by Peter Gronemann, CC BY 2.0[/caption]Der Nachbrenner röhrt und zeichnet die Spur der Hochtechnologiemaschine im Himmel nach. Mit neunfacher Erdbeschleunigung fliegt das Düsenflugzeug in einer engen Kurve über das Feld. Der Pilot spannt seine Oberschenkelmuskeln an und kämpft verbissen gegen die extrem hohen Kräfte, die ihn in den Sitz pressen. Er reißt das Kampfflugzeug plötzlich senkrecht nach oben, reduziert den Schub, rollt es mit einer leichten Handbewegung auf den Rücken und vollendet das Manöver mit einem halben Looping. Zufrieden lächelt er und bestätigt den Funkspruch aus dem Tower, der ihn zurück zur Landebahn lotst.Was manchen bei Flugshows ein freudiges Lächeln ins Gesicht zaubert, würde bei einem Flug in den Urlaub maßlos verärgern oder verängstigen. Normale Passagiermaschinen sind auf Sicherheit und Treibstoffeffizienz ausgelegt, und das erfordert eine sogenannte „stabile Auslegung“. Das bedeutet, dass das Flugzeug zum Beispiel bei Windböen oder kurzen Ausschlägen der Steuerflächen von selbst wieder in die Ausgangslage zurückkehrt. Für militärische Hochleistungsflugzeuge ist es hingegen wichtig, schnell und wendig zu sein, damit sie ihre Missionen erfüllen können. Um im Luftkampf überlegen zu sein, werden moderne Modelle deshalb häufig instabil ausgelegt: eine kleine Böe genügt um die Maschine in Bruchteilen von Sekunden senkrecht nach oben auszulenken. Agilität ist für den Erfolg eines Hochleistungsflugzeugs ausschlaggebend. Aber auch dessen Entwicklung kann agil sein.

Agile Entwicklung anno 1943

Erste Anzeichen von agilen Methoden in der Luftfahrt findet man schon ab 1943 in den Lockheed Advanced Development Programs, den geheimnisumwitterten Skunk Works, der Entwicklungsabteilung für Geheimprojekte des Rüstungs- und Technologiekonzerns Lockheed. Innerhalb von 180 Tagen sollte das Projektteam eine Antwort auf die übermächtige Me-262 der Deutschen entwickeln. Deshalb stahl sich Kelly Johnson alle notwendigen Mitarbeiter – Techniker, Ingenieure, Piloten – zusammen und sammelte sie in einem Zelt. Sie konnten sich voll und ganz auf die Entwicklung ihres Flugzeugs, die P-80, konzentrieren und nutzten andere agile Methoden – auch, wenn sie es damals nicht so genannt hätten. Ihr Ziel konnten Sie tatsächlich schon nach 143 Tagen erreichen.In jüngerer Zeit hat der schwedische Automobil- und Rüstungskonzern Saab mit seinem neuesten Flugzeugmodell, dem Gripen (Greif) E Multirole Fighter, ein neues Vorgehen für die in der Luftfahrt traditionell langen Entwicklungszyklen genutzt. Sie haben jedoch nicht nur die Software, sondern gleich das gesamte Flugzeug mit dem agilen Framework Scrum entwickelt. Bei Saab sind auf allen Ebenen und in jeder Domäne agile Methoden implementiert. Egal, ob Software, Hardware oder im Rumpf-Design: Saab nutzt unter anderem Praktiken aus Scrum, Kanban, XP und dem Lean Management. Das führt im Vergleich zu klassischen Luftfahrt-Entwicklungsprojekten zu zahlreichen Unterschieden in der Art, wie die Menschen zusammenarbeiten und Entscheidungen treffen.

Entschieden wird dort, wo die Information ist

Die Teams haben Klarheit über das Ziel, haben aber gleichzeitig die Freiheit, eigene Innovationslösungen zu schaffen. Sie haben die Freiheit, die beste Implementierung für ihren jeweiligen lokalen Kontext zu wählen und weiterzuentwickeln. Dadurch ergeben sich, je nach Team, auch Unterschiede im Reifegrad ihrer Agilität. Sie werden prozessual und technisch weitestgehend ermächtigt und auch Entscheidungen werden so weit wie möglich auf der Teamebene gefällt. Das setzt voraus, dass die technische Verantwortung ebenfalls dort liegen muss. Der Fokus von Saab auf autonome Teams reduziert die Bürokratie und ermutigt die Entscheidungsfindung auf der niedrigstmöglichen Ebene in der Projektorganisation. Dafür können Entscheidungsregeln genutzt werden, um ökonomische Fragen möglichst dezentral zu beantworten.Ein Beispiel aus der Entwicklung der B-777 bei Boeing liefert Donald Reinertsen in seinem Buch „The Principles of Product Development Flow“. Der Product Owner arbeitet mit allen Stakeholdern auf den verschiedenen Managementebenen zusammen. Er ist verantwortlich für die Ermittlung des Wertes von Features und priorisiert sie in regelmäßigen Abständen neu. Die herausfordernde Aufgabe des Product Owners ist es, als Schnittstelle zwischen den oberen Managementfunktionen und der Teamebene zu fungieren, da ein so großes Projekt sehr viel Koordination benötigt. Es ist wichtig, dass zum Zeitpunkt der Sprint-Planung der Teams, zu Beginn jedes Sprints, der Backlog bereit ist und vom Team bearbeitet werden kann. Dem Team ist klar, was geliefert werden muss, welche Abhängigkeiten vorhanden sind, und kann den Sprint mit gutem Gewissen beginnen. Die Product Owner der einzelnen Teams sind dafür verantwortlich zu klären, was die internen Kunden wollen und kommunizieren diese Erkenntnisse in die Teams. Gleichzeitig schaffen sie Klarheit in Phasen, die von Rauschen und anderen Störungen gekennzeichnet sind, damit den Teams klar ist, was getan werden muss. Dafür ist die Visualisierung der Backlogs, Pläne und Abhängigkeiten ein wichtiges Kommunikationsinstrument zwischen den Product Ownern. Allerdings müssen strategische Pläne als lebende Dokumente gesehen werden, die aufgrund von Feedback ständig angepasst werden.

Systematische und regelmäßige Integration als Erfolgsfaktor

In einem Projekt, das so groß und komplex ist wie die Entwicklung eines Hochleistungsflugzeugs, benötigt man regelmäßige Treffen mit dem Fokus auf den Integrationsproblemen. Die ständige Prüfung und Verbesserung der Kommunikation ist entscheidend für die Entstehung von Klarheit in der gesamten Organisation. Dafür haben die Teams einen gemeinsamen Rhythmus und einen stabilen Puls. Die Sprints dauern drei Wochen und beginnen und enden am selben Tag. Saab erkannte auch die Notwendigkeit der Synchronisation über einzelne Sprints hinaus und entwickelte eine Methode für Iterationen in vierteljährlichen Zyklen, den Development Step (Entwicklungsschritt). Das ist ein klar definiertes Funktionsziel für eine größere Freigabe, typischerweise für ein bestimmtes Versuchsflugzeug. Ein Entwicklungsschritt ist wiederum in mehrere Inkremente mit kleineren, besser handhabbaren Funktions- und Produktlieferungen unterteilt. Das Inkrement hat eine Timebox von drei Monaten, was zu einer Taktung von vier Drei-Wochen-Sprints führt.Innerhalb dieser Timeboxen gibt es ein strukturiertes System von Meetings, um Abhängigkeiten auf Teamebene zu identifizieren und sie über das Projekt sichtbar zu machen. So hat Saab Retrospektiven entwickelt, die nicht nur die Teamperspektive umfassen, sondern auch teamübergreifend stattfinden, um größere Themen zu besprechen. Jeder Development Step schließt mit einem Release ab. Aber auch schon während der quartalsweisen Inkremente werden kleinere Versionen veröffentlicht, um häufiges Feedback zur Produktintegration und -gestaltung sicherzustellen. Die meisten Probleme, die bei einer großen Produktentwicklung auftreten, treten dabei während der Integration verschiedener Module auf. Durch Zyklen der Integrationstests, die sogar kürzer als ein einziger Sprint sein können, ist Saab in der Lage, diese Probleme frühzeitig sichtbar zu machen und schnell Korrekturmaßnahmen zu ergreifen. Durch das kontinuierliche Zusammenspiel von Praxis- und Lernerfahrung werden Meilensteine im Laufe der Zeit detaillierter und weniger anfällig für Veränderungen, sobald sie den richtigen Development Step erreichen und umgesetzt werden.

Modulare Architektur und konsequentes Sammeln von Feedback

Schon zu Beginn des Gripen E-Programms war eine modulare Architektur und damit Flexibilität für zukünftige Updates ein wichtiger Schwerpunkt. Nach dem Gesetz von Conway ermöglicht Modularität des Designs auch eine Modularität der Organisation – und damit mehr Geschwindigkeit durch entkoppelte Entwicklungsteams. Saab konzentriert sich dafür auch auf den Aufbau hochmoderner Simulatoren. Diese erlauben kurze Rückkopplungszyklen und damit schnelleres Feedback. Die Teams können zum Beispiel sofort Designentscheidungen in Desktop-Simulatoren überprüfen. Um Feedbackzyklen noch weiter zu verkürzen, stationiert Saab die Testpiloten und Entwicklungsteams auf dem gleichen Gelände in Linkoping in Südschweden. Dies ermöglicht eine enge Interaktion zwischen den Entwicklungsteams und den Piloten, und Feedback wird in jedem Sprint zur Verfügung gestellt. Die Validierung erfolgt auch mit den Piloten der Kunden. Durch agile Praktiken kann Saab Variabilität effektiv managen und die Leistung mit Klarheit und Engagement steigern. Das Ergebnis ist ein Flugzeug, das schneller, mit niedrigeren Kosten und höherer Qualität entwickelt werden konnte.Dieser Artikel basiert auf einem Erfahrungsbericht von Scrum Inc. bei Saab.Furuhjelm, Jörgen; Segertoft, Johan; Justice, Joe; Sutherland, Jeff: Owning the Sky with Agile Building a Jet Fighter Faster, Cheaper, Better with Scrum.