Agile Missverständnisse: Die Rolle des PMO im Agilen

Arbeitet ein (Software-)Team erfolgreich agil, so wird dies schnell als Möglichkeit gesehen, das auf weitere Teams oder das gesamte Unternehmen auszurollen. Im klassischen Projektmanagement gibt es hier die Funktion des Project Management Office (PMO).

So kommt das Unternehmen also zur Erkenntnis, dass das PMO entscheidende Aufgaben übernehmen sollte. Im klassischen Projektmanagement sind das typischerweise:

• Gewährleistung von einheitlichen PM-Standards und Qualität
• Strategisches Projektmanagement (u. a. Portfolio)
• Operative Unterstützung (z. B. Controlling, Dokumentation, …)
• Koordination von Projekten und Ressourcen
• Effektivitäts- und Effizienzsteigerung (Standards, Richtlinien, Chancen-/Risiken-Management, …)
• Projekt-Coaching und -Training

Nicht selten wird das PMO als „Leitstand“-System betrachtet, von dessen Brücke aus alle Projekt-Aktivitäten in der (Teil-)Organisation betrachtet werden. Der kulturelle Clash mit agilen Werten & Prinzipien ist dabei unübersehbar.

Gewiss, eine Reihe dieser Aufgaben ist für Organisationen wichtig und legitim. Wie können also beide Welten vereint werden?

Agil vs. PMO

Zunächst einmal ist der bedeutendste Unterschied der, dass wir im Agilen häufig von einer Produktentwicklung ausgehen. Damit einher geht eine produktorientierte Denke mit einem (Software-)Produkt, das unterschiedliche Lebenszyklen erlebt. Der Product Owner als Teil des Teams ist idealerweise ein Intrapreneur – oder eben ein „kleiner“ Product Owner. Sehr hilfreich ist hier das „Big vs. Small Product Owner“-Modell von Roman Pichler.

Eine der Kernaufgaben des Product Owners ist die Stakeholder-Kommunikation, sowohl innerhalb der Organisation als auch mit den Endanwendern, die das Produkt nutzen.

Hat man mehrere Teams (jeweils mit mindestens einer Person in der Rolle „Product Owner“) für ein Produkt oder mehrere Produkte, so fällt es nicht schwer, sich ein passendes „PMO“ zu bauen, das die übergreifenden Aufgaben wahrnimmt.

Das neue PMO: die PO-CoP/-Gilde

„Community of Practice“ oder „Gilde“ ist hier das Zauberwort: Das „Agile PMO“ ergibt sich also nicht aus der zusätzlichen Beistellung von Projektleitern/-koordinatoren, sondern formt aus all den Product Ownern der einzelnen Teams eine Interessensgruppe, die sich genau zu obigen Aufgabenbereichen mit entsprechenden Fragestellungen beschäftigt und gemeinsame Praktiken oder gar Standards identifiziert. Solche Fragestellungen könnten also sein:

• Wie sieht ein gutes, transparentes Berichtswesen in unserer Organisation aus? (Burndown/Burnup-Charts, Budget-Burndowns/-Burnups, EPIC-Füllstände, flow-basierte Kanban-Boards aller Produktinitiativen, Dashboards über gelieferten Value wie z. B. Umsatz/Conversions/… aus den Produkten, Team Health Checks, etc.)
• Portfolio-Management: Welche Produktentwicklungen stehen neu an? Wie können sich einzelne Teams neue Produktentwicklungen „ziehen“?
• Projekt-Coaching und -Training: Wie helfen wir uns untereinander? Organisieren wir gemeinsame Slacktime-Open-Spaces, um unser Wissen & Erfahrung zu teilen?
• „Standards“ und „Qualität“: Können wir bei der Product Discovery voneinander lernen? Welche Working Agreements leben wir in den einzelnen Teams, was hat sich (nicht) bewährt? 

Teile dieser Fragestellungen wandern über auf den oder die Scrum Master, die sich ebenfalls in „CoPs“ / „Gilden“ organisieren und austauschen. Erstellt werden sie innerhalb der Teams.

Fazit

Das alte PMO hat in klassischer Zusammensetzung ausgedient. Im Agilen wird ein Fokus auf Value Creation für den Endanwender angestrebt, so dass typische Projekt-Denke zweitrangig wird.

Damit Wert für den Endanwender geschaffen werden kann, ist es wichtig, dass sich die Gruppe der Product Owner regelmäßig trifft und Wissen & Erfahrung miteinander teilt. Gemäß des agilen Prinzips „Inspect & Adapt“ ist ein Streben nach Verbesserung auf der Ebene der Product Owner angesagt.

Für die Kommunikation und das Berichtswesen in die eigene Organisation hinein sind ebenfalls die Product Owner zuständig. Im gemeinsamen Austausch und mit der Vereinbarung von (Makro-)Prinzipien kann eine Etablierung von Good Practices gelingen.

Projektleiter, die „neben“ den Product Ownern stehen, werden in der Regel nicht mehr benötigt. Überall dort, wo schwergewichtiges Berichtswesen in die Organisation hinein gefragt ist, sollten die Alarmglocken schrillen: Wieviel hat dies noch mit Wert-Generierung für den Endanwender zu tun?

Artefakte, die aus den agilen Produktentwicklungsteams per se herausfallen sind ebenso wie ergänzende leichtgewichtige Berichte – idealerweise publiziert im unternehmensinternen Wiki – das neue Berichtswesen.

Ein Teil der Aufgaben fällt den Scrum Mastern in den Produktentwicklungsteams zu, insbesondere was das Einhalten des gewählten agilen Prozess betrifft. Somit sind auch Teile der Aufgabenstellungen in den Teams verteilt und CoPs/Gilden eine gute Organisationsform, um sich teamübergreifend auszutauschen und Good Practices zu etablieren. Das Ausarbeiten von „Standards“ und Füllen des Themas „Qualität“ obliegt den Teams, die sich jedoch ebenfalls übergreifend austauschen sollten, um voneinander zu lernen.

Deine Herausforderungen

Möchtest Du mit mir in einem kurzen Telefonat Deine Herausforderungen in Bezug auf Agile & PMO in Deiner Organisation diskutieren? Dann vereinbare einen kostenfreien telefonischen Beratungstermin mit mir.

Unsere Serie Agile Missverständnisse