Laut einem Report des Project Management Institute (PMI) aus dem Jahr 2017 scheitern 14 Prozent aller IT-Projekte. Und zwar komplett. Von den übrigen Projekten, die nicht komplett scheitern, erreichen 31 Prozent nicht (alle) ihre Ziele, 43 Prozent überschreiten das geplante Budget und 49 Prozent liefern zu spät. Was in einem gescheiterten Projekt schlecht, oder was in einem erfolgreichen Projekt gut lief, bleibt meist im Verborgenen beziehungsweise nur den Projektbeteiligten vorbehalten.
Damit nicht nur die individuelle Entwicklerin oder der individuelle Entwickler, das beteiligte Entwicklungsteam oder das betroffene Unternehmen aus der Projekterfahrung lernen kann, sondern auch unsere Industrie als Ganzes, bedarf es einer öffentlichen Diskussion von IT-Projekten. Dies ist jedoch die Ausnahme und passiert viel zu selten, beispielsweise dann, wenn eine 655 Millionen US-Dollar teure Raumsonde verloren geht, oder wenn eine Fortune 500 Company (Hertz) eine andere Fortune 500 Company (Accenture) wegen eines gescheiterten IT-Projektes verklagt.
NASA Mars Climate Orbiter
Die Mars Climate Orbiter (MCO) Mission der NASA ist ein Beispiel für ein IT-Projekt, dessen Scheitern gut dokumentiert ist. Hierbei ging eine Sonde, die das Klima des Planeten Mars erforschen sollte, am 23. September 1999 aufgrund eines Einheitenfehlers im Navigationssystem verloren. Nur eine Woche später, am 30. September 1999, machte die NASA die Fehlerursache öffentlich: Ein Teil des Teams hatte mit Inches, Feet und Pounds gerechnet, während der Rest des Teams mit metrischen Einheiten gerechnet hatte. Bemerkenswert ist diese Aussage:
The problem here was not the error, it was the failure of NASA's systems engineering, and the checks and balances in our processes to detect the error.
Der technische Fehler, der zum Verlust der Sonde führte, wird also nicht als zugrunde liegende Ursache angesehen, sondern als Folgefehler von Unzulänglichkeiten im Entwicklungsprozess: zu wenig Kommunikation zwischen den Teams und fehlende Integrationstests.
Boeing 737 MAX 8
Im Oktober 2018 verunglückte ein Flugzeug des Typs Boeing 737 MAX 8 kurz nach dem Start in Indonesien (Lion Air Flug 610). Im März 2019 stürzte ein Flugzeug desselben Typs ebenfalls nur Minuten nach dem Start in Äthiopien ab (Ethiopian Airlines Flug 302). In beiden Fällen kamen alle Menschen an Bord ums Leben. In beiden Fällen war Software, das Maneuvering Characteristics Augmentation System (MCAS), die Ursache für den Absturz.
Robert C. Martin, Softwareentwicklerinnen und -entwicklern als "Uncle Bob" bekannt und Autor von "Clean Code", hat in einem Artikel analysiert, was über die Softwareprobleme des MCAS der Boeing 737 MAX 8 bekannt ist. Seine Perspektive ist hierbei nicht auf die eines Experten für Softwareentwicklung beschränkt. Als Pilot kennt er auch den Kontext, in dem die fragliche Software operiert. So weit bekannt ist, wurden der MCAS-Software in beiden Fällen fehlerhafte Daten von einem einzigen Anstellwinkel-Sensor geliefert. Auf Basis dieser Daten entriss das MCAS daraufhin den Piloten die Kontrolle über das Flugzeug. Die Software verließ sich auf die Daten dieses einen Sensors, ohne sie mit anderen Daten wie Fluggeschwindigkeit, Vertikalgeschwindigkeit oder Flughöhe abzugleichen — oder mit den Daten eines weiteren Anstellwinkel-Sensors. Ein solcher Cross-Check der Daten geht einer Pilotin oder einem Piloten bei der Ausbildung für den Instrumentenflug in Fleisch und Blut über. Schließlich kann ein Instrument so ausfallen, dass der Ausfall nicht direkt zu bemerken ist. In seinem Artikel stellt Robert C. Martin die Frage, warum die Softwareentwicklerinnen und -entwickler diese grundlegenden Prinzipien der Luftfahrt nicht berücksichtigten.
Hertz gegen Accenture
Im April 2019 sorgte die Klage der US-amerikanischen Autovermietung Hertz gegen ihren IT-Dienstleister Accenture für Aufsehen. Die öffentlich gewordene Klageschrift enthält viele Details, die tiefe Einblicke in ein gescheitertes IT-Projekt gewähren. Im August 2016 erteilte Hertz Accenture den Auftrag, eine neue Online-Präsenz zu entwickeln, die im Dezember 2017 in Produktion gehen sollte. Diese erste Deadline wurde ebenso verfehlt wie eine zweite (Januar 2018) sowie eine dritte (April 2018). Hertz verklagte Accenture auf 32 Millionen US-Dollar an bereits gezahltem Honorar sowie weitere Millionen, die benötigt werden, um das hinterlassene Chaos aufzuräumen. Laut Hertz hat Accenture weder eine funktionierende App noch eine funktionierende Webseite geliefert. Obwohl von Hertz eine Lösung gefordert war, die auch für die Marken Dollar und Thrifty sowie in Märkten außerhalb Nordamerikas eingesetzt werden kann, entwickelte Accenture eine Software, die nur für die Marke Hertz und nur in Nordamerika verwendbar war — und die obendrein nie fertiggestellt wurde.
Es mag verlockend sein, Schadenfreude darüber zu empfinden, dass auch große Firmen wie Hertz und Accenture ein Projekt spektakulär in den Sand setzen können. Aber das einzige, was das Scheitern dieses Projektes besonders macht, ist die Tatsache, dass zum einen sehr viel falsch gelaufen ist und zum anderen all das durch eine Klage ans Licht der Öffentlichkeit gelangte.
Accenture hat die entwickelte Software nicht getestet, zumindest weder gründlich noch rechtzeitig. Die Klageschrift kann so gelesen werden, dass weder automatisierte Tests im Allgemeinen noch Test-Driven Development im Besonderen zum Einsatz kamen. Die fehlenden automatisierten Tests lassen sich nachträglich kaum implementieren, weil nicht klar genug ist, wozu der Code eigentlich existiert. Warum sollte nicht klar sein, warum der zu testende Code existiert? Das lässt sich zwischen den Zeilen der Beschreibung anderer Projektprobleme herauslesen. Beispielsweise waren die Entwicklerinnen und Entwickler bei Accenture nicht in der Lage, den Backend-Code (Java) fehlerfrei, performant und sicher mit dem Frontend-Code (Angular) zu integrieren.
Es wäre zu einfach, und zu bequem, die Ursache für das Scheitern des Projektes allein bei Accenture zu suchen. Hertz hatte kein eigenes Entwicklungsteam, das das Projekt hätte inhouse umsetzen können, weil alle Entwicklerinnen und Entwickler Anfang 2016 entlassen worden waren. Für ein erfolgreiches Gelingen des Projekts hätte zumindest die Rolle des "Product Owner", um einen Begriff aus der Scrum-Welt zu bemühen, inhouse besetzt werden müssen. Da dies nicht passierte, lag die Verantwortung dafür, welche Anforderungen im Product-Backlog stehen und in welcher Reihenfolge diese abgearbeitet werden, nicht in der Hand des Auftraggebers, sondern beim Dienstleister. Die hieraus resultierende schlechte Kommunikation zwischen Hertz und Accenture dürfte eine der Hauptursachen für das Scheitern des Projektes gewesen sein. Und egal, ob Hertz das gefordert hat oder nicht: Accenture hat sich auf ein Go-Live-Datum committet. Anstelle des geplanten Big-Bang-Deployments, das nie passiert ist, wäre es sinnvoller gewesen, in kurzen Iterationen, Use Case für Use Case nicht nur zu implementieren, sondern auch kontinuierlich auszurollen.
Aus Fehlern lernen
Moderne Entwicklungsprozesse sehen Retrospektiven und Post-Mortems vor, um aus den eigenen Fehlern zu lernen. Diese helfen den individuellen Entwicklerinnen und Entwicklern, den einzelnen Teams sowie dem gesamten Unternehmen dabei, besser zu werden. Ich finde es lobenswert, wenn Unternehmen ihre Post-Incident-Analysis, beispielsweise im Firmenblog, öffentlich machen, wenn etwas bei ihnen schiefgelaufen ist. Das gibt anderen die Möglichkeit, aus den Fehlern der anderen zu lernen.
Natürlich können wir auch aus Dingen lernen, die in einem Projekt gut gelaufen sind. Ich schaue mir beispielsweise gerne Videos der "Classic Game Post-Mortem"-Vorträge von der Game Developers Conference an. Da lerne ich nicht nur etwas über Spiele wie Maniac Mansion oder Civilization, die ich als Kind auf dem Amiga gespielt habe, oder darüber, wie die Entwicklerinnen und Entwickler mit trickreicher Programmierung die Hardware-Limitierungen der damaligen Computer ausgereizt haben, sondern auch, wie zu der Zeit Software entwickelt wurde, wie Projekte verwaltet wurden (oder auch nicht), und so weiter. Da bin ich hinterher immer froh, dass Software heute anders entwickelt wird.
Das Chrysler-Projekt
Das Chrysler Comprehensive Compensation System (C3-Projekt) ist ein Beispiel für ein IT-Projekt, aus dem viel Gutes entstanden ist. Zu Beginn der 1990er Jahre beschloss der US-amerikanische Automobilhersteller Chrysler, eine neue Software für die Lohn- und Gehaltsabrechnung von 87.000 Angestellten zu entwickeln. Die Entwicklung in SmallTalk begann im Jahr 1994, und zwei Jahre später, ohne dass die Software auch nur eine einzige Abrechnung durchgeführt hatte, wurde Kent Beck engagiert, um das Projekt zu retten. Dieser wiederum holte Ron Jeffries an Bord. Im März 1996 schätzte das Team, dass die Software gut ein Jahr später einsatzbereit sein würde. Das C3-Projekt ging in die Geschichte der Softwareentwicklung ein, weil sich das Team 1997 entschloss, die Art, wie es arbeitet, zu ändern. Diese neue Art zu arbeiten wurde später unter dem Namen "Extreme Programming" bekannt. Die Schätzung erwies sich als fast zutreffend: Mit nur wenigen Monaten Verspätung, aufgrund einiger weniger unklarer Anforderungen, ging eine erste Version in Betrieb, mit der monatliche Lohn- und Gehaltsabrechnungen für 10.000 Angestellte abgewickelt wurden. Die von Kent Beck, Ron Jeffries und ihrem Team angewandten Praktiken — Test-First Programming, Pair Programming, engere Einbeziehung des Kunden und vor allem kurze Feedbackzyklen — wurden im C3-Projekt erfolgreich erprobt und in dessen Nachgang formalisiert und popularisiert. Sie haben die Art, wie wir alle Software entwickeln, nachhaltig verändert.
Was IT-Projekte erfolgreich macht
Erfolgreich Software zu entwickeln bedeutet, zielgerichtet vorzugehen. Diese Ziele sollten sich aus mit dem Business abgestimmten Akzeptanzkriterien ergeben. Ohne eine klare Vorgabe von Zielen (im Sinne von Tasks) laufen die Entwicklerinnen und Entwickler Gefahr, sich bei der Arbeit zu verlieren — und wissen insbesondere nicht, wann sie mit einem Task fertig sind. Es bietet sich an, Akzeptanzkriterien durch automatisierte Tests zu dokumentieren und zu überprüfen. So oder so müssen die Ziele definiert werden, bevor Produktionscode geschrieben wird. Das ist testgetriebene Entwicklung, egal ob wir es so nennen wollen oder nicht.
Die Hauptaufgabe einer Entwicklerin oder eines Entwicklers ist nicht das Schreiben von Code, sondern das Verstehen eines Problems. In seinem Artikel über die MCAS-Software der Boeing 737 MAX 8 formuliert Robert C. Martin das so:
Programmers must not be treated as requirement robots. Rather, programmers must have intimate knowledge of the domain they are programming in.
Eine Entwicklerin oder ein Entwickler kann nur dann sinnvoll arbeiten, wenn sie oder er die Domäne versteht, in der das Unternehmen agiert, für das Software entwickelt wird. Meiner Erfahrung nach funktionieren IT-Projekte dann schlecht, wenn "das Business" mit der "Kostenstelle IT" nur über Tickets kommuniziert — ohne Kontext, warum etwas geändert oder umgesetzt werden soll. Und IT-Projekte funktionieren meiner Erfahrung nach dann gut, wenn die Entwicklerinnen und Entwickler verstehen, wie das Unternehmen funktioniert und wie eine Änderung zum Unternehmenserfolg beitragen kann. Das gelingt, wenn allen Beteiligten klar ist, dass Softwareentwicklung mehr Mensch-Mensch-Kommunikation als Mensch-Maschine-Kommunikation ist.
