Die Rolle des Product Owners in skalierten Organisationen · 2017-11-21 · 3 Die Evolution von...

Die Rolle des Product Owners in skalierten Organisationen

Stephan M. Rossbach

2

Schön dass wir hier sind!

• Freier agiler Coach und Berater für Agile Transformation

• Seit >13 Jahren „agil infiziert“ (Scrum, Kanban, XP)

• Pragmatischer Methodiker

http://www.agile-ants.com https://www.linkedin.com/in/stephanrossbach https://www.xing.com/profile/StephanM_Rossbach

3

Die Evolution von agilen Organisationen

Wasserfall Agile Entwicklung und agile Test-/

Deploymentchain

Erste agile Gehversuche

(z.B. Pilotprojekt)

Funktionierende agile Entwicklung

Skalierte agile Organisation (viele Teams,

viele Streams)

4

Product Owner in einem nicht skalierten Team

Dev Team

Product Owner

Scrum Master

Aufgaben: • Verantwortet das Backlog eines Streams

• Entwickelt eine Product Vision und vermitteltdiese an das Team

• Nimmt an den Scrum Events teil bzw. verantwortet diese

• Betreibt Stakeholder Management

5

Ab einem Punkt gilt: Scale or fail!Grund: • Steigende Zahl von Stakeholdern

• Steigende Komplexität von Produktanforderungen

• Steigende Zahl von Scrum Teams

• Es entstehen Bottlenecks, oft beim Product Owner; die Wertschöpfung gerät ins Stocken

Besondere Herausforderungen für den Product Owner: • Sicherstellung der konstanten Kommunikation und des Feedbacks an das DevTeam

• Vermittlung der Product Vision an die Teams und der Roadmaps an die Stakeholder

• Antizipation von fachlichen Abhängigkeiten zwischen den Product Backlogs

• Sinnvolle Priorisierung über mehrere Backlogs hinweg

!

6

Bei Wachstum passiert oft dieses

UX Team

Product Owner

Product Owner

Product Owner

Product Owner

Web Dev Team

Backend Dev Team QA Team

Probleme:

• People sharing —> Konflikte

• Kommunikations-Bottlenecks

• Jeder Product Owner arbeitet an „seinem“ Backlog.

• Jeder Product Owner arbeitet für „seine“ Prioritäten

• Die Teams bekommen keine einheitliche Kommunikation

• Der Fokus auf die gemeinsame Product Vision geht verloren.

7

Variante 1: Product Owner in mehreren unabhängigen Workstreams

Dev Team

Product Owner

Scrum Master

Dev Team

Product Owner

Scrum Master

Dev Team

Product Owner

Scrum Master

8

Funktioniert besonders gut, wenn • Sicherstellung des Feedbacks an das DevTeam • Antizipation von Abhängigkeiten zwischen Product Backlogs • Sinnvolle Priorisierung über mehrere Backlogs hinweg

Besondere Herausforderungen für den Product Owner: • Keine großen Änderungen gegenüber einzelnen Workstreams

Product Owner in mehreren unabhängigen Workstreams (2)

9

Product Owner in voneinander abhängigen Workstreams

Dev Team

Product Owner

Scrum Master

Dev Team

Product Owner

Scrum Master

Dev Team

Product Owner

Scrum Master

Ziele Prioritäten

Funktionale Abhängigkeiten

Ziele Prioritäten

Funktionale Abhängigkeiten

10

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 Product Roadmap bestehen

• Keine Workstream-übergreifende Product Vision besteht

Besondere Herausforderungen für den Product Owner: • 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!

Product Owner in mehreren abhängigen Workstreams (2)

11

Wie organisieren eigentlich bekannte Unicorns ihr Wachstum?

12

Dev Team

Scrum Master

Dev Team

Scrum Master

Dev Team

Scrum Master

Chief Product Owner

Product Owner

Product Owner

Product Owner

Product Management Scrum Team

Chief Product Owner

Product Owner

Product Owner

Product Owner

Product Management Scrum Team

Das Product Management Scrum Team organisiert sich wie ein Scrum 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 Product Vision und Roadmap

14

Feature Teams/Vertical Teams

Product Owner

Feature C

Scrum Master

Feature A Feature B

Platform Architect

Backend Dev Team

UX Team

Web Dev Team

QA Team

Backend Dev Team

UX Team

Web Dev Team

QA Team

Backend Dev Team

UX Team

Web Dev Team

QA Team

Scrum Master

Scrum Master

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 Product Owner: • Antizipation von Abhängigkeiten zwischen Product Backlogs (Hilfe durch Platform Architect empfehlenswert)

• Sinnvolle Strukturierung & Priorisierung über mehrere Backlogs hinweg

• Teilnahme an den Scrum Events von allen Feature Teams

16

Squads, Tribes & Guilds

Scrum Master

Backend Dev Team

UX Team

Web Dev Team

QA Team

Product Owner

Scrum Master

Backend Dev Team

UX Team

Web Dev Team

QA Team

Product Owner

Scrum Master

Backend Dev Team

UX Team

Web Dev Team

QA Team

Product Owner

Scrum Master

Backend Dev Team

UX Team

Web Dev Team

QA Team

Product Owner

Web Technologie Guild

Tribe Squad

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 Product Owner: • Kontinuierliche Kommunikation mit den Squads, Tribes & Guilds in einem vernünftigen Maß

• Abstimmung mit anderen Product Ownern, z.B. in einer Guild, um eine einheitliche Product Vision zu vermitteln.

18

Zusammenfassung

• Es gibt kein „Silver Bullet“ für Product Owner in skalierten Organisationen.

• Es gibt aber einige Best Practices und Beispiele, wie es funktionieren kann.

• Bei funktional trennbaren Komponenten sind Feature Teams/Verticals/Squadseine gute Möglichkeit die Organisationen zu skalieren.

• Der Product Owner ist die „zerbrechlichste“ Rolle in skalierenden Organisationen

• Der Aufwand des Product Owners für Kommunikation steigt durch „aufgefächerte“Kommunikationswege - dies sollte bei der Skalierung beachtet werden.

19

Vielen Dank & viel Spass beim Skalieren!

Bei Fragen, gerne fragen.

http://www.agile-ants.com https://www.linkedin.com/in/stephanrossbach https://www.xing.com/profile/StephanM_Rossbach