Schlagwort-Archiv: Agiles Projektmanagement

Ist agil jetzt agil oder was?

In der Diskussion zu meinem letzten Artikel Ein agiler Bastard zwischen einem Karnickel und einer Rummelfliege wird schliesslich nicht mehr auf die ursprünglichen Fragestellung eingegangen, sondern über ganz andere Dinge diskutiert als über die Frage, was “agil” denn aussmacht. Dietrich Dörner nennt das vertikale Flucht, eine Strategie, die ich auch in Projekten immer wieder antreffe.

Kriterien für agiles Projektmanagement

Natürlich geht es mir nicht um eine Definition von “agil” in engerem Sinne, sondern um die Bedeutung des Begriffs und vor allem um Kriterien, mit denen ich agiles Projektmanagement erkennen kann. Wenn ein Kunde fordert, dass ich sein Projekt agil durchzuführen habe, dann muss er mir doch erklären können, was er darunter versteht! Tut er das nicht, kann ich nur auf den Ursprung des Begriffs zurück gehen, also auf das Agile Manifest, und feststellen, dass agil etwas ist, das mit Entwicklungsprojekten zu tun hat.

Wie kann ich erkennen, ob ein Projekt agil durchgeführt wird? Der Einzige, der mir bisher brauchbare Kriterien geliefert hat, ist Ralf. Er hat immer betont, dass agiles Vorgehen inkrementell sei. Im übrigen seien lernendes Vorgehen und unmittelbare Kommunikation kennzeichnend.

Kundennutzen versus Überraschungen

Ralfs Erklärungen des Begriffs “Inkrementell” und die Abgrenzung zu “iterativ” sind sehr aufschlussreich. Nach ihm resultiert jedes Inkrement in einem Kundennutzen. Da mein hauptsächlichstes Anliegen seit jeher der Umgang mit Überraschungen in einem Projekt ist, war ich bisher der Meinung, es gehe um agiles Ausweichen von unvorhergesehenen Ereignissen. Ich stellte mir tatsächlich den Haken schlagenden Hasen vor, der geschickt -sprich agil – dem Gegner ausweicht. Um den Kundennutzen brauche ich mir in Migrations- und Integrationsprojekten keine Sorgen zu machen. Sie finden ohnehin beim Kunden statt, der sehr genau aufpasst, dass er bei jedem Schritt den grösstmöglichen Nutzen hat. Das ist eben der grundlegende Unterschied zu Entwicklungsprojekten, die oft “off-shore”, also abseits des Kunden, abgewickelt werden. Mir ist schon klar, dass das einmal zu einer tiefgreifenden Veränderung kommen musste, deren Ziel es war, den Kunden mehr einzubinden.

Das Problem habe ich aber gerade bei Migrations- und Integrationsprojekten NICHT. Mein Problem ist das Unvorhergesehene. Inkrementelles Vorgehen kann nützlich sein, in Form von vorsichtigen kleinen Schrittchen. Knirscht das Eis unter den Füssen, nimmt man einen anderen Weg, auf dem es weniger knirscht. Wo aber das Eis dick genug und ausgemessen ist, kann man getrost grössere Schritte machen. Ich nenne das lieber rekursives statt inkrementelles Vorgehen, weil die Schrittweite vom bisher Erreichten abhängt (siehe Was ist der Unterschied zwischen inkrementellem und rekursivem Vorgehen?). Die Schritte sind also nicht vom Kundennutzen geleitet, sondern von unvorhergesehenen Ereignissen. Das setzt grosse Aufmerksamkeit voraus. Daher spreche ich von vigilantem Projektmanagement.

Lernende Organisationen und direkte Kommunikation

Das Kriterium “lernendes Vorgehen” verlangt nach Konkretisierung. Lernen ist sehr zeitaufwändig. Eine Unternehmung kann eine lernende Organisation sein, ob ein Projekt aber die Zeit hat zu lernen, ist fragwürdig. Länger als ein paar Monate bis höchstens zwei Jahre sollte ein Projekt nicht dauern. Ob das für organisationales Lernen reicht?

Und bezüglich unmittelbare Kommunikation gäbe es auch so einiges zu sagen. Der Verkäufer des Lieferanten muss das Projekt unter dem Preis anbieten, ob er nun mit dem Projektmanager redet oder nicht. Und der Einkäufer des Kunden sagt: “Prima, wir nehmen das Angebot an, aber zu einem 25% niedrigeren Preis”. Den Projektmanagern des Kunden und des Lieferanten wird dann nur noch gesagt, dass sie jetzt zu den und den Konditionen beginnen können. Während der Projektabwicklung sprechen z.B. die CEO von Kunden und Lieferanten miteinander über das Projekt, ohne die Projektmanager oder gar -mitarbeiter einzubeziehen, etc. Ein Projekt hat viele Stakeholders, die sich möglicherweise gar nicht alle gegenseitig kennen. Wie wollen sie da denn unmittelbare Kommunikation pflegen?

Ich habe zeitlebens Projekte in multinationalen Konzernen durchgeführt. Vielleicht haben die Vertreter agiler Methoden eher kleine Unternehmen im Sinn, die von ihrer Grösse und von ihren Entscheidungsstrukturen her schon agil sind?

 

Der Pfad der Ungewissheit in Projekten

Sibylle Peters schrieb in Management von Ungewissheit1 einen Aufsatz zum Thema Projektorganisation und Projektmanagement unter den Bedingungen zunehmender Komplexität2

Auf Seite 154 veröffentlicht sie die Iterations-Wolken-Metapher-Grafik von Oesterreich/Weiss. Sie visualisiert die iterative Zielklärung und -annäherung. Ganz besonders gefreut hat mich, dass auch für Oesterreich/Weiss das Projektziel erst bei Projektschluss bekannt ist. Während der Projektabwicklung findet ein ständiger Projektdrift statt.

Die Grafik hat mir derart gefallen, dass ich sie übernommen und weiter entwickelt habe. Nach herkömmlicher Projektmanagementtheorie gibt es am Ende einer Projektphase immer einen Review der bisher erreichten Teilergebnisse, eine Justierung der Planung und einen Forecast der nächsten Phase. Solche Meilenstein genannten Reflektionspunkte können indess auch an beliebiger Stelle in der Projektabwicklung vorkommen, wenn immer die Verantwortlichen das Gefühl haben, das Projekt sei vom “richtigen” Weg abgekommen.

Diese Reflektionspunkte sind in meiner Erfahrung keineswegs äquidistante Iterationszeitpunkte, wie sie das agile PM vorsieht. Neben den, in klassisch geplanten Projekten, vorgesehenen Meilensteine, gibt es weitere Momente der Besinnung, der Neuplanung und Korrektur. In jedem dieser Reflektionspunkte wird das Projektziel mehr oder weniger explizit neu definiert. Dadurch findet ein Zieledrift statt.

Der jeweilige Entscheidungsspielraum über die Marschrichtung ist nicht beliebig. Er engt sich sogar immer mehr ein, je weiter das Projekt fortgeschritten ist. Gewisse Entscheide hängen von früheren Entscheiden oder von Umweltbedingungen ab, die durch den bisherigen Projektverlauf geschaffen wurden. Das nennt sich Pfadabhängigkeit.

Geschieht etwas Unvorhergesehenes oder Unerwartetes, kann das mit einem Pfadbruch oder einer Unstetigkeit im Projektverlauf dargestellt werden. Das Projekt kann so wie bisher nicht fortgesetzt und muss neu aufgesetzt werden. Nach einem solch einschneidenden Ereignis ist sicher rasch ein Reflektionspunkt notwendig. Das Projekt muss neu geplant und berechnet werden. Die bisher erreichten Ergebnisse sind vielleicht nicht mehr viel wert. Dafür ist der Entscheidungsspielraum nach einem Pfadbruch wieder grösser, weil die historische Abhängigkeit fehlt.

Es kann aber auch passieren, dass niemand mehr weiss, was zu tun ist und alle orientierungslos vor sich hin wursteln. Das ist dann der Fall, wenn das Projekt den Planungshorizont des letzten Reflektionspunktes überschritten hat. Dann wird der Projektpfad holperig und faltig. Das Setzen eines Reflektionspunktes wird dringend notwendig. Jemand muss die Initiative ergreifen und das Projektteam zusammen rufen, um die nächsten Schritte zu definieren.

Das Modell ist effektiv brauchbar. Bisher wusste ich nicht so recht, was ich von Planung halten soll. Wozu planen, wenn es ja doch immer anders heraus kommt? In der Grafik wird aber klar, wie wichtig Planung für die nächste Periode wird. Eine Periode ist der Zeitraum zwischen zwei Reflektionspunkten. Agiles PM spricht von Iterationszyklen. Iteration bedeutet aber, stets dieselben Scheibchen von der Wurst abzuschneiden. Eine Iteration läuft stets nach demselben Programm ab, sogar dann, wenn das Programm obsolet geworden ist. Ich spreche deshalb lieber von Rekursion. Rekursion definiert die nächste Periode aufgrund des aktuellen Zustands. Rekursionszyklen sind nicht immer gleich lang, sondern passen sich an den momentanen Projektzustand an3.

1Böhle, Fritz & Busch, Sigrid (Hg): Management von Ungewissheit – Neue Ansätze jenseits von Kontrolle und Macht. transcript Verlag, Bielefeld 2012

2ebenda, S. 137-175

3 Siehe Frage 10 der Frequently asked questions über systemisches Projektmanagement

Ist agiles Projektmanagement immer anwendbar?

Im Umgang mit Komplexität sind agile Methoden heute in aller Leuten Munde. Wenn man unter einer komplexen Situation aber eine Situation versteht, die

  • unübersichtlich
  • vernetzt
  • unbestimmt

ist, dann sind agile Methoden im Umgang mit Komplexität meines Erachtens nicht notwendigerweise hilfreich. In Entwicklungsprojekten ist agiles Projektmanagement ein sehr nützlicher Ansatz, wenn man aus einem Produktebacklog gerade so viele Funktionen entnehmen kann, wie man in einer bestimmten Zeit entwickeln mag. Für Migrations- und Intregrationsprojekte (MIP) sind agile Techniken jedoch weniger geeignet1. Um das einzusehen, erinnern wir uns, dass Migrations- und Integrationsprojekte oft mit der Aufgabe starten, gelieferte Hardware zu entpacken, in einem Rack zu montieren, an ein Netz anzuschliessen und in Betrieb zu nehmen. Dazu gehören natürlich erste Funcional Tests, insbesondere Pingtests zu gewissen Servern in der bestehenden Umgebung.

Für die Montage und Grundinstallation sind z.B. 10 Tage geplant. Wenn die agile Projektmethodik eine Timebox von 4 Wochen vorgesehen hat, lässt sich aus der Montage keine Timebox machen.
Das agile Prinzip, innerhalb einer Timebox keine Changes zuzulassen, greift hier auch nicht, denn Changes sind in einem MIP nicht das grosse Schreckgespenst. Wenn der Kunde das Rack innerhalb des Serverraums zig Mal umplazieren will, nervt das zwar, ist aber weiter kein Problem. Changes machen auch noch keine Komplexität aus. Das Schwierige in MIP sind Ereignisse, die sowohl für den Kunden als auch für den Lieferanten gleichermassen unvorhergesehen sind. Eine typische Unvorhersehbarkeit während einer Montage ist die Tatsache, dass irgendwelche Firewalls nicht richtig konfiguriert sind (das ist mittlerweile derart typisch, dass es schon keine Unvorhersehbarkeit mehr ist, sondern als vorhersehbares Risiko behandelt werden kann. Aber sagen Sie das einmal dem Kunden…).

Ein weiteres agiles Prinzip ist der Kundennutzen. Jede Iteration soll einen bestimmten Kundennutzen haben. Jede weitere Iteration erhöht den Kundennutzen. Eine Reihe von Iterationen werden zu einem Release zusammen gefasst, der eigentlich schon ein fertiges Produkt darstellt. Das geht bei MIP nicht. Das Resultat der Monatge enthält kaum Kundennutzen, musst aber dennoch gemacht werden. Daraufhin folgt die Installation der Software und anschliessend monatelange Tests bis zur Migration oder der Abnahme. Man kann nicht eine Iterationfolge “ein bisschen Montage, ein bisschen Software, ein bisschen Tests” machen, um einen ersten Release zu haben. Das geht in MIP nicht. MIP sind wie eine Schwangerschaft: man installiert einen bestimmten Release; alles oder nichts. Ein weiterer Release ist ein neues MIP.
Da eine vollständige Benutzerdokumentation zum Lieferumfang eines MIP gehört, gilt auch das agile Prinzip “funktionstüchtige Produkte vor umfangreicher Dokumentation” hier nicht. Ob das Produkt funktionstüchtig ist, liegt nicht in der Macht des MIP, sondern des vorangegangenen Entwicklungsprojekts. Eine vollständige und umfangreiche Dokumentation ist jedoch ein typisches Deliverable eines MIP.

Für Entwicklungsprojekte mögen agile Techniken eine hervorragende Methode sein. Auf ein Entwicklungsprojekt kommen hoffentlich viele Migrations- und Integrationsprojekte. Schliesslich will man das entwickelte Produkt oft verkaufen und ausrollen. Agile Techniken sind aber für das Management von Migrations- und Integrationsprojekten nicht sehr geeignet.

1Addor, P. Projektdynamik – Komplexität im Alltag. Liebig Verlag, Frauenfeld 2010, S. 65ff

PM-Landschaft als Leiterlispiel

Nachdem es überraschend oft vorkommt, dass sich meine Studenten etwas verloren vorkommen, wenn ich im Zusammenhang mit Projektmanagement über Evolutionstheorie, Lernende Organisationen oder Konstruktivismus spreche, habe ich den Weg durch die weitverzweigte Landschaft des Projektmanagements in Form eines Leiterlispiels dargestellt.

Natürlich ist es nicht ernsthaft als Spiel gedacht. Auch soll es keine Lernhilfe sein. Es soll lediglich zeigen, dass es zusätzlich zum klassischen Projektmanagement neuere Ansätze gibt, mit denen die Menschen versuchen, Unvorhergesehenes zu berücksichtigen.

Viel Spass beim Betrachten der Kollage….