36 Fehlverhalten von Scrum Interessenvertretern 🇩🇪

In Kürze: Die Fehlverhalten von Scrum Interessenvertretern

Erfahren Sie, wie individuelle Anreize und veraltete Organisationsstrukturen – die persönliche Agenden und lokale Optimierungsbemühungen fördern – sich in Fehlverhalten von Scrum Interessenvertretern manifestieren, die leicht jede agile Transformation zu einer produktorientierten Organisation behindern.

🗳 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!

📅 💯 🇬🇧 June 20-23: A guaranteed Professional Scrum Master Training w/ PSM I Certificate in English.

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 2022“ 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 ntuzen bereits Business Agility, die Selbstauswahl von Team und Mob-/Ensemble-Programmierung.)

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.

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 aus Teams,
• Von allwissend und Problemlöser 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 und resultiert vielfach in Fehlverhalten von künftigen Scrum Interessenvertretern. Wahrscheinlich werden sich viele dieser Manager nicht anpassen und früher oder später sogar aus der Organisation ausscheiden.

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 Fehlverhalten von Scrum Interessenvertretern befasst sich mit systembezogenen Problemen, Fehlverhalten einzelner Akteure und mit Scrum-spezifischen Antimustern.

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. (“If you don’t know where you are going, any road will get you there.” In einem komplexen Umfeld mit einem hohen Maß an Wettbewerb und Unsicherheit muss jeder das Warum, das Was, das Wie und das Wer verstehen. Ein Mangel an Transparenz wird jede Anstrengung, agil zu werden, im Keim ersticken, denn dann werden sich nicht Missionare, sondern Söldner um die Aufgabe scharen. Elon Musks “The Secret Tesla Motors Master Plan (just between you and me)” ist ein gutes Beispiel für die Transparenz der Führung auf der Ebene der Vision und der Strategie.)
• 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. (Die Unterstützung des oberen Managements ist für jede Transformation von entscheidender Bedeutung. Kein Scrum-Team wird erfolgreich sein, wenn die „Führung“ die Bemühungen nicht anführt, indem sie z. B. an den Sprint Reviews teilnimmt, um jedem im Unternehmen ein Signal zu geben: Agilität ist eine bleibende Änderung, keine Modeerscheinung.)
• 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. (Das Herauspicken von agilen Praktiken und das Ignorieren des Kontexts, der erforderlich ist, damit diese funktionieren, ist eine verbreitete Form von Augenwischerei in Sachen ‚Agilität‘. Da diese jedoch Teil eines komplexen Systems sind, funktionieren isolierte agile Elemente in der Regel nicht, wenn das Unternehmen das Ziel hat, „geschäftliche Agilität“ zu erreichen. Um agil zu werden, muss sich die Denkweise ändern, gefolgt von einem organisatorischen Umbruch. Einfach nur ab und zu Retrospektiven zu veranstalten, reicht nicht aus.)
• 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. (Agil zu werden und geschäftliche Agilität anzustreben, ist ein monumentales und teures Unterfangen. Während die Ausgaben sofort sichtbar werden, kann es sein, dass sich die Investition erst nach Jahren auszahlt. Daher ist es ein sicherer Weg zum Scheitern, wenn Sie zu Beginn der Umstrukturierung notwendige Ausgaben kürzen und dabei auf ‚fehlende Ergebnisse‘ als Begründung verweisen.)
• 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 die Leute, die sich am besten mit der Aufgabe auskennen, herausfinden, wie man das Problem angeht; in einer komplexen Umgebung gibt es keine Experten: “How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.” (Quelle: Scrum Guide 2020.) Die Orientierung an Zielen und die Bereitstellung von Unterstützung, wenn sie gewünscht 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 eine schnelle Lösung: Nehmen Sie einfach nicht an Meetings teil, die keinen Wert für das Scrum-Team haben, während Sie gleichzeitig auf die Stakeholder zugehen und deren Lernweg unterstützen.)
• 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. (Die Vertriebsorganisation und andere funktionale Silos hüten den direkten Zugang zu den Kunden und verhindern so, dass die Scrum-Teams direkt von den Kunden lernen können. Die Vertriebsorganisation hält einen direkten Kontakt von Scrum-Team-Mitgliedern mit Kunden wahrscheinlich für zu riskant (für ihre Verkaufspläne) und verhindert diesen. Das Problem ist, dass das Filtern von Kundenfeedback vor allem dazu führt, dass das Scrum-Team die Situation des Kunden nur begrenzt versteht. Darüber hinaus kann es passieren, dass kritische Informationen über potenzielle Lösungen aufgrund mangelnder technischer Kompetenz aufseiten der Vertriebsorganisation das Scrum-Team nie erreichen, was dessen Fähigkeit einschränkt, eine Lösung auf die Bedürfnisse des Kunden zuzuschneiden. Um eine effektive Produktorganisation zu werden, ist es daher unerlässlich, dass das Scrum-Team regelmäßig direkt mit den Kunden kommuniziert.)

Sprint Antimuster 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 speist. Mit hoher Wahrscheinlichkeit würde auch die Absage eines Sprint und die Refokussierung 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 und die Langlebigkeit von Teams hat sich zur Bildung dieses Vertrauens als nützlich erwiesen. 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. Eine weitere Spielart dieser autonomen Teambildung ist das Dynamic Reteaming.)
• Spezialkräfte: Ein Manager weist bestimmte Aufgaben direkt den Entwicklern zu und umgeht so den Product Owner und ignoriert das Vorrecht der Entwickler, sich selbst zu organisieren. Alternativ nimmt der Manager einen Entwickler aus einem Team heraus, damit dieser an einer anderen Aufgabe für ihn 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 Stakeholder Fehlverhalten auf Scrum Event Ebene

Sprint Anti-Patterns der Interessenvertreter

Es gibt eine ganze Reihe von Fehlverhalten von Scrum Interessenvertretern während des Sprints. Einige wichtige negative Verhaltensweisen sind:

• Regelmäßige Notfälle: Jemand in deinem Unternehmen hat einem Kunden ein nicht existierendes Feature oder eine Funktionalität verkauft, um ein Geschäft abzuschließen. Gleichzeitig wurden wahrscheinlich bereits Liefertermine und Vertragsstrafen für den Fall der Nichtlieferung vereinbart. Jetzt soll sich das Scrum-Team darauf konzentrieren, diese Funktion zu liefern. (Es mag Momente geben, in denen dieser Eingriff von außen in den Scrum-Prozess unglücklich, aber akzeptabel ist. Besorgniserregender ist hier die Aussicht, dass dieses Verhalten zur Regel wird. Wenn die Unternehmensleitung diese Ausnahmesituation nicht anerkennt, kann sie die Anwendung von Scrum in der Organisation zum Scheitern bringen.)
• Entwickler direkt ansprechen: Die Interessenvertreter versuchen, kleine Aufgaben in den Sprint zu schleusen, indem sie diese direkt den Entwicklern vorschlagen. (Netter Versuch, allerdings konkurrieren alle Vorschläge um die Aufmerksamkeit des Scrum-Teams miteinander, und der Product Owner ist der Schiedsrichter in diesem Prozess.
• Jedes Feature ist ein Bug: Die Interessenvertreter versuchen, die Lieferung ihrer Anliegen 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 Anforderungen in diese „Express-Spur“ zu bekommen).
• Flow-Unterbrechung: Der Scrum Master ermöglicht es den Stakeholdern, den Flow 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 Beispiele wird die Produktivität des Teams behindern und kann die Erreichung des Sprint-Ziel gefährden: 
  • Die Stakeholder wenden sich während des Sprints ständig an die Entwickler und ignorieren dabei, dass die regelmäßigen Unterbrechungen der Effektivität des Scrum-Teams schaden; hier: dem Erreichen des Sprint-Ziels.
  • Vorgesetzte nehmen Teammitglieder aus dem Scrum-Team heraus und weisen ihnen andere Aufgaben zu. (Die Bildung eines Scrum-Teams ist aufgrund des unvermeidlichen Produktivitätsrückgangs während der Norming- und Storming-Phasen eine teure Angelegenheit. Daher ist die Änderung der Teamzusammensetzung eine kritische Entscheidung, in die die Teammitglieder einbezogen werden müssen. Scrum-Teams sind keine getarnten ‚Talentpools‘, die den Vorgesetzten nach Belieben zur Verfügung stehen.)
  • Vorgesetzte fügen dem Scrum Teammitglieder ohne vorherige Rücksprache mit den anderen Teammitgliedern hinzu. (Vorzugsweise sollten die Mitglieder des Scrum-Teams entscheiden, wer dem Team beitritt, siehe oben.)
  • Stakeholder oder Manager nutzen das Daily Scrum als Berichtsrunde. (Dieses Verhalten wird die Produktivität der Entwickler beeinträchtigen, da es ihr Selbstmanagement untergräbt und gleichzeitig durch die Hintertür wieder Command & Control einführt.)

Product Backlog Anti-Muster

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

• Stakeholder-Anforderungen werden durchgewunken: Der Product Owner erstellt Einträge, indem man Anforderungsdokumente von Stakeholdern einfach 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; der Verfeinerungsprozess hilft allen Beteiligten, das Warum, das Was und das Wie zu verstehen. Man denke zudem an Karl Popper: “Always remember that it is impossible to speak in such a way that you cannot be misunderstood.”)
• 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 von Scrum Interessenvertretern im Daily Scrum

Die meisten Fehlverhalten von Scrum Interessenvertretern 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“. (Die „drei Daily-Scrum-Fragen“ dienen hier oft als Vorlage für dieses Fehlverhalten.)
• Zuweisungen: Ein Stakeholder vergibt Aufgaben direkt an die Teammitglieder. (Es ist das Vorrecht der Entwickler, während der Sprintplanung alle Arbeiten auszuwählen, die sie zur Erreichung des Sprint-Ziels für notwendig erachten. Niemand ist befugt, die Arbeitslast der Entwickler zu erhöhen, indem sie ihnen neue Aufgaben zuweisen.)
• 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. (Netter Versuch. Dieser Hack ist aber auch ein unerwünschtes Verhalten und lenkt das Entwicklungsteam ab.)
• Gesprächige Stakeholder: Die „Chickens“ nehmen aktiv am Daily Scrum teil. (Die Stakeholder sollten zuhören, aber die Entwickler während ihrer Inspektion des Fortschritts auf das Sprint-Ziel nicht ablenken.)
• Kommunizieren über die Körpersprache: Formal bleiben die Stakeholder stumm. Sie beteiligen sich jedoch durch ihre Körpersprache am Daily Scrum. (Auch hier gilt: Die Stakeholder sollen zuhören, aber die Entwickler nicht ablenken. Das Rollen mit den Augen und das Verziehen des Gesichts sind jedoch genauso wirkungsvoll wie das gesprochene Wort. Außerdem sind selbst subtile Formen der Körpersprache Kommunikation, denn man kann nicht „nicht kommunizieren“. Außerdem können manche Interessenvertreter von Natur aus eine einschüchternde Ausstrahlung haben, die sich als nachteilig für die Kommunikation zwischen den Entwicklern erweisen kann.)

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 die Entwickler, indem er 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‘ unter den Entwicklern erstellt eine Prognose im Namen aller Entwickler.)

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-Muster ist typisch für Organisationen, die eine Mischung aus „agile“ und „Wasserfall“ verwenden: Es gibt einige glückliche agile Inseln, z. B. unser Scrum-Team, umgeben von einem Meer aus Wasserfall-Planung, das von funktionalen Silos, Budgetierung und Top-Down-Zielsetzung bestimmt wird. Doch auch in einer solchen Welt hat das Scrum-Team jedoch die Aufgabe, ein Produktziel zu erreichen. Daher ist es das Vorrecht des Scrum-Teams zu entscheiden, was wann ausgeliefert werden soll.)
• 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; niemand von der Führungsebene nimmt 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 bekannt als Kunden — nehmen nicht am Sprint Review teil. (Brechen Sie aus der Echokammer Ihres Unternehmens aus und laden Sie einige Kunden und Benutzer zu Ihrem Sprint Review ein. Und lassen Sie nicht zu, dass die Vertriebsleute Einwände gegen diese Idee erheben. Wenn Sie das direkte Feedback der Kunden beim Sprint Review ignorieren, führt dies unweigerlich zu einem schlechteren Ergebnis.)
• 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 regelmäßig an der Retrospektive. (Generell gibt es mehrere Möglichkeiten in Scrum auf die Kommunikations- und Informationsbedürfnisse der Stakeholder einzugehen: Hauptsächlich ist es der Sprint Review, die Möglichkeit, in das Daily Scrum hineinzuhören, wahrscheinlich sogar das Refinement des Product Backlogs und 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, siehe die Meta-Retrospektive. Die Teilnahme an der Team-Retrospektive sollte jedoch für Stakeholder tabu sein.)
• 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. Aber diese Informationen sind natürlich nur für Teammitglieder zugänglich.)
• Vorgesetzte sind anwesend: Die Vorgesetzten nehmen an Retrospektiven teil. (Dies ist eines der schlimmsten Sprint Retrospektiven Anti-Patterns, die ich mir vorstellen kann. Es macht die Retrospektive zu einem unsicheren Ort. Und wer erwartet, dass dies eine offene Diskussion unter den Teammitgliedern auslöst? Jeder Vorgesetzte, der auf einem solchen Verfahren besteht, signalisiert, dass er die grundlegenden Scrum-Prinzipien nicht versteht.

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, Fehlverhalten von Scrum Stakeholdern 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.

Fehlverhalten von Scrum Interessenvertretern — Weitere Lektüre

27 Product Backlog Anti-Patterns

28+2 Sprint Anti-Patterns

20 Sprint Planning Anti-Patterns

24+2 Daily Scrum Anti-Patterns.

21 Sprint Retrospektive Anti-Patterns

Scrum Master Fehlverhalten — 20 Hilferufe von Scrum Mastern

Alle Artikel über Scrum Anti-Patterns

Download the Scrum Anti-Patterns Guide for free.

✋ Nicht versäumen: Lernen Sie mehr über Fehlverhalten von Scrum Interessenvertretern 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 36 Fehlverhalten von Scrum Interessenvertretern wurde zunächst auf Berlin-Product-People.com veröffentlicht. (This one’s is for you, too, Shaun.)