Zuerst möchte ich mich für die diversen Kommentare und Rückmeldungen zu meinem letzten Blogbeitrag herzlich bedanken. Gerade auch die kritischen und kontroversiellen Rückmeldungen haben mich sehr gefreut. Genau deshalb habe ich auch nach gut 8 Jahren PM-Blog.com noch große Lust, von und mit meinen Leser/innen zu lernen.
Heute möchte ich eine kleine Tabelle veröffentlichen, die demnächst in Form eines Blogbeitrags im Projektmagazin erscheinen wird. Meine Kernthese: Projektmanagement und Agile (als Sammelbegriff für agile Frameworks wie Scrum) sind zwei unterschiedliche Disziplinen.
Warum wir Projektmanagement und Agile als unterschiedliche Disziplinen betachten sollten.
Bereits im Beitrag zu „Beyond Project Management“ habe ich ein paar Gedankensplitter zur Diskussion gestellt, weshalb ich zwischen Prozess-, Projekt- und Pionierarbeit differenzieren würde. Anhand der folgenden Tabelle möchte ich dies am Beispiel von Projektmanagement und Agile etwas näher ausführen:
Auch auf die Gefahr hin, dass ich mich wiederhole:
- Wir sollten Projektmanagement und Agile als getrennte Disziplinen betrachten.
- Wir sprechen von „Projekten“, als ob sie alle gleich wären. In Wirklichkeit verhalten sich viele Projekte wie Pop zu Jazz. OK, alles sind Musikrichtungen, aber… (vgl. hierzu z.B. Projekt ≠ Projekt).
- Entsprechend brauchen wir auch differenzierte Konzepte, Methoden und Herangehensweisen, um die unterschiedlichen Projektaufgaben (und Pionieraufgaben) zu bewältigen.
- Integration von Projektmanagement und Agile ist erst dann möglich, wenn wir zuerst die Unterschiede heraus gearbeitet haben. Zuerst differenzieren, dann integrieren (Stichwort „Integriertes Projektmanagement„) .
Ich gebe zu: Meine Vorfreude auf das diesjährige PM Camp in Dornbirn (20. bis 22. November 2014) steigt von Tag zu Tag. Denn dort werden wir Standpunkte und Perspektiven „Beyond Project Management“ austauschen – und vieles mehr…
sei mir nicht böse stefan: ich teile deine meinung überhaupt nicht. die tabelle listet ein paar äusserlichkeiten auf, mit denen versucht wird, das konzept „projektmanagement“ zu retten. als ob es das bräuchte. projektmanagement ist und bleibt die disziplin, agrenzbare, zeitlich betristete und mit einem klaren endziel versehene tätigkeiten zu steuern, koordinieren, überwachen.
wann immer leute probiert haben, agile, scrum oder design thinking neben projektmanagement zu platzieren, sind diese leute auf ignoranteste an der tatsache vorbeigeschrammt, dass diese methoden nichts anderes sind als projektmanagement. wenn projektmanagement sich heute – in einem exponentiell dynamischer gewordenen umfeld – neue methoden bedient: tant mieux. ändert nichts daran, dass projektmanagement die disziplin ist, die das alles vereint.
und das – sorry wenn ich globalgalaktisch werde – wird so bleiben bis ans ende der zeit: es wird immer repetitives und immer neues geben. letzteres nennt man projekt. und für das wird es immer ein management brauchen. egel welche methoden dabei zum einsatz kommen.
beste grüsse,
frank
ps: wenn ich jetzt beispielhaft die projektcrowdsourcing-seite http://www.omanet.org nenne, dann ist das nur einer von zigtausenden beweisen, dass es für das management von projekten nie etwas anderes geben kann als projektmanagement 🙂
Wie könnte ich Dir böse sein, Frank 😉 Im Gegenteil!
Danke für diesen Kommentar.
Beim Lesen des Artikels fühlte sich für mich irgendwas nicht richtig an. Einige Schlussfolgerungen/Wiederholungen kann ich durchaus unterschreiben, aber die Kernthese wirkt künstlich und willkürlich.
Ich stimme Frank Wolff zu: beides (agil & klassisches PM) sind Implementierungen derselben Basis und durchaus interoperabel.
Die Anwendung agiler Methoden/Ansätze im klassischen PM (und vice versa) ist schwieriger als die Anwendung agiler Methoden im agilen PM aber weder unmöglich noch tabu.
Danke auch an Stefan Hagen nicht vor kontroversen Themen halt zu machen und mich zum Mitdenken zu motivieren 🙂
Besten Dank, Frank!
Ich bin mir ebenfalls sicher, dass eine Disziplin, Fachrichtung oder Was-auch-immer namens Projektmanagement durchaus mehrere Spielarten verträgt und sich entsprechend weiterentwickeln kann und wird.
„Früher“ gab’s auch House nicht, das ist dennoch Musik. (Auch wenn man darüber gleichermaßen uneins sein kann. 🙂 )
Hm, tut mir leid, aber die Tabelle stellt Dinge als zugeordnet dar, die so nicht gegeben sind.
Zum Beispiel Beinhaltet ein Projekt natürlich auch Unplanbares – z.b. das Verhalten der Stakeholder während des Projekts, und im Agilen Vorgehen haben ich natürlich auch planbare Teile wie einen Durchlauf, wie die periodischen Meetings mit Product Owner etc.
Aus meiner Sicht waren Projekte immer schon agil – sprich gerade wenn sich das Umfeld stark ändert, die Unplanbarkeiten zu beherrschen sind – genau dann ist es ein Projekt.
Danke für den Input!
Mir ist sehr wohl klar, dass ich mit diesen Aussagen und den Beiträgen insgesamt polarisiere. Das ist ehrlich gesagt auch meine Absicht. Und nochmals: Ich behaupte nicht, dass ich in der Sache „recht“ habe. Denn 100% richtig oder falsch gibt es im Leben außerhalb der Naturwissenschaften (und nicht mal dort) eh nicht. Mir geht es darum, mal eine andere Perspektive einzunehmen, um die Dinge klarer (weil anders) zu erkennen.
Hallo Stefan,
danke für Deine Gegenüberstellung. Aus meiner Sicht geht es jedoch nicht darum, beide Begriffe gegeneinander abzugrenzen. Vielmehr steht auch das klassische Projektmanagement vor der Herausforderung tagtäglich mit Veränderungen und Unplanbarkeiten umgehen zu müssen. Agile Vorgehensmodelle (wie z.B. Scrum) können als Methodik helfen mit dieser Herausforderung umzusehen. Ganz ohne die Möglichkeiten der Agilität kommt aus meiner Sicht kein Projektmanagement aus. Hierbei muss es jedoch nicht immer der komplette Scrum-Baukasten sein. Meine Erfahrung zeigt, dass je nach Situation auch einzelne agile Elemente bereits ausreichend sein können um klassisches Projektmanagement mit der notwendigen Flexibilität auszustatten.
Wie sich agiles Projektmanagement flexibel und ohne großen Overhead umsetzen lässt habe ich hier beschrieben: http://www.scrum-mit-workflowy.de
Insgesamt würde ich agile Vorgehensmodelle daher als Ergänzung zu klassischem Projektmanagement verstehen.
OK. Gehen wir mal davon aus, dass Agile weiterhin der PM-Disziplin zugeordnet ist (was übrigens sehr wahrscheinlich ist). Können wir uns dann darauf einigen, dass es Vorgehensweisen, Ansätze und Disziplinen JENSEITS von dem braucht, was wir Projektmanagement nennen? Also Beyond Project Management.
das ist auf jeden Fall ein Unterschied, der einen Unterschied macht, lieber Stefan 🙂
…und die posts zeigen nach meiner Wahrnehmung auch genau den Punkt auf, an dem Du/ Wir schon länger dran sind: bei steigender Ungewissheit gibt es kein „führendes Modell“ mehr, sondern es braucht dem Projektgegenstand angemessene und sinnvolle Vorgehensweisen.
Und da ist es dem Projektgegenstand doch ziemlich „sch…egal“ mit welcher Hebamme er auf die Welt kommt. Der Arzt der heilt hat recht, hab ich mal am Ende einer Diskussionmit dem Titel „Ist Homöopathie wirksam?“ mitgenommen.
Was es also braucht ist ein klarer Fokus aller Projektarbeiter die erfolgreich sein wollen: nämlich auf den Projektgegenstand, den Kontext und das Umfeld. Wenn man da (i.d.R. nach einem erfolgreichen Start Up Workshop) klar ist, wählt man aus seinem Repertoire die Methoden und Tools aus, die es braucht.
Den Fokus dagegen verloren haben Organisationen und Manager, die mit „Strategien“ a la „Wir machen kein altes, klassisches PM mehr, wir machen ab jetzt modernes Scrum“ nur die Farbe des Dogmas „Die richtige Methode ist uns heilig“ wechseln.
…
Exakt, lieber Olaf. Aber wahrscheinlich müssen wir noch an der Anschlussfähigkeit unserer Gedankenwelt arbeiten 😉 Ich zumindest…
Ich glaube, die Hauptthese
„Projektmanagement und Agile (als Sammelbegriff für agile Frameworks wie Scrum) sind zwei unterschiedliche Disziplinen. “ ist falsch 🙂
Zum einen gibt es ja PM-Methodensätze, die beides zusammenbringen, Z.B. hat PRINCE2 sich mit DSDM zusammengetan, was 2015 in einem neuen Leitfaden (nach dem von 2007) von Axelos neu herausgebracht wird. Klassisches PM und Agile unterscheiden sich eher horizontal als vertikal. Wenn man mit PRINCE2 auf Lenkungsebene und Managementebene gut zurecht kommt, kann man auf Arbeitsebene gut mit Scrum arbeiten. Beispiel: wenn in einer staatlichen Finanzverwaltung in kleinen Teams mit wenigen Leuten mit Scrum neue Software entwickelt wird, müssen nicht zwingend alle Finanzbeamten selbstorganisierend sein.
Neulich habe ich ein neues Druckwerk von Axelos rezensiert „Integrating PRINCE2“. http://wk-blog.wolfgang-ksoll.de/2014/08/28/axelos-integrating-prince2-ein-neuer-leitfaden/ Dort wird aus dem Changemanagement kommend auf die beiden Pole einer möglichen Organisation abgehoben: a) Maschinen-Modell: Arbeit ist wie eine Maschine, Typ X nach McGregor b) Denkendes Modell: Mitarbeiter denken, Typ Y nach McGregor. Man findet aber beide Typen und muss entsprechend sich aufstellen. Das ist aber eine Frage der Organisationsentwicklung und nicht der Arbeitsweise mit klassischem PM oder auf Arbeitsebene mit Agilem.
Zu der Tabelle zwei Anmerkungen:
– Moscow ist Standard-Lehrstoff von PRINCE2 und kein Agiles Alleinstellungsmerkmal
– Qualität-Kosten-Zeit ohne Nutzen-Umfang-Risiko ist schon recht alt 🙂
Ich vermute mal, dass die Themen Führung, Selbststeuerung, Systemtheorie, Vision und Strategie besser in der Organisationsentwicklung aufgehoben sind (wo sie ja auch in tradionellen, hierarchischen von Psychologen häufig angewendet wird) als auf Projektebene.
Die Agile Methoden kommen fast alle aus der (Software-)Entwicklung, weil Wasserfall und V-Modelle nicht mehr funktionieren. Aber es gibt auch erhebliche Mängel, die ein Management verhindern. Die Hardcore-Scrum-Community sagt immer, dass sie finanziell nicht schätzen will. Gut, dann werden sie geschätzt. Von Managementebenen darüber. Man kann nicht zu einer Bank oder einem Aktionär sagen, dass man nicht (ökonomisch) schätzen will. Dann passt man nicht ins System und kann auch nicht systemisch werden, sondern bleibt tayloristisch. Softwerker haben zusätzlich einen eigentümlichen Mindset. Wenn ich das „gebaute“ einfach löschen kann und neu bauen kann, dann ist das was anderes als in der materiellen Welt. Eine Abspaltung des Agilen, wenn man eigentlich nur das agile Softwarenentwickeln meint, verschärft aber die nichtsystemische Desintegration. Zu erwarten, dass der ganze Shop sich so zu entwickeln hat, wie Informatiker Software entwickeln, löst sich aus der Welt. Ich habe im letzten Jahr mehrere Shops gehabt, die gesagt haben, „Ja in der Softwareentwicklung für unsere Produkte machen wir Scrum, aber außerhalb in der Systemintegration der Softwareprodukte bei unseren Kunden auf gar keinen Fall. Da machen wir klassisches PM.“
Ich glaube, man sollte noch mal schärfer hinsehen, was der Kern des Methodensets beim Agilen ist, dass es in für ihn geeigneten Kontexten erfolgreich macht. Aber in manchem ist es auch nru Kochrezept und Handwerk wie die klassischen auch: Product Backlog, Sprint, usw. Wenn man sich als Scrummer jeden Tag um 11:45 zum Daily Sprint trifft, dann ist das nicht sonderlich agil, sondern starrer Zeitrahmen. Wenn dann alle physisch vor Ort sein müssen, fehlt die Zeit zum systemischen irritieren lassen 🙂
Projektmanagement wird agiler, aber ich halte es für falsch, die beiden gegenseitig auszuschließen. Wir werden mehr integrieren müssen statt abzugrenzen. (Fürs Systemische empfehle ich immer auch gerne Niklas Luhmann: ein wahrer Quell der Erleuchtung. Der sagt zum Beispiel, dass soziale Systeme auf Kommunikation beruhen (also nicht auf den Mitgliedern). Was heißt dass dann, wenn sich die Kommunikation mit IT verändert. Was heißt das dann für den Agilen, wenn er nicht mehr zwingend im selben Raum mit seinen Kolleginnen sitzen muss, außer dass er dann die Flipcharts aus der Papierwelt vielleicht nicht alle gleichzeitig an der Wand hängen sehen kann? Man wird über neue Methoden nachdenken müssen, die skalieren, was die gängigen Agilen nicht tun.
Aber der Diskurs darüber ist wichtig. Danke dafür!
Wer sich die historische Entwicklung von Scrum, XP, etc. anschaut, der stellt fest, dass diese Denke nicht aus der Software-Entwicklung stammen kann. Einige Daten: 1950 Demming’s „Qualitätsprinzip“, 1959 Drucker’s „Knowledge Worker“, 1960 McGregor „Theory X/Y“, 1970 Greenleaf „Servant Leadership“, 1975 Ohno’s „Toyota Production System“, 1982 Demming’s „14 Points for Management“, 1986 Nonaka’s „New New Product Development Game“ (selbstorganisierende Teams). Alle samt mit Blick auf moderne und empirisch erfolgreiche Managementmethoden und Produktionsprozesse der Industrie (ein Schwerpunkt ist Automotive). Erst 1995 dann Schwaber’s „Scrum Development Process“ mit Focus Software-Entwicklung, in Anlehnung an die vorgenannten Pioniere für eine neue Denke und in Anpassung an neue Anforderungen der vorhandenen Märkte bzgl. Produktdifferenzierung, Volatilität und kürzere Konjunkturzyklen. Aus heutiger Sicht müssen wir sicher noch den disruptiven Character der Märkte hinzunehmen (etablierte Marktführer verschwinden innerhalb von Jahren in der Bedeutungslosigkeit).
Agilisten wollen nicht per se nicht schätzen, sondern sie haben verstanden, dass ein Schätzen, das als Commitment gewertet wird (gute alte Festpreisdenke, die alle drei im magischen Dreieck optimieren will) nicht funktioniert in der Praxis. Man lügt sich nur in die Tasche. Der Funktionsumfang muss verhandelbar sein, sonst kann man in der komplexen Welt keine Ergebnisse liefern, die den Kunden zufriedenstellen. Deshalb wird der Funktionsumfang auch ständig neu ausgehandelt. Hierbei kommen zwei wesentliche Aspekte zum Tragen: der Kunde kriegt regelmäßig etwas ausgeliefert und kann dann entsprechendes Feedback geben (wohin geht die Reise als nächstes hin im Sinne des Geschäftswerts) und der Kunde priorisiert seine Anforderungen regelmäßig nach aktueller Projektsituation, so dass wirklich nur das zum Liefertermin runterfällt, was für den Geschäftswert den geringsten Anteil bringen würde.
Was hier gänzlich übersehen wird: es geht nicht um die Praktiken, sondern um die Prinzipen/Werte hinter den beiden Vorgehensweisen. Klassisch folgt in den meisten Fällen McGregor’s X-Modell, agil grundsätzlich McGregor’s Y-Modell. Die Jungs oben in der historischen Liste haben allesamt festgestellt, dass X schon lange nicht mehr funktioniert. Hier sollten wir mal ansetzen bei der Diskussion. Wie wir dann die Sachen im Detail in den Projekten, oder davon abgeleitet für die Organisation abbilden, kann dann einfach abgeleitet werden. Wer in Y denkt, der verzichtet z.B. bewusst auf Incentivierung und Jahresgespräche und sorgt stattdessen für ein Umfeld in dem Mitarbeiter permanenten Support erfahren, wo ohne große Diskussionen geholfen wird, wenn sich Mitarbeiter beim Management melden (ohne zu hinterfragen, warum ;-)).
Sehe ich auch so. Man könnte noch Tom Peters, Mike Hammer u.a. Managementtheoretiker der 1990er oder Luhmann, Baecker oder Willke hinzufügen (die ja meist auch als systemische Berater tätig sind/waren).
Incentives und Jahresgespräche machen bei Y ja auch keinen Sinn, weil sie Pawlow und X sind 🙂 Machst Du meine Vorgabe zu 90%, bekommst Du 90% Bonus. Klassische Konditionierung. Aber man darf nicht aus dem Auge verlieren, dass viele Shops so gefahren werden, obwohl manche Nischen glücklich mit Y sind.
Das schwierige ist das Abgrenzen sinnvoller Gebiete für Agiles. Beispiel Automobil. In der Modellentwicklung kann man den Gesängen von Toyota folgen. Ist das Modell entwickelt und damit der Funktionsumfang fest, müssen die geschätzten Kosten vorliegen, damit man entscheiden kann, ob es einen Business Case gibt, um es zu bauen (außerhalb des agilen Projektteams). Ist der vorhanden, braucht es klassisches Projektmanagement um am ersten Tag der Werksferien die Bänder auf das neue Modell umgerüstet zu haben. Von da ab ist Business as Usual, Prozess. Also nur ein winziger Bruchteil der Autoindustrie agil.
Ähnlich bei Software: natürlich kann man ein neues ERP in kleinem Team agil entwickeln. Wenn man gut ist. Das Spannende am neuen ERP ist aber nicht der Funktionsumfang allein, sondern dass das 1.000, 10.000 oder 10.000 User richtig anwenden, so dass der Konzern seinen Abschluss am Jahresende gut durch Wirtschaftsprüfer und Finanzamt bekommt. Hier kommt es dann nicht nur darauf an, dass das Team gut entwickelt, sondern auch, ob es Empathie für die Nutzer hat, die ihre Massenbuchungen einfach bewältigen können oder einen leistungsfähigen Excel-Im-+Exporter zu haben, statt über die Vorteil von Open Source zu filosofieren 🙂
„der Kunde kriegt regelmäßig etwas ausgeliefert und kann dann entsprechendes Feedback geben“
Bei Software einfach, schon bei Autos schwierig.
Ich glaube, scharfe Abgrenzung ist wenig sinnvoll, sondern eher, je mehr a, desto mehr b und umgekehrt. Projekte bleiben es egal ob man klassisch oder modern handelt. Zeitlich abgegrenzt, kein Dauerbetrieb. Spannende Frage: Ist ein Braunkohle-Tagebau mit 50 Jahren Laufzeit ein Projekt (wohl definiertes Ende, einmalig, spezielle Organisation)? 😉
Hallo Stefan
ein bisschen spielst du Pipi Langstrumpf und machst die Welt, wie sie dir gefällt. Mit der Reduktion von PM von komplex auf kompliziert gehst du eine gewaltige Abkürzung. Keine Frage häufig wird PM lediglich für komplizierte Aufgabenstellungen angewandt, aber der Anspruch sind dennoch komplexe Problemstellungen (und ehrlich gesagt bezweifle ich auch, dass agil das Patentrezept für Komplexität ist – auch wenn es in vielen Fällen erfolgreich weiter hilft).
Statt dass wir uns der Komplexität in den kleinsten Dingen bewusst werden, versuchst du pauschal einen ganzen Bereich auszuklammern.
Liebe Grüße
Bernhard
Danke für Deinen kritischen Input!
Ich freue mich auf die weitere Diskussion. In den nächsten Wochen werde ich sicher noch den einen oder anderen Blogbeitrag zu dem Thema schreiben.
Lieber Stefan, meine etwas längere Antwort habe ich in diesem Artikel formuliert. Kernthese: Ja, PM und Agile sind unterschiedlich, im Sinne von unvergleichbar. Projektmanagement als Führungs- und Gestaltungsaufgabe findet immer statt, während Agile nur eine Antwort auf die Frage nach der richtigen Gestaltung der Zusammenarbeit ist.
Ich antworte mal hier, da das Thema hier etwas mehr Raum einnimmt. Ich kann die Unterscheidung in Führung und Organisation nicht nachvollziehen, um Agilität entspechend zu verorten. Agilität gibt eine ganz klare Antwort auf „Führung“. Servant Leadership und Y-Modell sind in der agilen DNA gleich mit verbaut, genauso wie Qualität. Bei all den Abgrenzungsversuchen sehe ich nicht, dass Agilität sich so einfach in eine bestimmte Ecke stellen lässt. Gerade wenn ich mir die Historie hinter dem agilen Manifest anschaue (siehe mein Kommentar weiter oben), sind die agilen Prinzipien sehr weit zu fassen und können über Projektmanagement hinaus sogar bei der Organisationsentwicklung mitreden. Ich bin sehr gespannt, ob wir in 5 Jahren noch versuchen werden, die alte Denke derart zu verteidigen. Oder ob wir dann nicht doch anfangen zu überlegen, wie die agilen Werte die klassischen Strukturen ablösen können, damit die agilen Projekte besser unterstützt werden, mit denen wir am Markt noch überleben können (mindestens mal im Software-Bereich). Dann wird das Rosinenpicken mal in die andere Richtung stattfinden: zu meinem agilen Prozess nehme ich mir noch etwas klassisches Stakeholdermangement dazu. Was ich schon heute so mache ;-).
Vielleicht war ich da nicht ganz präzise, lieber Rainer, aber im Prinzip bin ich da genau Deiner Meinung: Agilität ist eine Antwort auf die Fragen die sich in der Projektführung und -gestaltung stellen. Damit bewegt sich Agilität auf der Ebene der konkreten Lösungen, während Projektmanagement eine Ebene drüber liegt.
Sorry, falls ich da was missverstanden habe.
Hm. Projektmanagement teil sich in Theorie (Prinzipien) und Praxis (Praktiken) wie Agilität es auch tut. Da mag ich dann aber doch widersprechen. Dann sollten wir doch eher über Stefan’s Vorschlag der „Meta-Ebene darüber“ diskutieren. Aber wie wollen wir das nennen? Produktion?
Trotz aller völlig richtiger Werte und Prinzipien die agile Vorgehensweisen quasi in ihrer DNA verwoben haben, es muss jemand geben, der sich bewusst für den Einsatz agiler Vorgehensweise entschieden hat und das aus guten Gründen. Diese Entscheidung fällt notwendigerweise außerhalb des Anwendungsrahmens von Agile. Das ist uns bleibt die Führungsaufgabe des Projektmanagements: Die passende Gestaltung der Zusammenarbeit im Projekt. Agile Vorgehensweise, Prinzipien und Werte liefern da gute Antworten, mehr aber auch nicht.
Entscheidet das wirklich der PM? Diese Entscheidung liegt doch eher in der Organisation, die die Leute erst mal enablen muss agil arbeiten zu können. Ich glaube unsere unterschiedlichen Blickwinkel machen es schwierig, Agilität einzuordnen. Agilität auf Methoden und Werkzeuge zu reduzieren trifft es nicht. Dafür ist der Impact auf die Organisation viel zu groß. Deshalb sind mir die Prinzipen so wichtig. Es ist eben gerade nicht einfach nur eine Erweiterung des Bestehenden. Agile Projekte verändern die Organisation. Wenn sie das nicht tun, sind sie weniger effektiv als klassische Projekte und kein Mehrwert. Man muss sich letztlich entscheiden, ob der Mehrwert, der entstehen kann, dem Aufwand gegenüber gerechtfertigt ist (Change des Mindsets der Organisation). Da mischt aber das (Top-)Management mit.
Also wenn ich mir die Diskussion hier anschaue, dann wird Agile für mich immer mehr zum fragwürdigen Hype – dabei schätze ich agile Werte, agiles Denken und Handeln.
Klassisches Projektmanagement haben die Agilos erfunden – um sich abzugrenzen. Es gibt nur gutes und schlechtes Projektmanagement und situativ ist das mal mehr oder weniger agil.
Der Grundfehler des agilen Manifests ist die Vermengung von Werten und Methodik. Was an und für sich nicht schlecht ist, wird im falsch verstandenen Umkehrschluss (Ihr seid nicht agil, also seid Ihr „böse“) zum Absurdum. Rainers Argumention oben spricht so z.B. davon, dass „agile Werte klassische Strukturen“ ablösen sollen. Hört auf mit diesem Blödsinn! Es geht um die Lösung komplexer Problemstellungen (das ist Projektmanagement für mich), da führen solche Grundsatzdebatten zu rein gar nichts.
Auch wenn das jetzt etwas nach interner openPM-Diskussion aussieht: was wäre denn so schlimm, wenn es eine Ablösung gäbe? Wenn es die bessere Antwort auf die Veränderungen des Marktes wäre, warum den nicht? Für den Software-entwicklungsbereich sehe ich da grosse Chancen diesen Weg zu gehen.
Lieber Rainer, du bringst für mich die grandiose Selbstüberschätzung vieler Agilos zum Ausdruck: Der Glaube an ein besseres Rezept und die Ideologisierung. Dabei behaupte ich, wie zuvor gesagt, es gibt gar kein klassisches Projektmanagement, sondern das gibt es nur in den Abgrenzungsversuchen der Agilisten.
Wir sind uns sicher schnell einig, dass es viele fragwürdige und überholenswerte Methoden und Vorgehensweisen gibt, die wir gerne anpacken sollten, aber bitte keine Glaubenskriege. Und genauso bin ich bei dir, auch in der Arbeits- und Projektwelt mit einem humanistischen Menschenbild zu agieren, iterative Vorgehensweisen, Selbststeuerung und Teams in Projekten einzusetzen. Aber auch hier bitte nicht als ultima ratio, sondern mit Sinn und Verstand.
Es gibt für mich nur eine Projektwelt, aber mit sehr vielen verschiedenen Antworten und Facetten. Primär ist für mich dir Frage nach dem Kontext entscheidend und nicht die Frage nach der Schule mit der ich versuche einen Kontext zu bearbeiten.
Gestern Abend habe ich mich mit zwei Unternehmerfreunden getroffen. Beide in sehr extremen Projekten unterwegs. Und wollen ganz neue Geschäfte angehen.
Die haben mir erklärt, was Industrie4.0 bedeutet. Und ich war von den Socken. Dachte ich doch bisher, Industrie wäre nur so ein neues „buzzword“ und dass da mal wieder eine neue Sau durchs Dorf getrieben wird.
Ich musste aber lernen, dass es da durchaus seriöse Studien und entsprechend Ansätze gibt, die Ziele und mögliche Ergebnisse von Industrie4.0 beschreiben. Und verstanden, dass das ein Paradigma entsteht, dass das alte Produktionsverständnis völlig auf den Kopf stellt.
🙂 Sozusagen sollen in Zukunft die Reifen selber ihr Auto finden.
Und was die beiden mir erzählt haben, hat meine doch trotz ALO (agil, lean, open) immer noch sehr klassische Projektdenke zuerst mal ziemlich verunsichert.
Ich meine damit nur, dass man sich mal doch mit Industrie4.0 beschäftigen sollte und z.B. mit dem was die Kollegen von Fraunhofer dazu so alles veröffentlichen. Und selbst wenn Industrie4.0 vielleicht wirklich nur ein Buzzword ist, so könnte es zumindest einen heftigen Paradigmen-Wechsel im Projekt- und vor allem Organisationsdenken beschreiben und verursachen bzw. beobachten …
Hoffe, dass das jetzt nicht zuviel „Science Fiction“ war 😉
Ich hab mir Industrie 4.0 als sich „gerade abzeichnende Science Fiction“ noch nicht angeschaut, aber das hört sich verdammt nach dem an, was ich auch gerade so als notwendig ansehe. Ich verstehe die Bewußtseinshaltung, das Alte zu bewahren und zu modernisieren, aber es zeichnen sich disruptive Entwicklungen ab, bei denen mir Evolution derzeit nicht als ausreichend erscheint, weil viel zu langsam, um auf die Märkte noch akurat zu reagieren. Agilität steht für mich derzeit stellvertretend für eine mögliche Ausprägung in diese neue Richtung – mangels Alternative. Ken Schwaber hat bereits vor einiger Zeit in seinem Blog die Frage gestellt „Was kommt nach Scrum?“. Da in immer mehr Management-Büchern (z.B. Sprenger, Denning, Pfläging) , zwar nicht explizit, aber erkennbar agile Denke als neuer Ansatz integriert ist, ist für mich Agilität der nächste notwendige Schritt, ohne davon auszugehen, dass das schon ausreichen wird. Und hierbei sind nicht nur die Projekte betroffen, sondern die Organisation als solches.
Auch ich kann mich mit der Begriffsabgrenzung Projektmanagement vs. Agile und der Tabelle in dieser Form nicht anfreunden.
Im Grunde genommen stellt die Tabelle zwei Ausprägungen verschiedenartiger Projekte und zugehörige Methoden/Ansätze/etc. gegenüber. Im Kern spiegelt sich darin die meines Erachtens richtige und wichtige Erkenntnis wider, dass ein bestimmter methodischer Ansatz nicht für alle Projekte gleich gut geeignet ist.
Zunächst dachte ich, die Sache wird absolut richtig, wenn man die linke Spalte mit „klassisches Projektmanagement“ überschreibt. Andererseits trifft es das auch nicht so richtig. Diesbezüglich teile ich außerdem die Meinung von Bernhard Schloß. Der Begriff „klassisches Projektmanagement“ ist ja auch nicht klar definiert. Man könnte es vielleicht unflexibles oder Plan-zentriertes (oder nicht-agiles) Projektmanagement nennen.
So oder so verstehe ich unter Projektmanagement: Organisation, Methoden, Werkzeuge etc., mit denen wir Projekte durchführen. Ein erfahrener Projektleiter hat viele unterschiedliche Methoden in seinem Werkzeugkasten. Und wenn ein Projekt den Kriterien der rechten Spalte entspricht, wird er tendenziell den Einsatz „agiler Methoden“ (was immer der einzelne genau darunter verstehen mag) bevorzugen. Aber deshalb ist es für mich immer noch Projektmanagement. Dazu gehört eben auch, situativ zu entscheiden, welche Verfahren (und auch welche Organisationsform etc.) für den Erfolg des Projektes am besten geeignet sind.
Also: Ja, Projekte sind nicht alle gleich. Sie sind wie Pop und Jazz. Deshalb brauchen wir differenzierte Konzepte und nicht einzelne Ansätze, die behaupten für alle Projekte besser zu sein. Unbedingt! Das alles ist für mich aber inhärenter Bestandteil von Projektmanagement.
Übrigens: Es gab auch vor dem agilen Manifest Projekte, die die 4 Grundwerte desselben erfüllt haben. Man hat sie nur nicht „agil“ genannt. Und ich wage jetzt mal die Behauptung, dass diese 4 Grundwerte den klassischen Standardwerken für Projektmanagement nicht widersprechen. Ich kann mich zum Beispiel nicht erinnern, irgendwo gelesen zu haben, dass umfassende Dokumentation immer wichtiger sein muss als die Funktionsfähigkeit des Projektgegenstands.
Mag sein, aber es geht hier um Prinzipien, die gelebt werden müssen. Ich hab vor meinen agilen Projekten noch nicht erlebt, dass das Micromanagement vom Team durchgeführt wurde. Das hat wohl aus Vertrauensgründen ein PM erledigt. Aber da sind wir dann gleich wieder beim Menschenbild 🙂
Ich stimme Ihnen zu. Auch für mich ist „Agile“ nicht nur eine reine Verfahrensweise. Aber ist das nicht immer so? Wenn ich als Projektleiter alles haarklein vorgeben will und habe nur Freidenker im Team, wird es auch schwierig …
–
Eine Schwierigkeit der Diskussion ist, dass jeder unter „Agile“ etwas anderes versteht. Ich selbst halte mich vorwiegend an die 4 Grundwerte. Die schreiben beispielsweise nicht vor, dass Micromanagement vom Team durchgeführt werden muss. Und „klassisches Projektmanagement“ (mir fehlt leider ein besserer Begriff dafür) verbietet dies im übrigen auch nicht. 🙂
Ich will Stefan und Rainer in ihren Denkansätze freudig beipflichten – und für die tollen Impulse danken.
Ja, es geht um was Neues! Ich glaube mittlerweile Agil ist nur der Übergang zu dieser neuen Management Methodik. Was genau diese ist ist mir noch Unbekannt. Ich habe aber so eine Ahnung…
Adressieren wird die neue Methodik Komplexität, Unbekanntes, Unsicherheit, schnelle Veränderung und Dynamik und Selbstorganisation der Organisation !!!, …. Stärken wird sie intuitives und systemisches Handeln, kollektive Intelligenz, das Flow-Prinzip, Glück, Kreativität, Innovation, den bewußten Umgang mit Emotionen und Blockaden und Life Balance.
Management wird (wieder) lebendig(er).
Oder eben nicht. Irgendwo hab ich in den Kommentaren gelesen das die horizontale Organisationsebene in Unternehmen eben tayloristisch ist und bleibt nur die Vertikale variert. Das beschriebene Neue wird zu einer halben Sache (siehe Agile in der Praxis) und am Ende durchdringt wieder das Tayloristische die Organisation.
Die Zukunft ist Ungewiss. Noch….
…und bis dahin halte ich mich wie oben “vorgeschlagen” an Pipi Langstrumpf 😉
Tobias schlägt hier gerade eine Brücke in der Diskussion „Beyond Projektmanagement“. Spannend.
Wenn wir Agilität als ein Wertesystem auffassen, könnte dies hinter dem neuen Projektmanagement stehen, das wir eigentlich schon jetzt brauchen.
Ich würde im Sinne von Jurgen’s Ausarbeitungen zu „Management 3.0“ dann von einem „Projektmanagement 3.0“ sprechen. Damit können wir statt der Gegenüberstellung „klassisches Projektmanagement“ vs. „Agiles Projektmangement“ eine sauberere Abgrenzung von „Projektmanagement 2.0“, was zweifelsohne nicht rein tayloristisch ist (das wäre Projektmanagement 1.0), aber auch noch der Denkwelt von Taylor nachhängt, und „Projektmanagement 3.0“, das tayloristische Ansätze nur noch marginal betrachtet, definieren. Jetzt fehlt eigentlich nur noch die Definition, Tobias hat oben schon Vorschläge gemacht, welche Werte „Projektmanagement 3.0″verfolgen soll. Für mich würde mindestens das Agile Manifest darunter fallen: http://www.bluescrum.de/2014/09/21/was-ist-agilitaet/
So wie es aussieht hat lediglich Wolfram den Begriff „Projektmanagement 3.0″mal in einem Artikel angedeutet: http://speed4projects.net/downloads/veroeffentlichungen/industriell-und-agil-vereint/
Somit können wir diesen noch selbst besetzen. Dann mal los ;-).
Schöne Idee, Rainer. Ich finde zu Werten gehören auch immer Prinzipien. Damit klar werden kann was das für’s praktische Leben bedeutet. Offenheit ist ein schöner Wert aber was heißt das für meine Kommunikation & Zusammenarbeit, für meine Prozesse & meine Produktentwicklung? Ein schönes Beispiel für Werte und Prinzipien hab ich bei Spotify gesehen: https://labs.spotify.com/2013/03/20/agile-a-la-spotify/
Fürs „Management 3.0“ würde ich die Werte nicht (tayloristisch 😉 vor-definieren, sondern eher festschreiben, dass Werte zu definieren sind. Jeder kann dann selber für seinen Kontext, seine Organisation, sein Team und sein Projekt festlegen, was das heißt. Dazu können wir Anregungen geben und teilen was wir für uns erkannt haben. Sich da mal zu vergegenwärtigen finde ich eine schöne Anregung 😉