Moin,

Ich bin nicht ein Feind von "Agil"... aber es ist kein Allheilmittel. Immerhin sind nur eine Minderheit der Projekte "Softwareentwicklung". Ich stelle gerne mal die Frage:

"Würden Sie Ihr Haus agil bauen lassen?"

Hier ein Text aus dem Netz zu dem Thema:

___________________________________________________________

Hausbau wie Softwareentwicklung

Das Projekt ist der Bau eines Einfamilienhauses mit zwei Stockwerken und Keller mit einer Grundfläche von 100 Quadratmetern. Als Baumaterial werden Ziegelsteine verwendet. Der Architekt kalkuliert wie folgt: Das letzte Bauvorhaben (eine Doppelgarage) hatte eine Grundfläche von 25 Quadratmetern. Verbraucht wurden 1000 Ziegel. Die Baukosten betrugen 10000 €uro, was einen Preis von zehn €uro pro Ziegel bedeutet. Das neue Haus hat die vierfache Grundfläche und die doppelte Höhe - dies bedeutet 8000 Ziegel oder 80000 €uro Baukosten.

Das Angebot von 80000 €uro erhält den Zuschlag, und der Bau beginnt. Da die Maurerkolonne ausgelastet sein will, wird beschlossen, immer nur ein Zimmer zu konstruieren und gleich anschließend zu bauen. Das hat den Vorteil, dass die Planungs- und die Ausführungsgruppe immer ausgelastet sind. Weiter wird beschlossen, mit den einfachsten Sachen anzufangen, um möglichst schnell in die Bauphase einsteigen zu können. Das Schlafzimmer scheint dafür am besten geeignet zu sein.

Das Schlafzimmer wird zu schnell fertig und die Planungen für die Küche müssen unterbrochen werden. Da im Zusammenhang mit der Küche bereits am Esszimmer geplant wurde (Durchreiche zur Küche), wird dieses, um die Bauarbeiten fortführen zu können, als nächstes in Angriff genommen. Schritt drei in der Fertigstellung ist das Wohnzimmer. Als auch dieses fertig ist, stellt sich heraus, dass die Planungen für Küche und Bäder doch mehr Zeit in Anspruch nehmen, als geschätzt. Da der Bauherr auch "endlich" mal was Konkretes sehen will, wird eine Seite der Fassade komplett hochgezogen, um den Eindruck des fertigen Hauses zu vermitteln. Um das Dach montieren zu können, wird die andere Seite der Fassade ebenfalls hoch gemauert. Da hier noch keine Planung vorliegt, können leider keine Fenster- und Türöffnungen berücksichtigt werden. Man ist aber überzeugt davon, diese ohne größere Probleme später herausbrechen zu können.

Leider ist damit auch die Grundfläche des Hauses festgelegt. Damit ergibt sich der Zwang, die Küche in den ersten Stock verlegen zu müssen. Statt der geplanten Durchreiche wird nun ein Speiseaufzug eingebaut, was das Projekt erheblich verteuert. Dadurch haben sich trotz beständigen Arbeitens unter Hochdruck die Bauarbeiten verzögert, so dass der Hausherr (der seine alte Wohnung gekündigt hatte) gezwungen ist, in das erst halbfertige Haus einzuziehen. Als besonders nachteilig erweist sich das Fehlen von Elektro- und Sanitäranschlüssen. Letzteres Problem wird durch Anmieten eines Toilettenwagens (Kosten 170 €uro pro Tag) vorläufig endgültig überbrückt.

Alle anderen Arbeiten werden gestoppt, um vorrangig die Elektroinstallation vorzunehmen, schon allein wegen der fehlenden Fenster. Mit Hilfe externer Kräfte (1500 €uro pro Tag) wird die Elektronik in kürzester Zeit verlegt, allerdings auf Putz, um "saubere Schnittstellen" für die noch nicht geplanten Hausteile zu schaffen. Im Alltagsbereich stellt sich als nachteilig heraus, dass das Wohnzimmer als zuerst gebauter Hausteil als einziges Zimmer zur Straße hin liegt. Damals war dies die einfachste Lösung (kurzer Transportweg der Ziegelsteine), die Haustür hierhin zu legen, so dass das Haus vom Wohnzimmer her betreten werden muss.

Dies erscheint dem Hausherrn ganz und gar unerträglich; als Lösung wird ein Teilabriss erwogen. Dagegen spricht, dass bereits 250000 €uro verbaut sind und dass der Bauherr samt Familie übergangsweise in ein Hotel ziehen müsste. Die Tür nach hinten zu versetzen, erforderte ein Loch in die Fassade zu brechen. Im Hinblick auf die unsichere Statik wird davon Abstand genommen. So wird das Haus bis zum ersten Stock von außen mit Erde aufgeschüttet. Das ursprünglich geplante Badezimmer wird zum Flur umfunktioniert - die Toilettenwagen-Lösung hat sich inzwischen etabliert.

Weiterer Vorteil: auf den Fensterdurchbruch im ehemaligen Erdgeschoss kann verzichtet werden.

Das Erdgeschoss wird zum Keller, der Dachgarten als Wohnzimmer umgebaut und aus Kostengründen (und um eine endgültige Lösung nicht von vornherein zu verbauen) mit Planen abgedeckt. Kostengründe sind es auch, die das Projekt an dieser Stelle beenden. Alles weitere wird auf eine spätere Realisierungsphase verschoben.

Fazit: Der Bauherr hat zwar etwas ganz anderes bekommen, als er eigentlich wollte - aber immerhin hat er überhaupt etwas bekommen, auch wenn er statt der geplanten 80000 €uro nun immerhin ganze 440000 €uro hingelegt hat. Der Architekt hat seine Truppe ständig ausgelastet und mit Hochdruck und Überstunden gearbeitet. Wie vorgesehen, wurden 8000 Ziegelsteine verbraucht, was beweist, dass seine Schätzung im Prinzip richtig war. Seine aktualisierte "Cost-Database" weist nun einen Preis von 55 €uro pro Ziegel aus, was bei der nächsten Garage einen Angebotspreis von 55000 €uro ergibt.

________________________________________________________________________

Ich gebe ja zu. dass es sehr deutlich Ironie ist. Aber spätestens bei dem Satz "wird die Elektronik in kürzester Zeit verlegt, allerdings auf Putz, um "saubere Schnittstellen" für die noch nicht geplanten Hausteile zu schaffen." wurde mir klar, dass es so realitätsfremd nicht ist .

Ich hoffe, Ihr versteht Spaß!

Jens

Mal abgesehen von der netten Polemik kann ich nicht ein einziges agiles Prinzip in dem Text entdecken. Allerdings beschreibt er viele Ergebnisse, die man bei klassischen Vorgehen beobachtet, beispielsweise Fehler in der Kommunikation.

Die agilen Teams, hätten sich beim Hausbau über Scrum of Scrums so abgestimmt, daß diese Ergebnisse hätten gar nicht entstehen können. Die Teams hätten in den ersten Sprints die Architektur definiert, die Rahmenparameter zum Arbeiten geschaffen und der Chief Product Owner hätte den Product Backlog so organisiert und priorisiert, daß alles in der "richtigen" Reihenfolge abgearbeitet worden wäre. Einzig die Entscheidungen im Detail hätten die einzelnen Teams selber getroffen. Dabei hätten sie in den Daily Scrums Impediments rechtzeitig erkannt und der Scrum Master hätte für deren zügige Beseitigung gesorgt. Es wäre niemals dazu gekommen, daß die Elektrik auf Putz verlegt worden wäre.

Übrigens: "Elektronik auf Putz" disqualifiziert den Text endgültig. 

Ich schon wieder

Mich würde mal interessieren was das Bauamt und die Bank sagen würde, wenn Du Dein Haus nach Scrum bauen willst . Ich denke, beide Seiten sind nicht erfreut 

Es gibt eben Aufgaben, die lassen sich nicht agil bewältigen, und es gibt Aufgaben, die funktionieren am besten Agil.

Btw: Ich rede jeden Tag mit dem Team, das Team redet jeden Tag untereinander. Ich brauche kein Scrum, um tägliche Treffen im Team herbei zu führen. Warum auch: Gemeinsames Frühstück bringt viel Zusammenhalt und Kommunikation ins Team.

Wie schon mal gesagt: Es geht darum einen offenen Blick zu haben und sich nicht einzuengen auf "die eine richtige Vorgehensweise"!

Die gibt es nicht! Wie es auch den "einen wahren Glauben" nicht geben kann.

Ich will das nicht weiter vertiefen. Probier es einfach mal aus und dann reden wir noch mal über die Erfahrungen.

Moin Rainer,

Ich habe es nicht ausprobiert... ich habe es angewendet. Und es ist kein Problem, wenn die Umgebung, das team und die Aufgabe passt. Aber dies ist eben nicht immer gegeben.

Ich wiederhole es gebetsmühlenartig:

Es geht darum einen offenen Blick zu haben und sich nicht einzuengen auf "die eine richtige Vorgehensweise"!

Warum sollte ich mich einschränken?

Die Wiederholung macht es leider nicht wahrhaftiger. Agiles Vorgehen funktioniert besser, ich muß mich da nicht einengen. Vielmehr beobachte ich zunehmend, daß sich klassisch aufgestellte Projektmanager an den agilen Themen versuchen, scheitern, und dann erzählen es funktioniert nicht - oder es hänge von der Situation ab.

ich bring hier jetzt einfach mal Critical Chain als "agiles" Projektmanagement ins Spiel - damit alle was zum über den Tellerrand schauen haben

Ich hab mittlerweile ein paar Projekte auf dem Buckel und behaupte einfach mal ein paar Sachen. Ich werde in den nächsten Tage hier auch noch einiges an Artikeln abliefern.

zum Thema Agil:

• Agil wird oft mit Scrum verwechselt - Scrum ist eine Produktionssteuerung der 1. Generation - funktioniert weil WIP sauber unter Kontrolle - daher die tollen Erfolge - unbestritten!
• Kanban ist der nächste Schritt und eine Produktionssteuerung der 2. Generation - funktioniert oft noch besser als Scrum - weil noch einfacher und robuster
• Es gibt aber schon Produktionssteuerungen der 3. Generation! Das sind die Drum-Buffer-Rope Steuerungen. Noch flexibler noch weniger Bestand und noch schneller - aber ein bisschen anspruchsvoller. Aber dazu hier sicher noch mehr.
• Alle drei oben genannten Steuerung sind "PRODUKTIONS"-Steuerungen (im Kern) und damit nur geeignet, wenn man die Aufgabe vor der man steht in viele unabhängige kleine Teile zerlegen kann und wenn man man in Kauf nimmt, dass die Teile oft lange rumliegen (z.B. in Backlogs)
• Produktionssteuerungen sind vom Wesen her agil - dafür muss man halt alles klein hacken und damit ist ihr Einsatzbereich begrenzt (z.B. Häuser bauen funktioniert agil halt nicht - vieles andere auch nicht ...)

Immer dann wenn man nicht kleinhacken kann und viele Abhängigkeiten hat und eigentlich, damit es schnell geht, nichts rumliegen lassen kann - sondern immer arbeiten muss - dann ist man eigentlich erst in der PROJEKT-Welt (und um die geht es hier doch?). Man kann die agilen Frameworks auf Projekte nicht einfach übertragen (man muss ein bisschen tiefer schürfen).

• aber klassisches Projektmanagement mit der ganzen Detailplanung und Methoden und Prozessen u.s.w. ist tot (mausetot). Das funktioniert nur selten. Gerade im Multiprojektmanagement wird der Work-In-Progress nicht richtig begrenzt. Und das Ganze Thema Schätzungen ist komplett daneben und sachlich falsch angegangen worden. Mehr Details und Disziplin helfen da aber gar nix (In 10 Jahren werden das auch PMI und GPM verdaut haben Ich bin PMP und GPM-Mitglied daher darf ich das schreiben)
• um das obige zu lösen wurde 1997 Critical Chain erfunden. Da muss man sich reindenken - bricht mit vielen Traditionen (passt daher gut zu OpenPM). Es gibt viele Unternhemen (>2000 weltweit) die die Umstellung schon gemacht haben - und auch hier fließt es plötzlich und es wird agil und flexibel u.s.w.

So und jetzt kommts. Wenn man es geschickt anstellt, kann man beide Welten perfekt miteinander verknüpfen. Jeder gute Projektmanager macht das in irgend einer Form und Umfang schon. Hier nur ein grober Blueprint:

• damit man mit Scrum was im Projektmanagement anfangen kann muss es zuverlässig werden. Dazu muss man Sprints zu Releases zusammen fassen können (ist schon bekannt) und dieses Release mit einem Puffer absichern > reliable Scrum
• damit Projektmanagement funktioniert sollte man den WIP unter Kontrolle bringen und auch mit Puffern arbeiten > Critical Chain
• damit kann man in größeren Projekten einfach Projektmanagement mit Scrum kombinieren z.B. die Konzeptionsphase nach Critical Chain oder Teilprojekte mit reliable Scrum und andere mit Critical Chain
• aber hat sich schon mal jemand gewundert was kurz vor Schluss in jedem großen Projekt passiert? Das ist die Integrationsphase - wo alle Teilprojekte zusammen kommen! Da tauchen Bugs/Fehler/Probleme auf die gar nicht planbar sind. Diese sind of klein (muss man gar nicht mehr kleinhacken) und liegen rum (es vergeht immer Zeit zwischen erkennen, beheben, retest und neu integrieren) > das ist echte Produktion und damit prädesteniert für Kanban oder DBR

Ich behaupte einfach mal frech - die Zukunft im Projektmanagement (3.0) besteht darin, dass alle drei Steuerungen (Scrum/reliable Scrum, Critical Chain und Kanban/DBR) in etwas größeren Projekten je nach Projektphase und Teilprojekt zum einsatz kommen.

Und dann können Jens und Rainer zusammen einen Wein/Bier trinken - denn beide haben Recht. Und ich komme gerne dazu und lass mich einladen

Moin Wolfram,

Du hast mich verstanden

Ich denke, dass die 3. Generation auch wieder für bestimmte Elemente wieder Teile des "klassischen PM" mit integrieren wird. Was Du schreibst (aber klassisches Projektmanagement mit der ganzen Detailplanung und Methoden und Prozessen u.s.w. ist tot (mausetot).) ist korrekt, wenn man es so einsetzt wie oft behauptet. Aber das wäre ein dummer PM der das so täte. Das wäre, als wenn man ein Buch über Auto liest und meint, nur weil man verstanden hat, wie ein Motor arbeitet, könne man ein Auto heile durch den Londoner Verkehr in der Rush-Hour steuern.

Das Scheiterm der klassischen Methode sehe ich vor allem in ihrer Nicht-Anwendung begründet. Mir sind nur 3 PMs in meiner Laufbahn begegnet die in der IT PM beherrschten und einsetzten. Dass dann aber mit Erfolg... starkem Tailoring und gesundem Menschenverstand.

PMI und GPM habe ich schon lange wegverdaut... was meint: Sinnvolles aufgenommen und den Rest ausgeschieden

Ich käme nicht auf die Idee irgendeiner PM Methodik nach Lehrbuch einzusetzen. Gottseidank!

Und ich kann mit jedem ein Bierchen trinken ... sogar mit orthodoxen Scrummern

Also nach kurzer Lektüre des Beispiels von Jens bin ich doch sehr froh, dass wir im "richtigen" Bauwesen nicht einfach so drauf los bauen, sondern vorher doch gründlich überlegen und planen 

Ich bin in den letzten Wochen jedoch zum Schluss gekommen, dass die Planung von Bauprojekten (zumindest im Hochbau) eigentlich ein agiler und vor allem iterativer Prozess ist und es vermutlich immer schon war. Es geht nur bedeutend langsamer voran, als z.B. bei SCRUM. Nur wusste das bisher noch keiner ...

Damit's hier nicht so langweilig wird  : http://borisgloger.com/2012/04/16/scrum-baut-keine-fertighauser/

Aber der Herr macht ja einen Fehler... er denkt, dass nur Scrum über Inkremente ausliefert. Das stimmt ja gottseidank nicht. Ich hatte Projekte, wo wir uns über Mockups und Prototypen und dann Release für Release an das letztliche Produkt rangearbeitet haben. Und das mit PM Methoden.

Das Haus-Projekt hat ja immer das Problem, dass Statik und Bau-Gesetze beachtet müssen... und der Geldbeutel des Bauherren. Nicht jeder Bauherr kann es sich leisten, dass sein Projekt 200% teurer wird (wie Stuttgart21, was ja nun wirklich kein PM ist) sondern oft muss der Bauherr zur Darlehnsgenehmigung vorweisen können, was er mit dem Geld anfangen will.

Dieses Problem hat ja an sich jeder Sponsor.

Und: Das Beispiel des Flughafens zieht auch nicht, weil es hier nicht um einen Test im Sinne der QS handelt, sondern um Change Management und "Produktionseinschwingung" (Ich liuebe diese Wort!!! Es ist schön Deutsch! )

Netter Artikel...musste schmunzeln. ABER. was an diesem chaotischen Vorgehen ist "agil" ? Sowas habe ich schon bei Softwareentwicklungsprojekten erlebt. Ich denke chaotsiches Vorgehen ist nicht auf ein bestimmtes Vorgehensmodell beschränkt....

Irgenwann habe ich mal gelernt, dass das Projektvorgehen sowas wie der "Bauplan" sei, und deswegen immer für das jeweilige Projetk NEU erstellt wird (was nicht heißt, dass man auf Erfahrungen verzichtet).

Zitat: (z.B. Häuser bauen funktioniert agil halt nicht - vieles andere auch nicht ...)

Hierzu zwei Fragen:

a) verstehen sie unter agil = iterativ-inkrementell ?

b) Wo ziehen Sie die Grenze zw. agil und iterativ-inkrementell vs. chaotischem weil falsches Vorgehen?

Ich behaupte mal folgendes: Ein Hausbau (und vor allem die Renovierung eines alten Hauses) erfolgt sehr wohl agil. http://www.kubitz.net/projekte/agiles-projektmanagement-definition/

Aus dem Link zum Blogeintrag von Boris Gloger (von Reiner Eschen unten) gefällt mir besonders der Satz " Ganz im Gegenteil, sie reagieren bestmöglich auf alle diese neuen, veränderten Anforderungen."

Wie wahr: Wer schon mal ein altes Haus aus den Nachkriegsjahren kernsaniert hat kennt das. Da wird jeder noch so gute Plan kurzerhand zur Makulatur. Dann heißt es: Was geht mit wieviel Aufwand und was kostet es? Und deswegen muss man agil (= beweglich) bleiben.

Hallo Wolfram,

super Beitrag! Eine Frage: David Anderson nennt Drum-Buffer-Rope als ein Ergebnis aus der Engpasstheorie, er ist m.E. der Ansicht, dass Kanban leisten kann, was Drum-Buffer-Rope leisten kann. Wie kommt es zu der Einschätzung, Kanban sei 2. Generation und Drum-Buffer-Rope 3. Generation? (Wobei ich vom heutigen Kanban in der IT rede, nicht vom TPS) Kannst Du da eine Info bzw. Einordnung geben? Danke Dir - S.

Danke - und Vorweg ich hab letzte Woche gerade einen Freund getroffen dem sein Unternehmen gerade von David Anderson beraten wird und er hat mir gezeigt was Anderson da macht und du hast es schon leicht angedeudet. Anderson macht kein striktes Kanban wie aus dem TPS sondern er nutzt die Gedanken der Theory-of-Constraints und Drum-Buffer-Rope um das Kanban optimal einzustellen.

Auf meiner Website: http://www.speed4projects.net/know-how/forschung/drum-buffer-rope/ findet sich eine Beschreibug und Vergleich wo jetzt letzt endlich die Unterschiede noch sind. Ich versuche es hier ganz kurz.

Kanban (auch das von Anderson) regelt den Fluß über den Bestand der Arbeit vor jeder Arbeitsstation. Wenn man vier Stufen hat gibt es in jeder "in progress" und "done". Diese "done"-Haufen sind nichts anderes als Puffer, die den Fluss sicher stellen. Ein Puffer stabilisiert den Fluss hat aber den Nachteil dass er die Lead-Time (Durchlaufzeit) verlängert. >> Bestandregelungen über Puffer und Pufferhöhen (letzt endlich halbfertige Teile) nennt man 2. Generation.

Drum-Buffer-Rope geht davon aus, dass es in der Kette von Arbeitsstationen immer eine geben muss, die den Engpass bildet. Je es ist immer eine und genau eine und diese bestimmt den Durchsatz. Der Durchsatz ist dann optimal, wenn diese Station so gut wie möglich ausgelastet wird (darf nie leerlaufen). Um das sicher zu stellen braucht man vor dieser Station einen Puffer. Wenn upstream ein Störung vorkommt wird der Puffer angegrifen und später wieder, durch die vorhandene Kapazitäten wieder aufgefüllt. Downstream braucht man keinen Puffer hier kann ja alles einfach abfliesen - Störungen fallen nicht auf >> Drum-Buffer-Rope hat nicht vor jeder Station einen Puffer sondern nur noch vor dem Engpass. Dadurch gehen die Bestände (an halbfertigem Zeug) runter und die Durchlaufzeit steigt.

Soweit so gut - die 3. Generation kommt aber durch die operative Steuerung der Stories/Arbeitspakete mit einer Zeitsteuerung. Es gilt die Frage zu klären #1 Wann darf ich neue Arbeitspakete starten und #2 welches der Arbeitspakete hat Vorrang (Prio). Um die zu beantworten geht man weg von Beständen in zu Zeiten (3. Generation). Man betrachtet den Engpass (Constraint Resource) und trägt die Bearbeitungszeiten der Aufträge in dieser Ressource über der Kapzität der Ressource auf (das ist wie eine Pipelinedarstellung, ein Stapel oder Stack). Der Endtermin für einen Auftrag wird dann über Daumenwerte (die man mit der Zeit justiert) einfach festgelegt - typisch Ausgangszeitpunkt aus der Constraint Resource +50% typ. Durchlaufzeit. Genau so geht es mit dem Starttermin = Ausgangszeitpunkt aus der Constraint Resource -50%. That's it. Wenn dann ein Auftrag aus einer xbeliebigen Stufe fertig ist - wird immer der Auftrag gezogen, dem seine Zeit schon am weitesten fortgeschritten ist. Die +/-50% und die Durchlaufzeiten werden dann so lange optimiert bis der Durchsatz optimal ist >> in der 3. Generation gibt es keinen echten Bestandspuffer mehr sondern der Puffer ist im System in den Durchlaufzeiten. Nicht mehr an einen Station oder Auftrag geknüpft sondern über alle Stationen und Aufträge verteilt. Das ist wie bei einer Feuerversicherung - je besser das Risiko verteilt ist, desto kleiner der Riskozuschlag, desto billiger und in dem Fall desto schneller. DBP-Steuerung sind mathematisch nachweisbar der Anschlag - es geht nicht schneller dafür sind sie leider komplizierter (sieht man schon an der Beschreibung) ... richtig gut ist der Artikel (ich gebe es zu mit Schragenheim schaffe ich auch zusammen )
http://www.inherentsimplicity.com/files/files/Using%20SDBR%20in%20Rapid%20Response%20Project.pdf ..... ich wollte eigentlich aufhören - aber diese Steuerung ist dazu noch viel flexiebler als Kanban - bei Kanban muss alles immer irgendwie gleich klein sein und gleich wichtig - sonst kommt es aus dem Takt. Ein DBR macht das spielend mit (s. auch im Artikel - Rapid Response Aufträge).

p.s. im September gebe ich wieder zwei Seminar a) CCPM (das steckt eine DBR drin) und b) Reliable Scrum (da steckt CCPM drin ) und vor allem viel Spass

cu Wolfram

p.p.s.: Drum-Buffer-Rope geht aber noch einen Schritt weiter (und wird dabei zur simplified Drum-Buffer-Rope). Am Schluss ist es ja eine blöde Idee den Engpass im eigenen Hause in der Entwicklung zu haben! Wenn ich nicht schnell genug neue Werte für den Kunden liefere tut es ein anderer und ich verliere Marktanteile. Das muss man sich einfach auch mal klar machen. Wenn man unternehmerisch denkt wird man seine "Produktion" so mit Kapazitäten versehen, dass sie so schnell wie mögliche produzieren können und in der Menge die der Markt abnimmt (da gehört der Engpass hin). Wenn es keinen echten Engpass mehr gibt dann kann man die Aufräge nach Auftragseingang priorisieren und die Durchlaufzeit ist nur noch durch die physikalisch machbare Ressourceneinsatz pro Arbeitspaket und Station begrenzt. Ich kenne solche Unternehmen, die das machen - und die wachsen überproportional und haben extrem gute Kapitalrenditen. Der Übergang von DBR zu sDBR ist fließend.

Was mich an diesem Artikel (und anderen Diskussionen zum Thema) stört:

Es wird "agiles PM" erklärt, indem wiederholt und ausführlich der Begriff "agil" verwendet wird.

Ich glaube, diese Rekursion bringt uns hier nicht weiter.

Was heißt denn "agiles PM" tatsächlich?

Nach dem, was ich bisher über Agiles PM gelesen habe, gewinne ich den Eindruck, daß das mehr so die Variante "Mal gucken, was da raus kommt" ist.
Aber das kann es nicht sein.

Ich selbst komme aus dem sog. "klassischen PM", also dem Konzept "erst denken, dann planen, dann handeln".

Der Satz "Agile Projektarbeit ist gekennzeichnet von iterativem Vorgehen ..." paßt auch zu dem Ablauf, den ich kenne.
Üblicherweise durchläuft ein Projekt im Anlagenbau mehrere Phasen, in denen die Ergebnisse der vorhergehenden Phase bewertet, angepaßt und verfeinert werden. Manchmal werden sie auch verworfen und neu erstellt.

Das Stage-Gate-Modell, das ich aus der Produktentwicklung und der (industriellen) IT kenne, wird hier ersetzt durch die Projektphasen.
Hier läuft der Weg also von der Projektierung (Vertrieb/Sales) bis hin zur Gewährleistungsphase (Service/After-Sales), wobei in den einzelnen Gewerken die Phasen leicht bis deutlich versetzt sind.

Von der Laufzeit her rangieren wir in diesen Phasen irgendwo zwischen 3-6 Monaten und mehreren Jahren.
Anlagenbau Petrochemie (EPC) ist dann häufig:

1 Jahr Projektierung, Vergabe, Basic Engineering ("Engineering")
1 Jahr Detail Engineering, inkl. Bestell- und Fertigungszeiten ("Engineering&Procurement")
1 Jahr Baustelle / Construction  ("Construction&Commissioning")
2 Jahre Gewährleistungsphase ("After-Sales")

Schema:
Projektierung -> Vergabe -> Basic Engineering -> Detail Engineering -> Construction -> Commissioning -> After-Sales

Wo ist der tatsächliche Unterschied?

Die amerikanischen Kollegen aus der agilen Community würden das beschriebene Vorgehen wohl mit "Wasserfall" beschreiben. Das ist aber das Gegenteil von "iterativ". Iterationen können ohne Phasen auskommen, sollten aber mindestens in den genannten Phasen auftauchen. Damit ist es aber noch lange nicht agil. Scrum, z.B., würde nicht über drei Sprints nach vorne schauen. Ob man soetwas im Anlagenbau mit all den Rechten und Pflichten derzeit hinbekäme ist sicher fraglich (an anderer Stelle wird das gerade am Beispiel Hausbau noch mal neu diskutiert)

http://blog.rainwebs.net/2014/02/09/ein-agiler-change-fuer-die-gesellschaft-muss-her/

Halt ! Stop !

Warum schreibe ich das so?

Meine Meinung: Es gibt kein "agiles Projektmanagement. Es ist nur ein Hype welcher das Wort "agil" verwendet um zu suggerieren es wäre etwas Neues.

Gehen wir doch einmal drei Schritte zurück und schauen uns nur den Methodenkoffer des PM mal an. Was finden wir? Alles was wir schon kennen, angefangen von Planung, Stakeholdermanagement, Change-Mangement, Phasen etc.

Was ist daran denn agil, also im weiteren Sinne "beweglich" ? Doch nur das Wort "agil" (beweglich) weil wir (mehr oder weniger alle PL) verlernt haben warum eigentlich Projekte gestartet werden: Weil es gilt etwas neues, vorher nicht dagewesenes, etwas unbekanntes, zu erschaffen.

Bitte: Wo steht denn in all den Vorgehensmodellen, dass man sich strikt nach einem Plan halten muss und ihn "um Gottes willen" nicht davon abweichen darf?

NIRGENDWO ! !

Wo steht denn in der Disziplin des Changemanagements, dass jeder Change vom Kunden bezahlt werden muss ? Wo zum Teufel, steht, im V-Modell XT oder PRINCE2, DIN oder sonst wo, dass Changes stets zu Lasten des Kunden gehen?

Heute flatterte mir die neueste Ausgabe des PM-Magazins der GPM ins Haus, mit einem Artikel über "hybrides PM". Allein bei dem Titel geht mir die Galle hoch. Es gibt kein hybrides PM. Punkt. Alles andere ist die Integration von Scrum als Methode der Softwareentwicklung in Unternehmensprozesse. Und dabei sollte man es belassen, anstatt künstlich eine Geisteswissenschaft daraus zu machen wo keine ist. Lieber Hirnschmalz investieren und Kunden helfen Methoden und ihre Prozesse zu optimieren.

Fazit für mich: Wir (im weiteren alle PL mehr oder weniger und auch _Kunden_ !) haben verlernt MITEINANDER an etwas zu arbeiten.

Deswegen gibt es für mich kein "agiles PM" nur "back-to-the-roots".

Absorb what's useful, and reject what's useless.

Die wahre Kunst liegt nicht darin, immer mehr anzuhäufen, sondern wegzulassen was einen behindert.

In diesem Sinne.

Hallo Reiner,

was ist denn mit dir passiert - so viel Emotionen in einem Posting - das muss wirklich ein Kernglaubenssatz von dir getroffen haben ... nur vorweg die letzen drei Sätze sind klasse und danke - Miteinander arbeiten ist etwas sehr schönes, Nützliches verstärken und unnützes weglassen logisch und Behinderungen beseitigen auch Klasse.

Ich hab jetzt nicht wirklich rausgelesen was dich stört und bewegt - hier nur einfach nochmal eine Idee, wie man dieses Konflikt zwischen agil und Projekt sehen kann. Dieser Konflikt findet sich oft - ich hab aber schon ganze Kongresse (Inter-PM) in die "richtige" Richtung kippen sehen, wenn man ein paar Begriffe glatt zieht - vielleicht hilft es ja:

Der Konflikt entsteht IMHO dadurch, das zwei Klassen von Wortarten gemischt werden. "agil" ist ein Adjektiv - also ein Wort das die Charakteristika einer Klasse von Systemen benennt. "Projekt" ist eine Klasse von Systemen. Viele verwenden das wort Agil aber nicht als Charakteristika einer Klasse von Systemen sondern als Bezeichnung für Methoden. So verwirrend wie dieser Absatz so verwirrend sind dann die Diskussionen. Daher hier der weitere Versuch mal die Klassen zu benenen und dei Charakteristika.

Es geht um das Begriffspaar "Projekt" und "Produkt". Bei beiden wird etwas erzeugt. Dieses Erzeugen heißt dann "Projektmanagement" oder "Produktion".

Die zwei Klassen unterscheiden sich in der Art und Weise wie vorgegangen/gesteuert wird. Beim "Projekt" und "Projektmanagement" hat man es mit Arbeitspaketen zu tun, die dummerweise oft voneinander abhängig sind und deren Zeit/Aufwand nur extrem schwer zu schäten sind. Beim "Produkt" und der "Produktion" hat man es mit vielen kleine Aufträgen/Aufgaben/Stories zu tun, die relative ähnlich groß sind und recht gut vertauschbar sind. Man könnte jetzt noch über das Verhältnis von Bearbeitungszeit zu Durchlaufzeit sprechen - je kleiner das Verhältnis desto einfacher die Steuerung und desto näher ist man an der "Produktion".

Achtung: Produktion ist dabei kein Taylorismus und Projekt kein Wasserfall .. Taylor und Wasserfall sind jeweils nur kleine untermengen von Produktion und Projekt und seit ca. 50 Jahren auf dem Rückzug weil zware sehr effizient aber auch sehr "starr".

So und jetzt zu dem zweiten Begriffspaar den Adjektiven "agile" versus "starr". Das "agile" systeme sind leichtgewichtig, flink, beweglich - alles Charakteristiken die auf unterschiedliche Klassen von Systemen bezogen werden können. Der Gegenbegriff ist "starr" - im Sinne von träge, unbeweglich, schwer.

Adjektive kann man mit Klassen von Sytemen (ich hab noch eine Aufgenommen) kombinieren und Methoden zuordnen:

	starr	agil
Projekt	Wasserfall, V-Modell	Critical Chain, V-Modell XT (sorry ja das kann man ganz schön agil gestalten) und High-Speed-Projektmanagement
Produkt	Taylor, Ford, Ticketsyteme	eXtreme Programming, Scrum, Kanban, Reliable/Ultimate Scrum, FDD, u.v.a., TameFlow-Ansätze
es gibt noch mehr z.B. Innovationen	fällt mir nichts ein	TRIZ, Design-Thinking, IDEO u.v.a.

Beide Projektmanagement und Produktion kann man mit anderen guten Ideen Kombinieren:

• sozialen Techniken wie Teamarbeit,
• Selbstorganisation
• Itterationen/Prototypem
• Kundeninteraktionen
• Mitarbeiterentwicklung/Ausbildung
• Job enrichment
• Continuous Integration/Delivery

Aber am Schuss gibt es beides - es gibt Projekte und Produktion ("agile Methoden") - manche Sachen haben eben Abhägnigkeiten und hohe Streuungen (wie z.B. Marsmissionen, Bauen von Häusern aber auch mache Softwareprojekte). Andere Initiativen sind mehr itterativ zu lösen und in kleinen Schritten - dann ist Produktion das Mittel der Wahl (weil einfacher) z.B. Maintenance von Software, Innovative herantasten an neue Lösungen, Abarbeiten von großen Softwarereleases. Wenn man genau hinschaut findet sich immer auch ein bisschen Produktion im Projekt und Projekt in der Produktion - das sind die "Augen" im Ying-Yang

Aus dem Grunde finde ich es sehr gut wenn die GPM und die Projektmanger von den "agilen Methoden" lernen um besser zu werden

Ganz im Sinne vom weglassen von Unnützen und hinzufügen von Nützlichem

Cu Wolfram

p.s.: die Realität ist noch ein bisschen anspruchsvoller - Organisationen die Produkte erzeugen weise unterschiedliche Ebenen auf in denen die Systemcharakteristika wechselt - nur wens interessiert - eine sytemische Betrachtung:

Hi Wolfram,

die Unterscheidung Projekt-Produkt gefällt mir überhaupt nicht, weil ja auch die meisten Projekte einen Projektgegenstand oder ein Projektergebnis haben, das man als Produkt bezeichnen würde.

Deswegen habe ich vor einer Weile die Diskussion Projekt oder Prozess angezettelt.

Gruß

Bernhard

genau - passt doch perfekt was du sagst

Produkte entstehen sehr oft (nicht zwingend) in Form von Projekten - danach ist das Produkt aber in sich definiert und es geht in den Produktions(Prozess) über.

Große Unternehmen sind oft genau an der Stelle getrennt - es gibt eine Produktentwicklung und eine Produktion. Ich sage nicht, das das immer gut ist. Es ist aber eine Möglichkeit. Diese Entkopplung ist natürlich, da beide Welten ganz unterschiedliche Charakteristika (und damit verbunden Steuerungen) aufweisen.

In der Softwareentwicklung hat man aber oft mehr Freiheiten. Da kann die Produktentstehung selbst schon als Produktionsprozess (z.B. agile Methoden wie Kanban) gestaltet sein.In dem Fall ist auch die Trennung nicht mehr so offensichtlich (s. Continuous Integration/Delivery).

Man sollte Projekte/Projektmanagement wirklich auch nur da einsetzen wo es notwendig ist - denn Projektmanagment ist aufwändiger und komlexer als Produktion. Und das ist ja auch deine Aussage - es wird zu viel in Form von Projekten gemanged - da bin ich voll bei dir das ist zu komlex und zu teuer und reduziert den Durchsatz und Kundennutzen oft unnötig.

cu Wolfram

Hallo Bernhard,

wenn man "Produkt" als Ergebnis eines Projektes betrachtet, mal egal ob es körperlich ist, oder geistig (Erkenntnisgewinn), ist das erst einmal ein "Produkt". Ein Projekt ohne "Produkt" als Output ist ein sinnloses Projekt.

vs. Produkt welches vermarktet werden kann.

Grüße

Reiner

Hallo Reiner, 

also wenn ich an reine Organisationsprojekte denke, weiß ich nicht, ob ich das Ergebnis in diesem Fall als Produkt bezeichnen würde.

Aber das ist jetzt spitzfindig, denn auf der groben Linie sind wir uns einig.

Gruß

Bernhard

Im Fall von "Projektitis" schießt man nicht nur mit Kanonen auf Spatzen, sondern diskreditiert auch Methoden und Ansätze. Es fehlt dann dort, wo sie sinnvoll eingesetzt werden an Akzeptanz.

"Agil" ist für mich nur eine Worthülse, welche das eingentliche Problem/Aufgabe/Herausforderung/Vergessene: "Wie gestaltet man die Zusammenarbeit so, dass ein für den Kunden brauchbares Ergebnis herauskommt." verschleiert.

Ich bemerke in den letzten Jahren ein stetiges Festhalten an Verträgen mit allen Variationen und dann eine einhergehende "Vergeistlichung" des Projektmanagements....schade.

Betrachtet man "beweglich" sein, als dass was es ist, nämlich mit gesundem Menschenverstand (und evtl. auch noch Expertenwissen) Probleme zu lösen und setzt man obendrauf noch ein WIR......

SCRUM geht doch in die Richtung: "miteinander Reden" und mehr "machen" anstatt Papier produzieren (ist jetzt mal platt gesagt)...und warum ist es erfolgreich?

Ist jetzt recht ketzerisch formuliert...regt vielleicht zum Nachdenken an....

Ich weiss nicht, ob die obige Projekt- vs. Produkt-Diskussion bei Software-Entwicklung der richtige Ansatz ist. Ich habe bisher keine zwei Projekte erlebt, in denen die Erstellung von Software nur im Ansatz so standardisierbar gewesen wäre, dass man es hätte mit z.B. der Fliessbandproduktion bei Toyota vergleichen können. 

Aber mal was anderes: Es scheint, dass bei der Betrachtung von "agil" immer vergessen wird, dass "flexibler zu sein" nur ein Ergebnis ist, nachdem ich Verantwortung als klassischer PM abgegeben habe. Die Micro-Planung geht bei Scrum z.B. an das Umsetzungsteam über, die fachlichen Dinge an den Product Owner, die prozessualen an den Scrum Master. Da bleibt nicht mehr viel über für einen PM, wenn man das in der Organisation sauber verankert bekommt als neue Vorgehensweise bei Projekten. Das ist disruptiv, und nicht etwa mal alles vernünftig zu machen, wie Reiner es angedeutet hat. 

Ich verstehe die Idee, das klassische endlich mal vernünftig anbzubilden. Aber agil zu arbeiten ist da noch mal was ganz anderes.

vorweg - ich bin ein großer Freund von "vertragsfreier" Zusammenarbeit - selbst bei den größten Projekte im Mio€-Bereich waren die Verträge erst nach Projektabschluss fertig oder wir haben im Lauf der Zusammenarbeit festgestellt, dass die Verträge nicht helfen und wie lieber Kundennutzen generieren. Die Projekte waren alle agil - ohne dass jemals jemand es so genannt hätte.

Es ist halt oft so, dass ein Label übernommen wird weil es hipp ist - am Schluss wir es oft verwendet um sich den eigentlichen Problemen nicht zu stellen.

cu Wolfram

p.s.: ein Punkt habe ich aber auch noch - du hast in einer Zeile SCRUM - miteinander reden - und erfolgreich genannt. Würde ich so nie kombinieren. Scrum ist eine agile Methode der ersten Generation (mittlerweile ist man bei der 3. Generation/Drum-Buffer-Rope) und hat viele Nachteile. Agile Methoden an sich sind auch nicht erfolgreicher als klassiches Projektmanagement - s. Studie der Swiss-Q (http://www.swissq.it/resources-agile-trends-benchmarks-schweiz-2013/) im Vergleich zu Standisch Group Chaos Report - beide kommen auf nicht mehr als 36% in Time, in Scope und in Budget. Ich würde daher nicht per se von Erfolg sprechen. Ich werde auch laufend zu agilen Teams gerufen, die alles andere als performen - es ist halt mehr als nur eine SCRUM-Schulung/Zertifizierung (reine Geldmacherei)

Echte Teamarbeit im Fluss (minimaler WIP und continuous Integration) und enger Abstimmung mit dem Kunden würde ich als Erfolgreich bezeichnen - aber das ist unabhängig von Projekt/Produkt oder agil/klassisch

hast du dir mal Critical Chain angeschaut? Auch hier gibt der PM massiv Verantwortung nach unten ab und läßt die mikro-Planung in den Teams machen ...

... das größte Problem bei diesen Diskussionen ist, dass die neuen Methoden mit alten schlechten Projektmangement vergleichen wird. Es gibt wirklich gute neue Projektmanagement Ansätze die sind mit dem alten nicht mehr zu vergleichen - sorry.

Interessanterweise nähern sich beide Welten an. Es gibt auch eine Entwicklung in der agilen Welt die die Rollen verfeinert. Der Product Owner wird geteilt und wird zum fachlichen Product Owner und in Team bleibt ein Backlog Owner (der mehr wie ein Projektmanager aussieht), der Scrummaster braucht man in der 3. Generation nicht mehr so stark (weil die Prozesse so einfach sind) und der Teamleiter kann die Rolle des ScrumMasters übernehmen. Entscheider braucht man in beiden Welten.

Ich hab die Ehre in einem Kreis von größeren Unternehmen (ASK@-Veranstaltungen) zu sein, die schon weit über 5 Jahre agile Methoden anwenden (daher auch die obingen Aussagen). Hierbei kommt es nach 5-7 Jahren zu einem interessanten Effekt. Die kleinteiligen Aufgaben sind in diesem Zeitraum weitgehend abgearbeitet und die Produkte ausgefeilt. Wenn man dann noch Geld verdienen will muss man entweder einen neuen Makt öffnen oder ein großes neues Produkt entwickeln. Um das zu machen muss man aus der prozessorientierten Denke wieder aus in die Projektwelt. Daher haben alle der ASK@-Unternehmen mittlerweile wieder Projekte und Projektmanger. Diese koordinieren die Teams untereinander.

Ich lade dich gerne mal ein uns/mir über die Schulter zu schauen z.B. zu eine TOC4U-Netzwerktreffen zu kommen.

cu Wolfram

p.s.: die aktuell Hype um Kanban (die Produktionssteuerungsmethode von Toyota) zeigt genau, dass Software wie im Fließband produziert werden kann ... Fließband hat erst mal nichts mit stupide, langweilig oder kreativlos zu tun ... sondern nur mit der Art wie die Arbeit gesteuert wird - auch wieder so ein Mißverständnis ... porzessorientiertes Arbeiten kann sehr kreativ sein - die ganzen Innovationsprozesse sind so strukturiert (z.B. Design-Thinking)

p.p.p.: SCRUM hat einen stark militärischen Einschlag - Jeff Sutherland war Kampfpilot ... die Stand-UPs erinnern an den Morgenapell, das Planning I an den Eid und das Review and das Debriefing ... nur so nebenbei - ich halte SCRUM für massiv hinten dran - hat mehr Ähnlichkeit mit einer Steuerung zu Zeiten von Henry Ford und mit militärischen Einschlag ... keine Ahnung warum sich da heute jemand antut ... ich wüsste nicht warum das disruptiv sein sollte ... Volvo hat das in den 80er Jahren als Teilautonome Arbeitsgruppen eingeführt mit großem Erfolg - das ist 30ig Jahr her

nur noch kurz - disruptiv empfinde ich die Idee Unternehmen holistisch (systemisch) zu betrachten. Also weg von kleinen lokalen Optimierungen hin zu Betrachtung des Gesamtunternehmens als Ganzes. Das erscheint zwar zuerst etwas komplexer, wenn man aber das steuernde Element gefunden hat dann wir es einfach.

In diesem Zuge bekommt der Mitarbeiter plötzliche ein ganz andere Wertschätzung - weil in allen Unternehmen am Schluss die kreative kommunikative Arbeit der Menschen untereinander (s.o Kommunikation) der Engpass bildet.

Das ist disruptiv und hier sind wir gerade erst dran zu ahnen, was das bedeudet.

Wie gestaltet/skaliert/managed man große Teams (>500 Mitarbeiter) um ein großes Ziel zu erreichen. Aber jetzt kommts - nicht wie google/amazon/facebook mit massivem Ressourcenaufwand - sondern richtig effizient also ohne verheizen der Menschen.

cu Wolfram

Zum Thema V-Modell und "starr" bitte mal nach "iterativ" und "iteration" suchen auch in der 97er Version.....

....und wer gerne Winston/Royce zitieren möchte dem sei das Original empfohlen:

http://leadinganswers.typepad.com/leading_answers/files/original_waterfall_paper_winston_royce.pdf

Zitat zum Bild 2: "I believe in this concept, but the implementation described above is risky and invites failure." ...und dann heißt es "Steps" nicht "Phases"

Auch müsste man ja zu PRINCE2 sagen es sei "starr", wobei PRINCE2 ja gar nix über die die eigentliche Erstellung der "Spezialitenprodukte" sagt....uch im V-Modell XT wie in PRINCE 2 erfolgen Zuordnungen von Rollen - Aktivitäten-Ergebnissse/Produkte, da ganze garneirt mit Verantwortungszuordnungen.

Grüße

Reiner

Methoden, falsch angewendet, führen zwangsläufig zu Mißerfolg....SCRUM ist da keine Ausnahme.....nur eine von mehreren Möglichen zum Ziel zu kommen.

Meinem Kunden habe ich gesagt, dass man mit SCRUM an der Klippe steht und einen Schritt weg vom Chaos ist, wenn man Fehler macht. Und so langsam kommt auch beim Management die Erkenntnis an, dass man mit agilen Mehtoden auch seine Organisation verändern muss......

Ich sehe SCRUM gleichberechtigt neben allen anderen Methoden....Welche dann für ein Projekt "besser" gewesen wäre, läßt sich im nachhinein doch schwer feststellen, sonst müsste man das geliche Projekt mit den gleichen Personen nochmals machen.....

Zitat "Die Micro-Planung geht bei Scrum z.B. an das Umsetzungsteam über"...Die Planung habe ich in meinen Projekten nie selber und vor allem nie alleine gemacht. Am Anfang war immer ein Kernteam bei der Ausarbeitung dabei....und der Kunde. Aber die letztliche Verantwortung für das Projekt (accountable) wird man doch als Lenkungsausschuss wie auch als PM/PL bei SCRUM & Co nicht los.

Wenn am Ende eine "neue Organsiation" heruaskommt ist das (für mich) ein "Produkt", wenn nicht, war's Projekt vielleicht umsonst....

http://de.m.wikipedia.org/wiki/Disruptive_Technologie vielleicht mal zur Erklärung. 

Sehr interessant der Einwand, dass die agilen Themen immer mit den falsch gelebten klassischen Ansätzen verglichen werden. Leider ist mir in den vielen Jahren meiner Tätigkeit noch kein Projektkontext über den Weg gelaufen, bei dem dieses ideale Bild gelebt worden wäre. Selbst zertifizierte PMs nach PMI oder  IPMA sind hier gescheitert. Der Chaos-Report z. B. zeigt die Tendenzen seit Jahren auf. Die Ergebnisse lassen zu wünschen übrig. Verbesserungen sind eher marginal.

Hi Rainer,

genau - wichtig in dem Zusammenhang sind IMHO drei Bücher "Crossing the Chasm" G. Moore, "The Inventors Dilemma" M. Christensen und auch "The Tipping Point" M. Gladwell ...

Der Chaos Report ist insofern interessant, dass er eben auch zeigt, dass trotz massiver Anstrengungen in der Ausbildung der Projektmanager (PMI, GPM, ...) sich praktisch nichts geändert hat. Interessant ist auch, dass der Chaos Report jetzt nach all den frustrierenden Jahren einfach den Fokus geändert hat und agil in den Vordergrund stellt. Wie gesagt der Swiss-Q Report zeigt aber die gleichen Zahlen auch für agil - meine Schlußfolgerung ist daher (ganz frech) - beide Ansätze sind auf dem falschen Dampfer und adressieren noch nicht das richtige Problem.

D.h. um "agiles Projektmanagement" (beide Seiten) umzusetzen, muss man an was ganz anderes ran! Nur dann kann man disruptiv etwas erreichen. Und das Disruptionen möglich sind ist unbestritten. Es gibt immer wieder Teams (und Unternehmen) die außergewöhnlich Leistungsfähig sind.

Es ist sicher noch nicht zu Ende gedacht - Steve Tendon (ehem. Leiter der Borland Entwicklung) und ich haben unsere Ideen in einem Buch zusammengefasst ( "Tame the Flow" auf Leanpub ) - hier werden die holistischen systemischen Ansätze beschrieben (und auch erste Wege, wie man diese implementieren* kann).

Und beim Implementieren liegt IMHO das Hindernis, warum die Disruption nur so schwer von statten geht. Die Organisationen, wie wir sie kennen sind geprägt von "lokaer Optimierung" (jeder für sich, jedes Team optimiert für sich). Das spiegelt sich im Paradigma "teile und herrsche" wieder. Das was bei Algorithmen funktioniert die unabhängig zerteilbar sind - funktioniert ob der Kopplung in Organisationen nicht. Es ist einfach statistisch unwahrscheinlich, dass man ein großes Ziel in kleine Ziele fehlerfrei aufteilen kann. Damit sind zum einen Konflikte vorprogrammiert und zum anderen Engpässe. Wenn man dann noch versucht alle 100%ig auszulasten ist das Choas perfekt und der Engpass massiv überlastet.

Aus meiner Sicht (eher unsere es werden immer mehr) ist im mittleren Management der Knackpunkt und in diesen zwei Paradigmen die abgelöst werden müssen:

a) lokale Optimierung beseitigen --> holistisches Management --> Engpass (steuerndes Element finden/festlegen)

b) Überlastung beseitigen --> Flow --> Engpass gerade richtig ausgelastet, Nichtengpässe mit "protective Capacity"

Das ist nicht ganz einfach für das mittlere Management, denn es definiert sich oft genau durch diese Probleme. Daher investieren wir viel Zeit vor einem Change umd das mittlere Management auf die neue Welt vorzubereiten - s. QuiStain(R)able Change ...

cu Wolfram

* die Sache mit der Implementierung diskutieren wir gerade in der GPM-Fachgruppe "Agile Management" und kommen ganz gut voran ... Ergebnisse werden Mitte des Jahres veröffentlicht (ich hab Marcus schon gefragt ob wir OpenPM hier nutzen dürfen)