Daily Scrum

English
Daily Scrum

Das Daily Scrum ist ein 15-minütiges Meeting für das Scrum Team. Es findet an jedem Arbeitstag statt, im Normalfall zur gleichen Zeit am gleichen Ort. Das Treffen dient dem Team dazu, die Tätigkeiten im Zeitraum bis zum nächsten Daily Scrum zu teilen, zu planen und mögliche Hindernisse ("Impediments") im Team zu kommunizieren, um notwendige Aktionen möglichst sofort einzuleiten. Daily Scrum zählt wie Sprint Planning, Sprint Review und Sprint Retrospektive zu den Scrum Events.

Daily Scrum

Daily Scrum

English
Daily Scrum

Das Daily Scrum ist ein 15-minütiges Meeting für das Scrum Team. Es findet an jedem Arbeitstag statt, im Normalfall zur gleichen Zeit am gleichen Ort. Das Treffen dient dem Team dazu, die Tätigkeiten im Zeitraum bis zum nächsten Daily Scrum zu teilen, zu planen und mögliche Hindernisse ("Impediments") im Team zu kommunizieren, um notwendige Aktionen möglichst sofort einzuleiten. Daily Scrum zählt wie Sprint Planning, Sprint Review und Sprint Retrospektive zu den Scrum Events.

Daily Scrum

Einsatzmöglichkeiten

  • Das Daily Scrum ist ein fester Bestandteil im Scrum Framework
  • Das Daily Scrum eigenet sich auch in anderen Vorgehensmodellen dafür, dass sich die Teammitglieder austauschen und Arbeitspakete miteinander abstimmen.
  • In langen Workshops bietet das Format Daily Scrum die Möglichkeit, einen Zwischenstatus des Gesamtfortschritts festzuhalten und nächste Schritte innerhalb der Workshop-Übungen zu planen.
Daniel Reinold live erleben in der PM Welt @home!
PM Welt

Erleben Sie den Vortrag "5+ visuelle Quick-Hacks – Für eine bessere Kommunikation und Kooperation" sowie 30 weitere Speaker in der PM Welt @home.

Das Thema der Konferenz lautet
Stark durch Kooperation! Zusammen.Arbeiten.Grenzenlos.
Die Teilnehmer erhalten in den unterschiedlichen Vorträgen, Diskussionen und Workshops konkrete Praxistipps und Impulse für ihren Projektalltag

 

 

Ergebnisse
  • Das Team ist über den aktuellen Forschritt bezüglich des Sprint-Zieles informiert.
  • Fachliche Rückfragen wurden im Team geklärt, bzw. die Klärung wurde eingeleitet.
  • Vereinbarte Maßnahmen zur Behebung von Problemen bei der Umsetzung der Sprint-Ziele (“Impediments”) wie z.B. Pair-Programming, Arbeitsgruppen, Trainings- oder Umsetzungs-Dojos, Weiterbildungen, Coaching.
Vorteile
Die teilnehmenden Personen bleiben durch den straffen, 15-minütigem Ablauf konzentriert und schweifen nicht ab.
Die Behandlung aktueller Themen ermöglicht eine fokussierte Planung kurzer Zeiträume (i.d.R. 1 Tag).
Das einfache Regelwerk des Daily Scrums ermöglicht es einem stabilen Teilnehmerkreis, sich auch ohne Moderation weitgehend selbst zu organisieren.
Grenzen, Risiken, Nachteile
Tiefes Eintauchen in eine fachliche Thematik ist aufgrund der kurzen Dauer des Daily Scrums nicht möglich. Daily Scrum dient dazu, den Bedarf eines intensiveren Austauschs zu erkennen. Der vertiefte, fachliche Austausch findet dagegen nach dem Daily Scrum statt. In der Regel sind dabei nur die betroffenen Personen beteiligt.
Um die vorgesehene Zeit von 15 Minuten einzuhalten, benötigen alle teilnehmenden Personen eine hohe Disziplin bzgl. Pünktlichkeit und Einhaltung der einfachen Gesprächsregeln.
Nachholtermine oder Wiederholungen der Inhalte für Personen, die später erscheinen, sind nicht vorgesehen.
Ein Daily Scrum verhindert nicht die Schwierigkeiten räumlicher Trennung oder unterschiedlicher Zeitzonen. Alle Personen müssen zu einem festen Zeitpunkt an diesem Meeting teilnehmen.
Voraussetzungen
  • Alle teilnehmenden Personen sind in der Lage, ihre letzten und folgenden Tätigkeiten zur Erreichung des Sprint-Zieles mitzuteilen. Ggf. sind hierfür geeignete Tools zur Dokumentation einzusetzen.
  • Alle sind über das aktuelle Sprint-Ziel informiert und fachlich in der Lage, die Relevanz der eigenen aktuellen Tätigkeiten in das Sprint-Ziel einzuordnen. Das unterstützt die Fokussierung auf relevante Themen.
  • Das Team erscheint pünktlich zum Daily Scrum. Das Daily Scrum startet exakt zur vereinbarten Uhrzeit und endet spätestens 15 Minuten danach.
  • Falls erforderlich sind technische oder organisatorische Vorbereitungen (z.B. Platz freiräumen, Boards aktualisieren, Beamer anschalten) vor dem Start des Daily Scrum abzuschließen, so dass der pünktliche Start des Daily-Scrum nicht gefährdet ist.
Qualifizierung

Das Team muss mit den Regeln von Daily Scrum vertraut sein. Vor der ersten Durchführung eines Daily Scrums empfiehlt sich deshalb, das Team vorab kurz in die Methodik einzuführen. Die moderierende Person muss Erfahrungen zum Ablauf eines Daily Scrums und zu Timeboxing haben. Im Normalfall erklärt und moderiert der Scrum Master das Daily Scrum. Auf Wunsch oder bei Bedarf kann auch das Team die Moderation übernehmen.

Benötigte Informationen
  • Zusammengestellte Informationen über den individuellem Fortschritt bezüglich der Erreichung des Sprint-Ziels. Hierzu gehören die zuletzt durchgeführten Tätigkeiten, die geplanten Tätigkeiten und Informationen über Hindernisse.
  • Organisatorische Informationen: Zeit, Ort und Format (online / offline vor Ort), gegebenenfalls Zugangsdaten zu technischen Lösungen.
Benötigte Hilfsmittel
  • ungestörter, ausreichender Platz für das Team
  • optional: Kanban-Board des aktuellen Sprints
  • optional: Moderationsfläche (Whiteboard, Flipchart, Pinnwand) mit geeigneten Stiften

Für die Arbeit mit verteilten Teams in Verbindung mit digitalen Kommunikationslösungen:

  • Arbeitsplatz mit Internetanbindung – inklusive entsprechender Software und Lizenzen
  • Headset bzw. Mikrofon und Lautsprecher zur gegenseitigen Verständigung
  • Optional: Webcam zur Bildübertragung
Herkunft

Das Daily Scrum wurde erstmalig im Scrum Guide beschrieben. Scrum wurde in den frühen 1990er Jahren durch Ken Sutherland und Ken Schwaber erdacht (veröffentlicht unter dem Namen: "SCRUM Software Development Process"). Die Ausarbeitung der Idee basiert auf der Publikation "New New Product Development Game", in der Hirotaka Takeuchi und Ikujiro Nonaka 1986 die Entwicklung eines gemeinsamen Ziels durch Iterationen beschrieben. Besondere Schwerpunkte waren hierbei Geschwindigkeit und Flexibilität. Die aktuell gültige Version von Scrum ist im sogenannten "Scrum Guide" dokumentiert, der in mehreren Sprachen frei zum Download auf der Website www.scrumguides.org zur Verfügung steht.

Durchführung: Schritt für Schritt

Das Daily Scrum wird im Rahmen des Scrum Frameworks mit dessen Nomenklatur beschrieben (s.u. Herkunft). Zum besseren Verständnis definiere ich zunächst einige wichtige Begriffe und erkläre, wie ich sie in hier verwende.

Aus Gründen der einfacheren Lesbarkeit wird im Folgenden nur die grammatikalisch männliche Form (Scrum Master, Product Owner, Moderator) verwendet. Es sind dabei aber stets Personen jeden Geschlechts gemeint.

  • Der Scrum Master als Facilitator des Scrum-Vorgehens ist unter anderem für die Moderation der Scrum Events verantwortlich. In Absprache mit ihm kann auch ein anderes Teammitglied die Moderation übernehmen.
    Im Folgenden verwende ich deshalb allgemein den Begriff "Moderator" bzw. "Moderation". Den Begriff "Scrum Master" benutze ich, wenn es um eindeutig dem Scrum Master zugeordnete Tätigkeiten geht.
  • Der Product Owner vertritt die Auftraggeberseite und gibt gegenüber dem Team das "Was" vor. D.h. er benennt die Aufgaben, die das Team eigenverantwortlich lösen soll. Er stellt am Ende eines festgelegten, wiederkehrenden Zeitraums (Sprint, s.u.) die Zielerreichung fest und ist unter anderem erster Ansprechpartner für fachliche Rückfragen aus dem Team.
  • Sprint ist der festgelegte, wiederkehrende Zeitraum, in dem das Team die Aufgaben umsetzt. Die Dauer eines Sprints beträgt meist vier Wochen, sie kann aber auch kürzer oder länger festgelegt werden. Innerhalb eines Sprints finden festgelegte Events wie das Daily Scrum statt.
  • Aufgabe (Task), Bug, User Story, Epic: Diese sogenannten "Artefakte" sind Gegenstände oder Informationsspeicher, die in den Sprints vom Team bearbeitet werden. Sie haben unterschiedliche Größenordnung und Relevanz. Während Bugs und Aufgaben die kleinste Einheit darstellen, besteht eine User Story aus mehreren Aufgaben und ein Epic aus mehreren User Storys.
  • Ein Backlog beschreibt eine priorisierte Liste von Epics oder User Storys. Das Backlog wird vom Product Owner verwaltet. Je nach Scrum-Anwendung gibt es ein oder mehrere Backlogs wie z.B. Product Backlog, Sprint Backlog oder Epic Backlog. Bei gleichzeitigem Einsatz sind diese Backlogs Teilmengen voneinander (Beispiel: Ein Sprint Backlog ist diejenige Teilmenge des Product Backlogs, die im Sprint umgesetzt werden soll).
  • Das Sprint-Ziel ist eine kurz und präzise forumulierte Zusammenfassung des Sprint Backlogs, d.h. der Aufgaben des aktuellen Sprints.
  • Scrum Team und Entwicklungsteam (Development Team): In Scrum wird die Personengruppe, die direkt an der Umsetzung der geplanten Tätigkeiten im Sprint beteiligt ist, "Entwicklungsteam" genannt, unabhängig davon, ob es sich tatsächlich um Entwicklungstätigkeiten handelt. Es geht vielmehr um die Umsetzung der geplanten User Storys. Der Begriff "Scrum Team" schließt Scrum Master und Product Owner mit ein.
    In diesem Artikel verwende ich durchgängig den Begriff "Team" für "Scrum Team" und spreche einzelne Rollen je nach Bedarf gezielt an.
  • Eine Timebox ist ein vorab festgelegter Zeitraum, in dem anhand einer ausgereiften Methodik Wertschöpfung stattfindet. In Scrum wird dem Einhalten von Timeboxen ein hoher Stellenwert zugeschrieben. Alle Scrum Events, so auch das Daily Scrum, bestehen aus einer oder mehrerer Timeboxen. Die größte Timebox des Daily Scrums besteht aus seiner gesamten Dauer von 15 Minuten. Kleine Timeboxen können im Daily Scrum beispielsweise Gesprächs- oder Themen-Timeboxen sein.

Schritt 1: Der Moderator eröffnet das Daily Scrum

Pünktlich zum geplanten Beginn des Daily Scrum beginnt die Moderation mit der Einleitung des Meetings. Falls Teammitglieder fehlen, stellt die Moderation klar, dass ein Scrum Event stets pünktlich beginnt und keine Rücksicht auf fehlende Einzelpersonen genommen werden kann. Dies dient im gewissen Sinne der Erziehung zur Pünktlichkeit.

Die Moderation erklärt, dass das Daily Scrum ein Teamevent ist, in dem die Teammitglieder

  • sich austauschen, um einen thematischen Überblick zu erhalten,
  • Schwierigkeiten aufdecken, um sie gesondert, aber gemeinsam zu lösen
  • eine Prognose zur Bearbeitung der offenen User Storys abgeben, damit der Product Owner frühzeitig mögliche Optionen gemeinsam mit dem Team abwägen und verabschieden kann.

Die Moderation klärt ab, wie der Austausch erfolgen soll: Thematisch geordnet, reihum oder mit Wortmeldungen. Diese Abfrage ist nicht bei jedem Daily notwendig, jedoch lohnt sich ein Wechsel zwischendurch. Das sorgt nicht nur für Abwechslung, sondern unterstützt ebenfalls das Vermeiden einer Berichtsroutine.

Zur Vermeidung eingefahrener Abläufe gehört ebenfalls die Abhaltung im Stehen. Das Daily Scrum ist ein sogenanntes "Standup Meeting", d.h. während der 15 Minuten steht das gesamte Team (soweit physikalisch möglich) im Idealfall im Kreis oder im Halbkreis um die Moderationsfläche oder das Kanban-Board.

Schritt 2: Der Austausch im Team findet statt

Entsprechend der vereinbarten Reihenfolge berichten die Teammitglieder knapp aber präzise zu ihren Themen, die dem Sprint-Ziel dienen. Die Moderation unterstützt hierbei, achtet aber besonders auf eine gleichmäßige Verteilung der Redezeit. Im Zweifelsfall unterbricht sie einen zu ausführlichen Bericht oder eine Diskussion mit dem Hinweis auf die enge Timebox.

Unterstützend bietet Scrum drei klassische Leitfragen – hier in einer ausführlicheren Formulierung:

  • Was habe ich gestern / am letzten Arbeitstag getan, um das Sprint-Ziel zu erreichen?
  • Was werde ich heute tun, um das Sprint-Ziel zu erreichen?
  • Habe ich ein Impediment gefunden, das mich oder das Team bei der Erreichung des Sprint-Ziels behindert?

Die vorgeschlagenen Fragen helfen, den Zweck des Meetings zu beschreiben. Die Moderation, im Speziellen der Scrum Master, klärt im Falle eines Impediments, ob es durch das Team lösbar ist oder ob er bei der Lösung unterstützen kann (z.B.: durch eine direkte Beteiligung an der Lösungssuche oder Eskalation).

Rückfragen zu den berichteten Inhalten sind zulässig, werden aber ebenfalls knapp gehalten. Das erlaubt – sofern möglich – schnelle Entscheidungen und eine gezielte Klärung für umfangreichere Themen im Nachgang des Events.

Wenn Tools verwendet werden, wie z.B. ein Sprint-Backlog (analog oder digital dargestellt anhand eines Boards) aktualisiert das Team selbstständig während dieses Schritts den Status der Inhalte.

Varianten ...

Ergänzende Methoden

Sprint Planning

Planen Sie mit dem gesamten Scrum-Team den nächsten Sprint und sorgen Sie so für einen stabilen Entwicklungsprozess!

Sprint Review

Halten Sie Ihr agiles Projekt auf Kurs und beschließen Sie notwendige Maßnahmen zur Steuerung, in dem Sie nach jedem Sprint das Feedback der Stakeholder zum Produktinkrement einholen!

Sprint Retrospektive

Reflektieren und analysieren Sie mit dem Scrum Team den zurückliegenden Sprint! Leiten Sie gemeinsam aus den positiven und negativen Erfahrungen Maßnahmen ab, um im nächsten Sprint die Produktivität des Entwicklungsteams zu erhöhen.

User Storys erstellen

Definieren Sie mit User Storys den Leistungsumfang eines agilen Projekts in der Sprache des Kunden! Damit schaffen Sie eine bewährte Grundlage für die Kommunikation zwischen Product Owner und Entwicklungsteam, die das gesamte Projekt begleitet.

Kanban Light

Sorgen Sie für hohe Transparenz bei der Aufgabenplanung für das Projektteam und verkürzen Sie die Durchlaufzeit einzelner Aufgaben durch die Überwachung und Steuerung entsprechender Verantwortlichkeiten. Regeltermine fördern den teaminternen Austausch.

Fachartikel zur Methode

Teil 2:
Vorgehen in der Praxis
Im ersten Teil stellte Dominik Maximini ein Vorgehen vor, um Scrum-Projekte strukturiert zu planen und zeigte Fehler auf, die dabei häufig in der Praxis gemacht werden.

Wie organisiert man eine reibungslose Zusammenarbeit mehrerer agiler Entwicklungsteams für ein Produkt? Malte Foegen und Claudia Raak setzen auf eine Kombination aus den Skalierungsframeworks SAFe und LeSS.

Agile Methoden können auch im Maschinenbau sinnvoll und nützlich eingesetzt werden – behaupten Philipp Hecker und Prof. Dr. Arthur Kolb.
Teams, die von klassischer Projektarbeit auf Scrum umstellen, müssen nicht nur Rollen, Artefakte und Meetings einführen. Der Wechsel vom klassischen zum agilen Projektmanagement geht auch mit großen Veränderungen in der Zusammenarbeit einher.
Teil 2:
Projektsteuerung
Hybrides Projektmanagement vereint die Vorteile von klassischem und agilem Projektmanagement: Einerseits fixe Termine einzuhalten, andererseits auch bei kurzfristigen Änderungen flexibel zu reagieren.
Teil 1:
Welche Mischformen sind für die Praxis relevant?

Agil, klassisch, hybrid oder selektiv: Viele Unternehmen haben die Bedeutung agiler Methoden mittlerweile erkannt. Eine weitergehende Systematik, wie agile und traditionelle Methoden am besten zusammenspielen, fehlt jedoch meist. Dies stellt …

Aufgabengebiete

Download PDFDownload PDF

Bewertungen und Kommentare

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung.
2 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 2
Kommentare 2

Alle Kommentare (2)

Guest

Vielleicht wäre erwähnenswert, dass es zwei wesentliche Alternativen gibt, wie die Reihenfolge des Redners bestimmt wird: 1. Personen-zentriert (also z. B. einfach reihum) 2. (Sprint-)Themen-zentriert (also gemäß Reihenfolge der abzuarbeitenden Aktivitäten) (1) bietet den Vorteil, dass auch ruhige Teilnehmer über ihren Stand, ihre nächsten Schritte und Hindernisse aktiviert werden. Ein Nachteil ist, dass evtl. thematisch gesprungen wird, je nachdem an welchem Thema der jeweils aktive Teilnehmer arbeitet. (2) bietet den Vorteil, dass weiterhin ergebnis-fokussiert bis zum nächsten Daily geplant wird. Damit bleibt das Team "länger" in einem Thema. Nachteil, ruhige oder introvertierte Teilnehmer können benachteiligt werden bzw. sich auch leichter "entziehen". Hier ist also der Moderator/Facilitator gefragt. Aus eigener Erfahrung als Scrum Master kann ich sagen: (1) ist ein guter Start, um zu gewähleisten, dass sich alle beteiligen und die Disziplin erlernen kurz und prägnant zu formulieren. (2) unterstützt wesentlich besser den Fokus zu halten und liefert auch aus Sicht (zumindest meiner) Teams die bessere Effektivität. Es erfordert allerdings eine höhere Disziplin bei den Beteiligten und häufig eine gute Moderation, da sich Leute leichter in Diskussionen des jeweils aktuellen Themas verlieren können. Inwieweit (2) auch gut in anderen Umgebungen als Scrum mit seinen themenbegrenzenden Sprints funktioniert, weiß ich nicht. Denn wenn 8 Leute an 8 unterschiedlichen Themen arbeiten unterscheidet sich (2) nicht mehr von (1) ...

 

Dieter
Bertsch

…und noch ein paar Ergänzungen/Anmerkungen:
&nbsp
Lehrbuch: - Product Owner (PO) & ScrumMaster (SM) müssen nicht teilnehmen; SM muss dafür sorgen, dass es stattfindet - Öffentliches Meeting, an dem jeder teilnehmen darf; jedoch nur Mitglieder des Development Teams dürfen etwas sagen
&nbsp
Praxis: - PO & SM sollten teilnehmen und auch einen Redebeitrag über ihren Anteil zur Erreichung des Sprint Ziel haben - Letzte Statement der drei zu beantwortenden Fragen vorziehen: Erst sagen, welche Hindernisse da sind bevor man mitteilt, was man als nächstes tuen will - Große Gefahr bei der Aktualisierung des Sprint-Backlog bei der Verwendung digitaler Medien: Hier geht oft der Fokus für die Inhalte durch die Beschäftigung mit dem Tool verloren. Tipp: Wenn immer möglich, ein physische Task Board verwenden! - Apropos Task Board: Im Artikel wird mehrfach die Verwendung eines Kanban Boards erwähnt. Kanban ist eine Lean Management-Methode zur Optimierung von Prozessen. Kanban zeichnet sich durch die Limitierung der gleichzeitig in Bearbeitung befindlicher Backlog-Items aus (Work in Progress – WiP). Diese werden als Zahlen (WiP-Limits) über den Spalten des Kanban Boards vermerkt. Scrum fokussiert hingegen auf die Produkterstellung und limitiert die Menge der Arbeit durch Timeboxen (Sprints). Scrum kennt keine WiP-Limits und verwendet deshalb auch nur ein Task Board zur Visualisierung – kein Kanban Board!