Agile Fluency: Unterschiedliche Wege zur gelebten Agilität im PMO

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]

Warum Agilität unterschiedliche Pfade braucht

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]

Agile Praktiken: Mehr als nur Methodenanwendung

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]

Die vier Fluency-Zonen und was sie für das PMO bedeuten

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]

  1. Focusing: Teams beherrschen die agilen Grundlagen, arbeiten sichtbar an gemeinsamen Prioritäten und erzeugen Transparenz über Business Value und Fortschritt. Für ein PMO eignet sich diese Zone besonders für kurzlaufende oder einmalige Projekte, in denen vor allem Zusammenarbeit, Fokus und Nachvollziehbarkeit verbessert werden sollen – etwa bei Projekten in der öffentlichen Verwaltung, in denen Markt- und Produktverantwortung bewusst außerhalb des Projektteams liegen.[7][1]
  2. Delivering: In dieser Zone liefern Teams in einem verlässlichen Takt qualitativ hochwertige, einsatzfähige Software oder Services, gestützt durch Praktiken wie automatisierte Tests, Continuous Integration und stabile Delivery-Pipelines. Für das PMO ist wichtig: Der Aufbau dieser technischen Exzellenz braucht Zeit und oft signifikante Investitionen, weshalb er sich besonders für längerfristige Produkt- und Plattformteams lohnt, nicht aber zwingend für temporäre Projektteams.[3][1]
  3. Optimizing: Teams verstehen Markt, Nutzerbedürfnisse und Geschäftsmodell ihres Produkts und treffen eigenverantwortlich Entscheidungen, welche Features echten Mehrwert bringen und welche Ideen verworfen werden. Typischerweise arbeiten hier cross-funktionale Teams mit Produktmanagement- und Marketingkompetenzen; für ein PMO kann diese Zone ein Zielbild für strategische, marktnahe Produktinitiativen sein, weniger jedoch für interne Infrastrukturprojekte.[8][1]
  4. Strengthening: Teams dieser Zone wirken über das eigene Produkt hinaus und treiben die Weiterentwicklung der gesamten Organisation voran, indem sie mit anderen Teams, Führung und zentralen Funktionen zusammenarbeiten. Larsen und Shore betonen, dass diese „Zukunftszone“ aktuell nur selten dauerhaft erreicht wird, aber wertvolle Impulse für Organisationsgestaltung und Portfolio-Governance liefern kann – ein wichtiger Anknüpfungspunkt für strategisch ausgerichtete PMOs.[5][1][3]

Agilität braucht Zeit – Erfahrungswerte für das PMO

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]

„Der Bus in die Agilität“: Welche Teams steigen wo aus?

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]

Worauf sollte das PMO konkret achten?

Für ein PMO ergeben sich daraus einige Leitfragen, um den „richtigen Pfad“ in die Agilität zu wählen:[1][3]

  • Welche Projekte benötigen vor allem bessere Zusammenarbeit, Transparenz und Priorisierung (Focusing), und wo würde ein breiter Ausbau technischer Praktiken die verfügbaren Ressourcen überstrapazieren? 
  • Wo sind stabile, langfristige Produkt- oder Plattformteams vorhanden, bei denen sich die Investition in Delivering-Fluency – inklusive Automatisierung und technischer Exzellenz – wirtschaftlich und strategisch lohnt? 
  • Welche wenigen, strategischen Produktinitiativen sollen wirklich Optimizing erreichen, also Markt- und Produktverantwortung im Team bündeln, und ist die Organisation bereit, entsprechende Budgets, Entscheidungsbefugnisse und Rollen anzupassen? 

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]

Quellen

[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/

Kommentare

* Diese Felder sind erforderlich

Keine Kommentare

Autoren

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