Product Owner Fehlverhalten 🇩🇪

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“. Und es dabei spielt keine Rolle, ob dies auf Inkompetenz, Nachlässigkeit oder mangelnde Zusammenarbeit zurückzuführen ist. Zudem ist kein Product Owner der „Mini-CEO“ des Produkts, der eigenmächtig Entscheidungen fällen kann, denn Scrum ist ein Mannschaftssport. In einem erfolgreichen Scrum-Team gibt es keine Einzelgänger, denn Zusammenarbeit und Abstimmung Voraussetzungen sind für den Erfolg.

Ein Product Owner, der hingegen dazu neigt, Entscheidungen im Alleingang zu treffen, läuft Gefahr, seine Lösung über die Probleme der Kunden zu stellen. Folglich ist die Zusammenarbeit und Abstimmung mit den Teamkollegen über das Produktziel und das Produkt-Backlog eine bewährte Strategie zur Risikominderung für Product Owner. Es ist auch ein Beweis für die in Scrum integrierten Kontrollmechanismen, insbesondere jetzt, da das Product Operating Modell mehr Aufmerksamkeit erhält.

Die Rolle des Product Owners nach dem Scrum-Guide

Der Scrum Guide beschreibt die Aufgaben des Product Owners wie folgt:

• Maximierung des Produktwerts aus der Arbeit des Scrum-Teams.
• Entwicklung und explizite Kommunikation des Produktziels.
• Management des Produkt-Backlogs, einschließlich der Delegation von Verantwortlichkeiten, wobei die Rechenschaftspflicht gewahrt bleibt.
• Kommunikation mit den Stakeholdern und Darstellung der Anforderungen im Produkt-Backlog durch direkte Kommunikation oder Scrum-Veranstaltungen wie die Sprint-Überprüfung.
• Sicherstellen, dass das Produkt-Backlog transparent, sichtbar und verständlich ist.
• Anordnen von Produkt-Backlog-Elementen.
• Definieren von Geschäftszielen für Sprints.
• Abbrechen von Sprints, wenn ein Sprint-Ziel hinfällig wird.

Die meisten Product Ownern Anti-Muster resultieren aus einem Missverständnis des Aspekts des Managements des Produkt-Backlogs, der im Mittelpunkt der Verantwortlichkeiten des Product Owners steht. Insbesondere scheitern weniger erfolgreiche Product Owner daran, mit Teamkollegen und Stakeholdern zu kommunizieren. Den Wert der Arbeit des Scrum-Teams aus Kundensicht zu maximieren und gleichzeitig innerhalb der gegebenen Einschränkungen zum Unternehmensergebnis beizutragen, ist weniger eine Frage der Projektmanagementfähigkeiten, des Jonglierens mit Produktanforderungsdokumenten oder der Aktualisierung von Jira.

Folglich verbringen erfolgreiche Product Owner weniger Zeit mit der Bearbeitung des Produkt-Backlogs als vielmehr mit der Entdeckung von Produkten im Allgemeinen und der Abstimmung zwischen allen Beteiligten im Besonderen. Für sie ist das Produkt-Backlog ein Mittel zum Zweck und nicht der Zweck ihrer Existenz.

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

Erfahren Sie mehr: Scrum Guide 2020.

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.)

Food for Thought

Product Owner vs. Product Manager: Brauchen wir in einer Organisation, die sich der Anwendung von Scrum verschrieben hat, einen Produktmanager? Vor allem in größeren Organisationen beobachten wir häufig eine Trennung zwischen diesen beiden Rollen: Der Product Owner ist eine taktische Position auf Teamebene, die das liefert, was der Produktmanager auf Organisationsebene entworfen hat.

Ist dies eine vorteilhafte Aufteilung der Verantwortlichkeiten, wenn man bedenkt, dass unser Product Owner auch für die Product Discovery verantwortlich sein muss, wenn das Scrum-Team erfolgreich ist?

Schlussfolgerung

Zugegeben, die Rolle des Product Owners ist die anspruchsvollste Scrum-Rolle, und je höher die Erwartungen, desto leichter ist es, zu scheitern.

Wir werden als Scrum-Team nicht dafür bezahlt, Scrum zu praktizieren. Kein Stakeholder kümmert sich um diesen Aspekt, solange wir ethisch, legal und im Rahmen der bestehenden Governance-Regeln Werte schaffen. In anderen Worten: Wir werden dafür bezahlt, das Leben unserer Kunden zu verbessern und gleichzeitig zur Nachhaltigkeit unserer Organisation beizutragen.

In diesem Modell ist der Product Owner der Dreh- und Angelpunkt der Wertschöpfung, da er entscheidet, wie es mit dem Scrum-Team weitergeht. Keine andere Rolle in Scrum kann so sehr zu mittelmäßigen Ergebnissen beitragen wie der Product Owner – „garbage in, garbage out“. Sie werden mir sicher zustimmen, dass jeder erfolgreiche Product Owner im Grunde ein Produktmanager sein muss, soll die Rechnung aufgehen.

Glücklicherweise gibt es immer Raum für Verbesserungen, selbst in der anspruchsvollen Rolle des Product Owners. Diese Liste von Product Owner Anti-Mustern kann als Ausgangspunkt für Wachstum und Entwicklung dienen, sowohl auf der Team- als auch der individuellen Ebene.

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

🗞 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 42.000 Abonnenten anschließen.