32 Fehlverhalten von Scrum Interessenvertretern

Scrum Anti-Patterns Guide — Berlin Product People

In Kürze: Die Fehlverhalten von Interessenvertreter

Erfahren Sie, wie individuelle Anreize und veraltete Organisationsstrukturen persönliche Agenden und lokale Optimierungsbemühungen fördern und wie diese sich in Fehlverhalten von Scrum Interessenvertretern manifestieren, die jede agile Transformation behindern können.

32 Fehlverhalten von Scrum Interessenvertretern — Berlin Product People GmbH

Möchten Sie neue Artikel künftig in Ihrem Posteingang vorfinden? Sie können sich hier für unseren Newsletters ‚Food for Agile Thought‘ anmelden und sich 26,000 anderen Abonnenten anschließen.

📅 Nehmen Sie am 25. Hands-on Agile-Meetup am 20. August 2020 teil, um virtuelles Ecocycle Planning mit Qiqochat und Mural zu erkunden.

Scrum Stakeholder und organisatorische Exzellenz in Alt-Organisationen

Regelmäßig wendet InfoQ die „Crossing the Chasm“ – Metapher auf Softwareentwicklungspraktiken an und deckt damit einen Teil der agilen Bewegung zur Schaffung lernender Organisationen ab. Die Ausgabe von „Culture & Methods – the State of Practice in 2019“ stellte fest, dass Organisationen, die Scrum neu einsetzen, sich hauptsächlich aus der späten Mehrheit und den Nachzüglern rekrutieren. (Die frühe Mehrheit der Organisationen adaptiert bereits BDD/DDD oder Pragmatic Agility.)

Diese Nachzügler – oder Alt-Organisationen – sind leicht auszumachen: Eine Unternehmung aus dem Industriezeitalter, in der Regel auf einer strengen Hierarchie basierend, in welcher funktionale Silos mithilfe von Command & Control geführt werden, schaffte es in das postindustrielle Zeitalter. Oftmals wurden diese Organisationen einst gegründet, um Landarbeiter zu Fließbandarbeitern innerhalb eines standardisierten industriellen Prozesses anzulernen, die im Namen der Output-Optimierung standardisierte Produkte herstellen. Die Menschen wurden zu Rädchen in der Maschine, die dafür belohnt wurden, dass sie gut funktionierten, ohne Fragen zu stellen. Bedauerlich, wenn heutzutage Vielfalt, Autonomie, handwerkliches Können und Zielstrebigkeit zu den treibenden Faktoren in einem stark wettbewerbsorientierten Umfeld sind, in dem mehr vom Gleichen für alle keinen Wert mehr schafft.

InfoQ: Culture & Methods – the State of Practice in 2019

Copyright-Hinweis: InfoQ, 2019. (Alle Recht vorbehalten.)

Cannot see the form?
Please click here

Der Konflikt auf der Stakeholder-Ebene in solchen Alt-Organisationen ist offensichtlich: Meistens ist der Interessenvertreter ein Manager eines funktionalen Silos mit Zielen, die nicht unbedingt mit denen eines Produkt- oder Scrum-Teams übereinstimmen. Wenn die Organisation sich in eine Art „Team von Teams“-Struktur verwandeln muss, dann ist ein gemeinsamen Verständnis von Zweck und Richtung sowie der Notwendigkeit, Werte für die Kunden zu schaffen, zwingend notwendig. Die Realität einer Alt-Organisation, die versucht, agil zu werden, ist von diesem Ideal oft sehr verschieden. Für Manager bedeutet der neue Ansatz zwingend Verhaltensänderungen:

  • Vom WIFMD-Syndrom (Was-ist-für-mich-drin-Syndrom) zur umfassenden Zusammenarbeit — das Team gewinnt, das Team verliert,
  • Von der Karriereplanung als Einzelperson zu Servant Leadership in einem Team von Teams,
  • Von allwissend zu den Teammitgliedern vertrauend
  • Von „Scheitern ist keine Option“ zur Akzeptanz des Scheiterns als Mittel und Seiteneffekt effektiven Lernens,
  • Von der Beanspruchung des Teamerfolgs als persönlichen Erfolg zum Lenken des Rampenlichts auf das verantwortliche Team.

Das alte (Management-) Spiel — und damit auch seine Machtsymbole — aufzugeben und zu akzeptieren, dass ein agile Transformation zwar Arbeitsplatzsicherheit, aber ganz sicher keine Rollensicherheit bietet, ist ein monumentales Unterfangen für die Mehrheit der Führungskräfte einer Alt-Organisation. Wahrscheinlich werden sich viele dieser Manager nicht anpassen und früher oder später sogar aus der Organisation ausscheiden.

Upcoming Scrum Training Classes, Remote Agile Classes, and Liberating Structures Workshops — Fehlverhalten von Scrum Interessenvertretern — Berlin Product People GmbH

Typische Scrum Stakeholder Fehlverhalten

Nachdem wir den Kontext definiert haben, wollen wir einige Fehlverhalten von Scrum Interessenvertretern im Detail betrachten. Meistens resultieren die Scrum Stakeholder Fehlverhalten aus einer Trainings- und Coaching-Lücke, die damit einhergeht, dass individuelle Karriereziele in Hinblick auf die Transformation nicht verändert werden. So manifestieren sie sich in der fortgesetzten Verfolgung von lokalen Optima oder persönlichen Agenden. In beiden Situationen begünstigt die Bonusstruktur einer Organisation höchstwahrscheinlich immer noch ein vorhersehbares Verhalten von Interessenvertretern, das den Zielen der Organisation auf Systemebene widerspricht.

Charlie Munger: “Never, ever, think about something else when you should be thinking about the power of incentives.”

Die folgende Liste von Fehlverhalten von Scrum Interessenvertretern befasst sich mit Scrum-Ereignissen, systembezogenen Themen sowie mit Fragen einzelner Akteure.

Scrum Stakeholder Fehlverhalten auf Scrum Event Ebene

Sprint Anti-Patterns der Interessenvertreter

  • Entwickler direkt ansprechen: Die Interessenvertreter versuchen, kleine Aufgaben in den Sprint zu schleusen, indem sie diese direkt den Entwicklern vorschlagen.
  • Jedes Feature ist ein Bug: Die Interessenvertreter versuchen, die Lieferung zu beschleunigen, indem sie ihre Aufgaben als „ernsthafte Fehler“ bezeichnen. (Ein Sonderfall ist eine „Express-Spur“ für Fehlerbehebungen und andere dringende Probleme. Meiner Erfahrung nach wird jeder Beteiligte irgendwann versuchen, seine oder ihre Anforderungen in diese „Express-Spur“ zu bekommen).
  • Unterbrechung des Flusses: Der Scrum Master ermöglicht es den Stakeholdern, den Fluss des Scrum Teams während des Sprints zu unterbrechen. Es gibt mehrere Möglichkeiten, wie Stakeholder den Fluss des Teams während eines Sprints unterbrechen können. Jedes der folgenden Beispiele wird die Produktivität des Teams behindern und könnte die Erreichung des Sprint-Ziels gefährden. Der Scrum Master muss daher verhindern, dass diese sich manifestieren:
    • Der Scrum Master hat eine Laissez-faire-Politik, was den Zugang zum Entwicklungsteam betrifft. Insbesondere schult er oder sie die Stakeholder nicht über die negativen Auswirkungen von Störungen und wie diese die Erreichung des Sprint-Ziels gefährden können.
    • Der Scrum Master hat nichts dagegen einzuwenden, dass Vorgesetzte Teammitglieder aus dem Scrum Team nehmen und andere Aufgaben zuweisen.
    • Der Scrum Master hat ebenfalls nichts dagegen einzuwenden, dass Scrum Stakeholder Entwickler als Fachexperten zu willkürlichen Meetings einladen.
    • Schließlich ermöglicht der Scrum Master, dass entweder die Stakeholder oder die Vorgesetzten das Daily Scrum in eine Reporting-Session verwandeln. Dieses Verhalten behindert die Produktivität des Entwicklungsteams, indem es seine Selbstorganisation untergräbt und traditionelle Führungsprinzipien durch die Hintertür wieder einführt.
Download the Remote Agile Guide for Free

Product Backlog Anti-Muster

Diese Art von Fehlverhalten der Interessenvertreter resultiert daraus, dass sie die Rolle des Product Owners ignorieren und ihn oder sie zu einem bloßen Schreiberling degradieren. Zwei wichtige Anti-Muster dieser Art sind:

  • Kopieren & Einfügen-PO: Der Product Owner erstellt Einträge, indem er oder sie Anforderungsdokumente von Stakeholdern in kleinere Stücke zerlegt. (Dieses Szenario trug dazu bei, den Spitznamen „Ticket Monkey“ für den Product Owner zu prägen. Die Erstellung von Product-Backlog-Einträgen ist hingegen eine Teamaufgabe.)
  • Priorisierung durch einen Stellvertreter: Ein einzelner Stakeholder oder ein Komitee von Stakeholdern priorisiert das Product Backlog. (Die Leistungsfähigkeit von Scrum basiert auf der starken Position des Product Owners. Sie oder er ist die einzige Person, die entscheidet, welche Anforderungen zu Product-Backlog-Einträgen werden. Somit entscheidet auch der Product Owner über die Ordnung des Product-Backlogs. Wenn man diese Ermächtigung des PO eliminiert, verwandelt sich Scrum in einen ziemlich robusten Wasserfall 2.0 Prozess.)

Fehlverhalten im Daily Scrum

Die meisten Scrum Stakeholder Anti-Muster in dieser Kategorie ergeben sich aus einem gefühlten Informationsbedürfnis. Stellen Sie sich diese als Entzugssymptome vor:

  • Statusreport: Das Daily Scrum ist ein Statusreport-Meeting, und die Mitglieder des Entwicklungsteams warten darauf, ihre Fortschritt an einen Stakeholder zu „berichten“.
  • Gesprächige Stakeholder: Die „Chickens“ nehmen aktiv am Daily Scrum teil. (Die Stakeholder sollten zuhören, aber die Mitglieder des Entwicklungsteams während ihrer Inspektion des Fortschritts auf das Sprint-Ziel nicht ablenken.)
  • Command & Control durch das Management: Die Vorgesetzten nehmen am Daily Scrum teil, um „Leistungsdaten“ über einzelne Teammitglieder zu sammeln. (Dieses Daily Scrum Anti-Pattern widerspricht dem Zweck selbstorganisierender Teams.)
  • „Hättest Du nach dem Stand-up kurz Zeit?“: Die Vorgesetzten warten bis zum Ende des Daily Scrum und sprechen dann einzelne Mitglieder des Entwicklungsteams an, um Berichte von ihnen zu erhalten. (Auch dieser Hack ist ein unerwünschtes Verhalten und lenkt das Entwicklungsteam ab.)
  • Zuweisungen: Ein Stakeholder vergibt Aufgaben direkt an die Teammitglieder.

Scrum Stakeholder Fehlverhalten beim Sprint Planning

Prognose seitens Dritter: Die Sprintprognose über die vermutlich bewältigbare Arbeit ist keine teambasierte Entscheidung. Oder sie ist nicht frei von äußeren Einflüssen. (Es gibt hier mehrere Anti-Patterns: Zum Beispiel dominiert ein durchsetzungsstarker Product Owner oder Stakeholder das Entwicklungsteam, indem er oder sie den Umfang der Prognose definiert. Oder ein Interessenvertreter weist auf die frühere Velocity des Teams hin und fordert, mehr Aufgaben in den Sprint zu übernehmen— „wir müssen die verfügbare Kapazität auslasten“— oder der ‚technische Leiter‘ des Entwicklungsteams erstellt eine Prognose im Namen des Entwicklungsteams.)

Anti-Muster des Sprint Reviews

Diese Kategorie von Fehlverhalten von Scrum Interessenvertretern wiederum ist oft eine Kombination aus Unwissenheit, dem Kampf gegen einen wahrgenommenen Kontrollverlust oder Bestehen auf Managementprivilegien, um Scrum-Prinzipien außer Kraft zu setzen:

  • Scrum à la Stage-Gate®: Der Sprint Review ist eine Art Stage-Gate®-Genehmigungsprozess, bei dem Stakeholder Features abnehmen. (Dieses Sprint Review Anti-Pattern ist typisch für Unternehmen, die einen „agilen“-Wasserfall-Hybrid-Prozess verwenden. Es liegt jedoch im Ermessen des Product Owners, zu entscheiden, was wann released werden soll; das ist nicht Aufgabe der Stakeholder.)Fehlverhalten von Scrum Interessenvertretern — Stage-Gate® — Berlin Product People GmbH
  • Keine Stakeholder anwesend: Stakeholder nehmen nicht an dem Sprint Review teil. (Es gibt mehrere Gründe, warum Stakeholder nicht am Sprint Review teilnehmen: Sie sehen keinen Wert in dem Event, oder es überschneidet sich mit einem anderen wichtigen Meeting. Sie verstehen nicht, wie wichtig der Sprint Review für das Scrum Team ist und außerdem nimmt niemand von der Führungsebene am Sprint Review teil. Nach meiner Erfahrung muss man das Event innerhalb des Unternehmens „verkaufen“, zumindest zu Beginn der Nutzung von Scrum.)
  • Keine Kunden anwesend: Externe Stakeholder — auch Kunden genannt — nehmen nicht an dem Sprint Review teil. (Mein Vorschlag: Brechen Sie aus dem Filterblase Ihrer Organisation aus und laden Sie einige zahlende Kunden zu Ihrem Sprint Review ein.)
  • Keine Kontinuität: Es gibt keine Kontinuität in der Anwesenheit von Stakeholdern. (Beständigkeit ist nicht nur auf Teamebene von Vorteil, sondern gilt auch für die Teilnahme von Stakeholdern. Wenn sich die Zusammensetzung des Teilnehmerkreises zu oft ändern, z.B. aufgrund eines Rotationsschemas, kann dessen Fähigkeit, detailliertes Feedback zu geben, darunter leiden. Wenn dieses Antimuster auftritt, muss das Scrum-Team daran arbeiten, dass die Beteiligten die Bedeutung des Sprint Reviews besser verstehen.)
  • Passive Stakeholder: Die Stakeholder sind passiv und nicht engagiert. (Das Problem ist einfach zu beheben. Lassen Sie die Stakeholder den Sprint Review steuern. Oder organisieren Sie den Sprint Review als Messe mit mehreren Ständen. Shift & Share ist eine ausgezeichnete Übungen der Liberating Structures für diesen Zweck.)

Fehlverhalten von Scrum Interessenvertretern bei der Sprint Retrospective

Hier geht es vor allem um Fragen der Kontrolle und der Personalführung:

  • Stakeholder-Alarm: Die Stakeholder beteiligen sich an der Retrospektive. (Es gibt mehrere Möglichkeiten in Scrum auf die Kommunikations- und Informationsbedürfnisse der Stakeholder einzugehen: hauptsächlich der Sprint Review, das Daily Scrum, wahrscheinlich sogar das Refinement des Product Backlogs, ganz zu schweigen von den Möglichkeiten, ein Gespräch bei Kaffee oder während der Mittagspause zu führen. Sollte dieses Spektrum an Möglichkeiten immer noch nicht ausreichen, so können Sie zusätzliche Meetings in Betracht ziehen, wenn Ihr Team dies für notwendig hält. Die Teilnahme an der Retrospektive ist jedoch für Stakeholder tabu.)
  • Her mit dem Protokoll: Jemand von der Organisation — außerhalb des Scrum-Teams — verlangt Zugriff auf das Retrospektivenprotokoll. (Das ist fast so schlimm wie Vorgesetzte, die an einer Retrospektive teilnehmen wollen. Natürlich muss der Zugriff verweigert werden.)

Scrum Stakeholder Anti-Muster auf Systemebene

Diese Anti-Muster resultieren hauptsächlich aus einem halbherzigen Ansatz, eine agile Organisation zu werden. Typischerweise endet sie in der Form Cargo-Cult-Agilität:

  • Mangel an Transparenz: Die Organisation ist in Bezug auf Vision und Strategie nicht transparent, weshalb die Scrum-Teams daran gehindert werden, sich selbst zu organisieren.
  • Führungsmängel: Das obere Management beteiligt sich nicht an agilen Prozessen, z. B. den Sprint-Reviews, obwohl es eine Vorbildrolle hat. Stattdessen erwarten sie eine ihnen genehme Form der Berichterstattung.
  • Cargo-Cult-Agilität durch Rosinenpicken: Agile Prozesse werden entweder verdreht oder ignoriert, wann immer es angebracht erscheint, z. B. wird die Rolle des Product Owner auf eine Projektmanagerrolle reduziert. Oder Stakeholder umgehen den Product Owner, um eigene Dinge erledigt zu bekommen und kommen in den Augen der Unternehmensleitung davon, da sie „Initiative zeigen“ würden. Es mangelt an Disziplin, um die agile Transformation zu unterstützen.
  • Zu knappes Budget: Die Organisation wendet nicht genügend Zeit und Budget für eine angemessene Kommunikation, Schulung und Betreuung auf, um ein gemeinsames Verständnis von Zweck und Richtung unter allen Mitgliedern der Organisation zu schaffen.
  • Den Menschen sagen, wie sie Dinge tun sollen: In den guten alten Zeiten in der Werkstatt war es eine wertvolle Eigenschaft, Neulinge oder Arbeitsgruppen in der Kunst des Zusammenbaus eines Model T genau zu schulen — wie es die Manager zuvor wahrscheinlich selbst gelernt haben. Heutzutage, da wir die meiste Zeit in den Bau von Produkten investieren, die noch nie zuvor gebaut wurden, wird diese Einstellung zu einer Belastung. Lassen Sie einfach die Menschen, die der jeweiligen Aufgabe am nächsten stehen, herausfinden, wie man das am besten macht. Eine Anleitung durch Vorgaben und die Gewährung von Unterstützung, wenn diese angefordert oder benötigt wird, wird jedoch geschätzt.
  • Lenkungsausschüsse: Unbeeindruckt von der agilen Arbeitsweise besteht die Manager darauf, die zweiwöchentlichen Lenkungsausschüsse fortzusetzen, um sicherzustellen, dass das Team alle ihre Anforderungen rechtzeitig erfüllt. Hier gibt es jedoch eine schnelle Abhilfe: Nehmen Sie als Team einfach nicht an Sitzungen teil, die keinen Wert haben.
  • Kein Zugang zum Kunden: Die Verkaufsorganisation und andere funktionale Silos verhindern den direkten Zugang zum Kunden und beeinträchtigen damit das Lernen der Scrum Teams.

Sprint Anti-patterns des IT Managements

Außerdem gibt es einige typische Fehlverhalten der Stakeholder, die den Scrum-Teams am nächsten stehen — das IT-Management:

  • Alle Mann an Deck — aber ohne Scrum: Das Management gibt Scrum in einer kritischen Situation vorübergehend auf. (Dies ist eine klassische Manifestation des Zweifels an agilen Praktiken, die sich aus dem Command & Control-Denken speisen. Höchstwahrscheinlich würde auch die Absage von Sprints und eine Neufokussierung der Scrum-Teams das vorliegende Problem lösen.)
  • Neuzuweisung von Teammitgliedern: Das Management weist regelmäßig Mitglieder eines Scrum-Teams einem anderen Team zu. (Scrum kann nur dann sein Potenzial voll ausschöpfen, wenn die Teammitglieder untereinander Vertrauen aufbauen können. Die Langlebigkeit der Teams ist daher von entscheidender Bedeutung. Das Versetzen von Mitarbeitern zwischen Teams spiegelt im Gegensatz hierzu eine projektorientierte Managementphilosophie wider, die in der Nutzungsoptimierung des industriellen Paradigmas verwurzelt ist. Sie ignoriert auch die bevorzugte Teambildungspraxis: Scrum-Teams sollten sich selbst auswählen, alle Mitglieder müssen freiwillig in einem Scrum Team sein. Scrum funktioniert nicht, wenn es Teammitglieder aufgezwungen wird. Anmerkung: Es ist jedoch kein Anti-Pattern, wenn die Scrum-Teams beschließen, ihre Teamkollegen vorübergehend untereinander auszutauschen. Es ist eine etablierte Praxis, dass Spezialisten auf diese Weise Wissen verbreiten oder anderen Kollegen helfen.)
  • Spezialkräfte: Ein Manager weist bestimmte Aufgaben direkt den Entwicklern zu und umgeht so den Product Owner und ignoriert das Vorrecht des Entwicklungsteams, sich selbst zu organisieren. Alternativ entfernt der Manager einen Entwickler aus einem Team, damit dieser an einer anderen Aufgabe arbeiten kann. (Dieses Verhalten verstößt nicht nur gegen zentrale Scrum-Prinzipien. Es weist auch darauf hin, dass der Manager die alten Command- und Control-Praktiken nicht aufgeben mag. Er oder sie fährt fort, Untergebene zu bevormunden, obwohl ein Scrum-Team die Aufgabe auf selbstorganisierte Weise erledigen könnte. Dieses Verhalten zeigt ein Maß an Unwissenheit, das möglicherweise die Unterstützung des Scrum-Masters durch eine höhere Führungsebene erfordert.)

Persönlich motivierte Anti-Muster

Es gibt zahlreiche Möglichkeiten, wie Interessenvertreter den Fortschritt eines Produktteams behindern können. Fünf der häufigsten Fehlverhalten von Scrum Interessenvertretern sind die Folgenden:

  • Mein-Budget-Syndome: Die Stakeholder konkurrieren nicht um die Kapazität eines Scrum-Teams, sondern behaupten, dass sie „ihr“ Budget auf Feature-Anfragen nach eigenem Gutdünken zuteilen. (Dieser Prozess führt zur Schaffung lokaler Optima auf Silo- oder Abteilungsebene. Der Effekt ist besonders in Organisationen zu beobachten, die zusätzliche Zuwendungen an Einzelpersonen gewähren, wenn Vorgaben auf Abteilungsebene errreicht werden. Stattdessen sollten die Ressourcen im Geiste der Optimierung für die gesamte Organisation zugewiesen werden. Anmerkung: Auch „Lieblingsprojekte“ fallen in diese Kategorie.)
  • Wir wissen, was gebaut werden muss: Es gibt keine Anwenderforschung und auch keine anderen Interaktionen der Produktorganisation mit Kunden. (Es gibt mehrere Gründe, die dieses Phänomen verursachen, angefangen bei einem Gründer oder Unternehmer, der seine Produktvision verfolgt, ohne sich an Kundenforschungsaktivitäten zu beteiligen. Oder die Produktorganisation wird ausschließlich indirekt von Key-Account-Managern über Kundenbedürfnisse informiert. Wahrscheinlich hält die Vertriebsabteilung einen direkten Kontakt der Scrum-Teammitglieder mit Kunden für zu riskant und verhindert ihn daher. Was diese Anti-Muster gemeinsam haben, ist entweder eine Voreingenommenheit, die dem Lernprozess schadet oder eine persönliche Agenda. Während Ersteres durch Bildung überwunden werden kann, ist Letzteres schwieriger zu erreichen, da die Übeltäter typischerweise die Vorstellung ablehnen, dass sie von egoistischen Motiven geleitet werden. Um eine effektive Produktorganisation zu werden, ist es von wesentlicher Bedeutung, dass die Scrum Teams regelmäßig und direkt mit den Kunden kommunizieren.)
  • Verkaufen nicht vorhandener Funktionen: Welche Funktionen müssen wir zur Verfügung stellen, um das Geschäft abzuschließen? Vertriebler verfolgen Vertriebsziele, indem sie Interessenten um eine Wunschliste mit Funktionen bitten und diese der Produktlieferungsorganisation als Anforderungen übermitteln. (Das Problem mit den Kunden besteht darin, dass ihnen in der Regel die erforderlichen Kenntnisse fehlen, um nützliche Antworten auf diese Frage zu geben. Meistens fehlt ihnen auch die Ebene des abstrakten Denkens, die erforderlich ist, um eine praktikable, brauchbare und realisierbare Lösung zu finden. Wie das Sprichwort sagt: Wenn das einzige Werkzeug, mit dem Sie vertraut sind, ein Hammer ist, wird jedes Problem wie ein Nagel aussehen. Verfolgt man den Verkaufsprozess auf diese Weise, so wird das Produkt in eine Sackgasse geführt, wahrscheinlich zusätzlich durch Boni und persönliche Absichten beeinflusst. Das ist der Grund, warum Produktmanager die Kunden gerne in ihrer typischen Umgebung beobachten, wie sie ein Produkt verwenden, um eine derartige Fehlallokation von Ressourcen zu vermeiden. Auf Systemebene ist es hierzu auch hilfreich, individuelle finanzielle Anreize für Verkäufer zu überdenken. In einer lernenden Organisation gewinnen Teams und nicht Einzelpersonen.)
  • Bonus in Gefahr: Wir nähern uns dem Ende eines Quartals. Bonusrelevante Zielvorgaben laufen Gefahr, nicht erreicht zu werden. Die verantwortliche Stelle fordert Produktänderungen bzw. -erweiterungen in der Hoffnung, dass diese zusätzliche Verkäufe anregen. (Dieses Verhalten ist vergleichbar mit dem Anti-Muster „Welche Funktionen benötigen Sie, um das Geschäft abzuschließen“, wird jedoch dringlicher verlangt, in der Regel wenige Wochen vor Ablauf einer Bonusperiode, dann jedoch um so dringlicher.)
  • Finanzielle Anreize zur Innovation: Die Organisation gibt monetäre Anreize für neue Ideen und Vorschläge. (Ein Beitrag zu der Liste von Produktideen und damit zu den später in die engere Wahl gezogenen Hypothesen sollte intrinsisch motiviert sein. Jeder mögliche persönliche Gewinn könnte als Folge die Anzahl der Vorschläge aufblähen und das Produktteam dadurch ablenken, ohne einen Mehrwert zu schaffen.)

Weitere Informationen finden Sie im Webinar:: Product Discovery Anti-patterns.

Scrum Master Interview Question: free download of the most popular ebook on Scrum Master job interviews — by Age-of-Product

Fehlverhalten von Scrum Interessenvertretern — Fazit

Es gibt viele verschiedene Gründe, warum Scrum-Stakeholder nicht wie erwartet handeln. Einige resultieren aus organisatorischer Unzulänglichkeit, insbesondere bei Alt-Organisationen aus dem industriellen Bereich. Einige sind intrinsisch motiviert, z. B. durch persönliche Agenden, während andere aus mangelnder Ausbildung oder Ängsten herrühren. Was auch immer der Grund sein mag, Scrum Stakeholder Fehlverhalten müssen überwunden werden, um eine agile Transformation zu einem Erfolg zu machen. Andernfalls könnten Sie in einer Form von Cargo-Cult-Agilität oder Scrumbut enden.

Welche Fehlverhalten von Scrum Interessenvertretern haben Sie beobachtet? Bitte teilen Sie uns diese in den Kommentaren mit.

✋ Nicht versäumen: Lernen Sie mehr über Scrum Stakeholder Anti-Muster im 7.900-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.

Produktdenkweise: Join the Hands-on Agile Slack Group

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.

Scrum Stakeholder Anti-Muster — Weitere Lektüre

Download the Scrum Anti-Patterns Guide: 160-plus ways to improve your way of Scrum.

27 Sprint Anti-Patterns

Agile Management Anti-Patterns — An Introduction.

Tags: Agile transformation, Anti-Muster, Interessenvertreter, Stakeholder

Leave a reply

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.