Ein Deep Dive auf Basis von sieben Fachquellen

Letzte Woche habe ich auf dieser Website einen Beitrag zum Vergleich zwischen Scrum und der Wasserfallmethode veröffentlicht. Ich habe ihn anschließend auf LinkedIn geteilt – und die Reaktion hat mich ehrlich gesagt überrascht. Nicht wegen der Reichweite, sondern wegen der Tiefe der Diskussion, die er ausgelöst hat.

Besonders ein Kommentar hat mich zum Nachdenken gebracht:

„Mich würde mal interessieren, ob in der Statistik auch die Gründe des Scheiterns analysiert wurden (Root Cause).”

Dieser Kommentar hat mich neugierig gemacht und war der Anstoß für diesen Beitrag. Ich habe sieben Fachquellen – von akademischen Studien bis zu praxisnahen Analysen (Links am Ende des Beitrags) – systematisch untersucht und die gemeinsamen Nenner herausgearbeitet. Dabei ging es mir darum, Antworten auf die folgenden Fragen zu finden: Woran scheitern Projekte wirklich? Und: Welche Antworten liefert die Agilität auf diese Ursachen?

Dabei war mir von Anfang an wichtig, keine unfaire Gegenüberstellung zu konstruieren. Im Beitrag von letzter Woche habe ich bereits deutlich gemacht, dass Scrum nicht für jedes Projekt geeignet ist. Das gilt weiterhin. Mich interessiert hier etwas anderes: Greift die Agilität strukturell an Stellen an, die zum Scheitern führen – und wenn ja, wie?

Die Ausgangslage: Projekte scheitern erschreckend oft – in allen Lagern

Die Standish Group berichtet seit Jahren, dass mehr als 70 % aller Projekte entweder scheitern oder erhebliche Schwierigkeiten haben. Andere Studien kommen zu ähnlichen Ergebnissen. Auffällig ist, dass sich diese Zahlen nicht auf eine bestimmte Methode beziehen. Sie beziehen sich auf Projekte generell.

Der PMI-Forscher Michał Rączka hat in einem vielzitierten Beitrag darauf hingewiesen, dass weder ein Methoden- noch ein Personalwechsel das Problem löst, da beide Ansätze zu kurz greifen. Die Ursachen liegen tiefer: im Organisationssystem, in der Kultur und in den Strukturen.

Adrian Dooley von APMG International hat festgestellt, dass sich die Liste der Scheiternsgründe seit einer Studie aus dem Jahr 1972 kaum verändert hat, obwohl seither massiv in die Ausbildung zum Projektmanagement investiert wurde. Sein Fazit: Viele der genannten Faktoren sind Symptome, keine Ursachen.

Aus der Analyse der sieben Quellen haben sich zehn wiederkehrende Aspekte herauskristallisiert, die quer durch Branchen, Projekttypen und Methoden immer wieder auftauchen. Für jeden dieser Aspekte stelle ich die Frage: Was tut Agilität aktiv dagegen?

Zehn Gründe, warum Projekte scheitern – und die agile Antwort

Vorab eine wichtige Klarstellung: Die folgenden Aspekte sind keine Kritik an der Wasserfallmethode. Klassisches Projektmanagement hat klare Stärken – insbesondere bei Projekten mit stabilen Anforderungen, klarem Scope und hoher Planbarkeit. Es geht nicht darum, was beim Wasserfall fehlt. Es geht darum, welche strukturellen Antworten die Agilität auf bekannte Problemquellen entwickelt hat.

1. Unklare Ziele und Anforderungen

Das Problem: Projekte starten mit vagen oder missverstandenen Zielen. Ohne klare Definition fehlt dem Team die Richtung und der Erfolg lässt sich kaum messen.

Agiles Gegenmittel: Im agilen Arbeiten sind Ziele kein einmaliges Dokument am Projektstart, sondern ein lebendiges Artefakt. Das Product Backlog wird kontinuierlich gepflegt und priorisiert. Der Product Owner stellt sicher, dass die Ziele greifbar, messbar und jederzeit aktuell sind. Sprint Goals geben kurzfristige Orientierung – was in zwei Wochen erreicht sein soll, lässt sich präziser formulieren als das, was in zwei Jahren erreicht sein soll.

2. Kommunikationsprobleme

Das Problem besteht darin, dass Informationen nicht fließen, falsch weitergegeben werden oder zu spät ankommen. Silodenken, Hierarchien und fehlende Kommunikationskanäle verstärken dieses Problem.

Agiles Gegenmittel: Agilität baut Kommunikation strukturell ein. Daily Stand-ups, Sprint Reviews und Retrospektiven sind keine optionalen Meetings, sondern feste Taktgeber des Informationsflusses. Das Prinzip der Transparenz ist im agilen Manifest verankert. Colocation oder enge digitale Zusammenarbeit werden bewusst angestrebt.

3. Ressourcenmangel

Das Problem: Fehlendes Budget, überlastetes Personal oder falsch geplante Kapazitäten bremsen Projekte aus oder bringen sie zum Stillstand.

Agiles Gegenmittel: Idealerweise arbeiten agile Teams mit fester, dedizierter Besetzung – das Prinzip der 100-%-Allokation verhindert, dass Teammitglieder zwischen zu vielen Projekten aufgeteilt werden. Das Velocity-Konzept macht Kapazitäten sichtbar und planbar. Überlastung wird durch den Scrum Master aktiv adressiert.

4. Schlechtes Risikomanagement

Das Problem: Risiken werden zu spät erkannt, nicht bewertet oder schlicht ignoriert – und entwickeln sich zu ernsthaften Problemen.

Agiles Gegenmittel: Kurze Iterationen sind per se eine Form des Risikomanagements, da nicht monatelang in eine Richtung investiert wird, bevor Feedback eingeholt wird. Retrospektiven machen Risiken sichtbar, bevor sie eskalieren. Das Prinzip „Fail fast” erlaubt es, früh zu lernen und gegenzusteuern.

5. Mangelndes Management-Support

Das Problem: Ohne klares Commitment der Führungsebene fehlen Prioritäten, Ressourcen und Rückendeckung für das Projektteam.

Agiles Gegenmittel: Im agilen Rahmen übernimmt der Product Owner eine klar definierte Rolle als Brücke zwischen Business und Team. Die Einbindung der Stakeholder ist nicht optional, sondern systemimmanent. Sprint Reviews sind explizit als Feedback-Schleife mit dem Management gedacht – nicht als Berichtstermin.

6. Unrealistische Planung

Das Problem: Zu ambitionierte Zeitpläne und Budgets, die auf Wunschdenken statt auf Erfahrungswerten basieren, führen zwangsläufig zu Abweichungen.

Agiles Gegenmittel: Agile Planung ist empirisch, denn sie basiert auf gemessener Velocity statt auf Schätzungen ins Blaue. Mit Planning Poker und Story Points werden ehrliche, dezentrale Einschätzungen gefördert. Der Rolling-Wave-Ansatz plant nur so weit in die Zukunft, wie tatsächlich Sicherheit besteht.

7. Scope Creep

Das Problem: Unkontrollierte Erweiterung des Projektumfangs während der Laufzeit kostet Zeit, Geld und Fokus.

Agiles Gegenmittel: Das Product Backlog ist das zentrale Steuerungsinstrument gegen Scope Creep. Neue Anforderungen werden aufgenommen und priorisiert. Damit verdrängen sie Bestehendes, sofern die Kapazität nicht ausgeweitet wird. Der Sprint ist ein geschützter Raum: Was einmal im Sprint Planning vereinbart wurde, bleibt stabil. Änderungen kommen in den nächsten Sprint.

8. Teamprobleme und Führungsschwäche

Das Problem: Unklare Rollen, fehlende Entscheidungsautorität und Teamdysfunktionen lähmen die Ausführung.

Agiles Gegenmittel: Agile Teams sind selbstorganisiert – das ist kein Nice-to-have, sondern ein Kernprinzip. Der Scrum Master arbeitet aktiv an Teamdysfunktionen. Eine klare Rollenverteilung (Product Owner, Scrum Master, Entwicklungsteam) reduziert Unklarheiten über Verantwortlichkeiten. Retrospektiven schaffen einen sicheren Rahmen, um Probleme offen anzusprechen.

9. Falsche Methodenwahl

Das Problem: Die Wahl zwischen agil und klassisch wird zu selten bewusst getroffen – und zu oft einfach wiederholt, was man kennt.

Agiles Gegenmittel: Agilität beantwortet diese Frage nicht von selbst, aber sie macht den Kontext sichtbar. Agile Frameworks sind für Projekte mit hoher Unsicherheit, sich verändernden Anforderungen und Bedarf nach schnellen Lieferzyklen ausgelegt. Wer das beachtet, trifft bessere Methodenentscheidungen. Frameworks wie SAFe oder das Cynefin-Modell helfen dabei, Kontext und Methode zusammenzubringen.

10. Fehlende Stakeholder-Einbindung

Das Problem: Kunden, Endnutzer und Sponsoren werden zu selten und zu spät eingebunden, wodurch Lösungen entstehen, die an der Realität vorbeigehen.

Agiles Gegenmittel: Im agilen Arbeiten ist die Einbindung der Stakeholder keine Kür, sondern Pflicht. Sprint Reviews sind explizite Feedback-Schleifen mit echten Nutzern und Auftraggebern. Das Konzept des Product Owners stellt sicher, dass die Kundenperspektive im Team dauerhaft repräsentiert ist. Agilität liefert schneller sichtbare Ergebnisse und gibt Stakeholdern damit früher die Möglichkeit zu reagieren.

Fazit: Agilität ist keine Garantie, aber eine strukturelle Antwort

Wer hofft, dass dieser Beitrag mit „Agil löst alles” endet, wird enttäuscht. Wie mein Beitrag von letzter Woche gezeigt hat, ist Scrum nicht für jedes Projekt das richtige Werkzeug. Und auch agile Projekte scheitern – aus den oben aufgelisteten Gründen – wenn die Prinzipien nicht ernsthaft gelebt werden.

Die Analyse zeigt jedoch: Für jeden der zehn identifizierten Scheiternsgründe hat Agilität eine strukturelle Antwort entwickelt. Das ist zwar keine Garantie, aber eine bewusste Auseinandersetzung mit den Problemen, die Projekte regelmäßig in Schwierigkeiten bringen.

Rączka und Dooley haben recht: Die tiefsten Ursachen liegen im System, in Kultur, Hierarchie und Anreizsystemen. Keine Methode der Welt kann ein kaputtes Organisationssystem reparieren. Agilität gibt Teams und Führungskräften jedoch Werkzeuge an die Hand, mit denen sie an genau diesen systemischen Problemen arbeiten können – wenn sie es wollen.

Failing to plan is planning to fail – but planning the wrong things is just as dangerous.

Der Kommentar auf LinkedIn hat eine wichtige Frage aufgeworfen. Die Antwort ist unbequem: Projekte scheitern nicht, weil die falsche Methode gewählt wurde. Sie scheitern, weil bekannte Probleme immer wieder ignoriert werden – egal, welche Methode auf dem Titelblatt steht.

Agilität ist der Versuch, diese Probleme nicht länger zu ignorieren. Das ist ihr eigentlicher Wert.

Verwendete Quellen

AGILE TALK: Es wird Zeit, über Projektmanagement zu sprechen!

Agile Talk Hintergrundbild

Sind Scrum Master und Agile Coaches heute noch relevant im Projektalltag? 

Agiles Arbeiten macht Projekte effektiver, das belegen Statistiken. Trotzdem hat Agilität oft den Ruf, zu „weich“ zu sein.

Und genau darüber wollen wir offen, ehrlich und ohne fertige Antworten sprechen.

Melde dich an, und wir schicken dir den Zoom-Link: AGILE TALK