Als Management Consultant bekomme ich regelmäßig die Möglichkeit, die Scrum-Implementierung in den unterschiedlichsten Branchen und Unternehmen zu beobachten bzw. zu begleiten. Interessanterweise ähnelt in der Auslegung von Scrum kaum ein Unternehmen dem Nächsten – nicht einmal, wenn es um die Abhaltung der Scrum-Meetings geht. Selbst das kürzeste Meeting im Scrum Flow, das Daily Scrum, sieht stets anders aus. Vor allem bei Scrum-Neulingen habe ich die Erfahrung gemacht, dass ein gewisser, vorher gemeinsam mit dem Coach geübter Ablauf dem neuen ScrumMaster etwas Sicherheit bietet. Mein Vorschlag sieht meist so aus:
Zweck
Synchronisation innerhalb des Dev-Teams, um das Sprintziel und somit das Release zu schaffen.
Ziel
Als Team wissen wir, was erledigt werden muss, damit die committeten Stories auf Done gesetzt werden können.
Ablauf
- Das Dev-Team trifft sich im Halbkreis vor dem Taskboard. Der ScrumMaster steht seitlich ca. einen halben Schritt außerhalb dieses Halbkreises. Gäste stehen komplett außerhalb des Halbkreises.
- Begrüßung durch den ScrumMaster – ein “Guten Morgen” reicht aus. Hier ist ein motiviertes Auftreten wichtig: Wenn der ScrumMaster als Coach des Teams schon keinen Bock hat, wie soll das Team dann erst Lust bekommen? Der ScrumMaster startet mit einer Begrüßung und macht auf die geplanten Termine für den Tag aufmerksam.
- Falls jemand im Dev-Team noch keine Vorstellung hat, welche Arbeit er an diesem Tag leisten kann/ möchte/wird, sollte er sich gleich anfangs zu Wort melden, damit das restliche Team ihn für potenzielle Aufgaben in Erwägung ziehen kann.
- Nacheinander erzählt jedes Teammitglied seinen Kollegen Folgendes:
- Was habe ich seit dem letzten Daily umgesetzt? (falls fertig, wird der Task von Work In Progress in Done gehängt) Falls die Aufgabe wider Erwarten innerhalb des letzten Tages nicht fertiggestellt werden konnte, erklärt das Teammitglied kurz, wodurch die Aufgabe behindert wird. Dann wird ein Punkt auf das Post-It gemacht. Ggf. wird diese Störung am Impediment Backlog, auf dem Task bzw. an der Story visualisiert.
- Was werde ich heute tun? Hier zieht sich das Teammitglied eine Aufgabe aus der To Do Spalte der höchstpriorisierten User Story und hängt sie in Work In Progress. Falls möglich, plant das Teammitglied gleich Pair Programming mit einem Teamkollegen bzw. Unterstützung, die er in Anspruch nehmen möchte.
- Was behindert mich in meiner derzeitigen Arbeit? (Visualisierung nicht vergessen…)
- Wo benötige ich Hilfe?
- Meine heutige Verfügbarkeit
- Das nächste Teammitglied übernimmt und beantwortet dieselben Fragen gegenüber dem restlichen Team. Dies passiert reihum, bis das Team seine Arbeit synchronisiert hat und jeder weiß, was er heute mit wem bearbeiten soll.
- Ist eines der Teammitglieder nicht da, übernimmt ein anwesendes Teammitglied die Punkte des abwesenden Kollegen und hängt die jeweiligen Aufgaben auf dem Taskboard für ihn um.
- Der ScrumMaster fasst abschließend folgende Punkte zusammen:
- Neue Impediments, die in diesem Daily ans Tageslicht gekommen sind und um die er bzw. jemand im Team sich kümmern wird
- Inwieweit sind aktuelle Impediments schon gelöst bzw. ist dafür die Hilfe des Dev-Teams nötig?
- Neue Termine, falls ein detaillierter Abstimmungsbedarf zwischen Teammitgliedern sichtbar geworden ist
- Die eigene heutige Verfügbarkeit, ggf. einer Vertretung
- Falls der Product Owner anwesend ist: Spätestens jetzt noch fragen, ob er weitere Anmerkungen hat
- Das Burn-Down Chart wird von einem Teammitglied aktualisiert.
Alles was man für dieses kurze Stand-Up benötigt, sind ein ScrumMaster, ein Dev-Team, ein Taskboard und ein Burn-Down Chart. Gäste, vor allem der PO, sind immer herzlich willkommen. Die Rahmenbedingungen von max. 15 Minuten, täglich, stehend, selber Ort, selbe Zeit dürfen deshalb aber nicht außer Acht gelassen werden.
Was haltet ihr von diesem kleinen “How-To”? Wie sieht der Ablauf des Daily Scrums bei euch aus?!
7 Antworten zu “Das Daily Scrum – ein How-To für das kürzeste Scrum Meeting”
Hallo Stephanie, eine gute Zusammenfassung fürs Daily. Wir besprechen zusätzlich noch am Anfang wer und warum er fehlt. Damit jeder Bescheid weis. Zusätzlich geben wir einen Marker rum, als “Zepter” zum sprechen, wenn man fertig ist, gibt man ihn weiter. So wird auch an das Punkte machen gedacht. Wir fangen immer bei der selben Person an, aber hier bin ich mir noch nicht ganz sicher, ob das die beste Lösung ist. Ich denke ich werde mal etwas anderes ausporbieren.
Hallo Säm, das sind wichtige Punkte! Vor allem den Talking Stick finde ich richtig gut – manchmal machen wir das auch mit einem Ball, den wir dann dem Nächsten zuwerfen. Das macht Spaß + spätestens wenn jemand “abgeschossen wird”, ist jeder wach. Den Ball kann man aber natürlich nicht dafür nutzen, Punkte auf die Tasks zu machen. Aber beim nächsten Daily kannst du den Ball ja mal einer komplett anderen Person “zuspielen” – so etwas bringt meist Abwechslung in Meetings. Gib Bescheid, wie die Reaktion war 🙂
Hallo Stephanie! Eine wirklich nette und sehr genaue Zusammenfassung. Ich frage mich allerdings, wieso der PO noch immer so sehr aus dem Daily “ausgeschlossen” wird. Er ist schliesslich auch Teil des Teams und sitz im besten Fall auch beim Team. Dinge an denen er aktuell arbeitet, werden das Team in den nächsten Sprints “beschäftigen”. In meinem letzten Team hat eine stärkere Integration des PO erst dazu geführt, dass sich das Team als ein ganzes sehen konnte.
Ich finde das ist eine spannende Frage. Ja – der Product Owner gehört zum Scrum-Team. Für die Lieferung des Sprint-Zieles (der Backlog Items) ist aber doch das Dev-Team verantwortlich, richtig? Liefert der Product Owner etwas zu den jeweiligen Stories dazu, dann gehört er als Dev-Team zum Daily Scrum, – absolut ok. Tut er das aber nicht, dann ist er doch nach wie vor im DS ein Chicken, da er nichts zur Lieferung beiträgt. Oder sehe ich da etwas falsch? Dein Punkt sehe ich aber auch – er bereitet den nächsten Sprint vor, oder ist an sich auch Teil des Scrum-Teams, muss sich also auch verantworten, gegenüber dem Team. Das macht durchaus Sinn. Aktuell erlebe ich jedoch nach wie vor Product Owner, die alles tun, aber sicher nicht selbst transparent werden wollen.
Eine Variante, die ich bevorzuge, ist, dass nicht alle der Reihe nach erzählen sondern alle – vor den Taskboard stehend – auf die Fragen jeweils pro STORY (beginnend bei der obersten noch nicht erledigten Story) beantworten.
Das unterstützt einen besseren Überblick über die Arbeit an einer Story als Ganzes und die Teamarbeit an den Stories. Beim “Reihum-erzählen” sieht es ja eher nach “Berichten von Einzelkämpfern” aus.
Und bei den Fragen fehlt mir – auch hier – eine ganz entscheidende Frage vor dem Hintergrund, dass das Team ja auch eine “Lernende Organisation” sein sollte, nämlich diese:
“Was habe ich bei meiner Arbeit seit gestern gelernt oder erkannt, was auch für andere im Team interessant sein könnte”
Der SM sollte diese “Lern-Erkenntnisse” als Abschluss des Daily dann auch nochmals zusammenfassen um sie zu verstärken.
Und als Abschluss habe ich auch gute Erfahrungen damit gemacht, wenn auf einem Flipchart neben dem Taskboard in Stichworten Punkte (auch positive, nicht nur negative) notiert werden, die bei der nächsten Retrospektive behandelt werden sollten.
Die Idee – Story für Story zu berichten ist genial. Das macht total Sinn. Für mich war das immer implizit logisch, da bei uns alle im Team in der Regel an einer Story arbeiten sollen. Die Idee mit dem Lernen ist spannend – obwohl ich mich frage, ob das nicht quasi eine Tagesretro ist. Find ich gut die Idee.
genau: Statt “Das Dev-Team trifft sich im Halbkreis vor dem Taskboard.” müsste es heissen “Das Scrum-Team trifft sich im Halbkreis vor dem Taskboard.”, also mit dem PO. Im “Core Scrum” heisst es: “Während dieses Meetings äußern sich nur die Scrum-Team-Mitglieder, einschliesslich des ScrumMasters und Product Owners”. Und im “Scrum Guide” steht: “Das Entwicklungs-Team sollte jeden Tag in der Lage sein, dem Product Owner und Scrum Master zu schildern, wie es bis zum Ende des Sprints als selbstorganisiertes Team zusammen arbeiten möchte”