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?

 

Creative Commons License
Komplexitätsmanagement by Peter Addor is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Based on a work at www.anchor.ch.

About Peter Addor

Mathematiker und Systemiker. Trainings für Komplexitätsmanagement und Umgang mit Unerwartetem ANCHOR Management Consulting AG
This entry was posted in Projektmanagement and tagged , . Bookmark the permalink.

3 Responses to Ist agil jetzt agil oder was?

  1. Bernd says:

    Aha, vertikale Flucht, wieder was gelernt, vielen Dank!

    Diskussionswürdig finde ich den Punkt tatsächlich.
    Ich selbst habe die wichtigsten Dinge bisher NUR agil & achtsam geschafft.
    …und dennoch glaube ich, dass es “agiles PM” nicht (wirklich) gibt.

    Aus meiner unwissenschaftlichen, eher pragmatischen Persektive sieht es so aus:

    “Agil” ist eine Vorgehensweise.

    Wenn der Blickwinkel auf ein Projekt folgender ist:

    1. – ProjektIdee / Vision
    2. – Beauftragungsverfahren
    3. – Initialisierung
    4. – Kick-Off etc.
    5. – Durchführung
    6. – TakeDown

    Können sie das “Agile” fast nur in der Durchführung finden (und meist nicht in den anderen Punkten)…

    Sie erkennen eine agile Vorgehensweise (in der SE) daran,
    das die Vorgehensweise entweder

    inkrementell,
    ODER iterativ
    ODER eine Hybridform ist.

    Die Unterschiede sind so zu erkennen:

    1.) – Anforderungsanalyse & Fachliche Konzeption
    2.) – Technische Konzeption
    3.) – Realisierung
    4.) – Integration & Test
    —>
    5.) Durchführung beendet (wenn “klassisches Vorgehen”)
    –> Behelfsweise kann / muss es Feedbackschleifen zwischen den Steps geben, die im schlimmsten Fall dazu führen, dass die fachliche Konzeption (der Kundennutzen) “untergeht”

    Iterativ bedeutet: die Schritte 1-4 werden immer wieder wiederholt.
    …und richtig man kann das Ende / bzw das Ziel flexibel steuern, aber auch aus den Augen verlieren (Insofern paßt der Hase schon gut :D )
    Daher benötigt man dafür eine sich einprägende GUTE VISION
    und die Kommunikation zu den Zielgebenden.
    (Hat man die nicht, ist man quasie entlassen / handlungsunfähig ;-) )

    Inkrementell bedeutet:
    Der Schritt 1 wird abgeschlossen (Was also entstehen soll ist BottomUP bzw. vom FACHBEREICH / Kunden definiert) und die Schritte 2-4 werden wiederholt.
    Auch hier stelt sich die Frage wann das Projekt beendet wird / das Ziel erreicht ist -> Man benötigt also auch hier das Feedback / die Kommunikation.

    _______________________________________

    Agil ist je nachdem was sie tun 100% NICHT agil.
    Manche soziale-Prozesse und besonders auch IT-Projekte unterliegen einer Pfadabhängigkeit. Diese Pfadabhängigkeit ist die dominante Größe!
    Sie richtet sich leider nicht nach Ihren Interessen,
    sondern nach den guten Erfahrungen der Beteiligten aus alten “Problemen”. ;-)

    Sie können also selbst wenn sie wollen keine großen Haken schlagen
    oder Kurven VOR “schwarzen Schwänen” kriegen.

    Der Punkt ist, sie haben die Chance manche Dinge viel früher zu erkennen
    und können daher früher einlenken. Zudem entsteht ein PROZESS in dem Nutzen generiert wird (auch wenn sich die Ziele ändern sollten).
    Ohne die entspechende Achtsamkeit/Aufmerksamkeit gelingt es aber auch in diesem Prozess nicht… Schieflagen etc. zu erkennen geschweigedenn zu meistern.
    _______________________________________

    Je nachdem was sie unter “unmittelbarer Kommunikation” verstehen,
    können auch sehr große Projekte agil sein.

    Kennt der Leiter bsw. solche Leitsätze:
    “Geh hin und siehe selbst, wenn es ein Problem gibt” kann es bedeuten,
    dass die Kommunikation so gesteuert wird,
    dass die Kommunikation selbst (möglichst) unmittelbar ist.

    Es kann zB bedeuten (muss aber nicht!),
    dass ein Programmierer sein Programm selbst nutzt und beim Kunden selbst schaut,
    wenn es ein Problem gibt und wiederum in Kommunikation (ZB mit anderen Spezialisten) steht. Die moderne Technik macht das rund um die Welt möglich…
    und es müssen dabei nicht alle die gleiche Wellenlänge haben.

    Im nicht SW – Umfeld kann man da tatsächlich schnell an Grenzen stossen.

    _______________________________________

    Alle Projektbeteiligten irgendwie (am besten noch gleichzeitig) an einen Tisch zu setzen und auf einen nachhaltig erfreulichen Verlauf zu setzen, kenne ich nicht.
    Entweder gibt es zuviele Beteiligte oder zu unterschiedliche Wahrnehmungen & Gedächtnisinhalte; Meinungen, Interessen… etc.

    Da kann ich Ihnen also Zustimmen…

    Viele Grüsse
    Bernd

    • Peter Addor says:

      Hallo Bernd

      Vielen Dank für den interessanten Kommentar. Vor allem mit der Pfadabhängigkeit rennst Du bei mir offene Türen ein, obwohl ich ihre Wurzeln nicht nur auf die Erfahrung der Beteiligten reduzieren möchte. Ein gutes Beispiel für Pfadabhängigkeit ist der Mathäuseffekt: “Den Reichen wird gegeben, den Armen wird genommen werden”. Das beruht natürlich nicht auf den Erfahrungen der Reichen und den Armen, sondern ist ein systemimmanenter Effekt.

      Dein Kommentar habe ich nicht 100% verstanden, weil Du ihn sehr stichwortartig verfasst hast. Habe ich Dich richtig verstanden, dass für Dich Inkramentalität auch ein zentrales Kriterium für Agilität ist? Dann sagst Du aber doch, dass es agiles PM gar nicht gebe. Und mit der Beobachtung, dass unmittelbare Kommunikation unter allen Projekt-Stakeholders (fast) unmöglich ist, bist Du anscheinden einverstanden.

      Klar, man kann schwarze Schwäne nicht umgehen, weil sie ja unvorhergesehen sind. Da hilft weder inkrementelles, noch rekursives, noch agiles Vorgehen. Ich meinte, dass wwenn wir sehr aufmerksam das Projektgeschehen beobachten und nur kleine und vorsichtige Schritte machen, wir möglicherweise einen schwarzen Schwan früherkennen und seine Wirkung etwas abschwächen können.

      Gruss,
      Peter

  2. Bernd says:

    Hallo Peter,

    es freut mich zu lesen, dass der Kommentar für Dich von Interesse ist.
    Es war nicht meine Absicht das Thema “Pfadabhängigkeit” zu reduzieren.
    Du hast natürlich recht, wenn Du es weiter fasst.
    Ich wollte nur kurz in einem Satz erläutern, um was es gehen KANN.

    Spannend, dass Du den Mathäuseffekt erwähnst.
    Ich halte ihn (bzw. die Namensvergabe) für einen Denkfehler.
    Aus meiner Sicht ging es dem Verfasser nicht um Arm und Reich
    (im Sinne von Geld haben).

    Die Worte sind:

    “Wer da hat, dem wird gegeben, dass er die Fülle habe.
    Wer aber nicht hat, dem wird auch das genommen, was er hat.”

    …und könnten ganausogut ein Rätsel sein, dessen Lösung zum Beispiel:
    DANKBARKEIT
    heißt.
    Unsere “Vorfokussierung” lässt uns da, glaube ich, schnell in eine Falle tappen.
    Zu den Zeiten als die Zeilen geschrieben wurde, war vielleicht die Organisation des Zusammenlebens (und der eigenen Befindlichkeit) wichtiger als Geld…
    …und wer weiß, vlt spielt ja beim Zinssystem auch die gute Lösung eines alten Problems eine Rolle ;-)

    Doch zurück zum Thema.
    Ja, auch ich halte Inkrementalität für ein zentrales Kriterium und Ralf hat das (finde ich) prima eläutert…
    Im Wiki gibt es auch Bilder zu den Vorgehensmodellen:
    http://de.wikipedia.org/wiki/Inkrementelles_Vorgehensmodell

    Das agile PM, von dem ich nicht glaube, dass es das gibt, ist ein PM,
    dass wie ein Hase hin und her springt und dabei noch alle Ziele erreicht
    und es jedem recht macht etc.

    Mit dem was Du in Bezug auf die Kommunikation beobachtest und auch was Du im letzten Abschnitt schreibst, bin ich sehr einverstanden.
    Aus meiner Perspektive sieht es auch so aus.

    Ich wünsche ein schönes WE!

    Viele Grüße,
    Bernd

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>