Was ist ein Daily Scrum, warum ist es so langweilig und warum hört keiner zu?
Am Daily Scrum kann man oft erkennen, dass in der agilen Arbeitsweise etwas falsch läuft. Langweilig sollte es keinesfalls sein.

(Bild: Luis Villasmil / Unsplash)
- Stefan Mintert
Moin.
Wenn ein Team agil arbeitet, gibt es in der Regel ein “Daily”. Manchmal heißt es auch “Daily Stand-up” oder einfach nur “Stand-up”. Im Falle von Scrum gehört es zum festen Inventar, und dort heißt es “Daily Scrum”. So weit, so gut.
Nun ist es so, dass mir oft Teams begegnen, in denen ich das Daily nutzlos finde. Das könnte mein eigenes Problem sein und rechtfertigt keinen Blogbeitrag. Dass mir aber viele Teammitglieder verraten, dass sie ihr Daily langweilig finden und ihnen niemand zuhört, ist interessant.
Wie konnte es so weit kommen?
Ich stelle dann meist die Frage, warum das Team das Daily macht. Und wozu. Auf das “Warum?” bekomme ich häufiger Antworten als auf das “Wozu?” Die Frage nach dem Warum kann nämlich wunderbar mit allen möglichen Cargo-Cult-Gründen beantwortet werden. Zum Beispiel:
Es gehört doch zu Scrum. So macht man das eben. Das war schon so, als ich hier angefangen habe. Damit fängt unser Arbeitstag an.
Die Frage nach dem Wozu ist für manche Teams kniffliger. Sie wissen es einfach nicht. Bestenfalls bekomme ich mal Antworten der Art, “damit wir uns abstimmen können” oder “zur Synchronisierung” oder auch “um Transparenz herzustellen”.
Vordergründig sind das gute Antworten. In Verbindung mit Aussagen wie “es ist langweilig, was die anderen sagen” und “mir hört keiner zu” stimmt hier etwas nicht. Oder positiv ausgedrückt: Das Meeting hat eventuell Potenzial.
Wenn ich so eine Situation mit einem Team bearbeite, schlage ich zum Beispiel Folgendes vor:
- Bevor jemand etwas im Daily sagt, sagt er oder sie, wen das Gesagte interessieren sollte.
- Nach einem Wortbeitrag hebt jeder die Hand, wenn er etwas Hilfreiches gehört hat; unten formuliere ich das noch etwas anders (man beachte den Unterschied).
Die Folge kann sein, dass ein Daily ziemlich still verläuft. In diesem Fall sagt die Stille viel aus. Gleiches gilt, wenn oft niemand die Hand hebt. Manchmal liegt es daran, dass die Teammitglieder nicht wirklich zusammenarbeiten, sondern jeder seine “eigenen” Tickets bearbeitet. Ein Sprint-Ziel, auf das man gemeinsam hinarbeiten könnte, fehlt dann typischerweise ebenfalls.
Im Scrum-Guide heißt es “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.”
Ups, ein Sprint-Ziel? Das haben wir gar nicht. Und wir dürfen das Sprint-Backlog verändern? Wieso denn das? Wir haben uns doch auf die Tickets committet! Das sollen wir aufgeben?
Ja, denn in der agilen Arbeitsweise geht es gerade nicht darum, sklavisch Tickets abzuarbeiten. Nebenbei: Deshalb heiĂźt dieser Blog ja auch Escape the Feature Factory. Es geht darum, Ziele zu erreichen, die einen Wert haben. Ich fordere die Teams, mit denen ich arbeite, deshalb immer dazu auf, sich auf Ziele zu committen, nicht auf Tickets.
Wenn ich auf halber Strecke feststelle, dass ich ein Ziel auch erreichen kann, wenn ich einige Tickets nicht umsetze, warum sollte ich es dann tun? Und warum sollte ich nur ein einziges Ticket implementieren, wenn es keinem Ziel dient?
Der Aspekt der Zielsetzung ist wichtig und wird uns in diesem Blog bestimmt noch einige Male begegnen. Im Falle des Daily empfehle ich allen Entwicklern, die der Feature Factory entkommen wollen, den obigen Test: An wen richtet sich mein Beitrag? Und: Hand heben als sofortiges Feedback für Beiträge, die mir und dem Team helfen, dem Sprint-Ziel ein Stück näher zu kommen.
TschĂĽss. Stefan
(rme)