Bereits seit einiger Zeit beschäftigt mich die Frage, ob wir mit „Agile Project Management“ (Agiles Projektmanagement) nicht einem großen Blödsinn aufgesessen sind? Ist Agiles Projektmanagement nicht ein Widerspruch in sich – ein Oxymoron?
Kürzlich habe ich einen Blogpost mit dem Titel „Projekt ≠ Projekt. Projektmanagement ≠ Projektmanagement“ verfasst. Auslöser war ein gewisser Ärger, der in den letzten Jahren immer mehr in mir aufgestiegen ist. Vermeintliche „Experten“ werfen mit Konzepten und Begriffen um sich, und wir tauschen heftig Meinungen und Standpunkte aus. Aber haben wir ausreichend hinterfragen, was HINTER den ganzen Begriffen steht? Oder betreiben wir nur „Bullshit Bingo“ und Berater-Bla-Bla, was uns inhaltlich keinen Millimeter weiter bringt? Ich befürchte, dass letzteres häufig der Fall ist.
Agiles Projektmanagement ein Oxymoron?
Aber zurück zum eigentlichen Kerngedanken dieses Beitrags: Ich stelle mir ernsthaft die Frage, ob „Agiles Projektmanagement“ nicht ein Widerspruch in sich ist? Denn der Ursprung des (klassischen) Projektmanagements wird immer wieder mit dem Bau der Atombombe Mitte des 20. Jahrhunderts gleich gesetzt. Entsprechend ist doch auch klar, dass das Paradigma, das Welt- und Menschenbild, das hinter „klassischen PM-Ansätzen“ steht, jenem dieser Zeit entspricht.
Agiles Management hingegen hat seinen Urspung – so wird es zumindest von den meisten zitiert – mit der Veröffentlichung des Agilen Manifests aus dem Jahr 2001. Was hat sich in der Zeit geändert?
- Die Welt und damit auch die zu lösenden Aufgaben sind wesentlich komplizierter und komplexer geworden.
- Es hat sich in sozialen Systemen auf allen Ebenen (Gesellschaft, Wirtschaft, Familien etc.) ein Wertewandel vollzogen. Soziale Beziehungen sind vielfach fragiler geworden. Dies hatte heilsame aber auch nachteilige Konsequenzen auf unser Privat- und Arbeitsleben.
- Der Anteil an „Instabilität“ steigt tendenziell immer weiter an. Starre, hierarchische Organisations- und Arbeitsformen stoßen immer öfter an ihre Grenzen.
- Menschen sind heutzutage im Durchschnitt wesentlich besser gebildet und damit aufgeklärter. Sie lassen sich immer seltener dependent und autoritär führen. Führungskräfte müssen heutzutage eine Haltung im Sinne „führen heißt dienen“ (servant leadership) entwickeln, um als Führungskräfte anerkannt zu werden und wirksam werden zu können. Die Zeit der Helden, wie es mein Kollege Olaf Hinz treffenderweise bezeichnet, ist vorbei.
Fazit: Ist es nicht absurd, klassisches Projektmanagement mit agilen Werten, Prinzipien und Vorgehensweisen zu vermischen? Entsteht dadurch nicht ein Begriffs-Wirr-Warr, in dem plötzlich alles richtig und nichts mehr falsch sein kann?
Frage, die sich daraus für mich ergeben:
- Sollten wir nicht Projektmanagement Projektmanagement sein lassen und agile Prinzipien und Methoden getrennt davon betrachten und entwickeln?
- Sollte nicht „klassisches Projektmanagement“ für das Management einigermaßen planbarer, stabiler Vorhaben (wie z.B. Bauprojekte) verwendet werden und agile Ansätze für die Bearbeitung hochkomplexer, unsicherer Probleme (wie z.B. komplexe Softwarevorhaben)?
- Nach dieser Logik dürften wir nicht einmal den Begriff „Agiles Management“ verwenden, da auch diese Kombination einen Widerspruch in sich darstellt.
Ich gebe zu, auch ich bin in den letzten Jahren wohl dem „Witz des agilen Projektmanagements“ aufgesessen. Ich habe entschieden, diese Wortkombination zukünftig nicht mehr zu verwenden.
Gleichzeitig stehe ich aber zu meiner Überzeugung, dass wir ein systemisch-integratives Verständnis der verschiedenen Ansätze, Methoden und Vorgehensweisen brauchen. Bislang habe ich dies unter dem Stichwort „Integriertes Projektmanagement“ beschrieben. Mittlerweile halte ich „Systemisches Projektmanagement“ für die treffendere Bezeichnung. Hierzu aber demnächst mehr.
Über eine rege Diskussion zu dem Thema würde ich mich freuen.
Also prinzipiell sollte jede Art von Projektmanagement agil sein, denn wenn ich nicht rasch auf Änderungen in meinem Projekt reagieren kann, dann habe ich ein ziemliches Problem.
Falsch ist allerdings die Annahme, dass alleine das Benutzen von agilen Werkzeugen das eigene Handeln agil macht.
Ich stimme grundsätzlich Dir zu. Aber ist Umgang mit Veränderungen auch automatisch „agil“? Ich denke nicht.
Auch im klassischen Projektmanagement gibt es ein Änderungsmanagement (Project Change Management), das funktionieren kann. Aber nur, wenn man klassisches PM auch sauber praktiziert.
Wie gesagt: Ich denke nicht, dass professioneller Umgang mit Veränderung auch automatisch den agilen Ansatz bedarf.
Diskussionen „Klassisch oder agil“ werden oft sehr akademisch und vermeintlich ohne allzu viel Praxisbezug geführt. Das ist in bestimmten Kontexten sicher zweckmäßig, im wahren Leben aber unvollständig.
Du fragst „…Ist es nicht absurd, klassisches Projektmanagement” mit agilen Werten, Prinzipien und Vorgehensweisen zu vermischen? Entsteht dadurch nicht ein Begriffs-Wirr-Warr, in dem plötzlich alles richtig und nichts mehr falsch sein kann?..:“ Ich finde es eher merkwürdig, zu glauben, man könne nur „klassisch“ oder nur „agil“ arbeiten, ohne zu mischen. Insb. in großen Softwareprojekten (zumindest in meinen) bewährt es sich, die Scheuklappen abzunehmen, Glaubenssätze einfach mal zu vergessen und mit einem „Sowohl-als-auch“-Ansatz das Beste aller Welten zu verbinden. Hier steckt eine Menge Potenzial für Prozess-Innovationen abseits der von irgendwelchen Verbänden zelebrierten „richtigen“ Methoden.
Hallo Falk,
danke für Deine Gedanken.
An einem Punkt haben wir uns missverstanden: Natürlich kann und sollte man klassische und agile Ansätze und Methoden in der Praxis kombinieren. Mir geht es lediglich darum, dass man das bewusst tut.
Ich halte es für einen schweren Fehler, dass wir die Ansätze miteinander vermengen, ohne ein ausreichendes Bewusstsein zu haben, wann klassisches (Projekt)Management notwendig und sinnvoll ist und wann agile Prinzipien die Zusammenarbeit bestimmen sollten.
Ich gehe sogar noch weiter: Der Ruf nach Praxisorientierung ist erst dann legitim, wenn wir verstanden haben, worum es bei den einzelnen Ansätzen, Methoden etc. wirklich geht. Genau dort sehe ich nämlich in der Praxis häufig das Problem. Nach der Maxime der Praxisorientierung trivialisieren wir die Dinge und tun so, als ob Zusammenarbeit auf der Grundlage von Patentrezepten gelingen kann. Dem ist meines Erachtens aber nicht so.
Ich freue mich auf weitere spannende Diskussionen 😉
LG, Stefan
Hallo Stefan,
ja, da bin ich dann wieder 100%ig bei Dir. Nur wer das Handwerkszeug beherrscht, kann es auch sinnvoll anwenden. Ich vermeide daher auch gern die Diskussionen, ob man agile Methoden auch Projekt“management“ nennen darf, weil ich diese für zu oberflächlich halte. Wir brauchen in der Praxis ein umfassendes Verständnis der Projektarbeit: dazu gehört die Kenntnis sowohl klassischer als auch agiler Methoden und ein entsprechender Erfahrungshorizont, um Elemente beider richtig zu kombinieren.
Hallo Stefan,
ich begrüße die reflektierte Betrachtung der „agilen“ und „klassischen“ Ansätze und ihres jeweils vermeintlich isolierten oder kombinierten Ansätze deinerseits. Es gibt eine agile Projektumsetzung, die aber weniger auf das traditionelle administrative Management rund um die Umsetzung abzielt. Darin geht ja auch häufig die Idee eines „integrierten“ Ansatzes auf, der keine Vermischung sondern eher die innerhalb das PM-Systems der Organisation angewandten Nutzung klassischer und agiler Elemente und Abläufe als Zusammenwirken beschreibt. Dies hebt den von Dir angesprochenen Widerspruch auf. Es ist kein systemisches Projektmanagement aus meiner Sicht sondern ich unterscheide zwischen der Betrachtung des Projektmanagement-Systems innerhalb Organisation, in dem der Projektmanagement -Prozess nur ein Teil ist und dem Management sowie der Umsetzung des Projekts an sich. Dies mag auch wieder sehr akademisch klingen, ist es aber bei näherer Betrachtung gar nicht. Es trennt lediglich genau die Aspekte, die immer in einen Topf geworfen werden, in dem dann der PM-Brei vor sich hin kocht, für den jeder seine eigene Gewürz-Empfehlung ausspricht. Vielleicht haben auch mehr Menschen eine ziemlich klare Vorstellung und es mangelt nur an der Art, wie wir darüber reden.
Du sprichst mir ein Stück weit aus der Seele.
Ich treffe da folgende Unterscheidung: Je klarer die Lösungsvision der Problemstellung zu Beginn des Projektes ist, desto eher kann man sich aus dem klassischen Werkzeugkasten bedienen. Ist die Lösungsvision unklar (warum auch immer, Größe, Kompliziertheit oder echte Komplexität) sollte man verstärkt in die agile Kiste greifen.
Das mit der Geisteshaltung sehe ich differenziert. Klassisches PM basiert auf der Idee des Management, des Verwaltens und Steuerns menschlicher Arbeitskraft, überspitzt formuliert sind Menschen nur Resourcen. Das agile Manifest setzte hier mit dem ersten Abschnitt einen Kontrapunkt:
Individuals and interactions over processes and tools
Leider ist von diesem Wert nur noch wenig übrig geblieben. Der agile Werkzeugkasten wird heute in vielen Fällen nur noch verwendet um die „Resource Mensch“ noch besser auszubeuten.
Insofern sehe ich es eher so, dass die Geisteshaltung der Klassik die agilen Werte verdrängt. Agilität entwickelt sich m.E. immer mehr zum reinen Werkzeugkasten, der in manchen Fällen auch noch missbraucht wird, siehe verlinktes Beispiel.
http://www.pentaeder.de/projekte/2012/01/26/hort-mit-dem-etikettenschwindel-auf/
Als ich das erste Mal auf ein kleines Scrum-Team stieß, mit dem ich als Projekt-Manager ein klassisches Projektmanagement machen wollte mit 15 Arbeitspaketen habe ich mir auch meinen Kulturschock geholt.
Ja, man kann in kleinen Teams mit Product-Owner und Scrummaster in kleinen inkrementellen Schritten besser Software produzieren als mit langatmigem V-Modell oder Wasserfall. Aber man kann nicht ein Haus bauen, wenn ein agiles Malerteam beim Streichen eines Zimmers die Idee hat, dass man das Haus noch um 10 Etagen aufstocken sollte, weil das gerade hipp sei bei den Mietern. Anders als in isolierten Softwaremodulen geht nämlich dann der ganze Zirkus mit Statik und Genehmigung von vorne los, völlig unagil.
Im PRINCE-Bereich gibt es das Verständnis, dass man in den beiden oberen Ebenen Lenken und Managen klassisch managen kann und in der Lieferebene Scrum oder Agile machen kann. Wenn man Software baut. Ein Haus oder einen Flughafen kann man nicht agil bauen, den muss man seriös bauen (wir denken jetzt alle an Berlin, OK; aber Franz-Josef-Strauss in München hatte auch mehrjährige Verzögerung und Milliarden (DM) Mehrkosten. Der Neubau des Flughafen Düsseldorf hatte wie Berlin Probleme mit dem Brandschutz, die man aber nicht gelöst hat, sondern auf Tote gewartet hat).
Scrum und Agile ist gut für kleine Teams in räumlicher Nähe, die mittags ihr Daily Scrum Meeting machen und dann essen gehen, aber nicht für 10.000 Leute die fünf Jahre einen Flughafen bauen, der dann so aussehen soll wie geplant, genehmigt, finanziert und mit den Anwohnern besprochen.
Zum Systemischen: Natürlich ist Agile und Scrum ein schönes Beispiel für Selbststeuerung (kleiner) Lieferteams. Aber auch Luhmann schloss nicht aus, dass wir für komplexere Systeme eine funktionale Differenzierung brauchen. So haben die Projektmanager und die lenkenden Ebenen andere Funktionen als die Liefernden, d.h. die Vereinfachung auf „Agiles Projektmanagement“ ist unterkomplex im Luhmannschen Sinne.
Ich für meine Teil denke, dass PRINCE2 diese funktionale Differenzierung pragmatisch in der 3-Ebenen-Organistation herausgearbeitet hat.
Hallo Hr. Ksoll,
vielen Dank für Ihren tollen Input! Viele Ihrer Gedanken treffen exakt das, was mir in dem Zusammenhang auch durch den Kopf geht. Wir werden die Diskussion sicher weiter führen.
Viele Grüße, SH
Für mich liegt die Absurdität des agilen Ansatzes in der Verknüpfung von Werten und Methoden. Das ist der grundsätzliche Konstruktionsfehler des agilen Manifests. Mit dem fatalen Umkehrschluss, dass wer sich kritisch mit Agilität auseinander setzt gleich ein Gegner agiler Werte sein soll.
Methoden sind für mich grundsätzlich wertfrei und ihr Einsatz ist kontextspezifisch. Ob ich im Ergebnis klassisch oder agil agiere ist nebensächlich.
Sehr interessant an deiner Ausführung finde ich die zeitliche Komponente, die du ins Spiel bringst und die offenkundig aufzeigt, dass es wenig sinnvoll ist Wertvorstellungen der 50 Jahre direkt mit heutigen Wertvorstellungen zu vergleichen. Obgleich es sehr wohl Sinn macht unterschiedliche methodische Ansätze miteinander zu vergleichen, aber halt kontextspezifisch…
Hallo Stefan,
danke für den Impuls. Ein Thema, das mich auch schon lange treibt. Mein bisheriges Fazit geht in eine ähnliche Richtung wie Deine Gedanken. Allerdings möchte ich gerne noch eines ergänzen: die grundlegende Logik aller Ansätze ist dieselbe.
Ich habe immer eine Ausgangslage und möchte immer etwas Bestimmtes erreichen, wobei zwischen Ausgangslage und angestrebtem Zustand ein Unterschied besteht. Den Weg dorthin muss ich organisieren. Ich muss also ein System schaffen, das in einer nicht automatisch organisierten Situation dafür sorgt, das alle Aufgaben bekannt und auf Ressourcen verteilt werden, um anschließend bearbeitet zu werden. Dabei muss ich beachten, dass ich mit Annahmen arbeite, die zutreffen können, aber nicht müssen. Deshalb muss dieses System in der Lage sein, geänderte Annahmen möglichst mühelos aufzunehmen und das weitere Vorgehen anzupassen. Das setzt voraus, dass ich genau weiß, was mir wichtig ist und was nicht, da ich sonst keine Entscheidungen treffen kann.
Ob ich nun mit klassischem PM ein solches System schaffe oder mit anderen Methoden ist dabei auch immer eine Frage, was genau mein Anspruch ist. „Agile“ steuert für mein Verständnis sehr stark über die Qualität der Gesamtleistung (etwa über den Funktionsumfang), klassisches PM zwingt mich immer wieder zwischen Zeit, Aufwand und Qualität des Ergebnisses abzuwägen. (Was gelegentlich überfordern kann.)
Wenn ich die reine Logik der verschiedenen Denkansätze anschaue, habe ich gelegentlich den Eindruck, dass wir klassisches Projektmanagement falsch interpretieren. Etwa die Annahme, ein Plan müssen eingehalten werden, ist aus meiner Sicht falsch. Ein Plan gibt meine Annahmen wider und ich muss jederzeit bereit sein, diese und damit den Plan zu korrigieren. Die Änderung ist auch bei klassischem PM der Normalzustand.
(Ob das jetzt verständlich war? Hm.)
Beste Grüße aus dem Schwarzwald
Holger
@Holger … Dein Satz „Etwa die Annahme, ein Plan müssen eingehalten werden, ist aus meiner Sicht falsch“ weist auf einen wichtigen Punkt hin. Die Einhaltung des Plans ist tatsächlich ein vermeintlich hohes Gut, fast schon ein goldenes Kalb. Hier müsste vielleicht ein Bewusstseinswandel anfangen.
@Bernhard … so gesehen sind alle Ansätze absurd. Kein methodischer Ansatz ist wertefrei, das agile Manifest hat seine Werte nur explizit benannt. Das klassiche PM basiert u.A. auf den Werten des Taylorismus, der ein ganz bestimmtes Menschenbild zu Grunde legt.
@Eberhard: Und genau das ist das Missverständnis – Taylorismus beruht nicht auf einem bestimmten Menschenbild, sondern auf der Idee der Arbeitsteilung. Wir kennen alle die Menschen verachtenden Ergebnisse eines blind angewandten Taylorismus, doch die sind Folge, weil der Kontext ausschließlich auf die Arbeitsteilung reduziert wird. Für mich ist Arbeitsteilung als Konzept per se wertfrei, erst über ihre konkrete Anwendung kann ich mir dann ein wertendes Urteil erlauben. Das agile Manifest kritisiert solche Ansätze aber schon ohne den konkreten Kontext zu berücksichtigen. Es gibt sicher auch zahlreiche Anwendungsfälle tayloristischer Arbeitsteilung, die mein humanistisches Menschenbild überhaupt nicht berühren. Und bitte meine Argumentation nicht als ein Plädoyer für Taylorismus missverstehen, ich finde lediglich den Ansatz des agilen Manifests als ideologisch verkürzt.
@Bernhard … okay, das Prinzip Arbeitsteilung lässt sich wertefrei betrachten. Alle Methoden sind aber immer auch ein Kind ihrer Zeit und der vorherrschenden Geisteshaltung, ich hätte besser von impliziten Werten sprechen sollen (die im agilen Manifest hingegen sind explizit).
Für mich beinhaltet Projektmanagement nach wie vor prinzipiell das Lösen einer komplexen Aufgabe: Ob ich das mit agilen oder konservativen Projektmanagement-Methoden umsetze, kann ich situationsbedingt entscheiden. Entscheide ich mich für agile Vorgehensweisen, bleibt es für mich nach wie vor Projektmanagement – von daher für mein Verständnis kein Widerspruch.
Definitiv: Flexibilität ist NICHT Agilität!
Der Begriff des systemischen Projektmanagements ist aus meiner Sicht sehr sinnvoll und steht auch nicht im Widerspruch zum Projektmanagement gemäß dem „Waterfall-Model“. In dieser Modellwelt kann/ muss man auch flexibel in der Planung und in der Umsetzung sein. Flexibilität kann aber NICHT mit Agilität gleichgesetzt werden – das wäre falsch.
Agilität bedeutet in meinem Verständniss, dass man „beweglich“ plant – in etwas modernerer Sprache, gemäß der „trail & error“ Methode plant. Ich wage mich als Projektmanager etwas nach vorne und warte auf die Reaktion z.B. Feedback der Teammitglieder, Feedback des Auftraggebers oder multimediales Feedback, wie einen Shit-Storm. Somit werden Reaktionen der Umwelt, der Stakeholder direkt aufgenommen und in den nächste „trail & error“ Zyklus mit aufgenommen. Somit bleibt bei diesem Ansatz das Projektergebnis offen und unterscheidet sich somit signifikant vom Wasserfall-Modell. Somit ist dein ein extrem anpassungsfähiges Projektmanagement. Ich bin sehr dankbar für die Diskussion, da wir seit einigen Monaten dabei sind, eine SCRUM-Simulation (Brettplanspiel) zu entwickeln – und ich dabei von gleichen Zweifeln überfallen werden. Vielleicht bekomme ich gerade einen neuen Impulsschub.
Jetzt mal im ernst: ihr bekommt mit diesem Geschwurbel wirklich Kunden? Oder seid ihr PMs in geschützten Werkstätten?
@nattl … ich bekomme meine Kunden nicht mit Geschwurbel sondern mit Ergebnissen in realen, operativen Projekten. Eine Auseinandersetzung auf einer Meta-Ebene hilft mir bei der Reflexion der eigenen Tätigkeit.
+1
Lieber Stefan,
solche Diskussionen tragen immer dazu bei, dass wir unsere Begriffe schärfen und dass uns klar wird, was uns wichtig ist.
Wenn ich mir die Daten von Google Books ansehen, fällt auf, dass das Thema „Projektmanagement“ (deutsche Bücher, Zeit 1990 – 2000) deutlich zugenommen hat (siehe http://books.google.com/ngrams/graph?content=Projektmanagement%2Cscrum%2Cagil%2CXP&year_start=1940&year_end=2000&corpus=20&smoothing=3). Die Trendauswertung der Google-Suche zeigt einen deutlichen Abstand zwischen Scrum und Projektmanagement (Anfragen aus Deutschland, Zeit 2004-heute), wobei die Suchanfragen zu Scrum zunehmen und zu PM abnehmen (siehe http://www.google.de/trends/explore?q=scrum#q=scrum%2C%20%20projektmanagement&geo=DE&cmpt=q).
Diese Trends müssen wir erst mal zur Kenntnis nehmen. So, wie mal die Atkins-Diat in ist und ein anderes Mal „Schlank im Schlaf“. Als Berater bin ich von dem abhängig, von dem meine Kunden glauben, dass es ihre Probleme löst. Ein guter Berater (und natürlich auch eine gute Beraterin) erkennt die wirklichen Probleme und löst sie mit den Mitteln, die am besten zum Kunden und zum Problem passen.
Zu Deinen Fragen:
1. Projektmanagement ist Projektmanagement. Punkt. Egal ob klassisch, agil, grün oder eckig. Die Methoden sind agil, plan-getrieben o. ä..
2. Jedes Projekt braucht die Methode, die am besten zu ihm passt. Bauprojekte sind nicht stabil und planbar, siehe Bent Flyvbjergs „Megaprojects and risk“ (http://www.amazon.de/Megaprojects-Risk-Ambition-Bent-Flyvbjerg/dp/0521009464/) oder Peter Morris‘ „The Management of projects“ (http://www.amazon.de/Management-Projects-Peter-W-Morris/dp/0727725939/). Projekte sind immer Risiko.
3. Management ist Management. Die Methoden sind agil, plan-getrieben o. ä..
Besten Gruß, Jan
Ich denke, dass viele Unternehmen bereits agiles PM betreiben, nur wird es nicht zugegeben. Vorallem im Bereich der SW-Entwicklung sind oft die Anforderungen unpräzise. Das Projekt wird nach klassischen PM-Methodik aufgesetzt, aber im Laufe der Umsetzung wird das Ziel klarer. Da man oft das Projekt nicht abbrechen wird, wird stillschweigend das Ziel den geänderten Anforderungen angepasst. Geht es gut, dann jubeln alle. Geht es schief, dann ist das Team auf der Suche nach dem Schuldigen.
Ich bin ein Anhänger des klassichen PMs, da durch ein sauberes Setup ein faires Ergebnis erreicht werden kann.
Lieber Stefan,
mir gefällt Dein Beitrag, weil ich die Frage spannend finde, ohne aber die genauen Hintergründe der Diskussion in der PM-Szene zu kennen. Mich erinnert diese Diskussion an die Frage der Wirtschaftsentwicklung / Business as usual oder doch Nachhaltigkeit? Auch hier basieren die Konzepte (so es überhaupt welche gibt) auf unterschiedlichen Weltanschauungen. Es ist die Polarität zwischen mechanistischen und ganzheitlichen Denkwelten. Wir befinden uns heute in einem Übergangsraum; wir sind nicht mehr „ganz im alten“, aber auch noch lange nicht „im neuen System“ angekommen. In solchen Zeiten des Wandels sind prinzipielle Widersprüche die Regel. Sie sollen unseren Geist energetisch anregen und Menschen in den Dialog bringen. Die Suche nach Lösungen in unserem System mag viele beschäftigen, ist aber nur „Zeitverschwendung“. Nur in einem guten Dialog aller Kräfte können wir auf die Suche nach einer Synthese – einer Lösung auf höhere Ebene- gehen.
Danke und liebe Grüße „this way“, Peter