Hilft "kaputte" Agilität?

Inhaltsverzeichnis

Agilität in der Softwareentwicklung wird oft unzureichend umgesetzt und gelebt. Hilft sie trotzdem?

Softwareentwicklung ist kompliziert und komplex. Deswegen führen viele Projekte zu Fehlschlägen. Es ist schon schwer genug festzustellen, ob ein Projekt erfolgreich war oder nicht. Die Ziele sind gegebenenfalls nicht klar definiert, aus politischen Gründen können Fehlschläge zu Erfolgen umdefiniert werden und schließlich gibt es verschiedene Parameter, nach denen Erfolg bewertet werden kann. Subjektiv scheint der Anteil der Projekte, die eines oder mehrere der Projektziele nicht erreichen, durchaus signifikant zu sein.

Chaos-Report

Eine schon lange etablierte Untersuchung über den Erfolg von Projekten ist der Chaos-Report der Standish Group. Er stellt seit 1994 Erkenntnisse über IT-Projekte zusammen. Er verfügt über eine Datenbasis von über 20 Jahren und über 50.000 Projekten. Die Analysten bewerten die Projekte, sodass die Bewertung als Erfolg oder Misserfolg nicht auf den subjektiven Eindrücken der am Projekt Beteiligten basiert. Der Report aus dem Jahr 2015 ist kostenlos erhältlich. Er zeigt, dass schon seit mehreren Jahren circa 20 Prozent der Projekte Fehlschläge sind. Etwa 40 Prozent haben nicht alle Ziele erreicht und weitere 40 Prozent sind erfolgreich. In Kategorien wie Einhalten des Zeitplans, der Kosten oder der Termine erreichen zwischen 40 und 60 Prozent die Ziele nicht. Laut dem Report reduziert Agilität diese Zahlen erheblich, teilweise auf die Hälfte.

Diese Zahlen kann man sicherlich kritisieren: Erfolg ist kaum objektivierbar. Lange hat der Chaos-Report als Erfolgskriterien Budget, Scope und Zeit definiert. Agile Projekte können aber vorab keinen vollständigen Scope definieren, sondern planen nur das nächste Inkrement. Also können echte agile Projekte einen Scope nicht erfolgreich einhalten, weil er am Anfang des Projekts unbekannt ist. Das wirft die Frage auf, wie sich die Einhaltung des Scopes dann überhaupt bewerten lässt, wenn die Projekte tatsächlich agil sind.

Das Bessere ist der Feind des Guten

Wegen dieser Widersprüche kann es gut sein, dass die "agilen" Projekte aus dem Chaos-Report zwar einige Praktiken umsetzen, aber nicht alle. Aber auch aus anderen Gründen sind Zweifel daran angebracht, ob die "agilen" Projekte wirklich agil sind. So gibt es viele Missverständnisse in diesem Bereich. Viele Projekte nennen sich agil, obwohl sie in Wirklichkeit teilweise fundamentale Konzepte nicht umsetzen. Die agilen Projekte aus dem Chaos-Report sind also wahrscheinlich eher Projekte, die eine "kaputte" Version von Agilität umsetzen. Positiv ausgedrückt: Sie haben angefangen, Agilität zu adaptieren, aber haben noch lange nicht alles Wichtige umgesetzt. Da Agilität ein kontinuierlicher Verbesserungsprozess sein sollte, ist die Adaption von Agilität eigentlich nie vollständig abgeschlossen, aber auch dieser wichtige Aspekt wird oft nicht befolgt.

Wenn es tatsächlich so sein sollte, dass die "kaputte" Umsetzung agiler Mechanismen bereits erhebliche Verbesserungen bei den Projektergebnissen ergibt, dann ist dieser Weg wirtschaftlich auf jeden Fall sinnvoll. Man könnte sogar die Frage stellen, welchen weiteren wirtschaftlichen Vorteil die vollständige und korrekte Umsetzung von Agilität ergibt. Für solche wirtschaftlichen Vorteile gibt es aber durchaus gute Indizien. Aber die Umsetzung vollständiger Agilität – und vor allem der agilen Werte – könnte aufwendig sein, ohne dass es dafür einen entsprechenden wirtschaftlichen Vorteil gibt. Dann könnten die teilweise sehr schlecht umgesetzten agilen Prozessen bezüglich der Kosten-Nutzen-Abwägung wirtschaftlich nahezu optimal sein, weil sie relativ leicht zu erreichen sind und bereits erhebliche Vorteile bieten.

Um es mit Voltaire zu sagen: Das Bessere – also "echte" Agilität – ist eben der Feind des Guten – also "kaputte" Agilität. Man wird also eine weitere Verbesserung nur erreichen, wenn man sich nicht mit etwas zufrieden gibt, das bereits ausreichend gut ist. In der Folge könnten kaputte agile Prozesse ein Dauerzustand werden. Das mag zwar wirtschaftlich sinnvoll sein. Aber es sind nur bedingt positive Aussichten, weil "kaputte" Prozesse demotivieren und oft gerade Werte und Kultur leiden – und darunter leiden dann oft auch Menschen. Hoffen wir also, dass es nicht so ist.

tl;dr

Wenn "kaputte" Agilität schon deutliche Vorteile bringt, erklärt das, warum die Prozesse oft kaputt sind und warum sie nicht noch weiter verbessert werden.

Vielen Dank an meine Kolleginnen und Kollegen Anja Kammer, Martin Kühl und Hanna Prinz für die Kommentare zu einer früheren Version des Artikels. ()