Was ist ein Daily Scrum, warum ist es so langweilig und warum hört keiner zu?

Moin.

Escape the Feature Factory: Stefan Mintert

Stefan Mintert arbeitet mit seinen Kunden daran, die Unternehmenskultur in der Softwareentwicklung zu verbessern. Das derzeit größte Potential sieht er im Leadership; unabhängig von einer Hierarchieebene. Die Aufgabe, dieses Potential zu heben, hat er sich nach einem beruflichen Weg mit einigen Kurswechseln gegeben. Ursprünglich aus der Informatik kommend, mit mehreren Jahren Consulting-Erfahrung, hatte er zunächst eine eigene Softwareentwicklungsfirma gegründet. Dabei stellte er fest, dass Führung gelernt sein will und gute Vorbilder selten sind. Es zeichnete sich ab, dass der größte Unterstützungsbedarf bei seinen Kunden in der Softwareentwicklung nicht im Produzieren von Code liegt, sondern in der Führung. So war es für ihn klar, wohin die Reise mit seiner Firma Kutura geht: Führung verbessern, damit die Menschen, die die Produkte entwickeln, sich selbst entwickeln und wachsen können. Für Heise schreibt Stefan als langjähriger, freier Mitarbeiter der iX seit 1994.

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)