Scrum Master Fehlverhalten — 20 Hilferufe von Scrum Mastern

Scrum Anti-Patterns Guide — Berlin Product People

In Kürze: Scrum Master Fehlverhalten

Scrum Master Fehlverhalten: Die Gründe, warum Scrum Master den Geist des Scrum Guides verletzen, sind vielschichtig. Sie reichen von unpassenden persönlichen Eigenschaften und der Verfolgung persönlicher Agenden bis hin zur Frustration mit dem Scrum Team selbst.

Lesen Sie weiter und erfahren Sie in diesem Beitrag über Scrum Anti-Patterns, wie Sie erkennen können, ob Ihr Scrum Master Unterstützung benötigt.

Scrum Master Fehlverhalten — 20 Hilferufe von Scrum Mastern — Berlin Product People GmbH

Der Scrum Master nach dem Scrum Guide

Bevor wir mögliche Gründe und Erscheinungsformen des Fehlverhaltens von Scrum Mastern analysieren, wollen wir noch einmal darauf eingehen, wie der Scrum Guide die Rolle des Scrum Masters definiert:

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

Source: Scrum Guide 2017.

Der Eckpfeiler der Definition der Scrum Master Rolle ist der Servant Leadership-Aspekt. In den meisten Fällen von Scrum Master Fehlverhalten ist es genau dieser Anspruch, den ein Individuum nicht erfüllt. (Siehe auch die detaillierten Auflistungen der Leistungen im Scrum Guide, die der Scrum Master gegenüber dem Product Owner, dem Entwicklungsteam und der Organisation erbringt.)

Download the Scrum-Anti-Patterns Guide

Mögliche Gründe, warum Scrum-Master den Scrum-Pfad verlassen

Die Gründe, warum Scrum Master den Geist des Scrum Guides verletzen, sind vielschichtig. Sie reichen von unpassenden persönlichen Eigenschaften und der Verfolgung persönlicher Agenden bis hin zur Frustration mit dem Scrum Team selbst. Einige oft beobachtete Gründe sind:

  • Unwissenheit oder Faulheit: Ein Scrum-Standard passt zu jedem Team. Ihr Scrum Master hat das Handwerk in einem bestimmten Kontext gelernt und rollt nun genau dieses Muster in jeder Organisation, in der er oder sie tätig ist, unabhängig vom Kontext aus.
  • Ungeduld: Geduld ist eine kritische Ressource, die ein erfolgreicher Scrum Master im Überfluss aufbringen muss. Natürlich macht es keinen Spaß, ein und dasselbe Problem mehrmals neu anzusprechen, wenn die Lösung so offensichtlich ist — aus der Perspektive des Scrum Masters. Warum dem Team also nicht immer wieder sagen, wie man es „richtig“ macht, um so effizienter zu werden? Schade nur, dass Scrum anderen nicht aufgezwungen werden kann, sondern von diesen freiwillig angenommen werden muss — das ist die Essenz der Selbstorganisation.
  • Dogmatismus: Einige Scrum Master glauben daran, den Scrum Guide buchstäblich wenden zu müssen, was unweigerlich zu Reibungsverlusten führt, da Scrum ein Framework und keine Methodik ist..
  • Von Laissez-faire zu Gleichgültigkeit: Das Team in eine Richtung zu lenken, in der die Teammitglieder selbst eine Lösung für ein Problem finden können, ist gute Führung. Sie ohne Führung laufen zu lassen, führt jedoch wahrscheinlich zu Gleichgültigkeit oder, schlimmer noch, zu einer Ist-mir-doch-egal-Mentalität.
  • Dolla, dolla, bill ya’ll—der Scrum Master-Blender: Insgeheim ist der Scrum Master überzeugt, dass dieses Scrum-Ding eine Modeerscheinung ist, erkennt aber, dass es eine gut bezahlte ist: „Ich werde den Nachfragerückgang nach Projektmanagern mit einem Scrum Master-Zertifikat überbrücken. Wie schwer kann das wohl sein — das Handbuch umfasst nur 18 Seiten?“ Diese Überzeugung wird sich mit der Zeit unweigerlich offenbaren.
  • Perlen vor Säue — der frustrierte Scrum Master: Der Scrum Master arbeitet sich seit Monaten die Finger wund, aber das Team reagiert nicht auf die Anstrengung und der Grad der Frustration wächst. Es gibt viele mögliche Gründe für ein Scheitern auf dieser Ebene: das fehlende Sponsoring von der C-Ebene der Organisation, die weit verbreitete Überzeugung, dass „Agile“ nur die neueste Management-Tendenz und damit ignorierbar ist. Die Teamzusammensetzung ist falsch. Es gibt keine psychologische Sicherheit, um Probleme im Team anzugehen, und die Unternehmenskultur legt weder Wert auf Transparenz noch auf radikale Offenheit. Oder die einzelnen Teammitglieder haben persönliche Agenden, die nicht mit dem Ziel des Teams abgestimmt sind — um nur einige Gründe zu nennen. Gelingt es in diesem Kontext nicht, das Ruder herumzureißen, wird das Team wahrscheinlich seinen Scrum-Master verlieren. (Bitte beachten Sie, dass der Scrum Master diese Probleme nicht selbst lösen kann. Dies erfordert den Einsatz des gesamten Scrum-Teams und der Organisation.)
  • Der taktische Scrum Master: Diese Scrum Master sich von HR überzeugen lassen, dass der Scrum Master eine Position ist, keine Rolle. Es gibt nunmehr einen Karrierepfad vom Junior Scrum Master zum VP des Agile Coachings. Folglich beschränken taktische Scrum Master ihre Arbeit strikt auf das Scrum Team, bis sie befördert werden..
  • Der Anfänger: Wenn Sie Occam’s razor auf diese Situation anwenden, könnten Sie herausfinden, dass Ihr Scrum Master noch nicht zur dunklen Seite übergelaufen ist, sondern er oder sie könnte lediglich unerfahren sein. Da wir alle regelmäßig neue Fertigkeiten erlernen müssen, sollten wir in diesem Fall nachsichtig mit ihnen sein und ihr Lernen unterstützen. Scrum zu meistern ist eine Reise, kein Ziel, und man reist in der Regel nicht allein.
Upcoming Scrum and Liberating Stuctures training classes and workshops — Berlin Product People GmbH

Der Scrum Master als Agiler Manager

In meinen Augen ist „agiles Management“ ein Widerspruch in sich. Der primäre Zweck jeder agilen Praxis ist es, diejenigen, die einem Problem am nächsten sind, in die Lage zu versetzen, eine Lösung zu finden. Mit anderen Worten, das Team soll sich im Laufe der Zeit selbst organisieren und so der Organisation ein angemessenes Maß an geschäftlicher Agilität verleihen. Selbstorganisierende Teams brauchen Coaches, Mentoren und dienende Führungskräfte (Servant Leader), aber keinen Manager im tayloristischen Sinne des Wortes.

Achten Sie auf diejenigen Scrum Master Fehlverhalten, die dieser ‚agilen Manager‘-Einstellung entsprechen:

  • Agiles Management: Selbstorganisation bedeutet nicht die Abwesenheit von Management: Warum sollte ein Scrum Master z.B. die Verantwortung für die Lohn- und Gehaltsabrechnung übernehmen? Würde das bei der Wertschöpfung zugunsten der Kunden helfen? Wahrscheinlich weniger. Ein selbstorganisierendes Team zu sein, bedeutet also nicht die Abwesenheit von Management an sich. Es bedeutet aber, dass das Team kein Mikromanagement braucht, vergleichbar mit der Praxis in einem Montagewerk von General Motors im Jahr 1926. Der Scrum Master ist weder ein Vorgesetzter noch ein Disponent.
  • Das Wort bei Meetings erteilen: Wenn Teammitglieder den Blickkontakt mit dem Scrum Master suchen, bevor sie das Wort ergreifen, hat der Scrum Master bereits die Moderationsrolle zu Gunsten des Vorgesetzten-Modus verlassen.
  • Das Scrum-Team abhängig halten: In diesem Szenario umsorgt der Scrum Master das Team auf einem Niveau, welches das Team von seinen Diensten abhängig macht: Meetings organisieren, Stickies und Stifte kaufen, Notizen machen, Jira aktualisieren – Sie bekommen eine Vorstellung von diesem Service Level. Noch kritischer ist es jedoch, wenn der Scrum Master beschließt, das Team über Prinzipien und Praktiken im Dunkeln zu lassen, um seinen Job zu sichern. Dieses Verhalten ist nur einen kleinen Schritt von der dunklen Seite entfernt.
  • Verfolgung fehlerhafter oder gefährlicher Metriken: Während die Verwendung vordefinierter Jira-Berichte wahrscheinlich ein Zeichen von Unwissenheit oder Faulheit ist, ist es ein kritisches Warnzeichen, wenn individuellen Leistungskennzahlen — wie z.B. die Story-Punkte pro Entwickler pro Sprint—erfasst und diese an den Vorgesetzten dieser Person gemeldet werden. Das ist ein klassischer Vorgesetztentrick, um Command & Control durch die Hintertür wieder einzuführen. Es führt unweigerlich zu einer Version von Cargo-Cult-Scrum, welche für alle Beteiligten unbefriedigend ist.
  • Langer Arm des Managements: Während des Sprints berichtet der Scrum Master dem Management, ob das Scrum-Team den aktuellen Forecast einhalten wird oder nicht. Dieses Fehlverhalten habe ich aus einem Jobangebot entnommen, das ich erhalten habe: „Sie koordinieren und steuern die Arbeit der anderen Teammitglieder und sorgen dafür, dass Zeitpläne eingehalten und Verstöße eskaliert werden.“
  • Fokussierung auf Teamharmonie: Der Scrum Master kehrt Konflikte und Probleme unter den Teppich, indem er oder sie Sprint Retrospektiven nicht dazu benutzt, diese offen anzusprechen. Dieses Verhalten ist oft ein Zeichen dafür, dass man sich der Politik beugt und stattdessen Manipulation einsetzt, um organisatorische Anforderungen zu erfüllen, die den Scrum-Werten und -Prinzipien entgegenstehen. Wenn die Organisation ihre Untergebenen dafür schätzt, dass sie die ‚Regeln‘ befolgen, anstatt die Wahrheit zu sagen, warum sollten dann überhaupt Retrospektiven durchgeführt werden? Ein ‚Scrum Master‘, der an Cargo-Cult-Scrum teilnimmt, ist erneut eher Vorgesetzter als ein agiler Praktiker.)

Scrum Master Fehlverhalten nach Scrum Ereignissen

Das Sprint Planning

Die folgenden Anti-Patterns konzentrieren sich auf das Sprint Planning:

  • 100% Auslastung: Das Entwicklungsteam knickt regelmäßig vor dem fordernden Product Owner — „im letzten Sprint habt Ihr 25 Story-Punkte geliefert, jetzt wählt Ihr nur noch 17“ – ein und nimmt mehr Arbeit in das Sprint Backlog auf, als es verkraften kann. Der Scrum Master spricht in Folge nicht an, dass dies ein respektloses Verhalten ist, welches das Vorrecht des Entwicklungsteams auf Selbstorganisation negiert und die Notwendigkeit für Slack Time ignoriert. (Die Effektivität des Teams wird erheblich behindert, wenn das Team nicht jeden Sprint technische Schuld abbauen kann. Es wird auch darunter leiden, wenn es keine Zeit für Pair Programming oder gegenseitige Unterstützung gibt. Eine hundertprozentige Auslastung reduziert immer die langfristige Produktivität des Teams; es ist klassisches tayloristisches Managementdenken.) 100% Utilization fallacy Wenn am Ende eines Sprints 50% aller Aufgaben unvollendet in den nächsten Sprint übergehen und dies ein regelmäßiges Muster ist, dann praktiziert das Team kein Scrum. Wahrscheinlich ist es eine Art Kanban mit Zeitboxen — was selbstverständlich auch in Ordnung wäre. Entscheiden Sie sich einfach, wie Sie das Leben Ihrer Kunden verbessern wollen. Vielleicht wäre Kanban anstelle von Scrum eine gute Wahl.
  • Unverfeinerte Sprint Backlog-Einträge: Der Scrum Master geht nicht auf die Akzeptanz von „unreifen“ Product Backlog-Einträgen in das Sprint Backlog ein. Dies ist ein ziemlich sicherer Weg, dass das Entwicklungsteam das Sprint-Ziel verpassen wird, was ein Kernprinzip von Scrum nutzlos macht: die Bereitstellung eines wertvollen, potenziell lieferbaren Produktinkrements am Ende des Sprints. (Dieser Punkt bezieht sich auf regelmäßige Arbeit, nicht auf Notfälle).

Der Sprint

Die folgenden Scrum Master Fehlverhalten konzentrieren sich auf die Fehlbedienung des Sprints selbst:

  • 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 das Sprint-Ziel gefährden. Es ist die Aufgabe des Scrum Masters zu verhindern, dass diese Verhalten sich manifestieren:
    • Der Scrum Master hat eine Laissez-faire-Politik, was den Zugang zum Entwicklungsteam betrifft. Insbesondere schult er 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 widerspricht nicht, wenn Vorgesetzte Teammitglieder aus dem Scrum Team nehmen und ihnen andere Aufgaben zuweisen.
    • Der Scrum Master hat nichts dagegen, dass das Management Teammitglieder als Experten zu anderen Meetings einlädt..
    • Der Scrum Master drückt ein Auge zu, wenn der Product Owner die Prioritäten mitten im Sprint ändert..
    • Schließlich erlaubt der Scrum Master den Stakeholdern oder Managern, das Daily Scrum in eine Reporting-Session zu verwandeln.
  • Zuweisung von Teilaufgaben an Entwickler: Der Scrum Master hindert den Product Owner — oder auch andere Personen — nicht daran, Aufgaben direkt an Mitglieder des Entwicklungsteams zuzuweisen. (Das Entwicklungsteam organisiert sich selbst, ohne dass ein externes Eingreifen erforderlich ist. Und der Scrum Master ist in dieser Hinsicht das Schutzschild des Teams.)
  • Technische Lösungen definieren: Ein Entwickler, der zum Scrum Master wurde, „schlägt“ nun vor, wie das Entwicklungsteam Aufgaben umsetzen soll. (Alternativ verfolgt der Product Owner oder ein Außenstehender den gleichen Ansatz, z. B. ein technisch Verantwortlicher).
  • Fehlende Unterstützung: Der Scrum Master unterstützt Teammitglieder nicht, die Hilfe bei einer Aufgabe benötigen. Oftmals erstellen Entwicklungsteams Aufgaben, die ein Entwickler innerhalb eines Tages erledigen kann. Wenn jedoch jemand länger als zwei Tage mit einem solchen Job kämpft, ohne zu sagen, dass er oder sie Unterstützung benötigt, so sollte der Scrum Master das Problem ansprechen und Unterstützung anbieten. Übrigens ist dies auch der Grund dafür, dass man jeden Tag auf einem physischen Sprint-Board die Tasks mit roten Punkten markiert, die sich nicht bewegen. (Mit anderen Worten: Wir verfolgen das Work-Item-Alter).
Scrum Master Interview Question: free download of the most popular ebook on Scrum Master job interviews — by Age-of-Product

Die Retrospektive

Das letzte Bündel von Scrum Master Fehlverhalten betrifft die Sprint Retrospektive:

  • Zeitverschwendung: Das Team wertschätzt die Retrospektive nicht. (Wenn einige Teammitglieder die Retrospektive für wenig wertvoll oder wertlos halten, ist es meistens die Retrospektive selbst, die nervt. Ist es jedes Mal das gleiche Vorgehen, ritualisiert und langweilig? Dann machen Sie eine Meta-Retrospektive über die Retrospektive selbst. Ändern Sie den Veranstaltungsort. Machen Sie eine Bier- oder Wein-Retrospektive. Es gibt so viele Dinge, die ein Scrum Master tun kann, um Retrospektiven wieder zu beleben und die Abwesenheitsrate zu reduzieren. Und ja, nach meiner Erfahrung nehmen Introvertierte auch gerne an Retrospektiven teil — wenn diese das richtige Format haben).
  • Groundhog Day: Die Retrospektive ändert sich in ihrer Struktur, ihrem Veranstaltungsort und ihrer Dauer nicht. (In diesem Fall besteht die Gefahr, dass das Team immer wieder die gleichen Themen aufgreift — es ist wie „Und täglich grüßt das Murmeltier“ nur ohne das Happy End.)
  • Retrospective anti patterns: Groundhog Day — Berlin Product People GmbH
  • Verschieben wir die Retro: Das Team verschiebt die Retrospektive auf den nächsten Sprint. (Über die „Inspektion & Adaption“ des Scrum Teams hinaus soll die Retrospektive m.E. auch als ein Moment des Abschlusses dienen, damit sich das Team auf den neuen Sprint konzentrieren kann. Zusätzlich sollte das Scrum Team mindestens eine wichtige Verbesserungsaktion für den kommenden Sprint auswählen. Deshalb erfolgt die Retrospektive vor der Sprintplanung des folgenden Sprints. Eine Verschiebung der Retro in den nächsten Sprint kann daher den Fluss des Teams unterbrechen und wird wahrscheinlich ein oder mehrere wichtige Teamprobleme für die Dauer eines Sprints unadressiert lassen.)
  • #NixRetro: Es gibt keine Retrospektive, da das Team glaubt, dass es nichts zu verbessern gibt. (Meines Erachtens gibt es kein agiles Nirwana, wo alles einfach perfekt ist. Wie so schön gesagt wird: Agilität ist eine Reise, kein Ziel, und es gibt immer etwas zu verbessern.)
  • #NixDokumentation: Niemand macht Notizen für den späteren Gebrauch. (Eine Retrospektive ist eine beträchtliche Investition und sollte ernst genommen werden. Notizen und Fotos unterstützen diesen Prozess.)
  • Keine psychologische Sicherheit: Die Retrospektive ist ein endloser Kreislauf von gegenseitigen Schuldzuweisungen. (Das Team gewinnt gemeinsam, das Team scheitert gemeinsam. Die Schuldzuweisungen dokumentieren sowohl das Scheitern des Scrum Master als Moderator der Retrospektive als auch die mangelnde Reife und Kommunikationsfähigkeit des Teams.) 21 Sprint Retrospective Anti-Patterns — Keine psychologische Sicherheit — Berlin Product People GmbH
  • Mobbing: Ein oder zwei Teammitglieder dominieren die Retrospektive. (Dieses Kommunikationsverhalten ist oft ein Zeichen für einen schwachen oder uninteressierten Scrum Master. Die Retrospektive muss ein sicherer Ort sein, an dem jeder Probleme ansprechen und sein Feedback frei von Einflüssen Dritter geben kann. Wenn einige der Teammitglieder das Gespräch dominieren und wahrscheinlich sogar andere Teammitglieder tyrannisieren oder einschüchtern, wird die Retrospektive keine psychologische Sicherheit bieten. Dieser Misserfolg führt dazu, dass die Teilnehmer sich aus der Retrospektive zurückziehen und die Ergebnisse weniger nützlich werden. Es liegt in der Verantwortung des Scrum Masters, sicherzustellen, dass jeder gehört wird und die Möglichkeit hat, seine Gedanken zu äußern. Übrigens, eine gleichmäßig verteilte Redezeit innerhalb eines Teams ist laut Google ein Zeichen für ein leistungsstarkes Team. Weitere Lektüre: What Google Learned From Its Quest to Build the Perfect Team. Sehen Sie sich auch die “Conversation Café”-Übung der Liberating Structures an, welche dieses Problem mit einem einfachen Verfahren angeht, welches gut in eine Retrospektive passt.)
  • 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.)

📕 Jetzt verfügbar: ‘How to Get Hired as a Scrum Master’

How to Get Hired as a Scrum Master: From Job Ads to Your Trial Day — Learn How to Pick the Right Employer or Client beschreibt detailiert, wie Scrum Master und Agile Coaches systematisch geeignete Arbeitgeber oder Kunden identifizieren können, um Enttäuschungen später zu vermeiden. Wenn Sie einen Karriereschritt in den Beruf des Scrum Masters planen, sollten Sie diese Tipps nicht verpassen.

Scrum Master Career: How to Get Hired as a Scrum Master by Age-of-Product

Scrum Master Career: How to Get Hired as a Scrum Master ist als Kindle Ebook oder als Taschenbuch verfügbar.

Sehen Sie sich das Videos des Webinars über Scrum Master Anti-Patterns an

Das Video des Webinars ist jetzt verfügbar:


Anmerkung: Wenn der Browser das Video nicht automatisch startet, klicken Sie hier um das Webinar zu Scrum Master Anti-Patterns direkt auf Youtube zu sehen

✋ Nicht versäumen: Werden Sie Mitglied im 6.500-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.

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 Master Interview Question: free download of the most popular ebook on Scrum Master job interviews — by Age-of-Product

Scrum Master Anti-Patterns — Das Fazit

Es gibt viele Möglichkeiten, als Scrum Master zu versagen. Manchmal ist es der Mangel an Unterstützung aus der Organisation. Manche Menschen sind für die Aufgabe nicht geeignet. Andere stellen sich aus fragwürdigen Gründen über ihre Teams. Manchen Scrum-Mastern fehlt einfach das Feedback ihrer Scrum-Teams und Stakeholder. Wie dem auch sei, versuchen Sie, Ihrem Scrum Master in der Not zu helfen, die Misere zu überwinden. Scrum ist ein Teamsport.

Welche Scrum Master Fehlverhalten habe ich nicht angesprochen? Bitte teilen Sie es uns in den Kommentaren mit.

Weitere Artikel

Liberating Structures für Scrum (1): Die Sprint Retrospektive

27 Sprint Anti-Patterns Holding Back Scrum Teams

28 Product Backlog Anti-Patterns

21 Sprint Retrospektive Anti-Patterns.

Tags: Scrum Anti-Muster, Scrum Master, Scrum Master Fehlverhalten

Leave a reply

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