In Kürze: 24+2 Daily Scrum Anti-Patterns
Nach meiner Erfahrung ist das Daily Scrum das Scrum-Ereignis mit der höchsten Anti-Pattern-Dichte unter allen Ereignissen. Erfahren Sie mehr über die Daily Scrum Anti-Patterns, die Ihren Weg zur Agilität gefährden.
🗞 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!
Der Sinn des Daily Scrum-Events
Der Zweck des Daily Scrums ist im Scrum Guide klar beschrieben:
The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.
The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.
The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.
Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.
The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.
Quelle: Scrum Guide 2020.
Das Daily Scrum ist ein wesentliches Element der Inspektions-/Anpassungsschleife. Es wird von den Entwicklern durchgeführt und geleitet diese für die nächsten 24 Stunden auf ihrem Weg zum Erreichen des Sprint-Ziels. Das Daily Scrum ist der kürzeste Planhorizont in Scrum und essentiell zur Erreichung des Sprint Ziels.
Entgegen der landläufigen Meinung ist die 15-minütige Timebox nicht dazu gedacht, alle während des Daily Scrum angesprochenen Probleme zu lösen. Es geht vor allem darum, Transparenz zu schaffen und damit die Inspektion anzustoßen. Ist z. B. eine Anpassung des Plans oder des Sprint Backlogs erforderlich, steht es den Entwicklern frei, die daraus entstandenen Probleme jederzeit zu bearbeiten; hierfür ist das Daily Scrum jedoch nicht vorgesehen. Nach meiner Erfahrung resultieren die meisten Daily Scrum Anti-Patterns aus einem Missverständnis dieses Kernprinzips.
Scrum Anti-Patterns – Von dysfunktionalen Scrum-Teams bis zu Defiziten der Organisation
Normalerweise braucht ein gutes Scrum Team nicht mehr als 10 bis 15 Minuten, um seinen Fortschritt auf dem Weg zum Sprint-Ziel zu überprüfen. Angesichts dieser kurzen Zeitspanne ist es interessant zu beobachten, dass das Daily Scrum oftmals so viele Anti-Patterns erzeugt. Die Anti-Patterns decken dabei oft ein breites Spektrum ab, welches von dysfunktionalen Scrum-Teams bis hin zu offensichtlichen Fehlern auf organisatorischer Ebene reicht.
Meine unpriorisierte Liste bekannter Daily Scrum Anti-Patterns ist folgende:
Daily Scrum Anti-Patterns des Scrum Teams
- Orientierung verloren: Das Daily Scrum dient einem Zweck, indem es eine einfache Frage beantwortet: Sind wir noch auf dem richtigen Weg, um das Sprint-Ziel zu erreichen? Oder müssen wir den Plan oder das Sprint Backlog oder beides anpassen? Viele Development Teams können diese Frage nicht auf Anhieb beantworten. (In dieser Hinsicht ist die Visualisierung des Fortschritts auf dem Weg zum Sprint-Ziel eine nützliche Übung. Vor einigen Jahren wurde die Verpflichtung des Entwicklungsteams, ein Burndown-Diagramm zu pflegen, aus dem Scrum Guide entfernt. Dies bedeutet jedoch nicht, dass ein Burndown-Diagramm unnütz ist.)
- Statusreport: Das Daily Scrum ist ein Statusreport-Meeting, und die Mitglieder des Entwicklungsteams warten darauf, ihre Fortschritt an den Scrum Master, den Product Owner oder vielleicht sogar an einen Stakeholder zu "berichten".
- Keine Routine: Das Daily Scrum findet nicht jeden Tag zur gleichen Zeit und am gleichen Ort statt. (Während Routine das Potenzial hat, jede Retrospektive zu ruinieren, ist sie im Kontext des Daily Scrum hilfreich. Betrachten Sie es als einen spontanen Drill: Nicht zu viel Aufwand im Voraus betreiben, nicht lange nachdenken, sondern einfach machen. Das Überspringen von Daily Scrums öffnet dem Verfehlen des Sprint-Ziels Tür und Tor: Wenn Sie ein oder zwei Daily Scrums überspringen, warum nicht gleich jedes zweite Mal?)
- Fehlender Respekt I: Andere Teammitglieder sprechen, während jemand seinen oder ihren Fortschritt mit dem Entwicklungsteam teilt. (Die Verwendung von Sprech-Token unter Erwachsenen, um solche Daily Scrum Anti-Patterns wie dieses zu vermeiden, qualifiziert sich meiner Meinung nach nicht als eine Lösung.)
- Fehlender Respekt II: Die Teammitglieder kommen verspätet oder gar nicht zum Daily Scrum. (Dies stellt ein massives Risiko für das Entwicklungsteam dar, wenn es den Plan zur Erreichung des Sprintziels prüft und ggf. auf der Grundlage unvollständiger Informationen anpasst. Dies wird zwangsläufig die Wahrscheinlichkeit verringert, dass das Sprint-Ziel erreicht wird.)
- Übermässiges Feedback: Teammitglieder kritisieren andere Teammitglieder sofort, um eine Diskussion anzufachen, anstatt ihre Einwände nach dem Daily Scrum weiter zu verfolgen.
- Zu viele Teilnehmer: Das Daily Scrum ist aufgrund einer großen Anzahl aktiver Teilnehmer nahezu wirkungslos. (Es gibt einen Grund, warum der Scrum Guide empfiehlt, die Anzahl der Mitglieder des Entwicklungsteams auf neun zu begrenzen.)
Anti-Patterns der Entwickler
- Mangelnde Vorbereitung: Die Entwickler sind nicht auf das Daily Scrum vorbereitet. ("Ich habe irgendetwas gemacht, aber ich weiß nicht mehr, was. War aber wichtig.")
- Planungsmeeting: Das Entwicklungsteam nutzt das Daily Scrum, um neue Anforderungen zu diskutieren, User Stories zu verfeinern oder eine Art (Sprint)-Planning durchzuführen.
- Problemlösungsmeeting: Diskussionen werden angestoßen, um Probleme zu lösen, anstatt diese zu parken, damit sie nach dem Daily Scrum gelöst werden können.
- Monologe: Die Teammitglieder verletzen die Zeitvorgabe von 15 Minuten und beginnen Monologe. (60 bis 90 Sekunden pro Teammitglied sollten mehr als genug Zeit sein.)
- Statler und Waldorf: Ein paar Teammitglieder kommentieren jedes Problem. (Normalerweise ist das nicht nur Zeitverschwendung, sondern neigt auch dazu, bevormundend und ärgerlich zu sein.)
- Nur Ticketnummern: Updates sind generisch und haben für andere keinen oder nur geringen Wert. ("Gestern habe ich an X-123 gearbeitet. Heute werde ich an X-129 arbeiten.")
- Null Problemo: Niemand meldet irgendwelche Hindernisse; niemand braucht Hilfe oder Unterstützung von seinen Teamkollegen. (Glückwunsch zu Eurer scheinbar gut geölten Scrum-Maschine! Könnte es jedoch sein, dass sich die Entwickler nicht sicher fühlen, Fragen, Herausforderungen oder Probleme anzusprechen?)
Daily Scrum Anti-Patterns des Product Owners
- 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.)
Anti-Patterns des Scrum Masters
- Daily-Scrum-Erzwinger: Der Scrum Master setzt täglich das Daily Scrum durch. (Es ist die Aufgabe des Scrum Masters, sicherzustellen, dass “[…] all Scrum events take place and are positive, productive, and kept within the timebox.” (Quelle.) Wenn jedoch keiner der Entwickler glaubt, dass das Daily Scrum eine sinnvolle Investition ist, kann der Scrum Master diesen Mangel an intrinsischer Motivation nicht einfach dadurch ausgleichen, dass er den Scrum Guide als Zwangsmittel einsetzt. Er muss dazu beitragen, die Motivation aufseiten der Entwickler zu wecken, das Daily Scrum überhaupt durchzuführen. Das Erzwingen des Daily Scrum ist ein übliches Taylorismus-Artefakt, wenn das Vertrauen in die Fähigkeit der Entwickler zur Selbstorganisation fehlt).
- Fehlende Unterstützung für Entwickler mit Problemen: Ein Mitglied des Entwicklungsteams hat Schwierigkeiten, eine Arbeitsaufgabe über mehrere aufeinanderfolgende Tage hinweg zu lösen, und niemand bietet Hilfe an. (Oft ist dieses Ergebnis ein Zeichen dafür, dass entweder die Teammitglieder einander nicht vertrauen oder sich nicht umeinander kümmern. Oder die Arbeitsbelastung der Entwickler ist so hoch, dass sie sich nicht mehr gegenseitig unterstützen können. Die Verwendung der "Work Item Age"-Praxis hat sich zur Verhinderung dieser Probleme als hilfreich erwiesen.)
- Die Stakeholder nicht von der Teilnahme abhalten: Obwohl die Entwickler beschlossen haben, die Teilnahme am Daily Scrum auf die Mitglieder des Scrum-Teams zu beschränken, tauchen Stakeholder ungebeten auf, und der Scrum Master geht nicht auf das Problem ein. (Es ist das Vorrecht der Entwickler zu entscheiden, wie sie das Daily Scrum durchführen. Wenn sie wählen, die Stakeholder davon fernzuhalten, muss diese Entscheidung von allen anderen respektiert werden. Wenn die Stakeholder dies nicht tun, muss der Scrum Master eingreifen.)
- Das Zeitlimit nicht durchsetzen: Die Entwickler verlängern das Daily Scrum regelmäßig über die Zeitspanne von 15 Minuten hinaus. (Das ist bedauerlich, denn die Ausweitung der Time-Box lädt dazu ein, Problemlösungen und andere Aktivitäten in das Daily Scrum einzubringen, die dort nicht hingehören. So wird von der Beantwortung der entscheidenden Frage abgelenkt: Sind wir noch auf dem richtigen Weg, das Sprint-Ziel zu erreichen?)
Daily Scrum Anti-Patterns der Stakeholders
- 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 Mitglieder des Entwicklungsteams während ihrer Inspektion 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.)
🤔 Punkte zum Nachdenken
Es gibt einige Themen, über die es sich lohnt, als Scrum-Team nachzudenken:
Synchrone und asynchrone Daily Scrum Events: Einige Teams bevorzugen es, ihr Daily Scrum in Slack abzuhalten, insbesondere diejenigen, die verteilt bzw. im Homeoffice arbeiten. Die Verwendung von Slack manifestiert kein Daily Scrum Anti-Pattern an sich; es ist das Vorrecht des Entwicklungsteams, das Daily Scrum in beliebiger Weise durchzuführen, so lange es seinem Zweck dient: der Überprüfung des Plans zur Erreichung des Sprint-Ziel für die kommenden 24 Stunden. Ich arbeitete einmal mit einem Scrum-Team zusammen, das Slack als bevorzugte Methode für das Daily Scrum benutzte, obwohl alle im selben Raum saßen. Es hat gut funktioniert. Aber was ist mit einem asynchronen Daily Scrum in Slack?
Das Daily Scrum gänzlich ersetzen: Was ist mit der Idee, das Daily Scrum ganz auszulassen, da die Entwickler bei den meisten Aspekten ihrer täglichen Arbeit mehr oder weniger automatisierte Nachrichtensysteme verwenden, während sie den Rest bei anderen Veranstaltungen erledigen können, z. B. bei Pairing- oder Mobbing-Sitzungen? Ist es unter diesen Umständen sinnvoll, jeden Tag 15 Minuten für das Daily Scrum einzuplanen? Oder ist das reiner Dogmatismus?
Fazit
Angesichts der Bedeutung des Daily Scrum für den Erfolg der Bemühungen des Scrum Teams, das Sprint-Ziel zu erreichen, ist die Dichte der Anti-Muster keine Überraschung. Teilnehmer scheinen entweder unwissend (oder zumindest weniger gut unterrichtet) über seinen Zweck zu sein. Oder sie stören — absichtlich oder nicht — die Selbstorganisation der Entwickler. Auf die eine oder andere Weise ist es eine wichtige Aufgabe des Scrum Master, alle Teilnehmern am Daily Scrum zu unterstützen, diese typischen Scrum-Anti-Muster zu überwinden.
Welche Daily Scrum Anti-Patterns haben Sie im Alltag beobachtet? Bitte teilen Sie uns dies in den Kommentaren mit.
Weitere Lektüre
28 Product Backlog Anti-Patterns
20 Sprint Planning Anti-Patterns
21 Sprint Retrospektive Anti-Patterns
Download the Scrum Anti-Patterns Guide for free
✋ Nicht versäumen: Lernen Sie mehr über Daily Scrum Anti-Patterns 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.
Der Artikel “24+2 Daily Scrum Anti-Patterns” erschien zuerst auf Berlin-Product-People.com.