Selbstmanagement passiert nicht einfach so. In einer neuen Situation greifen Menschen meist auf bereits Bekanntes zurück. Deshalb gleicht das Daily Scrum bei neuen Teams häufig eher einem Statusmeeting.
Unter Statusmeeting verstehe ich einen traditionellen Statusbericht in Form eines Meetings. Jeder Entwickler im Team berichtet einer anderen Person den Status seiner Arbeit. Diese Person verwaltet die Erledigung eines vorgegebenen Plans. Diese Person kann der Scrum Master, der Product Owner oder eine Person außerhalb des Teams sein.
Woran erkennst du, ob das Daily Scrum ein Statusmeeting ist?
Hier einige typische Anzeichen, an denen du erkennen kannst, dass das Daily Scrum in Form eines Statusmeetings abgehalten wird:
- Die Entwickler berichten, was sie gestern getan haben, ohne dabei zu erwähnen, wie ihre Arbeit auf die Erreichung des Sprint-Ziels einzahlt.
- Es gibt keine Rückfragen, nachdem jemand gesprochen hat.
- Die Entwickler berichten ausschließlich darüber, was sie daran hindert, ihre Arbeit zu erledigen.
- Es findet kein Austausch darüber statt, wie die Entwickler gemeinsam an Aufgaben arbeiten werden.
Das Verhalten der Entwickler im Daily Scrum kann dabei viele Ursachen haben. Einige Beispiele hierfür:
- Langjährige Agile Coaches beziehen sich weiterhin auf eine eine ältere Version des Scrum Guides, in welcher die Moderation des Daily Scrum noch durch die Beantwortung von drei Fragen empfohlen wird.
- Die Entwickler empfinden das Daily Scrum nicht als hilfreich für ihre Arbeit und wollen es nur schnell hinter sich bringen.
- Frühere Projektleiter fungieren während der Einführung von Scrum als Scrum Master und interpretieren das Daily Scrum fälschlicherweise als einen Projektstatusbericht.
Ein Daily Scrum, welches einem Statusmeeting entspricht, fördert somit nicht die Kommunikation und die Zusammenarbeit unter den Entwicklern. Es schafft nicht den nötigen Fokus auf die aktuelle Arbeit, um die Wahrscheinlichkeit zu erhöhen, dass das Scrum Team das Sprint-Ziel bis zum Ende des Sprints erreicht. Und es bietet auch keine Möglichkeit dafür, dass die Entwickler ihre Arbeit eigenständig planen und verwalten.
Ein Statusmeeting steht also im Widerspruch mit dem Selbstmanagement eines Scrum Teams, da es nicht den Zweck des Daily Scrum erfüllt.
Was ist der Zweck des Daily Scrum in Scrum?
Die Entwickler überprüfen den Fortschritt im Hinblick auf das Sprint-Ziel.
Das Ergebnis des Daily Scrum ist ein aktualisiertes Sprint Backlog und ein Plan, woran die Entwickler heute arbeiten wollen, um dem Sprint-Ziel näherzukommen.
Im Unterschied zu einem Statusmeeting fokussieren sich die Entwickler im Daily Scrum nicht darauf, was ein Einzelner bis heute gearbeitet hat, sondern auf die gemeinsame Verantwortung: Woran wollen wir heute arbeiten, um dem Sprint-Ziel näherzukommen?
Die Unterschiede noch mal auf den Punkt gebracht:
- Arbeit versus Ziel
- Vergangenheit versus Zukunft
- Individuum versus Team
Wenn du als Scrum Master die Verantwortung dafür übernimmst, dass ein Team die Spielregeln von Scrum erlernt und effektiv danach spielt, dann solltest du deinem Team helfen, das Statusmeeting in ein Daily Scrum zu verwandeln.
Im Folgenden findest du eine einfache Anleitung, wie du deinem Team helfen kannst. Ich verwende sie seit Jahren, um Teams zu helfen, sich auf ein gemeinsames Ziel zu fokussieren und jeden bei der Planung des Arbeitstags einzubeziehen.
Wie du in 5 Schritten ein Daily Scrum facilitierst, welches das Selbstmanagement der Entwickler fördert
Aus meiner Sicht sollten wir uns als Scrum Master beim Daily Scrum auf zwei Dinge konzentrieren. Zum einen sollten wir den Entwicklern helfen, den Sprint Backlog transparent zu machen. Zum anderen sollten wir versuchen, den Fokus auf den Zweck des Daily Scrum zu richten. Dazu eignen sich offene Fragen besonders.
Im Vorfeld des Daily Scrum solltest du also mit den Entwicklern gemeinsam eine geeignete Visualisierung der Arbeit finden. Für mich hat sich hier bis jetzt immer ein Taskboard bewährt. Die Spalten des Taskboards beschreiben die Arbeitsschritte, die ein Product-Backlog-Eintrag durchläuft. Im Folgenden siehst du ein einfaches Taskboard mit den Spalten „To Do“, „Doing“ und „Done“.
Sobald der Sprint Backlog erstellt ist, solltest du zu Beginn diesen 5 Schritten folgen, um das Daily Scrum anzuleiten:
- Beginne das Daily Scrum, indem du die Entwickler noch mal an den Zweck des Daily Scrum erinnerst. (1 Minute)
- Bitte sie nun, die Tasks auf dem Taskboard zu aktualisieren. Die Entwickler sollen die Tasks so verschieben, dass sie den aktuellen Zustand der Arbeit widerspiegeln. Dies sollte in Stille passieren. Dadurch hat jeder die Möglichkeit, sich eigenständig ein Bild vom aktuellen Sprint zu machen. (2 Minuten)
- Wiederhole noch mal das Sprint-Ziel und bitte dann die Entwickler, ein Konfidenz-Voting mit Fist-of-Five durchzuführen. Stelle ihnen dazu die Frage: Basierend auf dem aktuellen Fortschritt, wie wahrscheinlich ist es, dass wir unser Sprint-Ziel erreichen? Hierbei bedeuten fünf Finger: „Ich bin sehr zuversichtlich.“ Ein Finger bedeutet: „Ich bin wenig zuversichtlich.“ (1 Minute)
- Lade die Entwickler nun ein, das Taskboard von rechts nach links zu besprechen. Eine Einladung hierfür könnte lauten: „Woran sollten wir heute arbeiten, damit die angefangenen Einträge fertiggestellt werden? Wie können wir uns dabei unterstützen?“ (10 Minuten)
- Beende das Daily Scrum mit der abschließenden Frage: „Hat jeder eine Idee, wie er heute das Team unterstützen kann, damit wir der Erreichung des Sprint-Ziels näherkommen?“ (1 Minute)
Was du bei der Verwendung dieser 5 Schritte unbedingt beachten solltest
Hier einige der Erkenntnisse, die ich über die Jahre mit diesem Vorgehen gesammelt habe:
- Beharre in den ersten Wochen auf den ersten Schritt. Dieser Schritt bereitet die Bühne für das Daily Scrum vor. Nach einigen Tagen kannst du auch mal einen Entwickler bitten, das Sprint-Ziel und den Zweck des Daily Scrum für alle zu wiederholen.
- Warum ich den zweiten und dritten Schritt in Stille durchführe? Somit beziehst du jeden mit ein und ermöglichst es jedem, sich ein eigenes Bild vom Fortschritt zu machen.
- Beim vierten Schritt ist es wichtig, von rechts zu beginnen. Als Scrum Team wollen wir Fortschritt bei der Erreichung des Sprint-Ziels ermöglichen. Der beste Garant dafür ist, Dinge abzuschließen und keine neuen Sachen zu beginnen.
- Schritt 4 ist – neben der Fokussierung auf das Sprint-Ziel – der Hebel, um ein Statusmeeting in ein Daily Scrum zu verwandeln. Denn auf einmal geht es nicht um die Menschen, sondern um die Arbeit!
- Die angeführten Zeiten sollen dir einen groben Hinweis geben, wie lange die einzelnen Schritte dauern sollen. Für mich hat es sich bewährt, einen Timer im Hintergrund für alle sichtbar laufen zu lassen. Versuchte das Daily Scrum einigermaßen kurzzuhalten. Im Idealfall stellt es den Auftakt zur Zusammenarbeit der Teammitglieder dar und nicht die ganze Zusammenarbeit des Tages. Es handelt sich also um einen ersten Synchronisationspunkt des Teams. Da im Laufe des Tages noch viele weitere folgen sollten, kann es ruhig kurz sein.
Sollte das Daily Scrum von nun an immer so ablaufen?
Natürlich nicht. Diese fünfschrittige Anleitung sollte dir nur einen ersten Startpunkt geben, wie du ein Statusmeeting in ein Daily Scrum verwandeln kannst.
- In Zukunft kannst du die Fragen variieren, um bestimmte Aspekte der Arbeit transparenter zu machen.
- Du solltest die Sprint-Retrospektive nutzen, um über den Zweck des Daily Scrum zu sprechen und nach Verbesserungen zu suchen.
- Hilf weiterhin deinem Team, das Sprint-Backlog mit weiteren hilfreichen Informationen anzureichern.
Die fünf Schritte dienen nur als Grundbaustein, damit dein Scrum Team einen Prozess findet, der es euch ermöglicht, Ziele zu erreichen und mit eurem Produkt Nutzer zu begeistern.
Ein abschließender Test, der dir zeigt, ob du das Selbstmanagement der Entwickler förderst
Beim Daily Scrum zeigt sich für mich immer wieder wie bei keinem anderen Event im Scrum, wie schwer die Verantwortung eines Scrum Masters in Wirklichkeit umzusetzen ist. Zum einen sind Scrum Master verantwortlich für die Einführung von Scrum. Zum anderen sollen wir die Scrum Events nur auf Anfrage facilitieren, damit wir die Selbstorganisation des Teams nicht behindern.
Um herauszufinden, ob wir die Gratwanderung beherrschen, hat sich für mich der „Urlaubstest“ bewährt: Findet das Daily Scrum auch weiterhin produktiv statt, wenn ich als Scrum Master im Urlaub bin?
Dieser Test hat mir bisher immer geholfen, zu bestimmen, wie gut sich das Team bereits selbst managen kann.
Wenn du weitere Anleitungen und Tipps suchst, wie du die Scrum Events effektiver gestaltest, dann lohnt sich der Besuch des Professional Scrum Facilitation Skills-Training.