Seit geraumer Zeit ist agiles Projektmanagement auch ausserhalb der Software-Branche hoffähig geworden. Nicht zuletzt, weil auch beispielsweise das PMI diesen „Gegenentwurf“ zum hierarchischen Wasserfall-Modell im wahrsten Sinne des Wortes assimiliert hat. Leider wird mit dem Begriff „agile“ – wie sollte es anders sein – auch viel Schindluder betrieben. Uns so bekommt so mancher Prozess das Label „agile“, nur weil einzelne Begriffe aus Scrum & Co. entlehnt sind.

Vergessen wird dabei gerne der eigentlich „revolutionäre“ Grundgedanke dahinter: „Agile“ zu sein bedeutet, dass nicht „die da oben“ sagen wo es lang geht, sondern „diejenigen, die die tatsächliche Arbeit leisten“. Die Idee dabei ist, dass die ausführende Basis besser weiß was wie und in welcher Zeit zu leisten ist, als das praxisferne Management in den Führungsetagen.

Was auf den ersten Blick nach „linker Utopie“ klingt, ist in Wirklichkeit auch ein gutes Stück kapitalistischer „Darwinismus“, denn das Prinzip ist, mit Hilfe eines iterativen Prozesses ein Produkt so schnell wie möglich „ans Laufen“ zu bringen, wobei jede Iteration Gelegenheit gibt den Prozess bzw. Entwicklungsstand zu überprüfen und gegebenenfalls korrigierend einzugreifen.

Zu guter Letzt geht es beim agilen Projektmanagement auch noch um Flexibilität und Anpassungsfähigkeit. Anstatt einem starren Plan zu folgen, gilt es flexibel auf wechselnde Anforderungen und Gegebenheiten zu reagieren, quasi nach dem Motto „Was nicht passt, wird passend gemacht“. Dahinter steckt die Erfahrung aus unzähligen gescheiterten Projekten. Denn, wer hätte es gedacht: Je komplexer ein Projekt ist und je mehr Stakeholder mitreden dürfen, desto schneller ist im Projektverlauf der ursprüngliche Plan Makulatur. Zu sehen beispielsweise an zig staatlichen Projekten, von der E10-Einführung bis zur Elektronischen Gesundheitskarte. Statt also bis zum Sankt-Nimmerleins-Tag an einem eh nicht mehr gültigen Plan festzuhalten wird im agilen Projektmanagement auf diesen quasi gleich verzichtet. Statt dessen wird eine funktionierende Minimallösung angestrebt, die dann schrittweise erweitert wird.

Um „Agile“ zu verstehen, hilft auch ein Blick ins Agile Software Development Manifest. Dessen Kernthesen lauten:

• Individuen und Interaktionen sind wichtiger als Prozesse und Tools
• Funktionierende Software ist wichtiger als umfassende Dokumentation
• Zusammenarbeit mit Kunden ist wichtiger als Vertragsverhandlungen
• Reaktion auf Änderungen ist wichtiger als einem Plan zu folgen