© Liashko/Shutterstock.com
Entwickler Magazin
Alternativen zur Rolle des Product Owners, oder: Wie bleiben wir agil?

Die Skalierung von Agilität in großen Organisationen

Scrum ist definiert für einzelne Teams und in dieser Größenordnung gut erprobt, umfangreich beschrieben und weit verbreitet. Bei einem Einsatz von Scrum in großen Unternehmen und bei der Entwicklung eines gemeinsamen Produkts durch eine große Anzahl von Teams werden wir in der Praxis aber zunächst allein gelassen: Literatur wie auch Erfahrungsberichte haben bislang keine Patentrezepte geliefert [1], [2], [3]. Die Realität zeigt jedoch große Herausforderungen. Ein zentrales Problem bei der Skalierung von Scrum ist die Skalierung der Rolle des Product Owners. Er wird schnell zum Bottleneck. Wie organisieren wir die Aufgaben der Product-Owner-Rolle in einer großen Organisation mit einer Vielzahl agiler Teams, die an einem gemeinsamen Produkt arbeiten? Dieser Artikel diskutiert Lösungsansätze und beschreibt eine favorisierte Organisationsstruktur im Detail.

Patrick Daut


Video: Softwarearchitektur in agilen Teams - Vom Elfenbeinturm zur Selbstorganisation

Der Product Owner als Bottleneck? Um uns den tatsächlichen Herausforderungen bei der Arbeit mit ­Scrum in einer großen Organisation anzunähern, stellen wir uns die Arbeit in und die Zusammenarbeit zwischen einer großen Zahl von Scrum-Teams vor. In der Praxis ist in der Regel jedem Team ein eigener Product Owner zugeordnet. Steigt die Anzahl der Teams, die gemeinsam an einem Produkt arbeiten, entsteht Abstimmungsbedarf zwischen den Product Ownern. Hier liegt ein zentrales Problem bei der Skalierung von Scrum: Die Rolle des Product Owners und damit die Anforderungsseite beziehungsweise die Beziehung zum Kunden skaliert nicht, der Product Owner ist ein Bottleneck.

Der Product Owner in großen Organisationen

Wie kommt es zu diesem zentralen Engpass? Gehen wir davon aus, dass in einer großen Organisation eine Abteilung typischerweise größer als ein ideales Scrum-Team ist, so müssen kleinere Teams gebildet werden. Das heißt also, mit der Einführung von Scrum werden Teams und Abteilungen in kleinere Teams zerlegt, um deren jeweilige Größe zu begrenzen. Dadurch entsteht eine – theoretisch beliebig hohe – Anzahl von Teams, die meist höher ist als die Anzahl der Abteilungen. Gehen wir weiter davon aus, dass diese Teams an einem einzigen gemeinsamen Produkt arbeiten. Die Herausforderung ist hier eine organisatorische: Da Scrum selbst den Fall mehrerer Teams nicht betrachtet, ist zunächst der Umgang damit nicht definiert. Naheliegend ist die Möglichkeit, jedem Team einen dedizierten Product Owner zuzuordnen. Doch wie stellen wir dann die Konsistenz des Gesamtprodukts sicher? Es besteht ein Koordinationsbedarf zwischen den Product Own­ern. Um diesen zu decken, muss eine Organisationsstruktur geschaffen werden, die im Scrum-Framework so zunächst nicht beschrieben ist.

Betrachten wir andererseits die Möglichkeit, allen Teams nur einen einzigen gemeinsamen Product Own­er zur Verfügung zu stellen, so besteht das beschriebene Problem nicht: Es gibt eine einzige Person mit der inhaltlichen Verantwortung für das Produkt. Allerdings muss der Product Owner dann mit steigender Anzahl von Teams zum Flaschenhals werden: Neben der Priorisierung von Anforderungen beinhaltet die Product-Owner-Rolle weiterhin die Aufgabe, während der Detaillierung von Anforderungen bzw. während deren Umsetzung dem Team als zentraler Ansprechpartner und ggf. als zentraler Kanal zum Kunden zur Verfügung zu stehen...

Entwickler Magazin
Alternativen zur Rolle des Product Owners, oder: Wie bleiben wir agil?

Die Skalierung von Agilität in großen Organisationen

Scrum ist definiert für einzelne Teams und in dieser Größenordnung gut erprobt, umfangreich beschrieben und weit verbreitet. Bei einem Einsatz von Scrum in großen Unternehmen und bei der Entwicklung eines gemeinsamen Produkts durch eine große Anzahl von Teams werden wir in der Praxis aber zunächst allein gelassen: Literatur wie auch Erfahrungsberichte haben bislang keine Patentrezepte geliefert [1], [2], [3]. Die Realität zeigt jedoch große Herausforderungen. Ein zentrales Problem bei der Skalierung von Scrum ist die Skalierung der Rolle des Product Owners. Er wird schnell zum Bottleneck. Wie organisieren wir die Aufgaben der Product-Owner-Rolle in einer großen Organisation mit einer Vielzahl agiler Teams, die an einem gemeinsamen Produkt arbeiten? Dieser Artikel diskutiert Lösungsansätze und beschreibt eine favorisierte Organisationsstruktur im Detail.

Patrick Daut


Video: Softwarearchitektur in agilen Teams - Vom Elfenbeinturm zur Selbstorganisation

Der Product Owner als Bottleneck? Um uns den tatsächlichen Herausforderungen bei der Arbeit mit ­Scrum in einer großen Organisation anzunähern, stellen wir uns die Arbeit in und die Zusammenarbeit zwischen einer großen Zahl von Scrum-Teams vor. In der Praxis ist in der Regel jedem Team ein eigener Product Owner zugeordnet. Steigt die Anzahl der Teams, die gemeinsam an einem Produkt arbeiten, entsteht Abstimmungsbedarf zwischen den Product Ownern. Hier liegt ein zentrales Problem bei der Skalierung von Scrum: Die Rolle des Product Owners und damit die Anforderungsseite beziehungsweise die Beziehung zum Kunden skaliert nicht, der Product Owner ist ein Bottleneck.

Der Product Owner in großen Organisationen

Wie kommt es zu diesem zentralen Engpass? Gehen wir davon aus, dass in einer großen Organisation eine Abteilung typischerweise größer als ein ideales Scrum-Team ist, so müssen kleinere Teams gebildet werden. Das heißt also, mit der Einführung von Scrum werden Teams und Abteilungen in kleinere Teams zerlegt, um deren jeweilige Größe zu begrenzen. Dadurch entsteht eine – theoretisch beliebig hohe – Anzahl von Teams, die meist höher ist als die Anzahl der Abteilungen. Gehen wir weiter davon aus, dass diese Teams an einem einzigen gemeinsamen Produkt arbeiten. Die Herausforderung ist hier eine organisatorische: Da Scrum selbst den Fall mehrerer Teams nicht betrachtet, ist zunächst der Umgang damit nicht definiert. Naheliegend ist die Möglichkeit, jedem Team einen dedizierten Product Owner zuzuordnen. Doch wie stellen wir dann die Konsistenz des Gesamtprodukts sicher? Es besteht ein Koordinationsbedarf zwischen den Product Own­ern. Um diesen zu decken, muss eine Organisationsstruktur geschaffen werden, die im Scrum-Framework so zunächst nicht beschrieben ist.

Betrachten wir andererseits die Möglichkeit, allen Teams nur einen einzigen gemeinsamen Product Own­er zur Verfügung zu stellen, so besteht das beschriebene Problem nicht: Es gibt eine einzige Person mit der inhaltlichen Verantwortung für das Produkt. Allerdings muss der Product Owner dann mit steigender Anzahl von Teams zum Flaschenhals werden: Neben der Priorisierung von Anforderungen beinhaltet die Product-Owner-Rolle weiterhin die Aufgabe, während der Detaillierung von Anforderungen bzw. während deren Umsetzung dem Team als zentraler Ansprechpartner und ggf. als zentraler Kanal zum Kunden zur Verfügung zu stehen...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang