Product Owner Fehlverhalten — 33 Möglichkeiten, sich als PO zu verbessern

In Kürze: Product Owner Fehlverhalten

Keine andere Rolle in Scrum kann so sehr zu mittelmäßigen Ergebnissen beitragen wie der Product Owner — Garbage in, Garbage out. Die folgende Liste mit den häufigsten Product Owner Fehlverhalten könnte daher ein Ausgangspunkt sein, über die Tätigkeit als Product Owner nachzudenken; vielleicht gibt es Verbesserungspotential?

Wenn Sie also einige Anti-Muster in Ihrer täglichen Arbeit erkennen, warum bitten Sie dann nicht den Rest des Scrum-Teams um Unterstützung? Führen Sie zum Beispiel eine Retrospektive mit Teamkollegen und Stakeholdern durch, um herauszufinden, wie erfolgreich das Team dabei ist, herauszufinden, was es wert ist, gebaut zu werden.

🗳 Update: Join the poll and its lively discussion on LinkedIn.

🗞 Soll ich Sie über Artikel wie diesen informieren? Großartig! Sie können sich hier für den Newsletter „Food for Agile Thought“ anmelden und sich über 35.000 Abonnenten anschließen.

🎓 Nehmen Sie an einer von Stefans kommenden Professional Scrum-Schulungen teil!

📅 Nehmen Sie am 30. Mai 2022 teil—wir sind bereits über 230 Teilnehmer: HoA #42: The Skinny on Lean Roadmapping and OKRs w/ Janna Bastow.

Die Rolle des Product Owners nach dem Scrum-Guide

Die Rolle des PO beschreibt der Scrum Guide folgendermaßen:

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

Der wichtigste Weg, dieses Ziel als PO zu erreichen, ist die effektive Verwaltung des Product Backlogs. Nach dem Scrum Guide umfasst diese Tätigkeit:

• Developing and explicitly communicating the Product Goal;
• Creating and clearly communicating Product Backlog items;
• Ordering Product Backlog items; and,
• Ensuring that the Product Backlog is transparent, visible and understood.

The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.

The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.

For Product Owners to succeed, the entire organization must respect their decisions. These decisions are visible in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review.

Source: Scrum Guide 2020.

(Sehen Sie sich auch die vollständige Liste des Scrum Guide 2020 über den Product Owner an, indem Sie den kostenlosen Scrum Guide Reordered herunterladen.)

Meiner Erfahrung nach resultieren die meisten der Product Owner Fehlverhalten aus einem Missverständnis dieser Aufgabe des Product Backlog Managements. Vor allem die weniger erfolgreichen Product Owner scheitern oft an der notwendigen Kommunikation mit ihren Teamkollegen und Stakeholdern. Den Wert der Arbeit des Scrum-Teams aus der Sicht des Kunden zu maximieren und gleichzeitig zum Gewinn des Unternehmens beizutragen, ist weniger eine Frage von Projektmanagementfähigkeiten, dem Jonglieren mit Produktanforderungsdokumenten und dem Aktualisieren von Jira.

Erfolgreiche Product Owner verbringen vielmehr weniger Zeit mit der eigentlichen Bearbeitung des Produktbacklogs als mit der Produktentdeckung im Allgemeinen und der Schaffung von Übereinstimmung zwischen allen Beteiligten im Besonderen. Für sie ist das Product Backlog ein Mittel zum Zweck, nicht der Sinn ihrer Existenz.

Folglich verbringen erfolgreiche Product Owner viel Zeit damit, ein transparentes System zu schaffen, das es ermöglicht, potenziell wertvolle Ideen aus allen Quellen zu identifizieren, das „Warum“ unermüdlich zu kommunizieren und mit den Entwicklern an dem „Was“ zusammenzuarbeiten.

Fehlverhalten im Management des Product Backlogs und dessen Verfeinerung

Die meisten Product Owner Fehlverhalten können wir im Hinterhof des PO entdecken — im Management des Product Backlogs und dessen Verfeinerung:

• Ideenspeicher: Der Product Owner verwendet das Product Backlog als Verzeichnis für Ideen und Anforderungen. (Ein großes Product Backlog gilt wohl als Zeichen für ein „gutes“ Scrum-Team: Sie sind völlig transparent und das ist ein Beweis für Ihre Nützlichkeit für die Organisation. „Vielbeschäftigt“ zu sein, ist jedoch nicht gleichbedeutend mit Wert für die Kunden und das Unternehmen schaffen. Das zusätzliche Rauschen, das durch die schiere Anzahl der Einträge entsteht, kann die Erkennung wertvoller Product-Backlog-Einträge beeinträchtigen. Und schließlich kann die Größe des Product Backlogs einen Verdrängungseffekt auf die Stakeholder haben, da sie sich überfordert fühlen. Das mit Ideen aufgeblähte Product Backlog kann die wichtige Kommunikation mit ihnen behindern.)
• Teilzeit-Product Owner: Der Product Owner arbeitet nicht täglich am Product Backlog. (Das Product Backlog muss die beste Nutzung der Zeit der Entwickler zu jedem beliebigen Zeitpunkt darstellen. Nehmen wir an, eine Aktualisierung des Product Backlogs erfolgt nur gelegentlich, zum Beispiel kurz vor der nächsten Sprintplanung. Aufgrund mangelnder Verfeinerung der Einträge wird dabei wahrscheinlich viel potentieller Wert nicht realisiert. Der Wert des Product Backlogs ergibt sich zu einem großen Teil aus der offenen Diskussion zwischen dem Product Owner und den Entwicklern. In einem guten Scrum-Team stellen die Entwickler den Product Owner ständig in Frage, was den Wert der vorgeschlagenen Product-Backlog-Elemente angeht. Dieser Ansatz der gegenseitigen Kontrolle verringert die Wahrscheinlichkeit, dass der Product Owner einem Confirmation-Bias zum Opfer fällt, und mindert damit das Risiko, dass das Scrum-Team bei der nächsten Sprint-Planung eine falsche Investitionsentscheidung trifft. Wie das Sprichwort schon sagt: Liebe das Problem des Kunden nicht Deine Lösung.)
• Kopieren & Einfügen-PO: Der Product Owner erstellt Product Backlog-Einträge, indem er die von den Stakeholdern erhaltenen Anforderungsdokumente in kleinere Stücke zerlegt. (Dieses Szenario hat dem Product Owner den Spitznamen „Ticket-Monkey“ eingebracht. Denken Sie daran: Das Verfeinern von Product-Backlog-Elementen ist eine Teamaufgabe. Außerdem hilft die Verwendung von Praktiken, wie z. B. Ron Jeffries’ User Story-Vorlage, allen Beteiligten, das Warum, das Was und das Wie zu verstehen. Erinnern Sie sich an Karl Popper: “Always remember that it is impossible to speak in such a way that you cannot be misunderstood.”)
• Dominanter PO: Der Product Owner erstellt Product Backlog-Elemente, indem er nicht nur das ‚Warum‘, sondern auch das ‚Wie‘ und das ‚Was‘ vorgibt. (Halten Sie sich einfach an den Scrum Guide und seine eingebauten Checks & Balances: Die Entwickler beantworten die Frage nach dem ‚Wie‘, die technische Umsetzung, und das Team und der Product Owner arbeiten gemeinsam an der Frage nach dem ‚Was‘: Welcher Umfang ist notwendig, um den gewünschten Zweck zu erreichen?)
• Priorisierung durch einen Stellvertreter: Ein einzelner Stakeholder oder ein Ausschuss von Stakeholdern priorisiert das Product Backlog. (Die Stärke von Scrum beruht auf der starken Position des Product Owners. Der Product Owner ist die einzige Person, die entscheidet, welche Aufgaben in das Product Backlog aufgenommen werden. Daher entscheidet der Product Owner auch über die Anordnung des Product Backlogs. Nimmt man ihnen diese Befugnis, verwandelt sich Scrum in einen ziemlich effizienten Wasserfall 2.0-Prozess.)
• 100% im Voraus: Das Scrum-Team erstellt im Vorfeld ein Product Backlog, welches das gesamte Projekt oder Produkt abdeckt, da dessen Umfang als begrenzt angesehen wird. (Lassen Sie mich eine Frage stellen: Wie können Sie sicher sein, heute zu wissen, was Sie in sechs Monaten liefern werden, wenn Sie an einem komplexen und adaptiven Problem arbeiten? Ist die Ungewissheit über die Zukunft nicht der Grund, warum Sie Scrum überhaupt einsetzen?)
• Überdimensioniert: Der Product Backlog enthält mehr Einträge, als das Scrum-Team innerhalb von drei bis sechs Sprints liefern kann. (Auf diese Weise erzeugen Product Owner unnötige Arbeit, indem sie Aufgaben und Probleme sammelt, die möglicherweise nie angegangen werden.)
• Veraltete Einträge: Das Product Backlog enthält Einträge, die seit sechs, acht oder mehr Wochen nicht mehr ansehen wurden. (Das ist typischerweise die Länge von drei bis vier Sprints. Wenn der Product Owner Product-Backlog-Einträge hortet, besteht das Risiko, dass ältere Einträge rasch im Wert verfallen und somit die zuvor investierte Arbeit des Scrum-Teams umsonst war.)
• Eine Schätzung für jeden Eintrag: Alle Einträge des Product Backlog sind detailliert ausgearbeitet und geschätzt. (Das ist zu viel Vorleistung und birgt das Risiko einer Fehlallokation der Arbeitszeit des Scrum-Teams. Die Verfeinerung der Product Backlog-Einträge ist ein kontinuierlicher Prozess, der nur bis zu dem Punkt fortgesetzt wird, an dem das Scrum-Team diese Einträge in Produkt-Inkremente umwandeln kann.)
• Komponenten-basierte Einträge: Die Product Backlog Elemente werden horizontal nach Komponenten und nicht vertikal nach End-to-End-Anwendermerkmalen aufgeteilt. (Dies kann entweder durch Ihre Organisationsstruktur verursacht werden, ein Effekt, der als Conways Gesetz bezeichnet wird. In diesem Fall sollten Sie diese Störung der Organisationsstruktur überwinden, indem Sie zu interdisziplinären Teams wechseln, um die Lieferfähigkeit des Scrum-Teams zu verbessern. Andernfalls sollte das Scrum-Team in einen Workshop zum Verfassen besserer Product-Backlog-Elemente investieren.)
• Fehlenden Akzeptanzkriterien: Es gibt Einträge im Product Backlog, die zusätzliche Akzeptanzkriterien benötigen, ohne dass diese aufgelistet werden. (Es ist nicht notwendig, zu Beginn des Verfeinerungszyklus alle Akzeptanzkriterien parat zu haben, obwohl sie die Aufgabe viel leichter verständlich machen würden. Alle Einträge im Product Backlog müssen jedoch schließlich der Definition of Done und ggf. den individuellen Anforderungen auf der Ebene des Arbeitspakets entsprechen. Wenn die Definition of Done Letztere nicht enthält, ergeben sich die nun erforderlichen Akzeptanzkriterien aus dem Verfeinerungsprozess.)
• Nicht mehr als ein Titel: Der Product Backlog enthält Einträge, die nur aus einem Titel bestehen. (Das Hinzufügen zahlreicher „Gedächtnisstützen“ zum Backlog, wodurch das Signal, welches das Backlog liefern soll, verschleiert wird, beeinträchtigt die Fähigkeit des Scrum-Teams, wertvolle Produkt-Inkremente für die Kunden zu erstellen. Ideen gehören nicht in das Product Backlog; sie sind Teil des anderen Artefakts, des Product-Discovery-Systems.)
• User-Story-Autor: Der Product Owner investiert im Vorfeld zu viel Zeit in die Erstellung von Product Backlog-Einträgen, sodass diese zu detailliert sind. (Wenn ein Arbeitspaket „vollständig“ aussieht, sehen die Entwickler möglicherweise nicht die Notwendigkeit, sich an der weiteren Verfeinerung zu beteiligen. Auf diese Weise verringert ein „fertig aussehender“ Product Backlog-Eintrag den Grad des Engagements des Teams und beeinträchtigt die Schaffung eines gemeinsamen Verständnisses. Das ist übrigens nicht passiert, als wir noch mit Karteikarten gearbeitet haben, da diese nur beschränkt Platz hatten.)
• Keine Experimente: Das Product Backlog enthält wenige bis gar keine Spikes bzw. zeitlich begrenzte Forschungsaufgaben. (Dieser Effekt hängt oft damit zusammen, dass ein Scrum-Team zu viel Zeit damit verbringt, zukünftige Probleme zu diskutieren, anstatt sie im Rahmen eines kontinuierlichen Product-Backlog-Verfeinerungsprozesses mithilfe eines Spikes zu erforschen.)
• Wie Team? Der Product Owner bezieht nicht das gesamte Scrum-Team in den Prozess der Verfeinerung des Product Backlogs ein und verlässt sich stattdessen nur auf den „Lead Engineer“ und einen Designer. Darüber hinaus sind die Entwickler mit diesem Ansatz einverstanden, da sie so mehr Code schreiben können. (Wenn man versucht, ein komplexes Problem zu lösen, gibt es keine Experten, sondern viele konkurrierende Ideen. Wenn man daher die Anzahl der aktiven Teilnehmer an den Verfeinerungsaktivitäten auf einige wenige Teammitglieder beschränkt, erhöht sich das Risiko, dass man Opfer eines Bestätigungsfehlers bzw. Confirmation Bias wird, da die Meinungsvielfalt unnötig eingeschränkt wird.)

Product Owner Fehlverhalten während des Sprint Plannings

Der zweitwichtigste Bereich auf meiner Liste der Product Owner Fehlverhalten ist die Sprintplanung:

• Wofür arbeiten wir? Der Product Owner kann das Geschäftsziel des bevorstehenden Sprints nicht mit der allgemeinen Produktvision bzw. dem Produktziel in Einklang bringen. (Ein ernstzunehmendes Geschäftsziel beantwortet die Frage „Wofür arbeiten wir?“ Bis zu einem gewissen Grad ist dies in Folge auch eine Verhandlung zwischen dem Product Owner und den Entwicklern. Das Geschäftsziel sollte daher fokussiert und messbar sein, da das Sprint-Ziel, welches auf dem Geschäftsziel basiert, und die Prognose der Entwickler Hand in Hand gehen.)
• Kein Geschäftsziel, kein Sprint-Ziel, nur eine Ticketliste: Der Product Owner schlägt Product Backlog-Einträge vor, die eher einer zufälligen Zusammenstellung von Aufgaben ähneln und daher auch keinen Bezug zueinander haben. Folglich erstellt das Scrum-Team kein Sprint-Ziel. (Wenn dies die normale Art und Weise ist, wie Sie Ihr Sprint Planning abzuschließen, dann haben Sie unter Umständen die Nützlichkeit von Scrum als Produktentwicklungs-Framework bereits überlebt. Je nach dem Reifegrad Ihres Produkts könnte sich Kanban als bessere Lösung erweisen. Andernfalls kann die Zufälligkeit einen schwachen Product Owner signalisieren, der zu sehr auf die Stakeholder hört, anstatt das Product Backlog aus Sicht der Nützlichkeit für die Kunden entsprechend zu bestücken und zu ordnen.)
• Unvollendete Geschäfte: Unvollendete Aufgaben aus dem letzten Sprint werden ohne Diskussion in den neuen Sprint übernommen. (Es kann gute Gründe dafür geben, z. B. weil sich der Wert einer Aufgabe nicht geändert hat. Es sollte jedoch kein Automatismus sein, denken Sie an den Sunk Cost-Trugschluss.)
• Änderungen in letzter Minute: Der Product Owner versucht, in letzter Minute unfertige Product Backlog-Einträge im Sprint unterzubringen. (Im Prinzip ist es das Vorrecht des Product Owners, solche Änderungen vorzunehmen, um sicherzustellen, dass die Entwickler zu jedem Zeitpunkt an den wertvollsten Aufgaben aus Kundenperspektive arbeitet. Wenn das Scrum-Team jedoch ansonsten regelmäßig Verfeinerungen des Product Backlogs durchführt, sollten solche Vorkommnisse eine seltene Ausnahme sein. Wenn diese häufiger vorkommen, deutet dies darauf hin, dass der Product Owner Hilfe bei der Erstellung des Product Backlogs und in der Teamkommunikation benötigt. Oder der Product Owner braucht Unterstützung im Umgang mit hartnäckigen Stakeholdern.)
• Output-Fokussierung: Der Product Owner drängt die Entwickler, mehr Aufgaben zu übernehmen, als sie realistischerweise bewältigen können. Wahrscheinlich beziehen sich Product Owner dabei auf frühere Teammetriken wie die Velocity, um ihren Wunsch zu unterstützen. (Dies ist auch ein sicherer Weg, um eine Feature Factory zu werden, und verdient die Aufmerksamkeit des Scrum Masters: Es ist eine Verletzung des Vorrechts der Entwickler, die Product Backlog-Einträge für das Sprint Backlog auszuwählen und missachtet Scrum-Werte).
• Fehlende Vorbereitung: Der Product Owner bereitet das Product Backlog für eine Auswahl nützlicher Product Backlog-Einträge durch die Entwickler nicht vor. (Das Product Backlog muss zu jedem Zeitpunkt die bestmögliche Nutzung der Arbeit der Entwickler aus der Perspektive des Kundennutzens darstellen. Mit anderen Worten, das Product Backlog Ihres Scrum-Teams muss rund um die Uhr „actionable“ sein. Nach meinen Maßstäben bedeutet dies, dass Sie jederzeit in der Lage sein müssen, ein sinnvolles Sprint Planning durchzuführen. Es reicht als Product Owner daher nicht aus, eine Stunde vor Beginn des Sprint Plannings kurz mal eben einige Product Backlog-Einträge vorzubereiten. Diese Qualität erreicht eine Produktbacklog nur durch regelmäßige Verfeinerung in Zusammenarbeit mit den Entwicklern.)

Fehlverhalten im Rahmen des Sprints

Ein weiterer Bereich für Product Owner Fehlverhalten ist der Sprint an sich:

• Der abwesende Product Owner: Der Product Owner ist den größten Teil des Sprints abwesend und steht den Entwicklern nicht für Fragen zur Verfügung. (Da das Sprint-Backlog sich während der Arbeit herausbildet und ggf. neue Arbeiten als notwendig für das Erreichen des Sprint-Ziels identifiziert werden, könnte diese Haltung die Entwickler unnötig im Dunkeln tappen lassen und die Erreichung des Sprint-Ziels gefährden).
• Der klammernde PO: Der Product Owner kann von Product Backlog-Einträgen nicht loslassen, sobald dieses Teil des Sprint Backlog werden. Der Product Owner erhöht beispielsweise den Umfang eines Eintrages oder ändert die Akzeptanzkriterien, nachdem das Team die Aufgabe in das Sprint Backlog aufgenommen hat. (Es gibt hier eine klare Trennung: Bevor ein Product-Backlog-Eintrag zu einem Teil des Sprint Backlog wird, ist der Product Owner verantwortlich. Sobald der Product Backlog-Eintrag jedoch Teil des Sprint Backlogs wird, sind die Entwickler verantwortlich. Wenn Änderungen während des Sprints erforderlich werden, entscheidet das Team gemeinsam, wie es damit umgeht).
• Der unflexible Product Owner: Der PO ist nicht flexibel bei der Anpassung der Akzeptanzkriterien. (Wenn sich bei der Arbeit an einer Aufgabe herausstellt, dass die vereinbarten Akzeptanzkriterien nicht mehr erreichbar sind, muss sich das Scrum-Team der neuen Realität beugen. Die blinde Befolgung des ursprünglichen Plans verstößt gegen Scrum-Prinzipien und das Agile Manifest.)
• Der verzögernde PO: Der Product Owner gibt kein Feedback zu Arbeiten aus dem Sprint-Backlog, sobald diese beendet sind. Stattdessen wartet er oder sie bis zum Ende des Sprints. (Der Product Owner sollte Aufgaben, die die Akzeptanzkriterien erfüllen, sofort mit dem jeweiligen Entwickler überprüfen. Andernfalls schafft der Product Owner eine künstliche Warteschlange innerhalb des Sprints, welche die Cycle-Time von Product Backlog-Einträgen unnötig erhöht. Diese Vorgehensweise seitens des PO gefährdet auch das Erreichen des Sprint-Ziels. Anmerkung: Die Inspektion von Product-Backlog-Einträgen ist nicht gleichbedeutend mit einer Art Arbeitsabnahme oder Qualitätskontrolle. So etwas gibt es in Scrum nicht. Sobald ein Product-Backlog-Eintrag die Definition von Done erfüllt, kann es an die Anwender weitergegeben werden.)
• Sprint-Tetris: Die Entwickler haben das Sprint Goal vorzeitig erreicht, und der Product Owner drängt sie dazu, neue Arbeit aus dem Product-Backlog zu übernehmen, um die „Lücke“ sinnvoll zu nutzen. (Das Scrum Team hat das Sprint Goal gemeinsam beschlossen und die Entwickler haben sich verpflichtet, es zu erfüllen. Daher ist es das Vorrecht der Entwickler, über die Zusammensetzung des Sprint Backlogs zu entscheiden. Sollten sie es schaffen, das Sprint Goal vor dem Ende des Sprints zu erreichen, ist es ihre alleinige Entscheidung, die verbleibende Zeit zu füllen. Die Aufnahme neuer Arbeit aus dem Product-Backlog kann eine Möglichkeit sein, die verbleibende Sprint-Timebox zu füllen. Das gilt auch für das Refactoring von Teilen des Tech Stacks, das Erforschen neuer Technologien, die nützlich sein könnten, das Beheben von Fehlern oder den Wissensaustausch mit anderen Teammitgliedern. Bei Scrum geht es nicht darum, die Auslastung der Teammitglieder zu maximieren. Das Erreichen des Sprint-Ziels ist für den Erfolg des Sprints ausreichend.)
• Sprint-Abbruch ohne Rücksprache: Der Product Owner sagt Sprints ab, ohne das Scrum Team zu konsultieren. (Es ist das Vorrecht des Product Owners, Sprints abzubrechen. Der Product Owner sollte dies jedoch nicht ohne einen ernsthaften Grund tun. Auch sollte dies niemals ohne vorherige Rücksprache mit den anderen Scrum-Team-Mitgliedern geschehen. Vielleicht hat jemand eine Idee, wie man das Sprint Goal retten kann, sofern es noch nützlich ist? Des Weiteren weist der Missbrauch des Abbruchprivilegs auch auf ein ernstes Problem der Zusammenarbeit des Teams hin).
• Kein Sprint-Abbruch: Der Product Owner bricht einen Sprint, dessen Sprint-Ziel nicht mehr sinnvoll ist, nicht ab. (Wenn der Product Owner eine lohnende Aufgabe für den Sprint identifiziert hat, z. B. die Integration einer neuen Zahlungsmethode, und das Management diese Zahlungsmethode dann mitten im Sprint aufgibt, dann wäre es eine Verschwendung, weiter an diesem Sprint-Ziel zu arbeiten. In diesem Fall sollte der Product Owner in Erwägung ziehen, den Sprint abzubrechen).

Fehlverhalten des PO im Daily Scrum

Im Vergleich zu anderen Scrum-Events ist das Daily Scrum bemerkenswert widerstandsfähig gegenüber Product Owner Fehlverhalten:

• Zuweisungen: Der Product Owner — oder auch der „Scrum Master“ — vergibt Aufgaben direkt an die Teammitglieder. (Die Entwickler organisieren ihre Arbeit selbst: “No one else tells them how to turn Product Backlog items into Increments of value.” Quelle: Scrum Guide 2020.)
• Mehrarbeit: Der Product Owner oder auch andere Stakeholder versuchen, während des Daily Scrum neue Arbeiten in den aktuellen Sprint einzubringen. (Dieses Verhalten kann für Fehler bzw. Bugs der höchsten Prioritätsstufe akzeptabel sein, obwohl die Entwickler diese vor dem Daily Scrum in der Regel bereits kennen sollte. Andernfalls liegt die Zusammensetzung des Sprint Backlogs in der alleinigen Verantwortung der Entwickler.)

Das Sprint Review und Product Owner Fehlverhalten

Schließlich gibt es noch das Sprint-Review. Obwohl dies eine hervorragende Gelegenheit für den Product Owner ist, die Zusammenarbeit mit den Interessengruppen und den Entwicklern zu verbessern und gemeinsam herauszufinden, in welche Richtung das Produkt als Nächstes entwickelt soll, verstehen einige Product Owner den Sinn und Zweck des Sprint Reviews nicht:

• Eigennütziger Product Owner: Der Product Owner präsentiert den Stakeholdern „seine“ Leistungen. (Scrum ist eine bemerkenswert egalitäre Angelegenheit: Niemand hat die Befugnis, den Teammitgliedern vorzuschreiben, was, wann oder wie sie etwas tun sollen. In Scrum-Teams gibt es keine Unterrollen und keine Hierarchie. Stattdessen basiert in Scrum alles auf Selbstmanagement und kollektiver Verantwortung — das Scrum-Team gewinnt gemeinsam, und das Scrum-Team verliert gemeinsam. Erinnern Sie sich an das alte Sprichwort: There is no “I” in “team?”)
• “Abnahme” durch den Product Owner : Product Owner nutzen den Sprint Review um Product Backlog-Elemente zu „akzeptieren“, welche die Entwickler als „done“ betrachten. (Eine formelle „Abnahme“ von Arbeitspaketen durch den Product Owner ist in Scrum nicht vorgesehen, dafür gibt es die Definition of Done. Eine Feedback-Schleife — haben die Entwickler die vereinbarte Funktionalität geliefert? — ist jedoch wertvoll. Product Owner sollten diese Feedbackschleife jedoch vom Sprint Review abkoppeln. Stattdessen sollten die Product Owner mit den Entwicklern kommunizieren, wann immer dies erforderlich ist oder wenn die Arbeitsaufgaben die Definition of Done erfüllen.)
• Unnahbarer Product Owner: Der Product Owner nimmt kein Feedback von den Stakeholdern oder den Entwicklern entgegen. (Ich verstehe das: Es fühlt sich gut an, die eigene Lösung über die Probleme der Kunden zu stellen. Außerdem kann eine gewisse Voreingenommenheit unsere Product Owner davon abhalten, sich von der Verfolgung ihrer geliebten Lösung ablenken zu lassen. Aber leider werden sie nicht dafür bezahlt, dass sie „ihre“ Lösung auf den Markt bringen. Dieses „Leben in der eigenen PO-Blase“ verstößt daher gegen den Hauptzweck des Sprint Reviews: Gemeinsam mit allen Stakeholdern herauszufinden, ob das Scrum-Team immer noch auf dem richtigen Weg ist, um das Produktziel zu erreichen, was in erster Linie Offenheit seitens der Product Owner erfordert.)

Fazit

Zugegebenermaßen ist die Rolle des Product Owners die anspruchsvollste Scrum-Rolle, und je höher die Erwartungen sind, desto leichter ist es, sie zu enttäuschen. Dennoch gilt das Konzept der kontinuierlichen Verbesserung auch für die Rolle des Product Owners. Die obige Liste von Product Owner Fehlverhalten kann ein Ausgangspunkt hierfür sein.

Wir werden als Scrum-Team nicht dafür bezahlt, Scrum zu praktizieren. Kein Stakeholder interessiert sich für diesen Aspekt. Wir werden jedoch dafür bezahlt, das Leben unserer Kunden zu verbessern und gleichzeitig einen Beitrag zum nachhaltigen Geschäft unserer Organisation zu leisten. In diesem Modell sind die Product Owner der Dreh- und Angelpunkt der Wertschöpfung, da sie entscheiden, wohin das Scrum-Team als Nächstes gehen soll. Keine andere Rolle in Scrum kann so sehr zu mittelmäßigen Ergebnissen beitragen wie der Product Owner — Garbage in, Garbage out.

Zum Glück gibt es Hoffnung, denn die Idee der kontinuierliche Verbesserung gilt auch für die Rolle des Product Owner. Diese Liste von Product Owner Fehlverhalten kann dabei ein Ausgangspunkt sein.

Welches Fehlverhalten von Product Ownern haben Sie beobachtet, die in der Liste fehlen? Bitte teilen Sie uns diese in den Kommentaren mit.

PO Fehlverhalten — Empfohlene Lektüre

20 Sprint Planning Anti-Patterns

Liberating Structures for Scrum (2): The Sprint Planning

28+2 Sprint Anti-Patterns

Daily Scrum Anti-Patterns: 24+2 Ways to Improve as a Scrum Team

21 Sprint Retrospektive Anti-Patterns

27 Product Backlog Anti-Patterns

Alle Artikel über Scrum Anti-Patterns

Download the Scrum Anti-Patterns Guide for free.

📺 Das Video über Product Owner Anti-Patterns

Das Video über Product Ownern Fehlverhalten ist jetzt verfügbar:

Anmerkung: Wenn der Browser die Wiedergabeliste nicht automatisch abspielt, klicken Sie hier, um sich die Wiedergabe des Webinars Product Owner Anti-Patterns direkt auf Youtube zu sehen.

✋ Nicht versäumen: Lernen Sie mehr über Product Owner Fehlverhalten im 11.000-köpfigen „Hands-on Agile“ Slack Team

Ich lade Sie ein, sich dem „Hands-on Agile“ Slack-Team anzuschließen und die Vorteile einer schnell wachsenden, lebendigen Gemeinschaft von agilen Praktikern aus der ganzen Welt zu genießen.

Wenn Sie jetzt beitreten möchten, müssen Sie nur noch Ihre Anmeldeinformationen über dieses Google-Formular angeben, und ich werde Sie anmelden. Die Mitgliedschaft ist kostenlos.

Der Artikel Product Owner Fehlverhalten — 33 Möglichkeiten, sich als PO zu verbessern erschien zuerst auf Berlin-Product-People.com.