agil ist besser !?

Bricht hier jetzt der Missionierungseifer aus, trete ich der agilen Religion bei und werde zum Propheten? Ich bin durchaus ein Anhänger des agilen Manifestes insbesondere des Punktes “teams and interactions over processes and tools” und eine gefühlte Erfahrung, dass agile Ansätze sehr gut wenn nicht sogar besser als klassische funktionieren, habe ich auch. Dabei will ich es aber nicht belassen. Inzwischen liegen mir auch Zahlen vor. Nebenstehend ist nochmals eine Aufschlüsselung der Vorgehensweisen nach erfolgreichen bzw. nicht erfolgreichen Projekten gezeigt. Die Zahlenbasis entspricht der detaillierten Aufschlüsselung im vorangegangenen Beitrag, die explizit benannten agilen Vorgehensweisen wurden für diese Darstellung zusammengefasst und ein Teil der Mehrfachnennungen ausgeschlossen. Agile Vorgehensweisen werden offensichtlich häufiger in erfolgreichen Projekten eingesetzt. Lässt sich aus obiger Grafik der Schluss ziehen, dass agile Vorgehensweisen per se besser sind? Nein. Meine Interpretation ist eine andere: Agile Vorgehensweisen sind in den meisten Fällen adäquater, weil viele Projekte agil sind! Im aktuellen Fragebogen ist auch eine kleine und entscheidende Frage enthalten: “Waren die Anforderungen bereits zu Beginn des Projekts bekannt?” Die Antworten zeigt die zweite Grafik. Nur in rund 7% der untersuchten Projekte waren alle Anforderungen zu Beginn bekannt. In knapp 26% waren zumindest 80% der Anforderungen bekannt. In allen übrigen wurde ein wesentlicher Teil der Anforderungen erst im Laufe des Projektes ermittelt. Mit anderen Worten nur in einem Drittel der Projekte wäre eine klassische Vorgehensweise (Planung – Changemanagement – Plananpassung) angebracht. Spätestens wenn die Hälfte der Anforderungen erst im Laufe des Projektes ermittelt werden (können) sollte man sich eingestehen, dass der erste Projektplan, der immer noch oft genug als das Maß der Dinge gesehen wird, nur eine erste Näherung gewesen sein kann. Es wäre ehrlicher und dem Projekterfolg dienlicher richtig agil zu arbeiten. Ich interpretiere die scheinbar höhere Erfolgsquote agiler Vorgehensweisen also folgendermaßen: In vielen Projekten lassen sich aus unterschiedlichen Gründen die Anforderungen erst im Laufe des Projektes klären. Wenn agile Vorgehensweisen gewählt werden ist schlicht und ergreifend die Wahrscheinlichkeit höher die Anforderungen richtig aufzunehmen und umzusetzen. Es gibt jedoch nach wie vor Projektsituationen in denen klassische Methoden besser sind – wenn die Anforderungen tatsächlich schon weitgehend zu Beginn klar sind macht eine agile Vorgehensweise wenig Sinn. Es gilt daher rechtzeitig zu entscheiden welche Vorgehensweise für das konkrete Projekt die passendere ist.

9 thoughts on “agil ist besser !?

  1. Hallo Frankk,

    sorry für meine späte Antwort, an Wochenenden und Feiertagen ruht der Blog meistens. Danke für die weiterführenden Gedanken. Gerade dieser Satz

    Ich gehe davon aus, dass zu Beginn eines Projekts ‘Anforderungen’ eine unbekannte Größe ist.

    scheint mir entscheidend zu sein. Wenn wirkliche alle Anforderungen bekannt und klar wären, wäre es (überspitzt formuliert) fast schon kein Projekt mehr. Ich denke auch, dass der Weg einer “kommunikativen Projektleitung” beschritten werden muss. Gelungene Kommunikation und echte Identifikation des Teams mit den Zielen sind wichtiger als ein “Methoden-Etikett”. Hierzu habe ich noch den einen oder anderen Beitrag in Vorbereitung

    viele Grüße Eberhard

  2. Hallo Eberhard.
    Deiner Beschreibung der Situation, dass meistens “teams and interactions over processes and tools” eine zu Recht gefühlte Erfahrung sind, stimme ich zu. Ich habe allerdings zwei Probleme mit der Analyse: Ich meine, dass agile Ansätze sehr gut mit(!) klassischen funktionieren, weil nur verschiedene Formen der Kommunikation – das wäre mein Schlüssel einer PM-Analyse – gemeinsam zu Erfolg führen. “Expect and plan the change of your plan and expectations” verlangt eine Variation der Projektführung, d.i. Kommunikation! Die Variation der Kommunikation reicht von impliziter oder expliziter Methode, einschl. eines Tools, über präzise Zielsetzung (tasks- objectives – goals oder andersherum), klare strukturierte und gesteuerte Kommunikation (plan your work and work your plan) bis zu Disziplin (wie gut, ehrlich und zielführend geht man miteinander um?) des Projektteams. Was dann unter den Abschnitt ‘agil’ fällt, wäre bestenfalls im Nachhinein festzustellen. Und auch die agile Kommunikation ist insoweit klar zu strukturieren, um nachvollziehbar und nachweislich Ergebnisse zu präsentieren.
    Das ‘ex post’ gilt ja auch für die Antworten auf die Frage, wieviel Prozent der Ziele waren bekannt. Das wäre mein zweiter Aspekt zur Bedeutung der Analyse. Ich gehe davon aus, dass zu Beginn eines Projekts ‘Anforderungen’ eine unbekannte Größe ist.
    Neu ist das m.E. alles nicht, denn das bekannte “tailoring” von Methoden setzte schon immer die Adaption agiler Prozesse und Kommunikation voraus.
    Herzliche Grüße
    Frank

  3. Hallo Bernhard,

    danke für das SAP Beispiel, immer besteht die Wahl nicht, aber wahrscheinlich öfter als man denkt – zu dem Thema habe ich noch was in Arbeit.

    Das mit dem Vergleich des Erfolgs sehe ich inzwischen entspannter. Egal wann und wie Anforderungen erhoben wurden und wie und in welchem Rythmus sie implemetiert wurden, dem Kunde ist wichtig, dass die umgesetzt werden. Zeit und Budget scheinen dabei nicht ganz so wichtig zu sein. Wenn viele wichtigen Parameter erhoben werden (Anforderungen, Erhebungzeit, Budget, Planänderungen, Kundenzufriedenheit) lässt es sich doch ganz passabel vergleichen.

    http://www.pentaeder.de/projekte/2010/09/08/wann-sind-kunden-mit-einem-projekt-zufrieden/

    viele Grüße Eberhard

  4. Hallo Eberhard,

    du bringst es auf den Punkt:
    Die Anforderungen sind häufig noch nicht fix bei Projektbeginn – aber diese definieren letztlich den Maßstab für den Projekterfolg. Somit ist es kein Wunder, dass bei agilen Projekten eine höhere Erfolgswahrscheinlichkeit besteht. Schließlich definieren sie ihren Erfolgsmaßstab erst im Laufe des Projekts und profitieren von der Lernkurve.

    Aber haben wir wirklich eine Wahl zwischen agil und klassisch? Ganz sicher nicht in allen Fällen. Ich habe noch kein Szenario für z.B. eine SAP Implementierung, die agil in vielen Sprints realisiert wurde, gesehen. Bei manchen Themen ist ein GoLive erst möglich, wenn eine “kritische Masse” erreicht wurde. Das heißt aber auch, dass sich die Erfolgsbeurteilung über derart unterschedliche Projektszenarien nur schwer vergleichen lässt.

    Gruß
    Bernhard

Comments are closed.

© pentaeder 2019 / 2020