Product Owner Sabotage – 53 Beispiele aus der Praxis

In Kürze: Product Owner Sabotage – 53 Beispiele aus der Praxis

Eine meiner Lieblingsübungen aus meinen Professional Scrum Product-Owner-Kursen ist die Frage, wie als Mitglied des mittleren Managements am besten Product Owner Sabotage betreibt. Die Regeln der Übung sind einfach: Sie dürfen keine Form von illegalen Aktivitäten anwenden. Es kommt also nicht infrage, die Aufgabe an einen Haufen Gesetzloser zu übertragen. Stattdessen dürfen Sie nur Praktiken anwenden, die in Ihrem Unternehmen kulturell akzeptabel sind.

Lesen Sie weiter und erfahren Sie anhand der Übungsergebnisse aus über zwanzig PSPO-Kursen mehr darüber, wie Sie einen Product Owner am besten sabotieren können. (Ich habe die Vorschläge zur besseren Lesbarkeit überarbeitet.)

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

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

Die Übung: Überlegen Sie, wie Sie einen Product Owner am besten sabotieren

Die Übung basiert auf einer Mikrostruktur von Liberating Structures namens TRIZ.

Hier ist das Briefing für die Teilnehmer. Normalerweise haben diese fünf Minuten Zeit, um in einer Arbeitsgruppe von drei bis fünf Personen Vorschläge und Beobachtungen zu machen.

• Sie sind ein mittlerer Manager in der IT-Organisation und glauben, dass dieses Scrum-Dingens eine Modeerscheinung ist und wieder verschwinden wird—mit ein wenig Hilfe von Ihrer Seite.
• Ihre Aufgabe: Überlegen Sie sich im Team, wie Sie den neuen Product Owner des ersten Scrum-Teams in Ihrem Unternehmen am besten sabotieren können.
• Bitte beachten Sie, dass nur legale und kulturell akzeptierte Praktiken für die Product Owner Sabotage infrage kommen.

Sobald wir den ersten Teil der Übung abgeschlossen haben—das Sammeln von sabotierenden Praktiken—, identifizieren die Teilnehmer der Arbeitsgruppe die Praktiken zur Product Ownern Sabotage, die sie bereits beobachtet haben, und zeigen anschließend Möglichkeiten auf, wie man diesen Praktiken entgegenwirken kann.

Ich habe die Ergebnisse der vorgenannten PSPO-Klassen in acht Gruppen eingeteilt:

1. Das Scrum Framework im Allgemeinen infrage stellen

Bei der ersten Kategorie der Product Owner Sabotage geht es im Allgemeinen darum, Scrum selbst als hilfreiches Rahmenwerk zu disqualifizieren oder Änderungen einzuführen, die den Prinzipien von Scrum zuwiderlaufen:

• Missachten Sie die Autonomie des Product Owners im Allgemeinen.
• Umgehen Sie den Product Owner und sprechen Sie direkt mit den Entwicklern.
• Der Product Owner muss gleichzeitig als Scrum Master fungieren.
• Dem Product Owner werden traditionelle Projektmanagement-Aufgaben aufgebürdet.
• Erzwingen Sie die Anwendung traditioneller oder Wasserfall-Praktiken innerhalb des Scrum-Frameworks; bestehen Sie zum Beispiel auf Ihrer Genehmigung eines jeden Inkrements.
• Isolieren Sie das Scrum-Team, indem Sie "alte" Prozesse an der Schnittstelle zwischen dem Scrum-Team und dem Rest der Organisation anwenden.
• Organisieren Sie wichtige Stakeholder-Meetings parallel zu den Sprint Reviews.
• Stellen Sie sicher, dass kritische Stakeholder nie für den Product Owner erreichbar sind.
• Geben Sie fixe Meilensteine vor.
• Bestehen Sie darauf, dass alle Projekte innerhalb eines festen Zeitrahmens, Umfangs und Budgets abgewickelt werden.

Cannot see the form?
Please click here

2. Scrum Teambildung & Hierarchie

Wenn der direkte Versuch nicht die erwarteten Ergebnisse bringt, warum dann nicht die Hintertür nutzen und dazu beitragen, dass das Scrum-Team so dysfunktional wie möglich ist? Einige Vorschläge, die Sie in Betracht ziehen sollten, sind:

• Ignorieren Sie das Selbstmanagement von Scrum-Teams; ziehen Sie alle Entscheidungen an sich.
• Teilen Sie den Entwicklern mehrere Projekte zu, um den Overhead zu erhöhen. Danach geben Sie dem Product Owner die Schuld für die mangelnde Produktivität.
• Ändern Sie die Struktur des Scrum-Teams häufig, um es in einem Zustand ständiger Teambildung zu halten. Weisen Sie beispielsweise während eines Sprints neue Teammitglieder zu oder tauschen Sie die Entwickler zwischen mehreren Scrum-Teams aus.
• Wählen Sie neue Scrum-Teammitglieder absichtlich unter denjenigen aus, die Scrum offen missbilligen.
• Teilen Sie Teammitgliedern Ad-hoc-Aufgaben zu, die nicht im Fokus des Scrum-Teams liegen.
• Setzen Sie die Entwickler ständig unter Druck. Sagen Sie ihnen, sie seien zu langsam und würden die Anforderungen des Unternehmens nicht verstehen.
• Geben Sie den Entwicklern widersprüchliche individuelle Boni, um einen internen Wettbewerb innerhalb des Scrum-Teams auszulösen.
• Nutzen Sie das Daily Scrum, um den Fortschritt zu überprüfen und machen Sie den Product Owner verantwortlich, wenn dieser Ihre Ziele nicht erreicht.
• Erschweren Sie die Verfügbarkeit von Tools und anderen Ressourcen für das Scrum-Team.

3. Zur Product Owner Sabotage den Informationsfluss behindern

Wenn Sie schon den Teambildungsprozess des Scrum-Teams durcheinanderbringen, warum legen Sie dem Scrum-Team nicht noch ein paar Steine in den Weg? Sabotieren Sie Ihre Product Owner, indem Sie diese im Dunkeln lassen, während Sie sie gleichzeitig dafür verantwortlich machen, nicht auf dem Laufenden zu sein:

• Geben Sie kein Feedback.
• Reagieren Sie ansonsten unregelmäßig und mit großer Verzögerung auf Anfragen des Product Owners.
• Teilen Sie dem Product Owner keine neuen Erkenntnisse oder Informationen über den Markt mit, insbesondere nicht während des Sprint Reviews. Machen Sie den Product Owner später dafür verantwortlich, dass er diese Informationen nicht kennt.
• Nehmen Sie gar nicht erst an dem Sprint Review teil.
• Generell sollten Sie Besprechungswünsche des Product Owners nicht annehmen.
• Schränken Sie den Zugang des Scrum-Teams zu den Kunden ein.
• Stellen Sie sicher, dass ausschließlich die Vertriebsmitarbeiter das Feedback von Kunden an das Scrum Team weitergeben.
• Kommunizieren Sie niemals rechtzeitig organisatorische Änderungen, die die Arbeit des Scrum-Teams beeinflussen könnten.

4. Metriken & Reporting

Der nächste Bereich mit nützlichen Sabotagepraktiken sind Metriken, OKRs oder KPIs. Machen Sie die Mitglieder Ihres Scrum-Teams einfach zu glorifizierten Datenerfassern, auf denen eine anspruchsvolle Berichterstattung lastet:

• Beschäftigen Sie das Team mit unnötigen Berichten, Dokumentations- oder Verwaltungsaufgaben.
• Setzen Sie proprietäre und obskure Metriken durch, die für das Scrum-Team nutzlos sind.
• Verlangen Sie Beweise für den Fortschritt. Gleichzeitig weisen Sie aber alle Vorschläge zu Metriken seitens des Scrum-Teams als untauglich zurück.
• Verlangen Sie detaillierte Angaben darüber, was wann wie getan werden soll. Bestehen Sie auf der Definition von Meilensteinen mit einer genauen Aufschlüsselung der Arbeitsaufgaben.

5. Vision, Product Discovery & Management des Produktbacklogs

Jede Sabotage basiert—zumindest teilweise—auf Täuschung. Verschleiern Sie daher alles, was den Product Ownern helfen könnte, zu verstehen, welche strategische Richtung sie mit ihren Scrum-Teams unterstützen sollen:

• Ändern Sie ständig den Fokus oder die Prioritäten der Organisation.
• Kommunizieren Sie eine unklare Vision und ändern Sie diese regelmäßig.
• Übersetzen Sie die Vision in unklare Anforderungen und weigern Sie sich, diese weiter auszuführen, indem Sie behaupten, die Anforderungen seien offensichtlich.
• Überwältigen Sie den Product Owner mit einer nicht enden wollenden Flut von unklaren Anforderungen und Anfragen.
• Identifizieren Sie Anforderungen, die außerhalb der Kompetenz des Scrum-Teams liegen. Beauftragen Sie das Scrum Team, diese umzusetzen, verweigern Sie diesem gleichzeitig jedoch die notwendigen Ressourcen. Machen Sie den Product Owner für das anschließende Scheitern verantwortlich.
• Überstimmen Sie die Entscheidungen des Product Owners, indem Sie auf Ihre Position pochen.
• Überlasten Sie den Product Owner, indem Sie ihn mit mehreren Produkten gleichzeitig betrauen, nur um sich dann über den daraus resultierenden Mangel an Aufmerksamkeit zu beschweren.
• Fügen Sie dem Product Backlog nach Belieben Einträge hinzu.
• Greifen Sie in die Verwaltung des Product Backlogs und seiner Verfeinerung ein. Bestehen Sie z. B. darauf, stets anwesend zu sein, aber nehmen Sie nur selten an den Meetings teil.
• Bestehen Sie auf detaillierten Spezifikationen für jedes Element des Product Backlogs.

6. Beinträchtigen Sie zur Product Owner Sabotage den Sprint, das Inkrement oder das Release

Lenkt der Product Owner das Scrum-Team immer noch zum Erfolg? Dann ist es an der Zeit für ein paar Gegenmaßnahmen, indem Sie z. B. neue Genehmigungsstufen und Sicherheitsmechanismen einführen—Ihren Kunden zuliebe, versteht sich:

• Lehnen Sie Inkremente als nicht spezifikationsgerecht ab und geben Sie dem Product Owner die Schuld.
• Fügen Sie dem Sprint Backlog Aufgaben für die Entwickler hinzu, die nicht mit dem Sprint Goal übereinstimmen.
• Streben Sie ständig nach Perfektion liefern Sie niemals Produktinkremente wegen offensichtlicher Mängel an die Kundschaft aus.
• Verlangen Sie vor jedem Release einen separaten, mehrstufigen Genehmigungsprozess außerhalb des Scrum-Teams.
• Installieren Sie ein separates Governance Board, das sich mit Fragen der Produktqualität und Sicherheit befasst.
• Definieren Sie neue Sicherheitsprotokolle, die das Scrum-Team überfordern, und berufen Sie sich auf rechtliche Anforderungen.

7. Interne Politik

Nutzen Sie Ihr Karrierekapital, das Netzwerk, das Sie über Jahre hinweg aufgebaut haben, zu Ihrem Vorteil. Vielleicht ist es an der Zeit, ein paar Gefallen einzufordern:

• Säen Sie innerhalb der Unternehmenshierarchie kontinuierlich Zweifel an den Fähigkeiten des Product Owners.
• Stellen Sie die Eignung von Scrum als Framework für Ihr Unternehmen infrage, indem Sie auf Misserfolge in anderen Unternehmen hinweisen.
• Wälzen Sie die Schuld für Misserfolge oder Unzulänglichkeiten auf den Product Owner ab, während Sie die Erfolge des Scrum-Teams für sich beanspruchen.

8. Budget

Wenn alles fehlschlägt, verschwenden Sie keine Zeit mit dem Lesen des Scrum-Guides. Nutzen Sie stattdessen den Budgetierungsprozess zu Ihrem Vorteil:

• Kürzen Sie das Budget, aber behalten Sie den Umfang der geplanten Arbeiten bei.
• Frieren Sie das Budget ein, aber erhöhen Sie den Umfang der geplanten Arbeiten.
• Machen Sie den Budgetprozess prinzipiell länger und komplexer, indem Sie unnötige Anforderungen hinzufügen, zum Beispiel in Bezug auf den Verwaltungsaufwand.

Product Owner Sabotage — eine Zusammenfassung

Jeder mittlere Manager hat reichlich Gelegenheit, Product Owner zu sabotieren. Außerdem ist es in den meisten Fällen unwahrscheinlich, dass andere diese Praktiken als absichtliche Behinderung erkennen werden. Wenn man ihnen den Vorteil des Zweifels einräumt und positive Absichten unterstellt, kommen sie wahrscheinlich damit durch. Daher ist es für uns agile Praktiker von entscheidender Bedeutung, diese Signale rechtzeitig zu erkennen.

Bitte bedenken Sie: Nicht jeder wird begeistert sein, wenn es der Organisation gelingt, agil zu werden. Selbstmanagement und die Verlagerung der Entscheidungsfindung auf diejenigen, die den Problemen am nächsten sind, werden die Hierarchie wahrscheinlich abflachen und den Bedarf an Managern verringern. In der Regel ist die Skalierung der "Agilität" gleichbedeutend mit einer "Verkleinerung der Organisation".

Welche Praktiken der Product Owner Sabotage haben Sie beobachtet? Bitte teilen Sie uns Ihre Erkenntnisse in den Kommentaren mit.

📖 Product Owner Sabotage — Die Leseempfehlungen

Die folgenden Informationsquellen können Sie bei Ihren Bemühungen unterstützen, die Product Owner Sabotage in Ihrem Unternehmen zu unterbinden:

Three Essential Agile Failure Patterns in 7:31 Minutes—Making Your Scrum Work #12

Agile Failure Patterns in Organizations 2.0

Scrum Master Sabotage – 44 Beispiele aus der Praxis

Cargo Cult Agile: The ‘State Of Agile’ Checklist For Your Organization

Scrum First Principles — Mit Elon Musk zum Scrum Guide

Download the ’Scrum Anti-Patterns Guide’ for Free

Der ergänzte Scrum Guide — Scrum Muster und Konzept einfacher erkennen

📅 Professional Scrum-Schulungen nach Scrum.org, Workshops und Events

Sie können sich Ihren Platz für Scrum-Schulungen, Workshops und Meetups direkt sichern, indem Sie dem entsprechenden Link in der Tabelle unten folgen:

Alle kommenden Professional-Scrum-Klassen finden Sie hier.

Sie können Ihren Platz für die Schulung direkt buchen, indem Sie den entsprechenden Links zum Ticketshop folgen. Sollte der Beschaffungsprozess Ihrer Organisation einen anderen Einkaufsprozess erfordern, wenden Sie sich bitte direkt an die Berlin Product People GmbH.

✋ Nicht versäumen: Lernen Sie mehr über Product Owner Sabotage und deren Vermeidbarkeit in der 11.000-köpfigen "Hands-on Agile" Slack-Community

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.

Tags: Anti-Patterns, Product Owner, Scrum Anti-Patterns