Nachtrag: Ich hoffe, es wird von Euch nicht als "Eigenwerbung" empfunden, dass ich die Verlinkungen zu den Blogbeiträgen eingefügt habe. 

Ich habe das Thema hier eingestellt, weil es mich seit einiger Zeit beschäftigt und weil mich interessiert, was Eure Meinung dazu ist.

Die Links auf Dein Blog sind absolut legitim und hilfreich als Hintergrundwissen. In gewisser Weise ist ja jede Arbeit im Web 2.0 Eigenwerbung oder hat jedenfalls werblichen Nebeneffekt. 

Lieber Stefan,

ich würde hier nicht so zwingend in eine detaillierte Begriffsklärung eintauchen. Ich frage mich schon länger, was den agile PMler unter klassichen Projektmanagement verstehen. Ich würde von mir behaupten, dass ich ein klassischer – mit der Zeit gehender/in der Zeit seiender – PMler „bin“.

In diesem Verständnis bedeutet Projektmanagement für mich

• Führung und Leitung von offenen und geschlossenen Projekten
• der Umgang mit Widersprüchen und Unterschieden und PM verfügt dazu
• über einen Methodenkoffer.

Agiles Projektmanagement öffnet – was ich bisher kenne – die Türen für einen professionellen Umgang mit Widersprüchen und Unterschieden, für das systemische Denken und das Denken darüber hinaus. Dass es dann manchmal in der Praxis etwas anders aussieht und die Hinwendung zur reinen Methodensicht erfolgt, tut der Grund“energie“ der Veränderung innerhalb des Projektmanagements aber keinen Abbruch.

Agil und Management sind nur scheinbar ausschließende Begriffe. Aber letztendlich sind sie das nicht. Im Gegenteil – ich möchte fast behaupten, dass dies sehr dienlich ist, um das sowohl-als-auch im Projektmanagement zu stärken.

Es ist momentan ein bisschen so, wie in einer reinen Projektorganisation. Die Tochter (agiles PM) entfernt sich von der Mutter („klassisches“ PM) und versucht sich selbst besser dar zustellen. Das ist wichtig – in der Entwicklung von etwas. Und das ist auch Zeichen unserer Zeit, was aber nicht heißt, dass wir uns mehr trennen sollten, sondern eher einfach mal das Ganze wohlwollend - aus der Sowohl-als-auch Haltung - zu beobachten, was da gerade vor sich geht. Und letztendlich können jene, die schon länger theoretisch und praktisch mit Projektmanagement verbunden sind, der „Tochter“ wertvolle Impulse geben, um nicht ähnliche Fehler zu wiederholen.

Insgesamt ist es doch heute nicht so einfach in der Rolle des Projektmanagers in einem Unternehmen zu agieren – in einer Zeit, wo soviele unterschiedliche Denkebenen tagtäglich zusammen arbeiten. Die Widersprüche zwischen Hierarchie und Projekt sind dabei nur ein Aspekt. Auch haben es doch jene Projektmanager, die ein Stück weit mehr den ganzheitlichen, integrativen, systemischen, spirituellen Ansatz verfolgen, selbst in ihren Reihen -  im klassischen und im agilen Projektmanagement nicht wirklich einfach.  

Lieber Stefan, hoffe mit meinen Überlegungen Dir dienlich zu sein.

Und ein kleiner Nachsatz: Eine offene und kluge Mutter lernt auch viel von der Tochter! Das ist wichtig zu erwähnen. Insofern vielen Dank für diese "Gespräche".

In Wikipedia heißt es zu Management unter anderem:

Zu den typischen Funktionen oder Aufgaben des Managements in Unternehmen und Organisationen gehört die Planung, Organisation,Führung und Kontrolle (im Sinne von Erfolgskontrolle).

Projektmanagement bedeutet also erst mal nur: Planung, Organisation, Führung und Erfolgskontrolle von Projekten.

Im klassischen (damit meine ich eher nach Wasserfall organisiertem) Projektmanagement gibt es einen Projektleiter, der diese Aufgaben üblicherweise in einer Person abdeckt.

Im agilen Projektmanagement (darunter verstehe ich das Management von Projekten auf Basis der Werte aus dem agilen Manifest) muss ebenso geplant, organisiert, geführt und der Erfolg kontrolliert werden. Das passiert nur anders als üblicherweise klassischen Projektmanagement und beispielsweise in Scrum werden Aufgaben des Projektmanagements von unterschiedlichen neuen Rollen (PO, SM, Team) übernommen. Scrum aber ist eigentlich keine Projektmanagement-Methode, sondern eine Methode für Softwareentwicklung.

Ich habe schon Situationen erlebt, in denen ein agiler Projektmanager zusätzlich zu SM, PO und Team einen großen Mehrwert gebracht hat (beispielsweise wenn ein Projekt die Anpassung und Einführung von mehreren Produkten mit jeweils eigenen Produktteams) bedeutet hat.

Nur weil Begriffe wie Projektmanagement, Management oder Führung durch die Historie "belastet" sind und einen bestimmten Stil oder eine bestimmtes Vorgehen vermuten lassen, ist der Begriff im Kern ja nicht falsch. Projekte zu managen und Mitarbeiter zu führen auf Basis agiler Werte - das ist für mich "agiles Projektmanagement" bzw. "agiles Management".

Hoffentlich konnte ich dir hiermit noch ein paar weitere Impulse geben.

Ach, spricht mir dieser Beitrag aus der Seele  Und ich dachte schon, ich wäre der Einzige, der vermeintlich noch "hinterm Mond lebt".

Hallo,

ich würde hier, bevor wir uns wieder im "wir haben uns alle lieb" verlieren, gerne ein bisschen aufrütteln ...

... für mich ist der wichtigste Satz von Stefan "Wir tauschen Meinungen und Standpunkte aus. Aber haben wir ausreichend hinterfragt, was HINTER den Begriffen steckt?" Ich denke ein klares NEIN - es ist zu einfach Meinungen zu vertreten anstatt stichfeste Begründungen und Verständnis zu liefern. Also ich möchte hier keine Meinung darstellen sondern den Versuch neue tieferliegende Aspekte aufzuzeigen.

... ich bin mit Stefan auch schon mal dran gewesen das "integrative Projektmanagement" zu beschreiben. "Systemisches Projektmanagement" ist aber fast noch besser und dann sind wir schon beim ersten Begriff "systemisch". Wenn ich über Systeme rede muss ich immer über Schnittstellen und die Systemeigenschaften sprechen. Wenn man bei den Systemeigenschaften einen Fehler macht dann fällt das Ganze Gedankengebäude in sich zusammen - daher würde ich hier den Fokus drauf legen. Also die interessante Frage ist - "Was sind Systemeigenschaften von Projekt und was von Agil?" Agil (das ist ja gar keine System) - da fehlt sogar noch der richtige Systembezeichner!

Ein Projekt ist gekennzeichnet durch zwei herausragende Systemeigenschaften - hohe Unsicherheiten bzgl. der Dauer einzelner Arbeitsschritte und hohe Kopplung der Arbeitsschritte. // Anm. an Stefan - deine Definition von Projekt ist nicht falsch aber ein Subset dieser hier // Diese Beschreibung der Systemeigenschaften von Projekten ist sehr selt so formuliert und Stammt von u.a. E.Goldratt.

Warum ist das so wichtig? Wenn ich hohe Streuungen habe und hohe Abhängigkeiten dann bin ich "gekniffen". Dann muss ich mir wirklich Gedanken machen und mit viel Hirnschmalz mir was überlegen, wie ich das in den Griff bekomme. Einfache vertauschen von Arbeitspaketen geht nicht und "it's done when it's done" auch nicht. Selbstorganisation ist auch keine Lösung - man kann ja nicht x-fach wieder anfangen. In so einem Fall mach echte Führung und Management echt Sinn. Das ist Projektmanagement! // Achtung: das ist kein Wasserfall. Auch das Projektmanagement hat sich weiter entwickelt. Im Projektmanagement gibt es genau so Itterationen, frühe Integration, Teamarbeit. Darüber hinaus braucht man aber um das in den Griff zu bekommen Netzpläne und Puffermanagement (s. auch Critical Chain) //

Und jetzt zu dem "Agile" das ist keine Systembezeichnung sondern ein Adjektiv - man ist agil (flink, schnell). Es ist aber gar kein System. Aber wann sprechen wir von "agilen Systemen" - das ist "Agil" ist nämlich die Benennung von sehr speziellen Systemeigenschaften. Agile ist man dann wenn man schnell und flink ist. Also schnell die Richtung wechseln kann, schnell auf etwas reagieren kann. Dazu braucht man viel kleine Aufgaben und wenig Aufgaben die gerade in Bearbeitung sind - sonst könnte man nicht agil sein. Agil ist man aber auch nur dann, wenn das Wissen im Team gut verteilt ist, wenn die Leute motiviert sind, wenn sie sich selbst organisieren können, wenn möglichst wenig von oben gesteuert wird u.s.w.

Aber wie heist jetzt das zugehörige Sytem zu diesen Eigenschaften? // und jetzt bitte nicht schlagen und mich in die falsche Ecke stellen // Diese obigen Eigenschaften sind sehr sehr characterisitsch für Produktion. Ganz oft spricht man bei agilen Teams auch von Produktteams - einfach wegen der starken Produktorientierung und Produktion ist das Erstellen von Produkten // Achtung: das hat nichts mit Taylorismus zu tun! Volvo hat war früher der Vorreiter der "teilautonomen Arbeitsgruppen" oooooops - das ist genau das was wir als agile Teams bezeichnen //

By the way - Produktionssteuerungen (z.B. Henry Ford/Fließband, Taichi Ohno/Kanban und E.Goldratt/Drum-Buffer-Rope) sind viel einfacher als Projektsteuerungen. Daher sind in unserem normalen Leben die Produktionssteuerungen in der Überzahl. Alles was wir als ToDo-Listen oder Taskboards kennen sind Produktionssteuerungen und das hat seinen Sinn - warum soll ich es kompliziert (Projekt) machen wenn es auch einfach geht. Es ist immer gut Energie zu sparen für den Spass im Leben!

Also wir reden hier von zwei ganz unterschiedlichen Sytemcharakteristika

a) Projekten - viele Abhängikeiten und große Streuungen und

b) Produktion - viele kleine relative unabhängige Aufgaben.

Und jetzt kommt's! Also der Begriff "agiles Projektmanagement" ist systemisch tatsächlich ungeschickt. Wer auf die Idee kommt mit agilen Methoden Projekte (wie z.B. die Mondlandung - denn das war der Ursprung des Projektmanagement, wenn man mal von den Pyramiden absieht) der wird Schiffbruch erleiden, weil er die Systemeigenschaften von Projekten ignoriert (man könnte Elbphilamonie und BER in diese Kategorier stecken - die Analyse hat nämlich ergeben dass zu das Anforderungsmanagement zu agil war).

Frei nach Covey und Goldratt - wo es einen Konflikt (und ein gemeinsames Ziel) muss es einen dritten Weg geben, der beide Bedürfnisse erfüllt - Win-Win und so.

Wenn man jetzt weiß wann welche Methoden einseztbar sind (s.o. Projekt und Produktion) dann kann man seine Inititiven (um Ziele zu erreichen) mal unter dem Aspekt anschauen wo welche Systemcharakteristika vorliegen und dann kommt man auf interessante Ideen (z.B. Systemisches Projektmanagement).

Ich nimm einfach mal eine supper duper Initiative (z.B. "Revolution im Handymarkt - iPhone").

Phase 1 - wir wissen nicht wie das Produkt aussehen soll! Wir wissen nur, dass es ganz anderst sein muss (viel einfacher)

• meines Erachtens ist das weder Projekt noch Produktion - sondern pure Kreativität
• viel Itteration, viel Ausprobieren, viel Wein trinken, über Tellerrand (und Tisch) hinaus schauen. Wieder ausprobieren - so lange bis man ein Gefühl hat "das ist es! Heureka!" ...
• Hände weg von Projektmanagement aber auch Hände weg von Sprints und Kanban-Boards ... mal mit TRIZ, Design-Thinking oder anderen Kreativitätsmethodem probieren

Phase 2 - Konzeption und Planung

• das ist nicht eindeutig - das kann Produktion sein (agil) bei hochinnovativen Vorhaben aber auch recht klassisch (bei bekannten Sachen wie Häusern - sind übrigends auch oft kreativ ... muss man im Einzelfall anschauen
• wenn klassisch - dann z.B. Critical Chain ... typisch Häuser, Anlagenbau, Automobilbau, Straßenbau ... hier wiederholt sich das Wort "bau"
• wenn hoch innovativ - dann z.B. Scrum mit kleinen Itterationen ... ich denke iPhone war eher hier

Phase 3 - Umsetzung das große Bild

• jetzt weiß man was zu tun ist - man hat typischerweise einen Idee wie man das Ziel ereichen kann - nennt man auch gerne Plan
• ein guter Plan parallelisiert und entkoppelt so viel wie möglich z.B. iPhone-Gehäuse, iPhone-Betriebssytem, iPhone Accu, ... // p.s. ich hab ein HTC One und bin super glücklich mit - aber iPhone waren halt die ersten und damit gebührt ihne die Ehre //
• aber auch parallel Stream muss man integrieren (damit entstehen Kopplungen) und auch parallele Streams haben Streuungen und Störungen
• und manchmal kann man nicht vollständig entkoppeln und hat damit zwischenintegrationen und die machen auch sinn früh und oft zu machen
• daher handelt man sich hier die Komplexität eines Projetes ein - also klar Projektmanagement

Phase 3 - Umsetzung das kleine Bild

• wenn man aber ein einzelnen Stream oder ein einzelnes Arbeitspaket anschaut kann es sein, dass man darin viele kleine Task findet, die wiederum wenig Abhängikeiten aufweisen ... mhhhhh - das riecht nach Produktion
• das gilt ganz oft für Sofwarestreams in großen Produktprojekten (coole Begriffkombi, die ich sehr mag) ... das ist meist die kritische Kette
• Produktion - ja klar hier kann wieder die agilen Methoden eingesetzt werden (Scrum - na bitte eher nicht ist zu langsam und zu starr, Kanban schon besser immer noch zu langsam oder Drum-Buffer-Rope schnell und flexibel)
• und klar bitte in möglichst stabilen Team um die ganze schöne Welt der Selbstorganisation mit zu nehmen

Phase 4 - Integration und Bugfixing

• egal wie oft man kontinuierlich integriert (ich bin ein große Fan von CI, Testautomation und CD). Irgendwann muss man es das letzte mal tun. Dann testet man zum ersten mal das vollintegrierte Produkt in seiner natürlichen Umwelt. Und dann tauchen hoffentlich noch kleinere Probleme auf und die muss man finden, beheben und gut.
• wenn auch nur wenige Problem - dann sind es kleine und sie sind hoffentlich unabhängig u.s.w. ... ganz klar das ist wieder Produktion!
• wir typischerweise mit einem Ticketsystem gemanaged - Ticketsysteme sind einfachste priogetriebene Produktionssteuerungen

Phase 5 - Roll-Out ...

• ist wieder Projekte - abarbeiten einer Taskliste - keine Reihenfolgenvertauschungen und Puffer am Ende ... aber sehr einfach

Was ich zeigen wollte ist - wenn man die Sytemeigenschaften kennt - hat man gewonnen. Dann weiß man wann welche Steuerung (besser Regelung) funktioniert und zum Einsatz kommen sollte. Dann kann man endlich die passenden Werkzeuge "integrieren" und man erhält "Systemisches Projektmanagement"

Feedback und Challanging willkommen - denn ich will hier keine Meinung vertreten sondern nur sachlich wissenschaftliche Ideen austauschen

cu Wolfram

p.s.: Systeme wechseln oft je man Komplexitätsebene ihre Sytsemeigenschaften ... d.h. man findet of Layer/Ebene in komplexen Systemen ... wenn man sich Projektmanagement anschaut kann man dies auch erkennen

unterste Ebene - Streams/Arbeitspakete/Teilprojekte - haben sehr of Produktionscharakter

mittlere Ebene - Projekte - klar Projektcharakter

obere Ebene - Multiprojektmanagement - viele Projekte, ein Engpass, kann man oft vertauschen ---- oh-oh wieder Produktion (Drum-Buffer-Rope)

...  der Charakter wechselt also von Ebene zu Ebene. Check-Frage: unter den Streams gibt es die µ-Ebene der Tasks - welche Systemeigenschaften sollten die wieder aufweisen? Ja klar - und tatsächlich es ist wieder so

... Das ist natürlich kein Beweiß dass alles richtig ist, was ich hier schreibe - aber es ist ein schöner Indikator, dass die Gedanken stimmig sind und zusammen passen. Und die Eleganz der Einfachheit ist nicht erst seit Steve Jobs bekannt und hoch geschätzt

Und jetzt der Werbeblock: Vieles davon findet sich in Buch "Tame the Flow", das ich mit Steve Tendon zusamen geschrieben habe. Es ist ein leanpub-Buch daher einfach herunterzuladen ... die ersten Leser sind so begeistert, dass sich in kürzester Zeit schon Übersetzer für 4 Sprachen gefunden haben

Sehr interessanter und tiefgründiger Beitrag. An einer kleinen Stelle möchte ich allerdings vehement widersprechen. Produktion besteht zwar aus (bei hoher Fertigungstiefe) vielen kleinen Aktivitäten. Allerdings sind diese nicht entkoppelt, sondern m.E. noch stärker verkoppelt wie Arbeitspakete im Projektmanagement. Wenn diese Verkopplung nicht existieren würde, gäbe den Grundgedanken des Flussprinzips nicht, ebenso wenig wie die resultierenden Methoden (Kanban & Co.). Wenn diese scheinbare Entkopplung in Produktionen festgestellt wird, geht das in der Regel mit Puffer, Zwischenlagern u.ä. und der daraus resultierenden Verschwendung einher.

Könnte natürlich sein, dass wir eine unterschiedliche Begriffsdefinition von Kopplung verwenden.

Danke für die ebenso tiefgründige Frage - auch die Kopplung ist immer eine Frage, auf welcher Ebene man sich befindet und welche Art von Kopplung man betrachtet. Für die Unterscheidung zwischen Projekt und Produktion gibt es zwei Arten und zwei Ebenen - sorry.

a) auf der Ebene der Erstellung eine Artefaktes (in Softwareentw. typ. ein Tasks) gibt es, wie von Ihnen beschrieben, eine harte inhaltiche Kopplung. Ich kann erst entwickeln, wenn ich min. im Kopf ein Konzept habe. Ich kann erst reviewen wenn ich etwas entwickelt habe u.s.w. - Projekt

b) auf der Ebene der Artefakte selbst (in Softwareentw. typ. Stories in einem Backlog) ist die Kopplung wesentlich weicher. Man kann, in gewissen Grenzen, die Stories umsortieren/priorisieren - lose Kopplung heißt hier ich kann die Stories ggf. vertauschen - Produktion

es gibt aber noch einen zweiten Aspekt/Art - die zeitliche Kopplung

#1 wenn das Ergebnis eines Vorgängertask möglichst direkt ohne Wartezeiten vom nachfolgenden Task verarbeitet wird ist das eine harte Kopplung. In solch einem Fall kann man nichts zwischenschieben, was die Flexibilität einschränkt - Projekt

#2 wenn das Ergebnis eines Vorgängertask mit großen Wartezeiten vom nachfolgenden Task verarbeitet wird ist das eine weiche Kopplung - Produktion

Bei der Zeitlichen Kopplung betrachtet man das Verhältnis zwischen Barbeitungszeit (Cycle Time) und Durchlaufzeit (Lead Time). Wenn das Verhältnis von Bearbeitungszeit zu Durchlaufzeit größer als 20% ist spricht man von Projektcharakter (ideal ist natürlich 100%). Wenn das Verhältnis kleiner als 10% ist von Produktionscharakter. Der Bereich dazwischen ist zu vermeiden - hier ist keine der beiden Steuerung wirklich gut.

Genau wie sie es auch sagen - sie können in der Produktion die Kopplung erhöhen und die Liegezeiten/Verschwendung reduzieren. Sie erkaufen sich das dann aber mit Inflexibilität in jeder Hinsicht und laden bei Henry Fords Fließband - keiner seiner Nachfolge hatte jemals so eine geringe Durchlaufzeit (man spricht von 2 Tagen vom Erz zu Auto). Aber auch bekannt er konnte alle Farben liefern - so lange es Schwarz war.

Also Projektgeschäft ist härter gekoppelt - daher typ. harte inhaltliche Kopplung (keine Vertauschmöglichkeit) und hoher Anteil Bearbeitungszeit zu Durchlaufzeit.

Agile Methoden (Produktion) sind weicher gekoppelt - daher die Möglichkeit Stories zu vertauschen und geringerer Anteil Bearbeitungszeit zu Durchlaufzeit! Durch die so gewonnene Flexibilität kann die Steuerung einfacher werden - man kann durch Vertauschungen praktisch jeden Termin für eine Storie wieder holen - genutzt wird Mechanismums b und #2.

Das führt übrigends zu meinem Nachdenkepunkt für agilen Methoden - sie sind einfach deutlich langsamer als gut geführte Projekte! Wenn man genau hinschaut liegen Stories im Mittel oft sehr lange herum - erst im Backlog, dann in den Sprints oder durch WIP-Limits ausgebremst. Ganz oft ist auch die Teamgröße/Velocity begrenzt, was die Liegezeit im Backlog weiter erhöht.

Das ist erst mal keine Kritik - wenn ich mich dafür entscheide die Vorteile (Einfachheit) einer Produktionssteuerung (Scrum, Kanban, Drum-Buffer-Rope) zu nutzen - dann muss ich halt auch den Seiteneffekt Verhältnis Bearbeitungszeit zu Liegezeit ist klein akzeptieren.

p.s.: die Ideen entstammen der Theory of Constraints - "Standing on the Shoulders of Giants" Goldratt, 2008 oder "Drum Buffer Rope and Buffer Management in a Make-to-Stock Environment" Eli Schragenheim and Rudi Burkhard, 2007

p.p.s.: David Anderson und Eli Schragenheim kennen sich - Eli hat das Vorwort zu einem der bemerkenswertesten Bücher von David geschrieben "Agile Management" 2004. Seit 2004 ist die Zeit aber weiter gelaufen. Die DBR (Drum-Buffer-Rope) hat sich als das leistungfähigere Konzept (wenn auch nicht das einfachere) herausgestellt ...

Je mehr ich über "AGILES Vorgehen und Handeln" nach denke, desto mehr glaube ich, dass es sich hierbei um ein Grundprinzip handelt, das die "alte Welt" von der "neuen Welt" unterscheidet.

"AGIL" könnte so die Fortsetzung von "Aufklärung" und "Benutzens seines Verstandes" sein, die sich immer im Spagat zwischen Individualität (was will ich, was kann ich, was darf ich ...) und Kollektivität (was wollen wir, was können wir, was dürfen wir ...) bewegen.

"AGIL" könnte auch den Willen bezeichnen, unser Leben in Freiheit zu führen - was an dieser Stelle bedeutet "willens und in der Lage sein, unser Leben in eigener Verantwortung zu führen" und dem Handlungsprinzip zu folgen "eigenes und fremdes Leben eher zu mehren als zu reduzieren".

"AGIL" ist auch die Kunst der Veränderung. Die wir brauchen und für die wir unsere Erkenntnisse mehren und diese dann auch anwenden können müssen. Dazu brauchen wir als Ergebnis unserer Arbeit selbstredend Modelle und Ansätze, Methoden und Vorgehensweisen ...

Um "AGIL" zu werden, müssen wir bereit sein immer Neues zu lernen, ungewohnte Dinge zu machen, Fremdes auszuprobieren und Erfahrungen zu sammeln. Wir müssen verstehen und begreifen, wie die Prozesse in unseren sozialen Systemen funktionieren. Das "integrative und systemische Verständnis" unserer Unternehmen wird so zur Voraussetzung fürs Gelingen von "Führung".

Soweit in aller Kürze ...

Die Diskussion um die verschiedenen Ansätze Agil, Klassisch, etc. ist mir viel zu dogmatisch. Es ist doch so, dass ursprünglich für ganz spezifische Anwendungsfälle bestimme Methodenbausteine zu einem für das Problem gut funktionierenden System zusammengefügt wurden. Dem Ganzen hat man dann einen Namen gegeben z.B. Agil. Dann gibt es viele Menschen, die diese Systeme auch auf andere Anwendungsfälle übertragen wollen, weil sie glauben das sei der Weisheit letzter Schluß und wollen zudem damit ggf. auch Geld verdienen. So entsteht der nächste Hipe.

Ich betrachte liber die einzelnen Methodenbausteien, egal aus welcher Strömung sie kommen, und setze sie so zusammen,dass sie auf meinen spezifischen Anwendungsfall und das Umfeld optimal passen. Als muss ich nicht über die Überschrift diskutieren.

Schließlich ist die Welt schon kompliziert genug!

Was für mich das agile PM vom klassischen PM unterscheidet, ist, daß es den Mensch und nicht den/die Prozesse in den Mittelpunkt stellt. Klingt abgedroschen, ist aber aus meiner Erfahrung heraus das "Geheimnis" des Erfolges von agilen Ansätzen. Plötzlich kann ich aktiv werden und bin nicht mehr der passiven Kaste der Ausführenden zugeordnet. Wenn das nicht motivierend ist?!

Mich stört auch die dogmatische Diskussion und teilweise Haltung die von Srumern eingenommen wird. Dabei wird gerne vergessen, dass die Projektwelt nicht ausschließlich aus IT und dort nicht ausschließlich aus Softwareentwicklung besteht. Das ist der kleine Teil der Welt.

Da möchte ich jetzt widersprechen. Der Mensch im Mittelpunkt ist m.E. "nur" der Unterschied zwischen guten und schlechtem PM. Das Gleiche gilt auch für die Prozesse. Wenn man Prozesse auf einer Meta-Ebene betrachtet, sind sie bei agilem PM sogar noch wichtiger. Prozess und Mensch ist grundsätzlich kein Widerspruch. Die Referenz zu dieser Aussage ist bspw. das Toyota Production System und die Grundphilosophie von Toyota: "Wir bauen keine Autos. Wir entwickeln Menschen, die Autos bauen."

Der Mensch im Mittelpunkt ist m.E. "nur" der Unterschied zwischen guten und schlechtem PM.

Sehr schön. Dem kann ich mich nur anschließen: eine Frage der Haltung und des Menschenbilds (s. meinen Artikel http://fuehrung-erfahren.de/2013/07/modernes-projektmanagement-eine-frage-der-haltung/)

Das sind doch theoretische Aussagen.

Wie oft werden Prozesse durchgeführt bzw. zu Ende gebracht "nur" weil es sie gibt? Wie oft werden Prozesse instrumentalisiert? Wer stellt Prozesse mit welchem Ergebnis in Frage?

Wenn die Projektwelt so heile ist, wieso dann der agile Aufruhr?

Weil sich jeder hinter (vermeintlich nicht funktionierenden) PM-"Prozessen" verstecken kann (also eine Ausrede hat a la "das Vorgehensmodell taugt nix) ? anstatt mal den gesunden Menschenverstand zu gebrauchen ?

Der Stefan schafft's doch immer wieder !

Er wirft ein Thema irgendwo hin, die Welt streitet sich darüber, er konsumiert die Inhalte des Streits und macht was draus. Währenddessen gehen die meisten Streitenden (Erzeuger dieser Inhalte) mit ihrer gestärkten/ geschwächten Überzeugung allerdings ohne Erkenntnisgewinn und ohne Hoffnung auf Eingiung - dazu sind die Positionen schlicht zu abstrakt oder vermeindlich weit voneinander entfernt - wieder auseinander und machen nichts draus.

Ich liebe so etwas und lächle über mich selbst, wie auch ich - gänzlich offene Quelle - erneut dazu beitrage ...

Irgendwo im Text habe ich gelesen, dass agil gar kein System ist. Das blieb hängen und mir kam folgender Gedanke:

"Vor 50 Jahren war die Welt aus Sicht der meisten Menschen noch sehr linear, normal und übersichtlich. Inzwischen ist sie mehr irregulär, abnormal und unübersichtlich. Vor 50 Jahren versuchten wir die selbe generelle Aufgabe zu erfüllen wie heute: Wir wollen in dieser Welt gut überleben. Vielleicht ist der größte Unterschied zwischen agil und klassisch, dass einige von uns glauben, mit agil würde man besser über-leben, während andere vertreten, dass dies mit klassisch eher gelingt. Stefan - von beidem angezogen - postuliert überzeugt: "Die gesunde Mischung machts!"
Freilich ohne sie zu kennen - sonst würde er ja nicht immer wieder uns andere um Rat fragen."

Was hilft? Wer weiß - vielleicht sagen uns dazu irgendwann einmal unsere Kinder etwas ?

Bis dahin, ein gutes klassisch agil gemanagtes (oder vielleicht besser ungemanagtes?) Weiterleben.

Hallo,

vielen Dank für das Originalposting.

Hätte man kein lateinisches Wort benutzt sondern ein Deutsches, so wäre klar, wie dumm die Begriffswahl war. Ich würde es völlig verstehen, wenn es bei mir Abmahnungen hageln würde, hätte ich meine Firma: "Richtiges Projektmanagement KG" genannt.

Es ist zwar so, dass mein Projektmanagement viel richtiger ist als Eueres und ich bin auch viel fleissiger als Ihr es seid....

Ich glaube, Ihr habt verstanden, was ich meine: Wer sagen muss, dass er fleissig ist, ist es sicherlich nicht. Derjenige, der richtiges Projektmanagement verkündet, weiss einfach nicht, was das ist.

Als alter Softwareentwickler kenne ich die gängigen Methoden und Vorgehensweisen, wie auch den Rational Unified Process. Wenn ich in der Rolle Projektmanager für Software-Entwicklung bin, verwende ich diesen Prozess gerne und gestalte die Iterationen entsprechend sinnvoll. Bei SCRUM wird das vorgegeben. Was soll der Quatsch? Was kommt heraus? Schnell irgendwie zusammengeschusterte Objektbibliotheken und eine Methodenauswahl, die man hätte sorgfältiger gestallten können.

Also übersetze ich das Wort agil seither mit sinnloser Hudelei und Schlampigkeit.

Aber danke, dass ich es auch mal sagen durfte!

Grüße

Michael

Gebhard, mein Lieblings-Kommentator! 

Du hast Recht: Der Austausch über neue Medien ist für mich mittlerweile einer der wichtigsten Lernimpulse überhaupt. Ich hoffe allerdings, die Impulse nicht nur "abzusaugen", sondern auch wieder etwas zurück zu geben.

Dass daraus kein Erkenntnisgewinn resultiert, sehe ich anders. Natürlich wird dies jede/r für sich zu beurteilen haben. Ich für mich kann sagen: Ich ziehe sehr wohl Erkenntnisse aus den ganzen Diskussionen.

Was den Inhalt der Diskussion betrifft, ist mein Eindruck, dass wir über einen schriftlichen Austausch keine abschließenden Antworten finden werden. Das Thema ist einfach zu vielfältig. Jede/r hier (inkl. ich selbst) versucht zu begründen, warum sein/ihr kognitives Modell der Welt das richtige ist. Schlussendlich scheitern wir dann aber immer wieder an unterschiedlichen Zugängen, Begriffsverständnissen und manifesten Glaubenssätzen.

Gebhard Borck: Vielleicht sollten wir den Ludwigsburger Kreis wieder mal einberufen? 

Stefan Hagen - soweit ich es mit verfolge, haben die PM-Camps rundweg einen positiven und guten Zuspruch. Warum sollten wir unsere Zeit in ein schnell wieder verstorbenes Format investieren, wenn derart erfolgreiche Formate bestehen?

Gebhard Borck: Wenn Du zum PM Camp im November kommst, ist ja alles geritzt!  Andernfalls wäre der Berg zum Propheten gegangen...

@Gebhard Borck: @StefanHagen

Hi - ich würde mich auch sehr freuen, wenn ich den Gebhard im November dann persönlich auf PMCamp13 persönlich kennen lernen würde!

Stefan Hagen: Ich bin noch nicht entschieden ! Allerdings bin ich auch nicht so wichtig, dass ohne mich wirklich etwas fehlen würde. Wie lautet der Großgruppenmoderationsspruch: Die die da sind, sind die Richtigen.

Roland Dürre Vielen Dank fürs Interesse, doch das muss ja nicht auf einem PMCamp sein  ... oder?

Hi Gebhard, natürlich nicht. Bei mir ist die Zeit (mein wertvollstes Gut  ) zurzeit ein wenig knapp. Bist Du mal in München? Meine E-Mail ist übrigens roland@duerre.de .