Product Owner Anti-Pattern – was ist das?

Viele, vor allem neue, Product Owner konzentrieren sich auf die Umsetzung und Prozesse in einem agilen Projekt – dabei spüren sie jedoch häufig Unstimmigkeiten. Wir haben in den vergangenen Jahren ähnliche Erfahrungen gesammelt. Deshalb haben wir – die Runde der Agilen Coaches bei Mayflower – das zum Anlass genommen, uns konkret darüber Gedanken zu machen und zu identifizieren, warum Projekte nicht reibungslos laufen und wie das verbessert werden kann. Daraus, und aus den vielen Gesprächen und dem Feedback anderer Product Owner, sind uns die essenziellen Merkmale der Rolle Product Owner aufgefallen.

Wir haben daraus 30 Product Owner Anti-Pattern abgeleitet, die wir im Rahmen einer Artikelserie vorstellen werden (und die als Product Owner Anti-Pattern Kartenset kostenlos bei uns bestellt werden können). Die Beiträge sollen dabei helfen, das Verständnis der Rolle des Product Owners zu schärfen.

Product Owner Anti-Pattern

Alle einzelnen Product Owner Anti-Pattern lassen sich in sechs Facetten kategorisieren. Die Betrachtung der Facetten hilft bereits dabei, die meisten Anti-Pattern zu vermeiden. Nachfolgend stellen wir die Facetten und ihre Bedeutung vor; die Anti-Pattern und die Lösungen folgen dann in den einzelnen Artikeln.

1. Facette: Soziales

Viele Unstimmigkeiten sind darauf zurückzuführen, dass der Product Owner nicht Teil des Teams ist. Das kann sowohl daran liegen, dass die Kollegen den Product Owner nicht als Teil des Teams ansehen beziehungsweise anerkennen. Andererseits kann auch der Product Owner der Ansicht sein, dass er nicht zum Team zu gehören hat.

Gerade in agilen Teams ist es sehr wichtig, dass alle Teilnehmer auf Augenhöhe miteinander zusammen arbeiten, damit ein gegenseitiger Respekt entsteht und dadurch ein kooperativer Austausch möglich ist.

2. Facette: Vision

Die Mehrheit der Menschen lassen sich leichter für etwas begeistern, wenn ihnen eine Vision und/oder eine Absicht vermittelt wird. Besonders bei Wissensarbeitern ist das ausschlaggebend.

Wenn der Product Owner weder die Vision für das Produkt kennt noch dazu in der Lage ist, sie zu vermitteln, dann fehlt den anderen Teammitgliedern ein wesentlicher Motivator und auch eine Zielrichtung. Das Ergebnis sind oft demotivierte Teams oder Teams, die (Teil-)Produkte entwickeln, die aktuell nicht nutzbringend sind.

3. Facette: Wert

Eine der Kernaufgaben des Product Owners ist dafür zu sorgen, dass das Team pro Sprint nutzbare und wertbringende (Teil-)Produkte liefert. Dazu gehört die Priorisierung der richtigen Backlog-Einträge.

Ohne eine Abschätzung des Wertes dieser Einträge wird das nicht gelingen. Und der Product Owner wird auch dem Rest des Teams nicht vermitteln können, warum die gewählten Einträge die richtigen sind.

4. Facette: Stakeholder

Immer wieder wird in hektischen Situationen der hauptsächlichste Stakeholder vergessen: der Kunde / Endnutzer / Benutzer. Das bedeutet nicht, dass alle anderen Interessenten an der Entwicklung vernachlässigt werden sollten; jedoch sollte der Product Owner nie den Nutzer vergessen, der das Produkt einsetzen wird. Denn nur dieser wird darüber entscheiden, ob es (für ihn) wertbringend ist oder nicht.

5. Facette: Organisatorisches

Agile Methoden basieren meistens auf bestimmten Rahmenparametern, die die Organistation betreffen. Darunter fallen z. B. die spezifischen Rollen im Scrum: der Product Owner, Scrum Master, die Umsetzer (Entwickler, Tester, Architekten, etc.).

Speziell bei den Rollen ist es fundamental, dass es keine Doppelbesetzung gibt (so was wie der Scrum Product Master Owner), weil sie alle unterschiedliche Zielsetzungen haben. Weiterhin gehört dazu auch die Life-Work-Balance und der Fokus auf qualitative Arbeitsergebnisse.

6. Facette: Strukturelles

Zu der letzten Facette gehören alle Arten von Anti-Pattern, die bestimmte Abläufe und Regeln brechen. Wie z. B. wenn der Scope als feste Zusage verstanden wird, keine Schätzungen gemacht werden, Storys als Verträge angesehen oder grundlegende Abläufe nicht beachtet werden.

Wenn der Scope als feste Zusage verstanden wird, oder Storys als Verträge angesehen werden, wird das Team länger planen und versuchen, Fehler zu vermeiden – dadurch wird die Möglichkeit zu lernen eingeschränkt. Ohne Schätzungen wird es schwieriger dafür zu sorgen, dass ein gemeinsames mentales Modell für die Storys entsteht.

Ausblick

Alle 30 Anti-Pattern die wir bisher erfasst haben und die wir als Karten mit Erkennungsmerkmalen und Lösungsvorschlägen anbieten, lassen sich auf die beschriebenen Facetten zurückführen. Die nächsten Artikel der Serie werden sich detaillierter mit den einzelnen Facetten befassen und für konkrete Lösungsvorschläge aufführen.

Welche Anti-Pattern habt ihr schon in euren Teams erlebt? Wir freuen uns darauf, weitere Anti-Pattern kennenzulernen und uns mit euch auszutauschen.

Product Owner Anti-Pattern