Projektmanagement

Drei fatale Begründungen für agiles Vorgehen

alarm

Es gibt viele sehr gute Gründe, sich für ein agiles Vorgehen im Projekt zu entscheiden. Zum Beispiel weil man an die Kreativität, Motivation und Eigenverantwortung der Mitarbeiter glaubt. Und weil man der festen Überzeugung ist, dass eine Organisationsform und ein Vorgehen, das auf diese Prinzipien setzt, für das Finden innovativer Lösungen in komplexen Situationen überlegen ist. Oder weil man nicht exakt das Ziel und den Umfang des Projekts kennt, weil man Neuland betritt. Neben diesen und vielen weiteren guten Gründen für ein agiles Vorgehen, gibt es aber auch einige sehr fatale Begründungen, die auf grundsätzliche Missverständnisse zurückgehen und das Vorhaben von Anfang an in Frage stellen.

Andere machen es doch auch!

Agile is like teen sex: Everyone wants to do it, many say they're doing it, only some actually are, and very few are doing it right.
via @hmans auf Twitter

Alle kennen die Geschichten erfolgreicher agiler Projekte. Nicht alle haben sich genau so zugetragen. Manches verklärt sich in der Rückschau und manches wird bewusst zu Werbezwecken überhöht. In vielen Fällen engt sich der Blick des neidisch auf solche Erfolgsgeschichten blickenden Entscheiders auf die agilen Methoden als solche. Ausgeblendet wird dabei gerne das Umfeld der Projekts und insbesondere die Kultur und die Werte der Unternehmen, die diese Projekte erfolgreich agil durchgeführt haben. Überträgt man nun einfach ein erfolgreiche Methode wie Scrum, die ja auch noch so verführerisch einfach daherkommt, in ein Umfeld das nicht die notwendigen Voraussetzung dafür aufweist, muss dieser Versuch zwangsläufig scheitern.

Beispielsweise setzt agiles Vorgehen unbedingt eine vertrauensvolle Zusammenarbeit aller Beteiligten auf Augenhöhe voraus. Nicht umsonst heißt es im Agilen Manifest „Customer collaboration over contract negotiation.“ Wenn aber schon Fachabteilung und IT-Abteilung im gleichen Unternehmen sich nicht ganz grün sind und Lieferanten grundsätzlich nur für Gewerke zum Festpreis eventuell mit entsprechenden Vertragsstrafen versehen eingekauft werden, wird es mit Vertrauen und Augenhöhe eher schwierig.

Wir fangen einfach schon Mal an!

„Wir gehen agil vor!“ ist das neue „Fangt einfach schon Mal an!“
via @marcusraitner auf Twitter

Ein weit verbreiteter Irrglaube besagt, dass man agil vorgehend weniger genau über Anforderungen und Prozesse nachdenken muss. Das Gegenteil ist tatsächlich der Fall: Es wird sehr viel mehr über Anforderungen und Prozesse gesprochen. Nämlich so lange bis das Team es verstanden hat und richtig umsetzen kann. Und das ist auch gut so. Wer also glaubt, ohne die nötigen Kapazitäten für diese Klärungen einfach Mal loslegen zu können, wird schnell stecken bleiben, weil das Team ohne fachliche Klärungen durch einen starken Product Owner nicht arbeiten kann.

Wer nicht genau weiß, wohin er will, der darf sich nicht wundern, wenn er ganz woanders ankommt.
Mark Twain

Tatsächlich geschieht die Diskussion der Anforderungen später als im gewohnten Wasserfallmodell und daher rührt dann auch der falsche Eindruck, dass man mit weniger oder weniger genauer Spezifikation auskommen könne. Verstärkt wird der Eindruck noch dadurch, dass tatsächlich in der Regel weniger niedergeschriebene Spezifikation vor der eigentlichen Softwareerstellung existiert. Schließlich geht es nicht darum, Papier zu bedrucken, sondern Software zu produzieren, welche die Prozesse optimal unterstützt: „Working Software over comprehensive documentation.“ heißt es dazu im Agilen Manifest.

Wir müssen verlorene Zeit aufholen!

Man verliert die meiste Zeit damit, dass man Zeit gewinnen will.
John Steinbeck

Das weitaus am meisten verbereitete Missverständnis ist es aber, mit agiler Vorgehensweise Zeit aufholen zu wollen. Agil heißt nicht schnell, sondern meint wendig. Es geht darum, die Richtung möglichst leicht und effizient ändern zu können. „Responding to change over following a plan.“ heißt es dazu im Agilen Manifest.

Natürlich liefert eine agile Vorgehensweise schneller erste Zwischenergebnisse, um schnell Rückmeldung zu erhalten und die Richtung entsprechend korrigieren zu können. Wenn es aber darum geht, ein fest vorgegebenes Ziel, einen klaren Umfang, möglichst schnell zu erreichen, kann man das auch agil tun, wird auf die gesamte Laufzeit betrachtet aber eher nicht schneller sein.

Fazit

Ich bin der letzte der nicht gerne agil vorgeht, aber eben nur wenn es zum Projekt und zum Umfeld passt. Daher frage ich immer nach, warum eine agile Vorgehensweise gewählt wurde oder werden soll. Will man Zeit aufholen, ohne Verzögerung einfach loslegen oder es anderen gleich tun, ist höchste Vorsicht geboten. Keinesfalls sollte man sich als Projektleiter ein agiles Vorgehen unter solchen Bedingungen diktieren lassen, sondern vielmehr Aufklärungsarbeit leisten und gemeinsam mit Auftraggeber und Entscheidern ein passendes Vorgehen finden und ein günstigeres Umfeld schaffen.

8 Kommentare

  1. Ja, ich denke auch, dass der Einsatz agiler Methoden mit zahlreichen Erwartungen verbunden ist. Und dass oft geglaubt wird, dass durch den Einsatz der richtigen Methode automatisch das Problem gelöst wird.

    Aber wie Sie ja zeigen ist das Ganze mit Erwartungen und einer damit einhergehenden inneren Haltung verbunden: Alles möglichst effizient und schnell erfolgreich durchzuführen.

    Und dabei offensichtlich zu vergessen, dass man in einem Team arbeitet und alle nur dann dabei sind, wenn sie auch verstanden haben worum es eigentlich geht. Und dieses Verständnis herzustellen kostet eben Zeit.

    Mit welcher Methode auch immer.

    Herzliche Grüße und eine schöne Arbeitswoche
    Martina Baehr

  2. Hallo Marcus,

    Ich glaube, dass dieselben 3 Argumente sehr wohl genutzt werden können, um doch endlich mal aus der Sackgasse des ewig gleichen Scheiterns raus zu kommen:

    .) andere tun’s doch auch:
    Klassiker ist, dass eine Führungskraft in anderen Organisationen damit erfolgreich war und nun tatsächlich etwas mit neuen Ansätzen bessere Produkte, Services etc liefern will. Sehr häufig findet man daher in vielen Unternehmen die Argumentation vor: „Agil, ja aber …“. Ein erfahrenes und überlegtes Vorgehen macht genau das möglich, was tatsächlich woanders bereits funktioniert. Perfekte Voraussetzungen zu ersinnen ist wenig hilfreich (und auch bei Erfolgsgeschichten selten der Fall gewesen). Es benötigt aber umschauende Herangehensweisen.

    .) Wir fangen einfach schon mal an
    Spitz formuliert, aber gar nicht so verkehrt. Eine zeitlich begrenzte erste Iteration, die nötigen Rahmenbedingungen, Klärungen, detaillierten Festlegungen – und dann möglichst rasch ein fokussiertes, hypothesen- und lernorientiertes Zusammenarbeiten auf Grundlage vielfältiger Feedbackschleifen ist der Kern des Erfolgs. Anforderungen und Prozesse in Vorfeldern möglichst genau verstehen zu wollen, ist meist mit / ohne Agil ein Problem. Immer zielführend und kriegsentscheidend ist Klarheit über das Warum, über das Wer, für Wen, ohne sich in detaillierten Prozessen und Anforderungen zu verlieren. Ja, gesprochen, analysiert und dokumentiert wird „genau so viel wie es braucht“. Das bedeutet aber auch, dass Teams nicht unbedingt Zeit vergeuden, um sehr gut zu verstehen, was gar keinen effektiven Sinn ergibt. Verstehen über das Wirken von Deliverables ist Teil des Realisierungsprozesses, gepaart mit aktivem Nutzen von Feedbackschleifen. Schlüssel ist jedoch, verstehen des Umfelds, des Zwecks, der Annahmen, der Validierbarkeit, der Möglichkeiten zur Zusammenarbeit. Wir sprechen daher von einer völlig anderen Herangehensweise, die sich nicht bloß darüber differenziert, wann wieviel spezifiziert wird.

    .) Verlorene Zeit aufholen
    Why not? Natürlich nicht, indem schneller gearbeitet oder derselbe Umfang (womöglich wieder fix … und ohne genau zu wissen, warum).

    Du siehst schon, der konservative Agil-Zugang, in seiner Konsequenz:
    – „geht doch bei uns nicht so wie bei denen“
    – „agil ja, aber erst genau spezifizieren“
    – „schneller geht halt nicht“

    … ist trotz guter Anregung Deiner 3 Kernfragen nicht unbedingt über den Tellerrand gedacht ;) Ohne ein Hasardieren anregen zu wollen, ist aber genau dieses „Freidenken neuer Optionen“ die grundsätzliche Basis, um am Ende nicht bloß sagen zu müssen: tja, wir machen Agil, wir machen’s vernünftig, fühlt sich gut an, haben wir eigentlich ja immer schon so gemacht, hat auch keine nennenswerten Verbesserungen gebracht ;)

    lg, Mike

    • Vielen Dank für Deinen ausführlichen Kommentar, lieber Mike! Daraus spricht natürlich Deine große Erfahrung. Wir sind uns absolut einig, dass jedes meiner drei Argumente auch einen guten Kern hat, den Du super schön herausgearbeitet hast. Zu dem Kern muss man aber erst Mal kommen und das wollte ich durch Hinterfragen erreichen. Du hast die Fragen einfach noch ein ganzes Stück weiter gedacht. In meiner Wahrnehmung ist es aber leider oft so kurz gedacht, wie ich es beschrieben habe. Ich habe beispielsweise nichts dagegen, loszulegen und schnell Ergebnisse zu liefern und dadurch zu lernen. Wenn dahinter bei allen Beteiltigten insbesondere im höheren Management das richtige Verständnis herrscht. Und das Verständnis endet ganz oft, wenn die erste Lieferung zwar sehr lehrreich, aber im Wesentlichen ein Fehlschlag ist.

  3. Hallo Marcus,

    tolle Denkanstöße wieder!

    Magst Du den auf Initiative Wirtschaftsdemokratie wieder einklinken?

    LG Martin

    p.s.: Der Blog hat konstant über 20.000 Besucher pro Monat :-)

  4. Pinkback: Drei fatale Begründungen für agiles Vorgehen | Initiative Wirtschaftsdemokratie

  5. Pinkback: Agiles Projektmanagement | Dr. Rainer Feldbrügge

Schreibe einen Kommentar

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