in Agilität, Erfolgskriterien, Literaturtipps, Planung, Standards

Es muss funktionieren!

PMI hat mit Disciplined Agile (DA) einen integrativen Ansatz entwickelt, dessen vier Kernaussagen ich voll unterstützen kann. Die deutsche Übersetzung ist sperrig, daher zitiere ich das Original:

  1. Context counts: Es kommt darauf an, in welchem Umfeld und mit welchen Zielen und Ressourcen ein Projekt abzuwickeln ist.
  2. Choice is good: Es ist gut, dass wir auswählen können und nicht sklavisch Vorgaben folgen müssen. Das ist risikoreich und anstrengend, man kann sich bei Fehlern nicht auf eine Vorgabe berufen, die man wortgetreu umgesetzt hat.
  3. We should optimize workflow: Es kommt immer darauf an, die Leistung des Projektes zu optimieren: Wie können wir mehr in der verfügbaren Zeit erledigen und dabei nachhaltig erfolgreich sein?
  4. We want to be awesome: Klingt vielleicht etwas befremdlich im Business-Kontext, aber es ist richtig: Wir wollen zufriedene Kunden als Minimum, streben aber begeisterte Kunden an. Leider sind zu viele IT-Organisationen damit beschäftigt, die Anforderungen ihrer Kunden abzuwehren oder zumindest auf das gerade noch hingenommene Mindestmaß zu reduzieren.

DA wendet sich gegen Ansätze, die sich agil nennen, in Wirklichkeit aber starre Regelwerke sind. SAFe eignet sich besonders dafür, denn man kann aus den definierten Meetings mit vorgeschriebenen Intervallen und Rollen ein bürokratisches Monster erzeugen, das AINO ist, „Agile in name only“.

DA hat einen wunderbaren Begriff kreiert, den man ebenfalls nicht gleichwertig ins Deutsche übersetzen kann: WoW (Way of Work). Jedes Projektteam muss seinen WoW finden, um die eingangs genannten Postulate zu erfüllen; die Doppeldeutigkeit von Wow ist natürlich nicht zufällig (siehe Punkt 4 oben). Tailoring, die Anpassung der Projektorganisation, der Entscheidungs- und Steuerungsprozesse, der Teamzusammensetzung etc. an den spezifischen Kontext ist die größte Herausforderung. Und es ist keine einmalige Aktion, sondern erfordert einen kontinuierlichen Verbesserungsprozess (siehe Abbildung 1).

Abbildung 1: Kontinuierlicher Verbesserungsprozess (© PMI, Choose your WoW, 2022)

Man sieht, dass DA in völliger Übereinstimmung mit der Empfehlung von Bruce Lee ist.

Wie löst DA aber die Gefahr der völligen Orientierungslosigkeit und Beliebigkeit, denn mit dem einfachen Rat: „Mache es irgendwie, nur richtig!“, ist uns auch nicht geholfen. Und wie vermeidet man, erst wieder ein überladenes System an Vorschriften zu werden?

Zunächst verabschiedet sich DA vom Anspruch, bestehende Projektmanagement-Paradigmen zu ersetzen und positioniert sich als „agnostische Sammlung guter Ideen“, wobei diese nicht auf die bekannten agilen Ansätze beschränkt sind (siehe Abbildung 2).

Abbildung 2: DA ist eine agnostische Sammlung guter Ideen (© PMI, Choose your WoW, 2022)

Beim Umgang mit diesen guten Ideen denken wir wieder an Bruce Lee.

Was sind besonders gute Ideen, die man sorgfältig auf ihre Eignung im konkreten Kontext prüfen sollte. Ich nenne einige Beispiele aus meiner persönlichen Sicht, wobei weder die Liste der Paradigmen noch die der dort angeführten guten Ideen vollständig ist:

  • Die fixe Taktung von Ergebnispräsentationen (Sprints) und das strikte Ablehnen von Terminverschiebungen, weil man nicht fertig geworden sei in Scrum.
  • Die für alle transparente Visualisierung des Arbeitsfortschritts je Arbeitspaket sowie die Reduktion der gleichzeitig bearbeiteten Arbeitspakete (WIP: Work in Progress) im Kanban.
  • Strikte Ausrichtung der Priorisierung von Arbeiten an der Auslastung des Engpasses („Constraint“) und Verzicht auf Puffer in den einzelnen Arbeitspaketen zu Gunsten eines Puffers auf Gesamtprojektebene im Critical Chain Project Management (CCPM).
  • Die enge Zusammenarbeit zwischen Business und IT, Testgetriebene Entwicklung sowie Pair Programming im XP (Extreme Programming ist meiner Meinung nach einer der meist unterschätzten Ansätze in der agilen Welt).
  • Anwendung agiler Prinzipien auf die Zusammenarbeit von Software-Entwicklung und Betrieb und verkürzte Deployment-Zyklen in DevOps.
  • Gesamtsicht auf die zu leistende Arbeit in Form eines Projekt-Strukturplans und Erarbeitung eines durchgängigen Meilensteinplans im Wasserfallmodell.
  • Synchronisation parallel laufender Entwicklungsstränge in einem fixen Rhythmus von 3 Monaten (Program Increment) und interaktive Abstimmung in Form eines standardisierten Meetings aller Beteiligten (PI-Planning) im SAFe.

Und wer sagt, dass man diese guten Ideen nicht kombinierten kann oder darf? Nur Dogmatiker und die tun das aus einer Position der Schwäche, sie fühlen sich durch die Wahlfreiheit überfordert.

DA bietet aber mehr an als nur eine Aufforderung, gute Ideen zu nutzen, egal woher sie kommen. Zunächst gibt es eine enorm hilfreiche Darstellung jener Faktoren, die den Kontext eines Projektes bestimmen (siehe Abbildung 3).

Abbildung 3: Faktoren, die den Kontext eines Projektes determinieren (© PMI, Choose your WoW, 2022)

Für mich ist diese Darstellung allein hinreichend, um die Absurdität jedes „One size fits all“-Ansatzes zu demonstrieren. Wofür ist z.B. Scrum ideal und ausreichend? Man verbinde die jeweils innersten Punkte mit einer Linie, dann hat man die ideale Konstellation für Scrum, in einzelnen Dimensionen kann man mit Scrum auch noch die nächste Stufe gut abdecken, aber je weiter man nach außen geht, umso weniger wird man mit Scrum das Auslangen finden, obwohl für einzelne Aufgabenbereiche trotzdem Scrum der beste Ansatz sein kann.

Ich gehe hier nicht darauf ein, wie in DA die Wahl des Vorgehensmodells gestaltet wird, das würde den Rahmen dieses Newsletters sprengen. Es ist auch meiner persönlichen Meinung nach nicht der stärkste Teil von DA, hier hat man wohl auch aus Marketing-Gründen versucht, SAFe etwas entgegen zu setzen und begibt sich damit in die Gefahr, auch die Nachteile von SAFe zu reproduzieren.

Uneingeschränkt genial finde ich allerdings den Ansatz, die Wahl des besten Vorgehens innerhalb der einzelnen Aufgabenbereiche zu unterstützen. Ich greife hier den Bereich der Anforderungsanalyse heraus (siehe Abbildung 4). Die Gesamtaufgabe wird in Teilaufgaben heruntergebrochen und zu jeder Teilaufgabe werden mögliche Umsetzungsansätze genannt. Teilweise ist es eine ungeordnete Liste an Möglichkeiten, wo besonders empfohlene Optionen durch Fettdruck hervorgehoben werden. In einigen Fällen gibt es einen empfohlenen Entwicklungspfad (durch einen Pfeil dargestellt), dort signalisiert der Fettdruck, welche Option jedenfalls angestrebt werden sollte, nicht immer ist es die am höchsten gereihte Option.

Abbildung 4: Optionen für die Umsetzung der Prozessziele der Scopedefinition (© PMI, Choose your WoW, 2022)

Der DA-Standard beinhaltet zahlreiche solcher Diagramme. Natürlich ist es sinnvoll und entspricht dem Grundgedanken von DA, für die jeweils gegebene Situation zu überlegen, ob man Optionen ergänzt oder streicht und ob man diese anders bewertet als es hier erfolgt ist. Idealerweise sollte in einem Unternehmen, das agil arbeitet, die Weiterentwicklung solcher Diagramme Teil der Organisationsentwicklung sein.

Wer jetzt motiviert ist, sich mit Disciplined Agile näher zu beschäftigen, findet hier die weiterführenden Links:

Homepage Discipline Agile

Das Buch als idealer Einstieg

Schreibe einen Kommentar

Kommentar