Was ist ein Daily Scrum?

Das zentrale Scrum Artefakt des Daily Scrums ist das Sprint Backlog. Weil es sowohl das Sprintziel selbst als auch den aktuellen Plan des Scrum Teams beinhaltet, können die Entwickler des Scrum Teams mit seiner Hilfe überprüfen, wie es um die Erreichung des Sprintziels steht. Das Sprint Backlog sorgt also für die notwendige Transparenz, um Überprüfung & Anpassung im Daily Scrum überhaupt erst zu ermöglichen.

Sofern derzeit alles nach Plan verläuft, kann der aktuelle Kurs beibehalten werden. Falls nicht, verändern die Entwickler ihr Sprint Backlog eigenständig. Sie ergänzen es also um neue Tasks, löschen unnötige Tasks oder sogar User Stories und dergleichen mehr. Sollte sich während des Daily Scrums jedoch herausstellen, dass das Sprintziel wahrscheinlich nicht (mehr) erreicht werden kann oder die Entwickler aufkommende Probleme nicht eigenständig lösen können, bestehen grundsätzlich zwei Optionen:

Das Daily ist ein Event der Entwickler (und nur der Entwickler) eines Scrum Teams.

Weder Product Owner, noch Scrum Master, noch Stakeholder sollten am Daily Scrum teilnehmen.

Denn nur auf diese Art fördert das Daily Scrum das Selbstmanagement der Entwickler. (Zu den Problemen, die die Anwesenheit von anderen Personen im Daily Scrum verursacht, erfährst Du weiter unten mehr.)

Wie alle Scrum Events hat auch das Daily Scrum eine Timebox. (In diesem Fall von maximal 15 Minuten.) Das heißt, es darf nicht länger als 15 Minuten dauern, kann aber grundsätzlich auch kürzer sein, wenn es seinen Zweck erfüllt hat.

Soweit zum generellen Zweck des Daily Scrums und den allgemeinen Rahmenbedingungen, unter denen es stattfinden sollte. Nichtsdestotrotz kann dieser Scrum Event auf viele verschiedene Arten scheitern oder schiefgehen. (Auf Scrum.org findest Du dazu beispielsweise den Artikel 5 Dysfunctions of a Daily Scrum von Piyush Rahate.)

Das Daily Scrum ist nicht der Ort, an dem Manager oder Product Owner Informationen ans Team weitergegeben, weil “gerade alle da sind.” Es ist auch nicht Sinn und Zweck dieses Events, jedem alles zu erzählen, was man am gestrigen Tag alles getan hat.

Jede Information, die während des Daily Scrums ausgetauscht wird, muss einen Bezug zum aktuellen Sprintziel haben. Ist das nicht der Fall, gehört diese Information nicht ins Daily Scrum.

Häufig beobachte ich, dass Manager oder andere Stakeholder am Daily Scrum teilnehmen, um “auf dem Laufenden” zu sein. Meist geschieht das auch in bester Absicht, um dem Team direkt Unterstützung anbieten zu können. Der Effekt ist in der Regel immer der gleiche: Die Entwickler beginnen damit, dem anwesenden Manager zu berichten, wie der aktuelle Stan der Arbeit ist und beantworten ihm oder ihr Fragen. Damit verkommt das Scrum Event zu einem reinen Reporting.

Stakeholder im Daily Scrum sind (meiner Meinung nach) ein Anzeichen für mangelndes Vertrauen, dass die Entwickler selbstgemanagt ihr Sprintziel erreichen können.

Auch der Product Owner ist kein Teilnehmer des Daily Scrums. Oft ist hier der gleiche Effekt zu beobachten, wie bei anwesenden Stakeholdern: Die Entwickler reporten ihrem Product Owner den aktuellen Stand der Arbeit. Es ist jedoch nicht die Aufgabe des Product Owners, an der Umsetzung des Sprintziels mitzuwirken. Seine Aufgabe besteht darin, mit seinen Stakeholdern, Nutzern und Kunden zu kommunizieren, um den bestmöglichen Wert seines Produktes sicherzustellen.

Eine Ausnahme gilt hier allerdings: Sofern der Product Owner gleichzeitig auch Entwickler des Scrum Teams ist, nimmt er natürlich am Daily Scrum teil. (Aber als Entwickler und nicht als Product Owner.)

Genauso wie Stakeholder und Product Owner ist auch der Scrum Master kein Teilnehmer das Daily Scrums. Seine Aufgabe besteht lediglich darin, sicherzustellen, dass das es stattfindet.

Diese Regel gilt nicht unbedingt für neue beziehungsweise unerfahrene Scrum Teams. Denn wie willst Du als Scrum Master Deine Entwickler dabei unterstützen, ihr Daily Scrum durchzuführen, wenn Du nicht anwesend bist? Gerade zu Beginn benötigen Deine Entwickler natürlich Unterstützung bei ihrem Daily. Nichtsdestotrotz solltest Du als Scrum Master darauf hinarbeiten, dass die Entwickler ihr Daily eigenständig durchführen (können).

Wie für den Product Owner gilt auch für den Scrum Master eine Ausnahme: Sofern der Scrum Master gleichzeitig auch Entwickler des Scrum Teams ist, nimmt er natürlich am Daily Scrum teil. (Aber als Entwickler und nicht als Scrum Master.)

Manche Scrum Teams verlieren sich im Daily zu sehr im Detail und versuchen, Probleme direkt dort zu lösen. (Dabei wird auch regelmäßig die Timebox von 15 Minuten “gerissen”.) Das ist ganz besonders dann nicht gut, wenn es Themen sind, die nur zwei Entwickler betreffen. Für ein effizientes Daily reicht es jedoch vollkommen aus, ein Problem anzusprechen, einen Kollegen um Hilfe zu bitten und das Problem mit diesem Kollegen nach dem Daily Scrum zu lösen.

Das Daily Scrum ist kein Problemlösungs-Event.

Falls Ihr mit einem Kanban-Board arbeitet, hat es sich als hilfreich herausgestellt, immer mit denjenigen User Stories oder Tasks zu beginnen, die sich bereits weit rechts auf Eurem Board befinden. Meiner Erfahrung nach erzeugt das einen stärkeren Fokus auf die Fertigstellung von Aufgaben. (Die Regel des Scrum Guides, dass niemand den Entwicklern vorzuschreiben hat, wie sie ihr Daily durchführen, gilt natürlich weiterhin, aber es schadet ja nicht, es einmal auszuprobieren.)

Achtet darauf, dass Ihr für aufkommende Probleme oder neue Aufgaben festhaltet, wer sich um sie kümmern möchte. Bei gut funktionierenden Teams ist das meist kein Thema. Aber nichts ist schlimmer als ein Task, der als wichtig erkannt wurde, jedoch im nächsten Daily Scrum noch immer nicht erledigt wurde, weil sich niemand seiner angenommen hat.

Zu guter Letzt der vielleicht wichtigste Hinweis von allen: Das Daily ist Euer Notfall-Anker. Es stellt sicher, dass Probleme bei der Arbeit maximal 24h unerkannt bleiben. Die agile Kommunikationsregel gilt jedoch weiterhin:

Kommuniziere so oft wie nötig und früh wie möglich!

Genauso wie Du bei Problemen in Deinem Team nicht bis zur Sprint Retrospektive warten solltest, solltest Du wichtige Informationen an Deine Kollegen so früh wie möglich weitergeben und nicht auf das Scrum Daily warten.

Richtig durchgeführt, ist das Daily Scrum einer der wichtigsten Scrum-Elemente, um Fokus und Selbstmanagement der Entwickler zu fördern. Ich hoffe, ich konnte Dir ein paar hilfreiche Tipps & Tricks mit auf den Weg geben und vielleicht sogar mit dem einen oder anderen hartnäckigen Mythos aufräumen. Falls Du noch Fragen hast oder den einen oder anderen Aspekt vielleicht anders siehst, schreib mir gerne einen Kommentar und auf der Seite. Ich freu mich auf den Austausch mit Dir!