
Als Fachgruppenleitung PMO bei der GPM ist es mir wichtig zu zeigen, wie das Agile Fluency Model unterschiedliche Wege in die Agilität sichtbar macht – und wie ein PMO diese Perspektive nutzen kann, um sinnvolle Entscheidungen für das Projektportfolio zu treffen. Sobald ein PMO agile Methoden in Teams lehren und einführen soll, gilt: “Choose your battle” – es braucht eine klare Vorstellung, welche Art von Agilität für welche Projekte wirklich geeignet ist und welche Investitionen Organisation und PMO dafür leisten wollen.[1][2][3]

In vielen Projekten – etwa bei SaaS-Plattformen oder digitalen Produkten – entscheiden sich Organisationen für agile Ansätze, um schneller nutzbare Ergebnisse zu liefern, Wert für Nutzerinnen und Nutzer zu schaffen und anpassungsfähiger zu werden. Das Agile Fluency Model von Diana Larsen und James Shore dient hier als Navigationshilfe: Es beschreibt, welche unterschiedlichen „Fluency-Zonen“ es gibt, welche Verhaltensmuster Teams dort zeigen und welche Rahmenbedingungen nötig sind, damit Agilität mehr wird als ein Methoden-Label.[2][4][1]
Larsen und Shore nutzen dabei das Bild einer Sprache: Teams beginnen mit einem Basisvokabular, können aber – je nach Nutzungskontext – auf einem einfachen „Urlaubsniveau“ bleiben oder sich zu einem hohen, souveränen „Sprachniveau“ entwickeln; entscheidend ist, wofür die Organisation Agilität tatsächlich benötigt.[3][5]
In der Praxis erleben viele PMOs denselben Verlauf: Nach einem Scrum-Training werden Dailys eingeführt, Boards visualisieren Tickets, und das Management erwartet kurzfristig deutliche Produktivitätssteigerungen. Das PMO erhält den Auftrag, alle Mitarbeitenden in agilen Methoden zu schulen – aber Entscheidungswege, Rollenverständnis und Struktur bleiben unverändert, sodass das Ganze eher wie ein neues Ritual wirkt als wie ein echter Wandel.[4][1]
Der Journalist Eliot Beer beschreibt dieses Phänomen als „Agile Theatre“: Es wird mit agilen Begriffen und Frameworks gearbeitet, ohne dass sich die dahinterliegenden Werte und Organisationsstrukturen ändern – mit entsprechend begrenztem Mehrwert für Kundinnen, Kunden und Geschäft. Das Agile Fluency Model hilft, diese Falle zu vermeiden, weil es sichtbar macht, dass unterschiedliche Zielbilder unterschiedliche Investitionen erfordern und nicht jedes Team dieselbe Art von Agilität braucht.[6][1][2]

Das Modell unterscheidet vier Fluency-Zonen, die jeweils andere Kompetenzen, Rahmenbedingungen und Investitionen voraussetzen – und damit für ein PMO eine wichtige Entscheidungsgrundlage darstellen.[1][4]
Das Agile Fluency Model macht deutlich, dass die Entwicklung von Fluency keine „Über-Nacht-Transformation“ ist, sondern ein Weg mit Lernkurven, Plateaus und Rückschritten. Auf Basis ihrer Erfahrung nennen Larsen und Shore grobe Orientierungswerte, bis Teams typische Muster in den Zonen zeigen: Focusing benötigt etwa 2–6 Monate, Delivering 3–24 Monate, Optimizing kann 1–5 Jahre beanspruchen, während für Strengthening bewusst keine konkrete Zeitspanne angegeben wird, da sie stark von der organisationellen Veränderungsbereitschaft abhängt.[1][3]
Für ein PMO sind diese Zahlen wichtig, um Stakeholdern realistisches Erwartungsmanagement zu bieten: Wer in kurzfristigen Projekten in wenigen Monaten „Optimizing-Fluency“ erwartet, wird systematisch enttäuscht – und überfordert Teams mit unrealistischen Transformationsansprüchen.[9][3]

Larsen und Shore beschreiben Agilität als Busfahrt: Teams sitzen im „Fluency-Bus“, doch die Organisation bezahlt das Ticket – sprich, sie entscheidet, welche Zonen sie finanziell, strukturell und kulturell unterstützt. Nicht jedes Team muss alle vier Haltestellen ansteuern; gerade in klassischen Projektportfolios kann es sinnvoll sein, dass viele Teams bei Focusing aussteigen, einige bei Delivering bleiben und nur ausgewählte, strategische Produktteams in Richtung Optimizing weiterfahren.[3][1]
In der Praxis – etwa bei LCSI SaaS Operations – zeigt sich, dass in kurzlaufenden Projekten mit bisher nicht agil arbeitenden Teams ein Fokus auf Focusing oft der größte Hebel ist: gemeinsame Ziele, Transparenz und nachvollziehbare Ergebnisse reichen hier aus, um spürbare Verbesserungen zu erzielen, ohne unrealistische Optimizing-Ansprüche aufzubauen. In langfristigen SaaS-Produkten mit kontinuierlicher Weiterentwicklung lohnt sich hingegen die gezielte Investition in Delivering und Optimizing, da fluente Teams hier direkt zur Produktstrategie und Marktorientierung beitragen können.[10][4][8][1]
Für ein PMO ergeben sich daraus einige Leitfragen, um den „richtigen Pfad“ in die Agilität zu wählen:[1][3]
Das Agile Fluency Model hat sich in der praktischen Arbeit mit Kundinnen und Kunden bewährt, weil es allen Beteiligten – von Teams über PMO bis hin zu Sponsorinnen und Sponsoren – ein gemeinsames Vokabular gibt, um über „Agilität, aber passend“ zu sprechen: Welche Zone ist für dieses Projekt sinnvoll, welche Investitionen sind realistisch und welcher Nutzen ist zu erwarten. Damit wird Agilität weniger zum Dogma und mehr zu einer bewussten Portfolio-Entscheidung, die das PMO aktiv mitgestalten kann.[2][4][1]
[1] The Agile Fluency Model martinfowler.com/articles/agileFluency.html
[2] The Agile Fluency Model www.agilefluency.org/model.php
[3] AoAD2 Chapter: Choose Your Agility www.jamesshore.com/v2/books/aoad2/choose_your_agility
[4] The Agile Fluency Model with Diana Larsen www.scrum.org/resources/blog/agile-fluency-model-diana-larsen
[5] The Agile Fluency Model ® — Diana Larsen www.youtube.com/watch
[6] The battle for Agile's soul: Is Agile Theatre taking over? - The Stack www.thestack.technology/future-of-agile-theatre-agiles-soul-the-stack/
[7] AoAD2 Chapter: Invest in Agility - James Shore www.jamesshore.com/v2/books/aoad2/invest_in_agility
[8] Let's Unfix McKinsey's Helix Organization unfix.com/blog/lets-unfix-helix
[9] AoAD2 Chapter: How to Be Agile - James Shore www.jamesshore.com/v2/books/aoad2/how_to_be_agile
[10] Agile Fluency® Modell — Diana Larsen für Hands-on ... berlin-product-people.com/de/agile-fluency-modell-diana-larsen-hands-on-agile-meetup-46/
Keine Kommentare
Stefanie Hanschkatz ist Fachgruppenleiterin PMO bei der GPM und seit vielen Jahren auf Projekt- und Multiprojektmanagement spezialisiert, insbesondere auf den Aufbau wirksamer PMOs und die Steuerung von Mehrprojektsituationen. Beruflich verantwortet sie als Head of Transformation Platform Services bei der LCSI GmbH den IT-Betrieb und die Weiterentwicklung von Plattformlösungen für die öffentliche Verwaltung. Engagiert verbindet sie strategische Steuerung mit pragmatischen Ansätzen wie dem „Minimum Viable PMO“, um Organisationen schnell zu messbarem Projektnutzen zu führen.
s.hanschkatz@gpm-ipma.de
Kommentare