Das Projekt war Jahre unterwegs, hatte bereits Hunderte Millionen Dollar gekostet und lag weit hinter dem ursprünglichen Plan. Ein Teil der gelieferten Software hatte erhebliche Performance- und Usability-Probleme. Weitere Projektphasen wurden gestoppt. Dann änderte die Organisation ihr Vorgehen grundlegend und setzte auf agile Entwicklung mit Scrum. Wie Scrum ein Projekt gerettet hat – eine echte Case Study zeigt, was danach tatsächlich passierte. Wichtig ist dabei die richtige Einordnung: Scrum allein rettete das Projekt nicht. Entscheidend waren kürzere Lieferzyklen, echte Nutzerbeteiligung, klare Priorisierung, mehr Transparenz und eine grundlegende Veränderung der Verantwortung. Genau daraus lassen sich wertvolle Erkenntnisse für gefährdete IT-Projekte ableiten.

Eine große US-amerikanische Bundesbehörde wollte ihr veraltetes Fallmanagement modernisieren.

Das Vorhaben war geschäftskritisch. Zehntausende Mitarbeiter waren auf die Verarbeitung und den Austausch von Informationen angewiesen.

Bereits ein Vorgängerprojekt war gescheitert.

Das neue Programm startete 2006. Die ursprüngliche Kostenschätzung lag bei 425 Millionen US-Dollar. Später stieg die Planung auf 451 Millionen Dollar. Ursprünglich sollte die Entwicklung Ende 2009 abgeschlossen sein.

Doch das Projekt geriet erneut in Schwierigkeiten.

Eine wichtige Ausbaustufe wurde zwar formal angenommen, litt aber unter erheblichen Performance- und Usability-Problemen. Anfang 2010 stoppte die Organisation Teile der weiteren Entwicklung, um zunächst die vorhandene Lösung zu stabilisieren.

Zu diesem Zeitpunkt war klar:

Mit dem bisherigen Vorgehen würde das Projekt sein Ziel kaum erreichen.

Bis dahin wurde die Entwicklung weitgehend phasenorientiert und linear gesteuert.

Das Problem war nicht, dass ein klassisches Vorgehensmodell grundsätzlich ungeeignet wäre.

Das Problem lag in der Kombination aus:

Wenn zwischen Anforderung, Entwicklung und echtem Nutzerfeedback zu viel Zeit liegt, steigt das Risiko.

Das Team kann Monate an Funktionen arbeiten, bevor sichtbar wird:

Genau hier änderte die Organisation ihren Ansatz.

Im Herbst 2010 wurde die verbleibende Entwicklung neu organisiert.

Die Behörde wechselte zu einem agilen Vorgehen mit Scrum.

Die Entwicklung wurde fortan in zweiwöchige Sprints zerlegt. Anforderungen wurden als User Stories und technische Anforderungen als Architecture Stories bearbeitet. Nach jedem Sprint sollte neue Funktionalität demonstriert und getestet werden.

Das wirkt heute selbstverständlich.

Für ein großes, reguliertes öffentliches IT-Vorhaben war der Unterschied fundamental.

Vorher lautete die Steuerungslogik vereinfacht:

Planen → entwickeln → später prüfen.

Jetzt:

priorisieren → entwickeln → zeigen → testen → lernen → anpassen.

Damit änderte sich nicht nur die Projektmethode.

Die Informationsgeschwindigkeit des gesamten Projekts änderte sich.

Scrum rettet kein Projekt durch Daily Scrum, Sprint Planning oder neue Rollenbezeichnungen.

Sein größter Hebel liegt woanders.

Der offizielle Scrum Guide basiert auf drei empirischen Säulen:

Scrum nutzt kurze, iterative und inkrementelle Zyklen, damit Probleme und falsche Annahmen früher sichtbar werden. Die aktuell gültige offizielle Version des Scrum Guide stammt weiterhin aus November 2020.

Im dokumentierten Projekt lassen sich diese Prinzipien sehr konkret erkennen.

Ein gefährdetes Projekt braucht vor allem eines:

schnellere Wahrheit.

Mit zweiwöchigen Sprints musste das Projekt nicht mehr monatelang warten, bis sichtbar wurde, ob eine Lösung funktioniert.

Nach jedem Sprint entstand ein überprüfbares Ergebnis.

Damit verkürzte sich die Zeit zwischen:

Annahme

und

Beweis.

Das ist bei komplexen IT-Projekten enorm wertvoll.

Angenommen, ein Team benötigt sechs Monate, um festzustellen, dass eine technische Lösung ungeeignet ist.

Dann wurden sechs Monate falsch investiert.

Wird dieselbe Annahme nach zwei oder vier Wochen getestet, sinkt das wirtschaftliche Risiko deutlich.

Scrum verhindert Fehler also nicht automatisch.

Es kann aber die Kosten falscher Annahmen reduzieren.

Ein zweiter entscheidender Unterschied war die stärkere Nutzerbeteiligung.

Die Organisation gründete eine Nutzergruppe, die neue Funktionen bereits während der Entwicklung prüfte und Feedback gab.

Zusätzlich fanden zahlreiche Beta-Tests, Demonstrationen und praktische Übungen statt.

Allein während einer dokumentierten Testphase nahmen mehr als 550 Nutzer an Beta-Tests oder Demonstrationen teil. Später fand ein organisationsweiter Funktionstest mit mehr als 700 Beschäftigten statt.

Damit wurde eine der gefährlichsten Fragen im Projektmanagement früher beantwortet:

Bauen wir tatsächlich etwas, das die Anwender nutzen können?

Das unterscheidet agile Entwicklung von einer rein internen Produktionslogik.

Fortschritt bedeutet nicht:

„Die Entwicklung ist zu 80 Prozent fertig.“

Fortschritt bedeutet:

„Wir besitzen funktionierende, überprüfte Ergebnisse.“

Das hatte auch unangenehme Folgen.

Bei einem großen Funktionstest stellte sich heraus, dass die vorhandene Hardwarekapazität für den Betrieb der Lösung nicht ausreichte.

Der Termin musste erneut verschoben werden.

Zusätzliche Hardware kostete rund 6,2 Millionen Dollar.

War das ein Scrum-Erfolg?

Auf den ersten Blick nicht.

Ein neuer Termin und zusätzliche Kosten sehen eher nach einem Rückschlag aus.

Doch genau darin steckt eine wichtige Lektion:

Gute Projektsteuerung bedeutet nicht, keine schlechten Nachrichten zu produzieren. Sie bedeutet, schlechte Nachrichten rechtzeitig sichtbar zu machen.

Das Infrastrukturproblem wurde während einer realistischen Prüfung entdeckt.

Nicht erst nach dem flächendeckenden Go-live.

Transparenz kann ein Projekt kurzfristig schlechter aussehen lassen.

Langfristig kann sie erheblichen Schaden verhindern.

Parallel zum methodischen Wechsel änderte die Organisation ihre Delivery-Struktur.

Die Zahl der Mitarbeiter des bisherigen Hauptauftragnehmers im Projekt wurde von ungefähr 135 auf rund zehn reduziert.

Die Behörde übernahm wesentlich mehr Entwicklung und Steuerung selbst.

Das zuständige Kontrollorgan stellte später fest, dass die monatlichen Ausgaben gegenüber den früheren Projektphasen deutlich gesunken waren. Gleichzeitig entstand ein direkterer Blick auf die tatsächlich entwickelte Funktionalität.

Das ist für die Bewertung des Falls wichtig.

Scrum allein war nicht die Ursache der Verbesserung.

Das Projekt veränderte gleichzeitig:

Wer aus der Case Study lediglich ableitet:

„Wir brauchen jetzt Sprints“

hat die wichtigste Lektion verpasst.

In klassischen Krisenprojekten entsteht häufig ein gefährliches Phänomen.

Jeder arbeitet.

Alle berichten Fortschritt.

Trotzdem wird nichts fertig.

Scrum setzt dem ein anderes Prinzip entgegen.

Ein Increment muss nutzbar sein. Arbeit, die die vereinbarte Definition of Done nicht erfüllt, gehört nicht zu einem fertigen Increment.

Für ein gefährdetes Projekt ist das entscheidend.

Denn es trennt:

begonnen

von:

fertig.

Ein Projekt kann 80 Prozent seiner Arbeit begonnen haben und trotzdem praktisch nichts lieferfähig haben.

Deshalb sind bei einem Recovery-Vorhaben Fragen wie diese wichtiger:

Scrum erhöht den Druck, genau diese Unterschiede sichtbar zu machen.

Das Projekt verfügte ursprünglich über mehr als tausend dokumentierte Anforderungen.

Im Verlauf wurden Anforderungen verändert, entfernt oder teilweise auf andere Systeme übertragen. Ein Executive Steering Council kontrollierte Änderungen an den formalen Anforderungen.

Auch das ist eine wichtige Recovery-Lektion.

Gefährdete Projekte können nicht automatisch gerettet werden, indem das Team:

Oft muss neu entschieden werden:

Was brauchen wir wirklich?

Dann wird Scope zur Managemententscheidung.

Nicht zum historischen Versprechen.

Im Juli 2012 wurde die neue Lösung allen Anwendern zur Verfügung gestellt.

Die Behörde berichtete, dass das System anschließend regelmäßig für die tägliche elektronische Fallbearbeitung eingesetzt wurde.

Die offiziellen Projektkosten bis zur Bereitstellung wurden mit rund 441 Millionen US-Dollar angegeben. Damit lagen sie zehn Millionen unter dem zuletzt verfügbaren Budget von 451 Millionen Dollar.

Diese Zahl braucht allerdings Kontext.

Die Aufsichtsbehörde wies darauf hin, dass unter anderem zwei Jahre späterer Betriebs- und Wartungskosten sowie bestimmte interne Personalkosten in dieser Darstellung nicht enthalten waren. Außerdem wurden nicht alle ursprünglich vorgesehenen Funktionen innerhalb des Systems umgesetzt.

Deshalb wäre die Aussage:

„Scrum hat das Projekt plötzlich billig und pünktlich gemacht“

falsch.

Die bessere Bewertung lautet:

Ein stark gefährdetes Großprojekt wurde nach einer grundlegenden Neuausrichtung in einen Zustand gebracht, in dem ein nutzbares System flächendeckend ausgeliefert werden konnte.

Das ist ein erfolgreicher Turnaround.

Aber kein Scrum-Märchen.

Aus der Case Study lassen sich sechs zentrale Faktoren ableiten.

Zwei Wochen statt monatelanger Blindflug.

Fortschritt wurde überprüfbarer.

Feedback kam während der Entwicklung.

Nicht erst danach.

Nicht alles musste gleichzeitig umgesetzt werden.

Die Organisation reduzierte die Abhängigkeit von einem großen externen Liefermodell.

Der ursprüngliche Plan wurde nicht länger als unveränderbare Wahrheit behandelt.

Das ist vermutlich der wichtigste Punkt.

Scrum funktioniert nur, wenn die Organisation tatsächlich bereit ist, aufgrund neuer Erkenntnisse etwas zu verändern.

Ein Softwareunternehmen hatte Scrum bereits eingeführt.

Formal existierten:

Trotzdem entstand die gewünschte Agilität nicht.

Die Organisation bezeichnete ihre erste Einführung später selbst als weitgehend mechanisch.

Weiterhin bestanden Probleme wie:

Die Organisation startete deshalb einen „Scrum Reboot“.

Im Mittelpunkt standen nun:

Bei einem großen Produktvorhaben wechselte die Organisation dadurch von einem monolithischen Release-Modell zu laufenden Updates, die ungefähr monatlich veröffentlicht wurden. Die vorher üblichen Hardening-Phasen zur späteren Beseitigung technischer Schulden konnten beseitigt werden.

Auch hier lautet die Erkenntnis:

Nicht Scrum-Termine erzeugen Agilität. Inspection und Adaptation erzeugen Agilität.

Montag Wasserfall.

Dienstag Scrum.

Das löst keine strukturellen Probleme.

Neue Titel ändern keine Verantwortlichkeiten.

Wenn jede Priorisierung vom Management überschrieben wird, funktioniert das Modell nicht.

Ein Krisenprojekt braucht häufig echte Priorisierung.

Ein Sprint ist keine Erlaubnis, unfertige Arbeit schneller zu produzieren.

Dann entsteht zusätzliche Bürokratie.

Teams optimieren dann Story Points statt Wert.

Auch Scrum ersetzt kein aktives Stakeholder Management.

Scrum ist kein universelles Recovery-Modell.

Es hilft besonders, wenn ein Projekt Probleme hat mit:

Weniger hilfreich ist Scrum allein bei Problemen wie:

Dann muss zuerst das zugrunde liegende Managementproblem gelöst werden.

Auch die Forschung spricht gegen die vereinfachte Gleichung „agil = erfolgreicher“.

Eine Untersuchung von 477 Projekten fand keine statistisch signifikanten Unterschiede zwischen agilen, hybriden und traditionellen Ansätzen bei Budget, Termin und Scope beziehungsweise Qualität. Agile und hybride Projekte erreichten jedoch höhere Stakeholder-Zufriedenheit als traditionelle Projekte.

Die richtige Methode ist also nicht die modernste.

Sie ist diejenige, die zur Unsicherheit des Projekts passt.

Bevor ein Unternehmen ein gefährdetes Projekt auf Scrum umstellt, sollte es sieben Fragen beantworten.

Wenn niemand weiß, was erreicht werden soll, helfen auch Sprints nicht.

Ohne Priorisierung entsteht nur Wasserfall in Zwei-Wochen-Scheiben.

Nicht Präsentationen.

Nicht Statusberichte.

Sondern überprüfbare Increments.

Ohne Feedback fehlt ein zentraler Lernmechanismus.

Diese Person braucht ausreichende Entscheidungsfähigkeit über das Product Backlog.

Eine klare Definition of Done verhindert, dass unfertige Arbeit als Fortschritt verkauft wird.

Wenn nach jedem Sprint zwar gelernt wird, aber niemand Scope, Reihenfolge oder Vorgehen verändern darf, entsteht keine Adaptation.

Ziel:

Nicht möglichst viel liefern.

Sondern beweisen, dass der neue Delivery-Zyklus funktioniert.

Stakeholder sehen das Increment.

Feedback verändert den Backlog.

Engpässe und technische Risiken gezielt bearbeiten.

Prüfen:

Danach lässt sich besser beurteilen, ob der Turnaround funktioniert.

Nicht nur Velocity betrachten.

Besser:

Wie lange dauert Arbeit vom Start bis Done?

Wie zuverlässig erreicht das Team seine Sprint-Ziele?

Wie viel Arbeit muss erneut gemacht werden?

Steigt oder sinkt die Fehlerlast?

Wie häufig entsteht tatsächlich auslieferbarer Wert?

Wie lange bleiben Hindernisse ungelöst?

Verändert die gelieferte Funktion tatsächlich das gewünschte Ergebnis?

Die letzte Kennzahl ist entscheidend.

Ein Scrum-Team kann jede Woche liefern.

Wenn niemand die Ergebnisse braucht, arbeitet es lediglich effizient am falschen Produkt.

Die größte Erkenntnis des dokumentierten Falls betrifft nicht Scrum.

Sie betrifft Führung.

Das Management akzeptierte irgendwann, dass der bisherige Weg nicht funktionierte.

Dann veränderte es nicht nur die Arbeitsweise des Teams.

Es veränderte auch:

Genau deshalb konnte Scrum seine Wirkung entfalten.

Viele agile Transformationen scheitern an der umgekehrten Logik.

Das Team soll agil werden.

Die Organisation bleibt unverändert.

Dann gibt es:

aber weiterhin Jahres-Scope.

aber keine Entscheidungsrechte.

aber keine Möglichkeit zur Veränderung.

aber bereits festgelegte Lösungen.

Das ist kein empirisches Arbeiten.

Es ist klassische Projektsteuerung mit agilem Kalender.

Wie Scrum ein Projekt gerettet hat – eine echte Case Study lässt sich nicht mit der einfachen Formel beantworten:

Wasserfall schlecht. Scrum gut.

Die Realität war deutlich komplexer.

Das Projekt hatte bereits Jahre Entwicklung, hohe Kosten und erhebliche Probleme hinter sich.

Der Turnaround gelang, weil sich das gesamte Delivery-System veränderte.

Scrum sorgte dabei für einen entscheidenden Mechanismus:

kürzere Abstände zwischen Arbeit, Ergebnis, Feedback und Entscheidung.

Zweiwöchige Sprints machten Fortschritt sichtbarer.

Anwender wurden früher eingebunden.

Funktionierende Software wurde regelmäßig demonstriert und getestet.

Anforderungen konnten stärker priorisiert werden.

Probleme wurden früher sichtbar.

Und die Organisation übernahm wieder mehr direkte Verantwortung für ihre eigene Lösung.

Genau darin liegt der Wert von Scrum bei gefährdeten Projekten.

Scrum garantiert keinen Projekterfolg.

Es schafft Bedingungen, unter denen die Organisation schneller erkennen kann, ob sie noch auf dem richtigen Weg ist.

Das funktioniert jedoch nur, wenn Management und Team die Konsequenz daraus akzeptieren:

Transparenz muss zu Entscheidungen führen.

Inspection muss zu Erkenntnissen führen.

Und Erkenntnisse müssen zu Anpassungen führen.

Sonst bleiben nur Meetings und Rollenbezeichnungen.

PURE Consultant unterstützt Unternehmen dabei, gefährdete agile Projekte zu stabilisieren, Scrum-Strukturen auf ihre tatsächliche Wirksamkeit zu prüfen und Delivery, Rollen, Priorisierung und Governance so auszurichten, dass aus agilen Ritualen wieder messbare Ergebnisse entstehen.