Einführung
Auch skaliert-agile Arbeitsformen (vgl. Kontexte 3 und 4 im Orientierungsmodell) benötigen Projektmanagement Kompetenzen. Wie sind diese aber in der verteilten Führung auf die verschiedenen Rollen verteilt? Illustrativ anhand eines Setups gemäss dem verbreiteten Scaled Agile Framework (SAFe) wird dies hier aufgezeigt.
Hilfestellung
Wo ist das Projektmanagement in skaliert-agilen Arbeitsformen?
In agiler Arbeitsweise wird ein Produkt durch ein cross-funktionales Team von 5 bis 12 Mitgliedern entwickelt und betrieben. Weit verbreitet ist dafür der Ansatz von Scrum. Der Scrum Guide beschreibt dabei einen grundsätzlichen Ansatz der verteilten Verantwortung in agilen Organisationen.
Verteilte Verantwortung in agilen Organisationen
Die typischen Aufgaben, Kompetenzen und Verantwortung des Projektleiters werden auf die Rollen Product Owner, Scrum Master und das Team verteilt:
- Der Product Owner verantwortet das Produkt/Service und deren inhaltliche Weiterentwicklung. Er ist im regen Austausch mit den relevanten Stakeholdern (Kunden, Anwendern, Marketing, Geschäftsleitung etc.) und bündelt deren Interessen. Die an ihn adressierten Produkt-Anforderungen bricht er in umsetzbare User Stories auf und priorisiert deren Abarbeitung. Er verantwortet «was» gemacht wird.
- Der Scrum Master verantwortet das Enabling des Teams. Er sorgt dafür, dass das Team reibungslos arbeiten kann, fördert die Zusammenarbeit und schützt das Team vor Störungen von aussen. Falls Abstimmungen mit anderen Teams notwendig sind, koordiniert er diese.
- Das Team verantwortet «wie» das Produkt hergestellt und betrieben wird. Dazu müssen Personen mit unterschiedlichen Fähigkeiten in einem Team – dem so genannten Crossfunktionalen Team – zusammengefasst werden. Oft organisiert sich ein solches Team selbst, kann beispielsweise auch die Rekrutierung und Kündigung von Team-Mitgliedern in Eigenregie durchführen. Weitere typische Projektmanagement-Disziplinen, wie Qualitätsmanagement, Risikomanagement etc. werden direkt vom Team übernommen.
Skalierte Agilität
Bei grösseren Produkten arbeiten mehrere Teams gleichzeitig an einem Produkt. Hier sprechen wir von «Skalierter Agilität», in der zusätzliche Rollen für die übergreifende Planung, Abstimmung, Steuerung und Zusammenarbeit notwendig sind. Dies hat zur Folge, dass Aufgaben, Kompetenzen und Verantwortung entsprechend weiter verteilt werden.
Wie funktioniert verteilte Führung in einem «agile» Setup?
Im Scaled Agile Framework (SAFe) werden die Arbeitspakete durch einen Agile Release Train (ART) umgesetzt. Das Steuerungsteam des ART besteht aus den Rollen Product Manager (PM), dem Release Train Engineer (RTE) und dem System Architect (SA), die gemeinsam das Was, Wann und Wie des Agile Release Trains verantworten. Sie stimmen sich untereinander, aber auch mit dem Umfeld laufend ab.
Die Rollen sind nicht hierarchisch zu verstehen – PM, RTE und SA agieren als «Servant Leaders» des ART.
- Der Product Manager (PM) arbeitet zusammen mit den Business Owner und versteht dessen Ziele und Prioritäten. Er entwickelt und kommuniziert die Strategie, Vision und Roadmap zum Produkt und arbeitet sehr eng mit den Product Owners. Er verantwortet die kontinuierliche Definition, Priorisierung und Validierung der Features im Program Backlog. Der Product Manager ist verantwortlich, dass der erwartete Business Value zu Gunsten seiner Stakeholder geliefert wird.
- Der Release Train Engineer (RTE) agiert als Chief Scrum Master (Scrum of Scrum). Der RTE ist für die Lieferqualität, die Prozess-Steuerung und Planning & Execution des Trains verantwortlich und beseitigt auf Programm-Level Hindernisse und Risiken. Der RTE ist für die kontinuierliche Verbesserung des Prozesses und für die Durchführung der ART-Zeremonien (u.a. System Demo, Program Increment (PI) Planning, Inspect & Adapt) verantwortlich.
- Der System Architect (SA) ist der technische Experte und für die Erstellung und Einhaltung der technischen Architektur zuständig. Er unterstützt die Teams und sorgt für eine übergreifende, mit der Enterprise Architektur abgestimmte Lösungsarchitektur.
Ein ART besteht typischerweise aus mehreren Teams, in welchen jeweils die durch Scrum beschriebenen Rollen anzutreffen sind.
Im Scaled Agile Framework (SAFe) werden die Arbeitspakete durch einen Agile Release Train (ART) umgesetzt. Das Steuerungsteam des ART besteht aus den Rollen Product Manager (PM), dem Release Train Engineer (RTE) und dem System Architect (SA), die gemeinsam das Was, Wann und Wie des Agile Release Trains verantworten. Sie stimmen sich untereinander, aber auch mit dem Umfeld laufend ab.
Die Rollen sind nicht hierarchisch zu verstehen – PM, RTE und SA agieren als «Servant Leaders» des ART.
- Der Product Manager (PM) arbeitet zusammen mit den Business Owner und versteht dessen Ziele und Prioritäten. Er entwickelt und kommuniziert die Strategie, Vision und Roadmap zum Produkt und arbeitet sehr eng mit den Product Owners. Er verantwortet die kontinuierliche Definition, Priorisierung und Validierung der Features im Program Backlog. Der Product Manager ist verantwortlich, dass der erwartete Business Value zu Gunsten seiner Stakeholder geliefert wird.
- Der Release Train Engineer (RTE) agiert als Chief Scrum Master (Scrum of Scrum). Der RTE ist für die Lieferqualität, die Prozess-Steuerung und Planning & Execution des Trains verantwortlich und beseitigt auf Programm-Level Hindernisse und Risiken. Der RTE ist für die kontinuierliche Verbesserung des Prozesses und für die Durchführung der ART-Zeremonien (u.a. System Demo, Program Increment (PI) Planning, Inspect & Adapt) verantwortlich.
- Der System Architect (SA) ist der technische Experte und für die Erstellung und Einhaltung der technischen Architektur zuständig. Er unterstützt die Teams und sorgt für eine übergreifende, mit der Enterprise Architektur abgestimmte Lösungsarchitektur.
Ein ART besteht typischerweise aus mehreren Teams, in welchen jeweils die durch Scrum beschriebenen Rollen anzutreffen sind.
Wie wird die Projektmanagement-Verantwortung verteilt?
Wenn ein Projekt konsequent agil aufgesetzt wird, verteilt sich also die Verantwortung der Projektleitung auf verschiedene Rollen. Beim Wechsel von Kontext 2 zu Kontext 3 oder 4 (vgl. Orientierungsmodell) sieht die Verteilung wie folgt aus – illustriert am Beispiel SAFe:
Was gilt es sonst noch zu beachten?
Zusätzlich zur Verteilung der bekannten Kompetenzen aus dem Projektmanagement erhalten in agiler Arbeitsweise neue Kompetenzen mehr Gewicht. Auf Basis der Referenz der IPMA zu Kompetenzen im Projektmanagement kann dies wie folgt skizziert werden:
Der Leitfaden der IPMA, Individual Competence Baseline, Version 4.0 (ICB4) in einer agilen Welt beschreibt, wie die Projekt Management Kompetenzen der ICB4 in einer agilen Welt interpretiert und ergänzt werden können. Damit wird auch die hybride Arbeitsweise, eine Kombination von klassischen und agilen Ansätzen, erleichtert. Wie bei der ICB4 gibt es hier drei Kompetenzbereiche: Kontext (perspective), Menschen (people) und Praktiken (practice). Jeder Kompetenzbereich umfasst eine Reihe von Kompetenzen, insgesamt sind es 29. Jede Kompetenz beschreibt Wissen, Fertigkeiten und Fähigkeiten, die zur Beherrschung der Kompetenz erforderlich sind.
Zusätzlich zur Verteilung der bekannten Kompetenzen aus dem Projektmanagement erhalten in agiler Arbeitsweise neue Kompetenzen mehr Gewicht. Auf Basis der Referenz der IPMA zu Kompetenzen im Projektmanagement kann dies wie folgt skizziert werden:
Der Leitfaden der IPMA, Individual Competence Baseline, Version 4.0 (ICB4) in einer agilen Welt beschreibt, wie die Projekt Management Kompetenzen der ICB4 in einer agilen Welt interpretiert und ergänzt werden können. Damit wird auch die hybride Arbeitsweise, eine Kombination von klassischen und agilen Ansätzen, erleichtert. Wie bei der ICB4 gibt es hier drei Kompetenzbereiche: Kontext (perspective), Menschen (people) und Praktiken (practice). Jeder Kompetenzbereich umfasst eine Reihe von Kompetenzen, insgesamt sind es 29. Jede Kompetenz beschreibt Wissen, Fertigkeiten und Fähigkeiten, die zur Beherrschung der Kompetenz erforderlich sind.
Weiterführende Literatur und Links
Feedback geben
Hinterlasse uns hier eine Nachricht – wir freuen uns auf Feedback!
