Die Rolle des Product Owners in skalierten Organisationen. Stephan M. Rossbach

Größe: px

Ab Seite anzeigen:

Download "Die Rolle des Product Owners in skalierten Organisationen. Stephan M. Rossbach"

Peter Böhme
vor 5 Jahren
Abrufe

1 Die Rolle des s in skalierten Organisationen Stephan M. Rossbach

Jahren agil infiziert (, Kanban, XP) Pragmatischer Methodiker

2 Schön dass wir hier sind! Freier agiler Coach und Berater für Agile Transformation Seit >13 Jahren agil infiziert (, Kanban, XP) Pragmatischer Methodiker

3 Die Evolution von agilen Organisationen Wasserfall Erste agile Gehversuche (z.b. Pilotprojekt) Funktionierende agile Entwicklung Skalierte agile Organisation (viele Teams, viele Streams) Agile Entwicklung und agile Test-/ Deploymentchain 3

4 in einem nicht skalierten Team Aufgaben: Verantwortet das Backlog eines Streams Entwickelt eine Vision und vermittelt diese an das Team Nimmt an den Events teil bzw. verantwortet diese Betreibt Stakeholder Management 4

5 Ab einem Punkt gilt: Scale or fail! Grund: Steigende Zahl von Stakeholdern Steigende Komplexität von Produktanforderungen Steigende Zahl von Teams! Es entstehen Bottlenecks, oft beim ; die Wertschöpfung gerät ins Stocken Besondere Herausforderungen für den : Sicherstellung der konstanten Kommunikation und des Feedbacks an das DevTeam Vermittlung der Vision an die Teams und der Roadmaps an die Stakeholder Antizipation von fachlichen Abhängigkeiten zwischen den Backlogs Sinnvolle Priorisierung über mehrere Backlogs hinweg 5

6 Bei Wachstum passiert oft dieses Probleme: People sharing > Konflikte Kommunikations-Bottlenecks Jeder arbeitet an seinem Backlog. Jeder arbeitet für seine Prioritäten UX Team Web Die Teams bekommen keine einheitliche Kommunikation Der Fokus auf die gemeinsame Vision geht verloren. Backend QA Team 6

7 Variante 1: in mehreren unabhängigen Workstreams 7

8 in mehreren unabhängigen Workstreams (2) Funktioniert besonders gut, wenn Sicherstellung des Feedbacks an das DevTeam Antizipation von Abhängigkeiten zwischen Backlogs Sinnvolle Priorisierung über mehrere Backlogs hinweg Besondere Herausforderungen für den : Keine großen Änderungen gegenüber einzelnen Workstreams 8

9 in voneinander abhängigen Workstreams Ziele Prioritäten Funktionale Abhängigkeiten Ziele Prioritäten Funktionale Abhängigkeiten 9

10 in mehreren abhängigen Workstreams (2) Funktioniert besonders gut, wenn Workstreams wirklich funktional voneinander unabhängig oder hinreichend abstrahiert sind (das sind sie bei näherer Betrachtung allerdings eher selten) Keine Abhängigkeiten in der Roadmap bestehen Keine Workstream-übergreifende Vision besteht Besondere Herausforderungen für den : Kollision von Prioritäten zwischen Workstreams (oder schlimmer: Ignorieren von Prioritäten zwischen Workstreams) Ellbogenmentalität zwischen POs durch Ziele, die nicht aufeinander einzahlen Nutzung von Shared people ist niemals dauerhaft funktionabel! 10

11 Wie organisieren eigentlich bekannte Unicorns ihr Wachstum? 11

12 Management Team Chief 12

13 Management Team Chief Das Management Team organisiert sich wie ein Team, incl. Sprint Planning, Review Retro and Dailies Hilfreich bei/für die gemeinsame Sicht auf übergeordnete Prioritäten das Antizipieren von fachlichen Abhängigkeiten von Epics/Stories mehrerer Streams das Entwickeln und Sicherstellen einer übergreifenden Vision und Roadmap

14 Feature Teams/Vertical Teams Platform Architect Feature A Feature B Feature C Backend Dev Team Backend Dev Team Backend Dev Team UX Team UX Team UX Team Web Web Web QA Team QA Team QA Team 14

15 Feature Teams/Vertical Teams End to end Verantwortlichkeit des Teams für ein bestimmtes Feature: You build it, you run it! Funktioniert besonders gut, wenn Es fachlich voneinander unabhängige Funktionsteile gibt. Es eine gewisse Knowhow-Homogenität in den Teams gibt. Test-Driven Development gesetzt ist Besondere Herausforderungen für den : Antizipation von Abhängigkeiten zwischen Backlogs (Hilfe durch Platform Architect empfehlenswert) Sinnvolle Strukturierung & Priorisierung über mehrere Backlogs hinweg Teilnahme an den Events von allen Feature Teams 15

16 Squads, Tribes & Guilds Tribe Squad Web Technologie Guild Web Web Web Web Backend Dev Team Backend Dev Team Backend Dev Team Backend Dev Team UX Team UX Team UX Team UX Team QA Team QA Team QA Team QA Team 16

17 Squads, Tribes & Guilds Think it, build it, ship it, tweak it. Funktioniert besonders gut, wenn Selbst organisierende Teams bereits etabliert sind. Besondere Herausforderungen für den : Kontinuierliche Kommunikation mit den Squads, Tribes & Guilds in einem vernünftigen Maß Abstimmung mit anderen n, z.b. in einer Guild, um eine einheitliche Vision zu vermitteln. 17

18 Zusammenfassung Es gibt kein Silver Bullet für in skalierten Organisationen. Es gibt aber einige Best Practices und Beispiele, wie es funktionieren kann. Bei funktional trennbaren Komponenten sind Feature Teams/Verticals/Squads eine gute Möglichkeit die Organisationen zu skalieren. Der ist die zerbrechlichste Rolle in skalierenden Organisationen Der Aufwand des s für Kommunikation steigt durch aufgefächerte Kommunikationswege - dies sollte bei der Skalierung beachtet werden. 18

19 Vielen Dank & viel Spass beim Skalieren! Bei Fragen, gerne fragen

Ähnliche Dokumente

Scrum skaliert: Wie wir das Exoskelett Nexus mit Leben füllen

Scrum skaliert: Wie wir das Exoskelett Nexus mit Leben füllen Entwicklertag 2017 Karlsruhe 23. Mai 2017 Marion Gakstatter Agile Coach Felix Schad Agile Coach Agenda Skalierung bedeutet. dass für ein Produkt