“Wir machen jetzt alle Projekte nur noch agil. Alle anderen Ansätze sind schließlich veraltet und ineffizient.” – diese Parole gab es so oder so ähnlich unzählige Male in großen Unternehmen. Sie führte in letzter Konsequenz häufig zu Chaos und zu eigenartigen Auswüchsen, die sich so wohl kaum jemand zuvor hätte vorstellen können.
Eigentlich hatten die 17 Softwareentwickler, die im Frühjahr 2001 ihr gemeinsam erarbeitetes “Agile Manifesto” veröffentlichten, nichts Böses im Sinn. Sie legten damit den Grundstein für agiles Projektmanagement und definierten die wichtigsten Leitsätze ihrer Vorgehensweise. Eigentlich eine gute Idee, doch sie haben nicht bedacht, welche Folgen das alles haben würde.
Plötzlich wollte jede/r CIO alle Projekte agil umsetzen – schließlich macht man das ja jetzt so. Alle anderen CIOs haben das in “Dinner-Runden” und auf Events auch so bestätigt und da muss man natürlich mitziehen. Man kann sich ja nicht die Blöße geben, nicht mit der Zeit zu gehen. Wer jedoch plötzlich jedes Projekt pauschal und ohne Prüfung der Sinnhaftigkeit agil aufsetzt, wird schnell merken, dass diese Projektmethodik nicht immer zielführend ist.
Viel zu oft wurde die Methodik in den vergangenen Jahren regelrecht vergewaltigt. Es entstanden “agile” Projekte mit klassischen Projekt- und Budgetplänen, mit vorab klar definierten Abläufen und allen weiteren Elementen von Wasserfallprojekten. Hauptsache, das Ganze hieß noch irgendwie agil und man hatte tägliche “Stand-up”-Meetings (Tägliche Meetings, bei denen jeder kurz sagt, womit er gerade beschäftigt ist und welche Probleme er evtl. gerade hat. So soll sichergestellt werden, dass das gesamte Know-how der Gruppe genutzt und Probleme schnell gelöst werden.) – die sind ja schließlich eine prima Möglichkeit zur Kontrolle, viel besser als bei der klassischen Methodik mit ihren wöchentlichen oder zweiwöchentlichen Jour Fixes. Doch das alles führt dazu, dass die Vorteile eines agilen Ansatzes vollkommen verloren gehen.
Die Entscheidung, ob agil oder klassisch wäre dabei aber eigentlich ganz einfach: Je genauer die Anforderungen, der Lösungsansatz, Zeitplan und Budget schon zu Projektbeginn definiert sind, desto eher sollte das Projekt klassisch aufgesetzt werden – mit allem, was dazu gehört. Je unbekannter diese Faktoren zu Projektbeginn sind, desto mehr macht ein agiler Ansatz Sinn.
Würde man diese Formel konsequent anwenden, könnte man bei unzähligen Projekten viel Ärger, Tränen und Chaos einsparen. Nur weil etwas gerade gehyped wird, ist es nicht zwingend auch für jede Situation anwendbar.