Agilität in Internationalen Projekten

Ein Gespräch zwischen Prof. Dr. Ing. Roland Greule (HAW) und Arthur Wendelgaß zu einem Beispiel für Best Practice

Roland Greule: Meine Studenten schwärmen oft von agiler Softwareentwicklung und SCRUM. Arthur, du warst ja lange bei Airbus. Hat das Thema Agilität auch in einem Luftfahrtkonzern wie Airbus eine Rolle gespielt? Hier geht es doch vor allem um Sicherheit.

Arthur Wendelgaß: Agiles Arbeiten oder englisch Agile Development hat heute in vielen Bereichen Einzug in die Softwareentwicklung gehalten, auch bei sicherheitsrelevanten Themen. Viele verbinden Agile Development irgendwie mit Chaos, oder einer „jeder macht was er will“ Mentalität. Das ist falsch. Agilität geht in erster Linie mit einer neuen Denkeinstellung, neudeutsch Mindset einher. Das Produkt ist das wichtigste. Das Produkt wird von Menschen für Menschen gemacht, folglich steht bei agilem Vorgehen auch der Mensch im Mittelpunkt, bzw. die Zusammenarbeit von Menschen.

Roland Greule: Was heißt das konkret?

Arthur Wendelgaß:  Ich erkläre das mal an einem konkreten Beispiel aus meinem beruflichen Werdegang.:

1998 übernahm ich die Leitung eines Software Teams. Dieses Team (MST genannt), entwickelte damals bereits seit Jahren die Missionssoftware für ein Flugzeug in der Programmiersprache Ada. Unser Kunde, ein öffentlicher europäischer Auftraggeber, forderte jedoch immer mehr Funktionalität zu einem günstigeren Preis, da die Budgets kontinuierlich schrumpften.

Für uns bestand die Gefahr, den Auftrag zu verlieren, würden wir unser Entwicklungs – Framework nicht sehr schnell effektiver gestalten können.

Roland Greule: Was war euer Framework?

Arthur Wendelgaß:  Wir entwickelten nach dem klassischen Wasserfall Modell, das heißt, erst wurde eine Systemspezifikation im Detail verhandelt und dokumentiert, dann eine Softwarespezifikation, eine Softwarearchitektur, schließlich Software Requirements. Wenn alles fertig war wurde codiert bzw. implementiert. Dann ging es im V-Model wieder nach oben, Phase für Phase wurde gegen die entsprechende Spezifikation verifiziert.

Roland Greule: Ich nehme an, das war um die Standards zu erfüllen, die für fliegende Software gefordert sind?

Arthur Wendelgaß:  Das ist richtig. Unsere Frage war also: was können wir ändern, ohne diese Standards zu ignorieren? Was sind unsere Kostentreiber? An welchen Stellschrauben können wir drehen?

Roland Greule: Was waren die Hauptprobleme eurer alten Vorgehensweise im Wasserfallmodell?

Arthur Wendelgaß:  

1. Zu lange Verhandlungen über SW Funktionalitäten, Lieferzeiten und Kosten, die sich später als obsolet erwiesen, weil Hardwarekomponenten zu spät oder mit geänderter Spezifikation geliefert wurden.
2. Der Vertrag forderte eine nach Standard spezifizierte Dokumentation, wir sprechen dabei von Schränken voller Ordner. Die Dokumentation entsprach wegen der schnellen Änderungen jedoch selten dem aktuellen Stand.
3. Der zuerst festgezurrte Festpreis musste wegen immer wieder geänderten Kundenanforderungen wieder aufgemacht werden (schlecht für den Geldbeutel des Kunden, schlecht für unsere Reputation, denn am Ende interessierte sich niemand für die Gründe der Kostensteigerung)
4. Technisch komplexe Anforderungen wurden teilweise vom Kunden, aber auch von uns nicht verstanden und erst nach Softwareauslieferung an den Kunden im Flieger als nicht sinnvoll erkannt
5. Viel Nacharbeit bzw. Neuprogrammierung wurde notwendig. Extra Versionen zur Fehlerbeseitigungen mussten geliefert werden, teilweise auf unsere Kosten.
6. Es gab häufig Streit um Fehlerursachen (Falsche Anforderung oder falsche Implementierung)

Da immer das ganze Produkt „verhandelt“ wurde, bevor man die nächsten Ebene des Wasserfalls erreichte, waren auch die Änderungskosten sehr hoch.

Roland Greule: Was habt ihr unternommen?

Arthur Wendelgaß: Aufgrund unserer langjährigen Zusammenarbeit gelang es uns, den Kunden zu einem Workshop einzuladen, indem wir unseren gemeinsamen Entwicklungsprozess in Frage stellten. Teilgenommen haben u.a.: Experten meines Teams, Programmleitung, Kundenexperten (Technisch und Kommerziell), Endkunde (Piloten, Wartung).

Der dreitägige Workshop brachte noch kein Endergebnis, aber er war der Anfang einer engen Zusammenarbeit im Interesse beider Parteien.  Es dauerte dann fast 2 Jahre und viele weitere gemeinsame Workshops, danach hatten wir ein neues Framework aufgesetzt und nannten es FSD – Flexible Software Development (oder evolutionäre Softwareentwicklung).  Dieses Framework erfüllte immer noch alle Anforderungen, die für die Entwicklung fliegender Software gefordert waren.

Roland Greule: Was habt ihr gemacht und welche Vorteile habt ihr erzielt?

Arthur Wendelgaß: Unser neues Vorgehensmodell haben wir Flexible Software bzw. Evolutionary Software Development genannt. Wir haben damit die 6 oben von mir erwöhnten Hauptnachteile des Wasserfall Modells aufgehoben:

1. Wir vereinbarten jährlich Software zu liefern, die geflogen werden konnte und eine klar definierte Menge an neuen Funktionalitäten. Diese Menge wurde mit der Methode MASTER (diese Methode erlaubt das parametrisierte Abschätzen von Funktionalitätszuwachs, ich habe sie hier kurz skizziert) definiert.
2. Dokumentation wurde durch Information ersetzt, das heißt wir lieferten die von modernen visuellen Entwicklungstools digital generierten Informationen als Single Source auf digitalem Medium bzw. über verschlüsselten Link.
3. Die Methode MASTER erlaubte die Messung von Funktionalität und deren Kosten.
4. Wir hatten einen Flugsimulator entwickelt, in den die Original Missionssoftware geladen werden konnte. Den Simulator stellten wir auch unseren Kunden zur Verfügung. So konnten sowohl wir, als auch der Kunde unsere Daily Loads testen und Feedback geben. Parallel dazu wurden vom Kunden Testpiloten in unser Team abgestellt, welche unsere Softwareentwickler berieten und die Software gemeinsam mit unseren Testern evaluierten.
5. Wir lieferten teilweise täglich sogenannte Daily Loads sowie im monatlichen Rhythmus Snapshot Loads.  Im Jahresrhythmus wurde eine voll konfigurierte offizielle Load für das Flugzeug geliefert, also 2-3 mal so häufig wie zuvor.
6. Durch die verschränkten Teams und die häufigen Software Lieferungen blieben Streitigkeiten größtenteils aus

Roland Greule: Wenn ich es also richtig verstanden habe, dann war die Crux eures FSD Modells, ein großes Paket von Gesamtfunktionalität in Teilstücke zu zerlegen und diese in kleinen Teilstücken zu liefern. Ich glaube meine Studenten würden das als Sprint bezeichnen.

Arthur Wendelgaß: Genau, das ist schon ziemlich analog dazu. Designprobleme wurden in der Simulation also am fertigen Produkt gemeinsam mit dem Kunden sehr früh gefunden und so die Änderungskosten um mehr als 90% reduziert. Man bezeichnet diese Minimal-Inkremente auch als Minimum Viable Products (MVPs)

Roland Greule:  Setzte sich die Vorgehensweise durch?

Arthur Wendelgaß: Ja.Wir gehörten damals wahrscheinlich zu den Pionieren im Konzern. Das war Anfang des Jahrtausends. Mittlerweile haben sich im Konzern agile Entwicklungen mehr und mehr unter Anwendung des SCRUM Frameworks durchgesetzt.

Auch die agile Terminologie hat sich durchgesetzt. Wir waren damals Wegbereiter. Geschafft haben wir das, weil wir die Eigenmotivation – also die intrinsische Motivation – der Teammitglieder gefördert haben.

Roland Greule:  Und wie hat das der Kunde akzeptiert?

Arthur Wendelgaß: Das ist eine sehr gute Frage. Am Anfang hieß es immer, wir dürfen nichts an der Vorgehensweise ändern, weil der Standard alles so vorschreibt, also das vielzitierte „geht nicht weil„. Aber durch Vertrauens fördernde Maßnahmen habe wir es geschafft, seitwärts zu denken und gemeinsam mit dem Kunden FSD auf- und umzusetzen.

Roland Greule:  Würdest du sagen, dass sich eine agile Vorgehensweise also mehr oder weniger in allen Bereichen umsetzen ließe?

Arthur Wendelgaß: Agiles Handeln lässt sich so oder ähnlich auf andere, auch kleine und mittelständische Unternehmen übertragen, gleichgültig ob es sich um Software- oder Hardwareprodukte handelt, ob im Controlling, Marketing oder im Vertrieb. Übrigens auch in der Stadtverwaltung und in der Hochschulverwaltung. Wichtig ist dabei folgendes:

1. Gemeinsame Interessen gegenseitig verstehen. Bedürfnisse, Erwartungen und Anforderungen neu verstehen. Die aktuelle Zusammenarbeit an diesem neuen Verständnis überprüfen. Den Satz „Das haben wir schon immer so gemacht“ langsam aus der Kultur entfernen. Intrinsische Motivation zum Neu- Quer- und Seitwärtsdenken schaffen.
2. Wie können wir die Interessen künftig besser umsetzen. Was können wir neu vereinbaren. Erst wenn wir dies gemeinsam erarbeitet haben, achten wir wieder auf Effizienz. Vorher geht es um Effektivität: erst das richtige tun, dann es richtig tun und dabei immer besser werden.
3. Wie ersetzen wir die Planung von damals durch eine flexible Planung
4. Welches minimalen Inkrements (Minimum Viable Product, MVP), also welches „minimal überlebensfähiges Produkt) können wir unserem Kunden liefern, damit er früh sieht was er bekommt und früh Feedback geben kann.
5. In welchen Zyklen wollen und können wir liefern, welche Zyklen benötigt der Kunde.
6. Austausch von Personal (z.B. für Pilotprojekte) zwischen den Teams zwecks Vertrauensaufbau und gegenseitigen Lernen

Führt man diesen Paradigmenwechsel langsam durch (wie im Beispiel FSD), baut man Hemmschwellen ab, die sich in Unternehmen gegenüber neuen Methoden häufig finden.

Roland Greule: Ich nehme an, du wirst in der nächsten Vorlesung darüber etwas erzählen.

Arthur Wendelgaß: Klar, freue mich schon darauf, wieder mit Studenten zu arbeiten. Vielen Dank für dein Interesse

Roland Greule: Vielen Dank für das Gespräch

---

Hier finden Sie ein Beispiel für Story Points und eine Erklärung, warum die oben besprochene agile Vorgehensweise zu Kosteneinsparungen und noch mehr Funktionszuwachs pro Zeit geführt hat

---

Link zu Prof. Dr. – Ing. Roland Greule