Die Frage agiles Projektmanagement vs klassisches Projektmanagement erscheint mir häufig eine religiöse Frage zu sein – LEIDER! Entweder gehört man zur Glaubensrichtung der Agilisten oder Klassizisten. In diesem FRITZ Tipp stelle ich euch einen Ausweg aus dem Dilemma vieler Projektmanager dar.
Was ist klassisches Projektmanagement?
Die Einmaligkeit drückt sich in einer klaren Zielvorgabe aus. Des Weiteren ist ein Projekt zeitlich (klarer Start, klares Ende), finanziell (definiertes Budget) und personell (definierte Personalressourcen) klar ein- und abgegrenzt. Klassisches Projektmanagement ist nun eine Zusammenstellung von Regelungen, die innerhalb einer Organisation für die Planung und Durchführung von Projekten gelten. Mehr dazu im FRITZ Tipp Was ist ein Projekt?
Was ist agiles Projektmanagement?
Beim klassischen Projektmanagement werden zunächst Anforderungen erhoben und möglichst früh fixiert. Darauf basierend werden Kosten und Termine geschätzt. Beim agilen Projektmanagement werden zuerst Kosten und Termine fixiert. Die umgesetzten Anforderungen sind dann eine Schätzung des Teams im Sprint Planning. Mehr dazu im FRITZ Tipp Das Magische Dreieck des Projektmanagements.
Agiles Projektmanagement ODER klassisches Projektmanagement?
Die kurze Antwort : 80-90% der Projekte lassen sich mit klassischem Projektmanagement effizienter planen und umsetzen. In 10-20% der Fälle ändern sich min. 30% der definierten Anforderungen pro Monat und agiles Projektmanagement ist das bessere Vorgehensmodell.
Beide Projektmanagement-Religionen versuchen Arbeit in handhabbare Arbeitsstücke herunterzubrechen. Der Unterschied besteht lediglich darin, dass im klassischen Projektmanagement das gesamte Projekt bereits vorab geplant wird. Agiles Projektmanagement gibt sich damit zufrieden nur die Arbeit für den nächsten Sprint konkret zu planen. Die nachfolgende Abbildung zeigt weitere Übereinstimmungen dieser Form:
Wenn man nun in beiden Projektmanagement-Ansätzen durch ist, muss man sich meiner Meinung nach gar nicht mehr für die eine oder andere Religion entscheiden. Hierzu stelle ich euch die Tetralemma-Lösung vor.
Agiles Projektmanagement UND klassisches Projektmanagement?
Das Tetralemma ist für mich eine Entscheidungshilfe für die Frage agiles Projektmanagement vs klassisches Projektmanagement. Häufig sind wir in unseren Entscheidungen sehr begrenzt, entweder entscheiden wir uns für Schwarz oder Weiß. Das Tetralemma zeigt weitere Möglichkeiten auf:
- Das Eine, also Schwarz.
- Das Andere, also Weiß.
- Beides, also schwarz und Weiß.
- Keines, also weder schwarz noch weiß.
- Ganz was anderes, also vielleicht gar keine Farbe.
Das heißt, in einem Projekt kann ein Projektstrukturplan mit Arbeitspaketen sinnvoll sein. Die Aufwandsschätzung geschieht jedoch per Magic Estimation. Zu Beginn eines Projektes gibt es alle zwei oder vier Wochen ein Statusmeeting. In der heißen Projektphase steigen wir auf ein Daily SCRUM Meeting mit vorgegebenen Fragen um. Wir führen ein klassisches Projekt durch, schließen jedoch mit einer Retro anstelle eines Projektabschlussberichts.
Mehr dazu im FRITZ Tipp Tetralemma als Tool zur Entscheidungsfindung.
Fazit
Wenn man ein Projekt zu führen hat, muss man sich nicht zwangsläufig für klassisches Projektmanagement oder agiles Projektmanagement entscheiden. Je höher der Reifegrad des Projektmanagers, desto eher kann man sich die Projektmanagement Methode raus picken die für die Situation gerade passend und nützlich ist. Voraussetzung ist aber auch, dass man in beiden Welten wirklich durch ist. Das ist kein Vorgehensmodell für Anfänger!
Dr. Patrick Fritz
Die ganze Diskussion ist eigentlich Makulatur.
Wenn man sich die Arbeitsweise in den Unternehmen ansieht, und davon habe ich viele gesehen, stellt man fest, dass es so gut wie niemanden gibt, der die reine (agile) Lehre praktiziert.
Kann auch gar nicht. Denn die Praxis bietet endlos viele Stolpersteine, die erfordern, die Vorgehensmodelle auf eine Weise zurecht zu schneidern, die jene operativen Eigenheiten abbildet.
Im Automotive und Luftfahrt sind es beispielsweise Regularien, die Anforderungen an Dokumentation und Reporting stellen, dazu kommt saftey criticality, die weitere Bremsen hinein pflanzt. Kunden, die nicht mitspielen, usw.
Im Endeffekt ist fast jede Implementation ein Kompromiss und somit auch eine Form von best practice.
Hallo Oliver,
vielen Dank für deinen Kommentar! Ich finde du ergänzt die Diskussion um einen weiteren wesentlichen Punkt. Es geht nicht nur darum wie agil man sein will oder kann, sonder auch DARF.
Beste Grüße
Patrick
Hallo Patrick, hallo Oliver,
… naja … Agilität erfordert eben einige Ver-Änderungen und wenn diese nicht möglich sind – warum auch immer – ist Agilität nicht möglich. Man kann Agilität „anpassen“ – nur ist es dann keine Agilität mehr … Agilität lebt ja gerade von diesen notwendigen Ver-Änderungen!
Das erinnert mich an Diskussionen mit meiner Mutter in meiner Jugend, als sie sich beschwerte, dass die „Schwarzwälder Kirschtorte“ nicht schmeckt und das Rezept sch…lecht sei. Ich entgegnete dann immer: „Ohne Schokolade, ohne Kirschen und ohne Kirschgeist ist es KEINE Schwarzwälder Kirschtorte“ … Wenn ich etwas verändere, ist es nicht mehr das Original und ich darf es dann auch bitte nicht so nennen.
BTW: Tetralemma kenne ich mit vier Positionen https://de.wikipedia.org/wiki/Tetralemma
Beste Grüße
Torsten
Hallo Torsten,
vielen Dank für deinen Kommentar! Vielleicht kann ich noch einen Gedanken dazu geben:
Meines Wissens, wird nur in den Anfängerkursen gepredigt, dass man sich zu 100% an die Richtlinien halten muss. Sonst ist es eben nicht agil. Das macht bei einer Einführung auch absolut Sinn, damit sich die Leute orientieren können und an einem Standard festhalten können. Vergleichbar mit einem Lehrling. Der Geselle weicht an der einen oder anderen Stelle ab. Der Meister entwickelt den Standard weiter.
Ganz konkret gesprochen. Warum sollte ich zur Aufwandsschätzung in „klassischen“ Projekten keinen angepassten Planing-Poker verwenden? Warum sollte ich in einem „agilen“ Projekt keine Risikoanalyse vornehmen, nur weil sie nicht im Standard enthalten ist. Ich muss halt auf einer Meta-Ebene wissen was ich mache. Ob es dann noch agil ist oder nicht, ist eigentlich nicht wichtig.
Beim Tetralemma beziehe ich mich auf Insa Sparrer und Matthias Varga von Kibéd: https://syst.info/was-ist-syst/grundformen-der-syst/tla
Beste Grüße
Patrick