Ein­füh­rung

Auch ska­liert-agile Arbeits­formen (vgl. Kon­texte 3 und 4 im Orientierungs­modell) benö­tigen Projekt­manage­ment Kompe­tenzen. Wie sind diese aber in der ver­teilten Füh­rung auf die ver­schie­denen Rollen ver­teilt? Illus­trativ anhand eines Setups gemäss dem ver­brei­teten Scaled Agile Frame­work (SAFe) wird dies hier aufgezeigt.

Hil­fe­stel­lung

Wo ist das Projekt­manage­ment in ska­­liert-agilen Arbeitsformen?

In agiler Arbeits­weise wird ein Pro­dukt durch ein cross-funk­tio­nales Team von 5 bis 12 Mit­glie­dern ent­wi­ckelt und betrieben. Weit ver­breitet ist dafür der Ansatz von Scrum. Der Scrum Guide beschreibt dabei einen grund­sätz­li­chen Ansatz der ver­teilten Ver­antwortung in agilen Organisationen.

Ver­teilte Ver­antwortung in agilen Organisationen

Die typi­schen Auf­gaben, Kompe­tenzen und Ver­antwortung des Pro­jekt­lei­ters werden auf die Rollen Pro­duct Owner, Scrum Master und das Team verteilt:

  • Der Pro­duct Owner ver­ant­wortet das Produkt/​Service und deren inhalt­liche Wei­ter­ent­wick­lung. Er ist im regen Aus­tausch mit den rele­vanten Sta­ke­hol­dern (Kunden, Anwen­dern, Mar­ke­ting, Geschäfts­lei­tung etc.) und bün­delt deren Inter­essen. Die an ihn adres­sierten Pro­dukt-Anfor­de­rungen bricht er in umsetz­bare User Sto­ries auf und prio­ri­siert deren Abar­bei­tung. Er ver­ant­wortet «was» gemacht wird.
  • Der Scrum Master ver­ant­wortet das Enab­ling des Teams. Er sorgt dafür, dass das Team rei­bungslos arbeiten kann, för­dert die Zusam­men­ar­beit und schützt das Team vor Stö­rungen von aussen. Falls Abstim­mungen mit anderen Teams not­wendig sind, koor­di­niert er diese.
  • Das Team ver­ant­wortet «wie» das Pro­dukt her­ge­stellt und betrieben wird. Dazu müssen Per­sonen mit unter­schied­li­chen Fähig­keiten in einem Team – dem so genannten Cross­funk­tio­nalen Team – zusam­men­ge­fasst werden. Oft orga­ni­siert sich ein sol­ches Team selbst, kann bei­spiels­weise auch die Rekru­tie­rung und Kün­di­gung von Team-Mit­glie­dern in Eigen­regie durch­führen. Wei­tere typi­sche Projekt­manage­ment-Dis­zi­plinen, wie Qua­li­täts­ma­nage­ment, Risi­ko­ma­nage­ment etc. werden direkt vom Team übernommen.

Ska­lierte Agilität

Bei grös­seren Pro­dukten arbeiten meh­rere Teams gleich­zeitig an einem Pro­dukt. Hier spre­chen wir von «Ska­lierter Agi­lität», in der zusätz­liche Rollen für die über­grei­fende Pla­nung, Abstim­mung, Steue­rung und Zusam­men­ar­beit not­wendig sind. Dies hat zur Folge, dass Auf­gaben, Kompe­tenzen und Ver­antwortung ent­spre­chend weiter ver­teilt werden.

Wie funk­tio­niert ver­teilte Füh­rung in einem «agile» Setup?

Im Scaled Agile Frame­work (SAFe) werden die Arbeits­pa­kete durch einen Agile Release Train (ART) umge­setzt. Das Steue­rungs­team des ART besteht aus den Rollen Pro­duct Manager (PM), dem Release Train Engi­neer (RTE) und dem System Archi­tect (SA), die gemeinsam das Was, Wann und Wie des Agile Release Trains ver­ant­worten. Sie stimmen sich unter­ein­ander, aber auch mit dem Umfeld lau­fend ab.

Die Rollen sind nicht hier­ar­chisch zu ver­stehen – PM, RTE und SA agieren als «Ser­vant Lea­ders» des ART.

  • Der Pro­duct Manager (PM) arbeitet zusammen mit den Busi­ness Owner und ver­steht dessen Ziele und Prio­ri­täten. Er ent­wi­ckelt und kom­mu­ni­ziert die Stra­tegie, Vision und Roadmap zum Pro­dukt und arbeitet sehr eng mit den Pro­duct Owners. Er ver­ant­wortet die kon­ti­nu­ier­liche Defi­ni­tion, Prio­ri­sie­rung und Vali­die­rung der Fea­tures im Pro­gram Backlog. Der Pro­duct Manager ist ver­ant­wort­lich, dass der erwar­tete Busi­ness Value zu Gunsten seiner Sta­ke­holder gelie­fert wird.
  • Der Release Train Engi­neer (RTE) agiert als Chief Scrum Master (Scrum of Scrum). Der RTE ist für die Lie­fer­qua­lität, die Pro­zess-Steue­rung und Plan­ning & Exe­cu­tion des Trains ver­ant­wort­lich und besei­tigt auf Pro­gramm-Level Hin­der­nisse und Risiken. Der RTE ist für die kon­ti­nu­ier­liche Ver­bes­se­rung des Pro­zesses und für die Durch­füh­rung der ART-Zere­mo­nien (u.a. System Demo, Pro­gram Incre­ment (PI) Plan­ning, Inspect & Adapt) verantwortlich.
  • Der System Archi­tect (SA) ist der tech­ni­sche Experte und für die Erstel­lung und Ein­hal­tung der tech­ni­schen Archi­tektur zuständig. Er unter­stützt die Teams und sorgt für eine über­grei­fende, mit der Enter­prise Archi­tektur abge­stimmte Lösungsarchitektur.

Ein ART besteht typi­scher­weise aus meh­reren Teams, in wel­chen jeweils die durch Scrum beschrie­benen Rollen anzu­treffen sind.

Im Scaled Agile Frame­work (SAFe) werden die Arbeits­pa­kete durch einen Agile Release Train (ART) umge­setzt. Das Steue­rungs­team des ART besteht aus den Rollen Pro­duct Manager (PM), dem Release Train Engi­neer (RTE) und dem System Archi­tect (SA), die gemeinsam das Was, Wann und Wie des Agile Release Trains ver­ant­worten. Sie stimmen sich unter­ein­ander, aber auch mit dem Umfeld lau­fend ab.

Die Rollen sind nicht hier­ar­chisch zu ver­stehen – PM, RTE und SA agieren als «Ser­vant Lea­ders» des ART.

  • Der Pro­duct Manager (PM) arbeitet zusammen mit den Busi­ness Owner und ver­steht dessen Ziele und Prio­ri­täten. Er ent­wi­ckelt und kom­mu­ni­ziert die Stra­tegie, Vision und Roadmap zum Pro­dukt und arbeitet sehr eng mit den Pro­duct Owners. Er ver­ant­wortet die kon­ti­nu­ier­liche Defi­ni­tion, Prio­ri­sie­rung und Vali­die­rung der Fea­tures im Pro­gram Backlog. Der Pro­duct Manager ist ver­ant­wort­lich, dass der erwar­tete Busi­ness Value zu Gunsten seiner Sta­ke­holder gelie­fert wird.
  • Der Release Train Engi­neer (RTE) agiert als Chief Scrum Master (Scrum of Scrum). Der RTE ist für die Lie­fer­qua­lität, die Pro­zess-Steue­rung und Plan­ning & Exe­cu­tion des Trains ver­ant­wort­lich und besei­tigt auf Pro­gramm-Level Hin­der­nisse und Risiken. Der RTE ist für die kon­ti­nu­ier­liche Ver­bes­se­rung des Pro­zesses und für die Durch­füh­rung der ART-Zere­mo­nien (u.a. System Demo, Pro­gram Incre­ment (PI) Plan­ning, Inspect & Adapt) verantwortlich.
  • Der System Archi­tect (SA) ist der tech­ni­sche Experte und für die Erstel­lung und Ein­hal­tung der tech­ni­schen Archi­tektur zuständig. Er unter­stützt die Teams und sorgt für eine über­grei­fende, mit der Enter­prise Archi­tektur abge­stimmte Lösungsarchitektur.

Ein ART besteht typi­scher­weise aus meh­reren Teams, in wel­chen jeweils die durch Scrum beschrie­benen Rollen anzu­treffen sind.

Wie wird die Projekt­manage­ment-Ver­antwortung verteilt?

Wenn ein Pro­jekt kon­se­quent agil auf­ge­setzt wird, ver­teilt sich also die Ver­antwortung der Pro­jekt­lei­tung auf ver­schie­dene Rollen. Beim Wechsel von Kon­text 2 zu Kon­text 3 oder 4 (vgl. Orientierungs­modell) sieht die Ver­tei­lung wie folgt aus – illus­triert am Bei­spiel SAFe:

Was gilt es sonst noch zu beachten?

Zusätz­lich zur Ver­tei­lung der bekannten Kompe­tenzen aus dem Projekt­manage­ment erhalten in agiler Arbeits­weise neue Kompe­tenzen mehr Gewicht. Auf Basis der Refe­renz der IPMA zu Kompe­tenzen im Projekt­manage­ment kann dies wie folgt skiz­ziert werden:

Der Leit­faden der IPMA, Indi­vi­dual Com­pe­tence Base­line, Ver­sion 4.0 (ICB4) in einer agilen Welt beschreibt, wie die Pro­jekt Manage­ment Kompe­tenzen der ICB4 in einer agilen Welt inter­pre­tiert und ergänzt werden können. Damit wird auch die hybride Arbeits­weise, eine Kom­bi­na­tion von klas­si­schen und agilen Ansätzen, erleich­tert. Wie bei der ICB4 gibt es hier drei Kom­pe­tenz­be­reiche: Kon­text (per­spec­tive), Men­schen (people) und Prak­tiken (prac­tice). Jeder Kom­pe­tenz­be­reich umfasst eine Reihe von Kompe­tenzen, ins­ge­samt sind es 29. Jede Kom­pe­tenz beschreibt Wissen, Fer­tig­keiten und Fähig­keiten, die zur Beherr­schung der Kom­pe­tenz erfor­der­lich sind.

Zusätz­lich zur Ver­tei­lung der bekannten Kompe­tenzen aus dem Projekt­manage­ment erhalten in agiler Arbeits­weise neue Kompe­tenzen mehr Gewicht. Auf Basis der Refe­renz der IPMA zu Kompe­tenzen im Projekt­manage­ment kann dies wie folgt skiz­ziert werden:

Der Leit­faden der IPMA, Indi­vi­dual Com­pe­tence Base­line, Ver­sion 4.0 (ICB4) in einer agilen Welt beschreibt, wie die Pro­jekt Manage­ment Kompe­tenzen der ICB4 in einer agilen Welt inter­pre­tiert und ergänzt werden können. Damit wird auch die hybride Arbeits­weise, eine Kom­bi­na­tion von klas­si­schen und agilen Ansätzen, erleich­tert. Wie bei der ICB4 gibt es hier drei Kom­pe­tenz­be­reiche: Kon­text (per­spec­tive), Men­schen (people) und Prak­tiken (prac­tice). Jeder Kom­pe­tenz­be­reich umfasst eine Reihe von Kompe­tenzen, ins­ge­samt sind es 29. Jede Kom­pe­tenz beschreibt Wissen, Fer­tig­keiten und Fähig­keiten, die zur Beherr­schung der Kom­pe­tenz erfor­der­lich sind.

Feed­back geben

Hin­ter­lasse uns hier eine Nach­richt – wir freuen uns auf Feedback!