Agiles Projektmanagement wird manchmal als "traditionelles Projektmanagement, nur schneller" dargestellt. Die tatsächlichen Unterschiede reichen tiefer als Tempo und berühren grundlegende Annahmen über Planung, Anforderungen und die Rolle der Projektmanagerin oder des Projektmanagers selbst.
Unterschiedliche Annahmen über Planung
Traditionelles Projektmanagement nimmt an, dass detaillierte Vorabplanung sowohl möglich als auch wertvoll ist, und Abweichung ein zu korrigierendes Problem darstellt. Agiles Projektmanagement nimmt für komplexe, unsichere Arbeit an, dass detaillierte Langfristpläne generell auf eine Weise falsch sind, die erst sichtbar wird, sobald die Arbeit läuft, und dass Planung kontinuierlich statt umfassend im Voraus geschehen sollte.
Unterschiedliche Annahmen über Anforderungen
Traditionelle Ansätze wollen Anforderungen vor Arbeitsbeginn festlegen, mit Änderungen gemanagt durch formale Change Control, die Änderung als Ausnahme behandelt. Agile Ansätze nehmen an, dass sich Anforderungen entwickeln werden und sollten, während Stakeholder funktionierende Inkremente sehen, und behandeln Änderung als erwartete, wertvolle Information statt als Ausnahme.
Eine genuin andere Rolle für die Projektleitung
Traditionelle Projektmanagerinnen und Projektmanager halten typischerweise direkte Autorität über Aufgabenzuweisung und Umfang. In agilen Ansätzen wird diese Autorität bewusst verteilt: Die Product-Owner-Person kontrolliert Priorität, das Team kontrolliert, wie Arbeit erledigt wird, und oft gibt es überhaupt keine traditionelle Projektmanagement-Rolle.
Organisationen versuchen manchmal, die traditionelle Autorität einer Projektleitung zu bewahren, während sie agile Zeremonien nur dem Namen nach übernehmen, was einen Hybrid erzeugt, der keinem der beiden Modelle gut dient, und ein häufiger Grund, warum die Einführung nicht die eigentlichen Vorteile von Agile liefert.
Was das für die Wahl eines Ansatzes bedeutet
Agiles Projektmanagement passt zu Arbeit mit hoher Anforderungsunsicherheit und hohem Wert im Einbeziehen von Feedback. Es passt schlechter zu gut verstandenen, stabilen Anforderungen mit geringer Toleranz für zeitliche Abweichung. Die Wahl ist nicht "agil ist einfach besser": Es geht darum, den Ansatz an die tatsächliche Natur der beteiligten Unsicherheit anzupassen.