Aufbruch: Im Jahr 2001 veröffentlichten US-amerikanische Softwareentwickler mit dem Agilen Manifest das Gründungsdokument der agilen Bewegung. Mit den zwölf Prinzipien, die sie darin formulierten, wollten sie die Softwareentwicklung revolutionieren: Schneller, schlanker und nutzerorientierter sollte sie werden. Heute, 20 Jahre später, ist nicht völlig klar, was davon geblieben ist.
Einerseits hat sich das Label „agil“ ohne Zweifel auf breiter Front durchgesetzt. Praktisch niemand möchte heute noch über sich hören, nicht agil zu sein. Viele Unternehmen spielen dabei aber lediglich agiles Theater. Sie tun einfach nur so, als ob, und zwingen ihrer schönen neuen agilen Welt auch weiterhin die alten Prozesse auf. Ein Klassiker dabei: Sie setzen nach wie vor einen übergreifenden Projektverantwortlichen mit Zugriff auf die Einzelressourcen ein und konterkarieren damit den agilen Grundsatz, dass die Entwicklungsteams Probleme eigenverantwortlich intern aufarbeiten sollen. Eine wirklich agile Software-Entwicklung, wie im Manifest gefordert, findet sich nur selten.
Die Gründe dafür sind vielfältig. So mangelt es vielen Unternehmen schlicht und einfach am Mut, die Prinzipien des Agilen Manifests konsequent umzusetzen. Man verlässt sich im Zweifel lieber auf Bewährtes. Beauftragen Unternehmen einen Dienstleister mit Softwareentwicklung, ist ihnen ein fester preislicher und zeitlicher Rahmen oft wichtiger als schnellere, nutzerorientierte Ergebnisse. Damit lassen sie dem Dienstleister gar keine andere Wahl als auf klassische Vorgehensweisen zurückzugreifen.
Hinzu kommt, dass sich Agilität nicht für jeden beliebigen Fall eignet. Je unklarer die Anforderungen an eine Software sind und je unklarer auch der Weg dorthin ist, desto mehr können die agilen Methoden ihre spezifischen Stärken ausspielen. Je klarer Anforderungen und Weg sind, desto vorteilhafter sind klassische Methoden.
Außerdem ist Agilität auch nicht das Nonplusultra für jeden Mitarbeiter. Die vom Agilen Manifest geforderten selbstorganisierten Teams verlangen eine Zusammenarbeit der Mitglieder auf Augenhöhe. Das scheitert aber oft an den vorherigen hierarchischen Strukturen, die mit in die agilen Teams gebracht werden – oder auch schlicht und einfach am dominanten Wesen einzelner Personen. Zudem sehnen sich viele Teammitglieder nach Führung und sind deshalb in klassischen Projekten mit hierarchischen Strukturen und weniger Selbstverantwortung einfach besser aufgehoben.
Das alles bedeutet aber nicht, dass die agile Revolution auf ganzer Linie gescheitert ist. Im Gegenteil: Agile Methoden haben ihre Berechtigung und geeignete Projekte sollten auch unbedingt agil umgesetzt werden, denn in diesen Fällen können sie alle ihre Versprechen erfüllen. Aber die Rahmenbedingungen müssen stimmen und wenn die Entscheidung für Agilität fällt, müssen ihre Methoden auch konsequent und mit Sinn und Verstand angewendet werden. Sonst bleibt alles nur Etikettenschwindel. jf
