Die Frage agiles vs klassisches Projektmanagement erscheint mir häufig eine beinahe religiöse Frage zu sein – LEIDER! Zuerst muss klar festgehalten werden, nicht jedes Team kann agil geführt werden. Wenn Wollen, Können und Dürfen vorhanden sind, gibt es eine viel attraktivere Möglichkeit, anstelle sich für eine der beiden Seiten zu entscheiden.
Vergleich: Agiles vs klassisches Projektmanagement
Je länger ich mich mit agilen und klassischen Projektmanagement-Methoden beschäftige, desto klarer wird mir, dass es in der jeweils anderen Welt eine Entsprechung gibt. In der klassischen Welt wird zum Beispiel von Projektstrukturplan und Arbeitspaketen gesprochen. In der agilen Welt wird von Product oder Sprint Backlog und User Stories gesprochen.
Grundsätzlich versuchen beide Methoden, Arbeit in handhabbare Arbeitsstücke herunterzubrechen. Der Unterschied besteht lediglich darin, dass im klassischen Ansatz das gesamte Projekt bereits vorab geplant werden soll. Beim agilen Ansatz wird nur die Arbeit für den nächsten Sprint konkret geplant, also für die nächsten zwei bis vier Wochen. Die nachfolgende Liste zeigt weitere Übereinstimmungen dieser Form:
Wenn man nun in beiden Ansätzen durch ist, muss man sich meiner Meinung nach gar nicht mehr für die eine oder andere Seite entscheiden. Hierzu möchte ich euch die Tetralemma-Lösung vorstellen:
Tetralemma-Lösung
Das Tetralemma ist für mich eine Art Entscheidungshilfe für die Frage agiles 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.
Stacey Matrix für Agiles vs klassisches Projektmanagement
Bei Marc Engelhardt bin ich auf eine Adaptierung der Stacey Matrix gestoßen, der den Sachverhalt wunderbar illustriert:
Wenn das HOW (Technology) und das WHAT (Requirements) relativ klar sind ist klassisches Projektmanagement klar die beste Wahl. Je unklarer Technologie und Anforderungen werden, desto eher fällt die Wahl auf agiles Projektmanagement.
Fazit – Agiles vs klassisches Projektmanagement
Wenn man ein Projekt zu führen hat, muss man sich nicht zwangsläufig für die agile ODER die klassische Welt entscheiden. Je nach Reifegrad bei Requirements und Technologie kann man sich die Methode raus picken die gerade passend und nützlich ist. Voraussetzung ist aber auch, dass man in beiden Welten wirklich durch ist. Das ist kein Anfänger-Vorgehensmodell!
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