Der Product Owner und das Team: Anatomie einer Beziehung

Zur Rolle des Product Owners gehört eine ganze Menge. Der Product Owner soll eine mitreißende Produktvision haben, sein Backlog immer schön pflegen und darüber hinaus den Business Value nicht aus den Augen verlieren. Das allein kann es jedoch nicht gewesen sein. Es gibt genügend Product Owner, die all diese Tätigkeiten gut bis sehr gut beherrschen - und dennoch nicht wirklich in ihrer Rolle angekommen sind, mit ihrem neuen Amtsverständnis hadern und fremdeln. Oftmals liegt das daran, dass der Product Owner nicht im Scrum-Team angekommen ist.Ein klassischer Projektleiter weiß, in welcher Beziehung er zu seinem Team steht. Er führt seine Mitarbeiter direkt oder indirekt, teilt ihnen Aufgaben und Verantwortlichkeiten zu. Dem Product Owner ist diese Form des Zugangs zum Team verwehrt. Das Entwicklungsteam soll ja selber entscheiden, wie viel es schafft und wer die Aufgaben erledigt. Die so verstandene Autonomie des Entwicklungsteams kann abschreckend wirken - ein Product Owner, der mit seinen Wünschen und Vorstellungen immer wieder abprallt, zieht sich gerne in seine Ecke zurück.

Scrum-Fernbeziehungen sind gefährlich

Wenn wir von Scrum-Teams reden, denken wir immer noch viel zu oft nur an das Entwicklungsteam. Das ist auch irgendwie logisch. Schließlich ist es das Entwicklungsteam, das Stories bearbeitet und am Ende des Sprints liefert. Der Product Owner wird dabei gerne in eine externe Rolle gedrängt: Nach diesem Verständnis beschränken sich seine Aufgaben auf die Versorgung mit Stories und die Abnahme an Ende des Sprints.

copyright Gerhard Peyrer

Das sieht dann so aus: Der Product Owner macht seine Arbeit. Das Entwicklungsteam macht seine Arbeit. Man trifft sich zu den Plannings und Estimation Meetings, und damit soll es gut sein.Partnerschaften funktionieren so nicht. Scrum auch nicht. Der ganze Sinn und Zweck von Scrum besteht ja darin, das Abteilungsdenken aufzulockern, die Grenzen durchlässiger zu machen und die interdisziplinäre Kommunikation zu verdichten. In klassisch geführten Projekten brütet der Produktmanager im stillen Kämmerlein seine Produkte aus, schreibt dutzende Seiten zusammen - und mutet dann seinen Entwicklern zwei Dinge zu: Erstens das ganze Dokument zu lesen und zweitens die Produktidee dann auch noch so umzusetzen, wie er sich das gedacht hat.

Krieg der Welten, neu inszeniert

Dass das nicht funktionieren kann, weiß jeder Schüler, der sich mit Textinterpretation beschäftigt hat. Sobald die Tinte trocken ist, lösen sich die Gedanken vom Autor und entwickeln ein eigenes Leben. Dinge können so oder so ausgelegt werden - und was für die Fachseite völlig klar zu sein schien, kann für die Entwickler etwas komplett anderes bedeuten. Gregor Gramlich, agiler Entwickler, hat in einem köstlichen Theaterstück mal einen Auftraggeber gespielt, der von einem Entwickler eine App zum Verwalten von Basketball-Spielen haben wollte. Das ging dann ungefähr so:Auftraggeber: [...] Ja, und dann sollen die Spieler mit ihren Rückennummern aufgeführt werden.Entwickler: Ja, klar. Jeder Spieler soll anhand einer Nummer identifiziert werden. Wollte ich sowieso so machen. Was für Nummern sind das denn?Auftraggeber: Puh, das können alle einstelligen und zweistelligen Nummern sein.Entwickler: Gut. Aber zwei Spieler können nicht die gleiche Nummer haben - oder?Auftraggeber: Wie meinst du das - im gleichen Team?Entwickler: Ja, genau.Auftraggeber: Doch, die Nummern können im Laufe einer Saison durchaus geändert werden.Entwickler: Und wie ist es mit der Null? Kann ein Spieler eine Null haben?Auftraggeber: Ja, der kann eine einfache oder eine eine doppelte Null bekommen.Entwickler: Eine doppelte Null? Das ist aber schlecht. Die gibt es als Zahl doch gar nicht!Auftraggeber: Wie - die gibt es nicht?Und so weiter.Die Aufführung zeigt sehr schön, wie zwei Welten aufeinanderprallen. Der Auftraggeber sitzt gedanklich schon im Spiel. Für ihn sind Nummern schlicht und einfach die Zahlen, die einem Spieler für die Dauer des Spieles zugewiesen werden. Der Entwickler ist hingegen schon bei der technischen Umsetzung: Er denkt an seine Datenbank - und wie dort ein Spieler anhand einer eindeutigen und dauerhaften ID identifiziert werden kann.

Gemeinsame Perspektiven durch offene Kommunikation

In Scrum geht es darum, Perspektiven auf einen Nenner zu bringen. Ein Product Owner hat zwangsläufig andere Interessen und auch ein anderes Produktverständnis als ein Entwickler. Das bedeutet aber nicht, dass beide aneinander vorbei reden müssen. Durch offene und mutige Kommunikation können sich beide Seiten ein Stück weit in die Rolle des anderen hinein versetzen - und sich auf dieser Grundlage ein gemeinsames Verständnis erarbeiten. Wenn der Entwickler aus unserem Theaterstück wüsste, dass der Auftraggeber unter Spielernummern etwas komplett anderes versteht als er selbst, könnten einige Missverständnisse erspart bleiben.

copyright Gerhard Peyrer

Missverständnisse entstehen dann, wenn Aussagen ungeprüft übernommen werden. E-Mails und sonstige schriftliche Kommunikation sind ein herrlicher Nährboden für Missverständnisse. Deshalb ist es so wichtig, den Product Owner nicht als externen Zulieferer des Scrum-Teams zu verstehen, sondern ihn ganz bewusst in dessen Mitte zu platzieren. Wenn der Product Owner nicht nur am Anfang und Ende, sondern auch während des Sprints im Team ist, dann muss sich keiner zweimal überlegen, was denn eigentlich mit dieser einen Anforderung gewollt war - oder warum diese andere Story nicht besser in zwei Stories geteilt wird.

Fragen statt vermuten

Anstatt wild zu vermuten, was der Product Owner wohl mit seinen Stories gemeint hat, kann man einfach zu ihm gehen und fragen. Die Macht solcher informellen Kommunikationswege ("hast du mal eben Zeit?") kann man gar nicht hoch genug schätzen. Wer die Themen aus dem Tagesgeschäft sofort bespricht, kommt schneller auf die wesentlichen Punkte. Auch der Product Owner profitiert davon, wenn er mitten im Team lebt: Gut verstandene User Stories sind das A und O eines funktionierenden Product Backlogs. Kürzlich wurde meinem Team durch ein scheinbar nebensächliches Gespräch klar, dass eine hoch priorisierte Story in der damaligen Form nicht umsetzbar war.Die Rolle des Product Owners ist sicher keine einfache. Manchmal erschweren wir sie uns aber unnötig, indem wir etwa den Product Owner zum genialen und einsamen Visionär hochstilisieren. Dabei wird gerne vergessen, dass der Product Owner und sein Team auf ein und dasselbe Ziel hinarbeiten: erfolgreich zu liefern. Und das gelingt - wie so vieles im Leben - zusammen leichter als allein.Dr. Bernd Krehoff, Scrum Consultant bei bor!sgloger

Agile Toolbox
Scrum
Product Owner
Rollen
Scrum-Begriffe
Team
bgloger-redakteur
February 20, 2012

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Warum macht ihr eigentlich kein SAFe?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Transformation

FRAGE: Was kostet eine agile Transformation?

Agile Management
Agile Organization
Agile Toolbox
Leadership
Agiles Lernen

FRAGE: Welche Rolle spielt Training?

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Wer sind die Top 10 agilen Unternehmensberatungen?

Agile Management
Agile Organization
Agile Tools
Agiles Management
Leadership

FRAGE: Wie viel bringt die Investition? Was ist der Business Case dahinter?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Führung

FRAGE: Welche sind häufige Herausforderungen, die ihr beim Kunden löst?

Agile Management
Agile Organization

FRAGE: Warum sollten wir mit borisgloger arbeiten?

Agile Management
Agile Organization
Agiles Management
Transformation

FRAGE: Wie viel kostet eine Beratung und ist es wirklich rentabel bei borisgloger?

Agile Prinzipien
Agile Toolbox
Projektmanagement

The Lie Behind the Parable of the Golf Balls and the Jar

Video
Change
Digitale Transformation
Hardware
Agile Organization

Agile in Industrial Automation: The Digital Transformation of Yokogawa

Versicherung
Neues Arbeiten
Führung
Agile Prinzipien
Kundenfokus

Kundenzentrierte Versicherung: Kann ein agiles Projekt die Organisation retten?

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

Agilität in den Vertrieb bringen – für Versicherer sinnvoll

Versicherung
Agile Prinzipien
Kundenfokus
Agile Toolbox
Produktentwicklung

BizDevOps in der Versicherungsbranche – Wie multidisziplinäre Teams wirklich besetzt sein sollten

Versicherung
Agile Prinzipien
Kundenfokus
Neues Arbeiten
Meetings

Undercover Agile für Versicherer: 5 agile Praktiken für Ihr klassisches IT-Projekt

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

IT-Projekte in der Versicherungsbranche – Das Rennen um die Time-to-Market

Team
Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills

Umgang mit Fehlern & Diversität – Erfolgreiche agile Teams #2

Team
Neues Arbeiten
Agile Toolbox
Produktentwicklung

Das Geheimrezept von High-Performance-Teams

Team
Arbeiten bei borisgloger consulting
Agile Prinzipien
Freiwilligkeit
Selbstorganisation

Konsent und offene Wahl: 2 Prinzipien aus der Soziokratie, die jedes agile Team gebrauchen kann

Team
Neues Arbeiten
Meetings
Social Skills

Der agile Adventkalender

Team
Agile Toolbox
Scrum
ScrumMaster-Praxistipps
Agile Prinzipien

Selbstorganisation der Teams fördern: Ask the team!

Team
Agile Toolbox
Design Thinking

Who Recognizes the Truly Good Ideas?

Team
Agile Organization
Transformation

Pizza Is Not Dead, and Neither Is Agility

Scrum4Schools
Neues Arbeiten
Führung
Life
Social Skills

Trauen wir unseren Kindern mehr zu – auch in der Schule!

Scrum4Schools
Change
Agiles Lernen
Neues Arbeiten
Remote Arbeiten

Eine Scrum4Schools-Projekt-Rückschau mit Physiklehrer Ivan Topic

Scrum4Schools
Mehr Formate
Interview
Nachhaltigkeit

Mit Scrum4Schools dem Weltraum auf der Spur

Scrum4Schools
Change
Agiles Lernen

Scrum4Schools - ein Projekt nimmt Fahrt auf

Scrum4Schools
Agile Schulentwicklung
Agile Toolbox

Technik im Alltag - Scrum4Schools zu Gast in Langenzersdorf

Projektmanagement
Agile Toolbox
Scrum
Scrum-Begriffe
ScrumMaster-Praxistipps

Sprechen Sie Agile? Den klassischen Projektplan in die agile Welt überführen

Projektmanagement
Agiles Management
Agile Toolbox
Scrum
Enterprise Scrum

Das Management in Scrum

Projektmanagement
Change
Digitale Transformation

Agilität in der Logistik oder: Liefern wie Amazon

Projektmanagement
Agile Toolbox
Scrum

Meilensteine und Scrum

Portfoliomanagement
Project management

Too many projects? Portfolio management simplified

Neues Arbeiten
Mehr Formate
Agile Toolbox
Scrum
Scrum Values

Wie agiles Arbeiten die Kommunikation aus der Selbstverständlichkeit holt

Neues Arbeiten
Change
Agiles Lernen
Mehr Formate
Audio

New Learning heute für das New Work von morgen – mit Angelika Weis

Neues Arbeiten
Change
Soziale Innovation

New Work Experience 2019 – ein Erfahrungsbericht

Neues Arbeiten
Audit
Change

Agil im Audit: das Starter-Kit

Neues Arbeiten
Agile Toolbox
Scrum
Scrum4Schools
Agile Prinzipien

Scrum4Schools: Lernen für die Zukunft

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Meetings
Retrospektive

Arbeiten wir uns gesund!

Neues Arbeiten
Agile Toolbox
Scrum
ScrumMaster-Praxistipps

Who should be in (agile) HR?

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Values

Glauben Sie an die Seele Ihrer Firma?

Neues Arbeiten
Agile Toolbox
Scrum
Product Owner
ScrumMaster-Praxistipps

Produktivität auf Irrwegen: "Führen wir schnell mal Scrum ein!"

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freiwilliges Teilen von Wissen – Erfolgreiche agile Teams #5

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Doing vs. Being Agile – Erfolgreiche agile Teams #1

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freude bei der Arbeit & Sustainable Pace – Erfolgreiche agile Teams #3

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Anpassungsfähigkeit & schonungslose Offenheit – Erfolgreiche agile Teams #4