April 2026 10 min Lesezeit Meinung
Drei Fragen. Fünfzehn Minuten. Jeden Morgen. Das Daily Scrum ist die einfachste Zeremonie im Scrum. Und eine der zuverlässigsten, die degeneriert. In allen Organisationen, in denen ich gearbeitet habe – Banken, Telekommunikation, Softwareunternehmen, Beratungen – ist das Muster nahezu universell: Was als Team-Synchronisierungswerkzeug beginnt, wird innerhalb von Monaten nach der Einführung zu einem Management-Berichtsmechanismus. Das Team lernt, die Zeremonie aufzuführen, ohne sie zu nutzen.
Der Hook: Die meistbeobachtete Zeremonie ist die am wenigsten verstandene
Das Daily Scrum hat die höchste Sichtbarkeit aller Scrum-Events. Es findet jeden Tag statt. Manager können teilnehmen. Stakeholder können zusehen. Compliance-Auditoren können bestätigen, dass es stattgefunden hat. Für Organisationen, die Agile als Prozessschicht statt als Arbeitsweise einführen, wird es zur wichtigsten Zeremonie – weil sie die lesbarste ist: die, die überprüft, gezählt und berichtet werden kann.
Diese Sichtbarkeit ist die Quelle ihrer Dysfunktion. Das Daily Scrum wurde entwickelt, um die Selbstorganisationsbedürfnisse des Entwicklungsteams zu unterstützen. Es wurde zum primären Werkzeug der Organisation, den Teamfortschritt zu überwachen. Diese beiden Zwecke sind nicht kompatibel – und wenn sie in Konflikt geraten, gewinnt die Überwachungsfunktion.
Die Realität: Drei Fragen, die nichts beantworten
Die ursprüngliche Scrum-Guide-Formulierung stellte drei Fragen: Was habe ich gestern gemacht? Was mache ich heute? Was blockiert mich? Die meisten Praktiker kennen das. Die meisten Praktiker verwenden genau diese Fragen. Und in den meisten Organisationen ist das Ergebnis keine Team-Synchronisation – sondern ein im Stehen vorgetragener Statusbericht.
Die Drei-Fragen-Falle
Das Problem sind nicht die Fragen selbst. Es ist, was mit den Antworten passiert. Wenn jeder Teammitglied weiß, dass ein Manager zuhört, dass die Antworten notiert werden und dass die falsche Antwort Konsequenzen hat – “Ich habe gestern nicht fertiggestellt, was ich gesagt habe” – werden die Fragen zum Berichtsmechanismus. Das Team synchronisiert sich nicht um gemeinsame Arbeit. Jede Person liefert ihr individuelles Statusupdate und wartet, bis die nächste Person dasselbe tut.
Beobachte ein Daily Scrum in den meisten Organisationen, und du wirst sehen:
- Teammitglieder sprechen den Manager an, nicht einander
- Das Gespräch fließt durch den Scrum Master oder Manager statt zwischen Entwicklern
- Blocker werden zu wenig gemeldet, weil das Nennen eines Blockers ein Risikosignal ist
- Das Meeting dauert genau fünfzehn Minuten, unabhängig davon, ob es etwas zu synchronisieren gibt
- Niemand spricht über das Sprint-Ziel
Dieser letzte Punkt ist am wichtigsten. Das Daily Scrum dreht sich im aktuellen Scrum Guide explizit um das Sprint-Ziel. Das Team überprüft seinen Fortschritt in Richtung des Ziels und passt den Plan für den nächsten Arbeitstag an. Wenn niemand das Sprint-Ziel erwähnt, ist das Meeting kein Daily Scrum. Es ist ein Morgenstandup, der den Zeitblock des Daily Scrum ausleiht.
Das Problem der Managementpräsenz
Die Anwesenheit von Management beim Daily Scrum ist ein erheblicher Treiber der Zeremoniendegradierung. Manager beabsichtigen selten, das Daily in ein Statusmeeting zu verwandeln. Sie nehmen oft teil, weil sie sich ehrlich für die Arbeit interessieren oder weil sie das Gefühl haben, mit ihren Teams verbunden sein zu müssen. Die Wirkung ist unabhängig von der Absicht konsistent.
Teams sind nicht irrational. Wenn ein Manager anwesend ist, reagieren sie auf die Machtdynamik im Raum. Informationen werden gefiltert. Probleme werden minimiert. Fortschritt wird betont. Das Meeting dient dem Manager statt dem Team, und das Team lernt das schnell.
Die Checksum: Wofür das Daily eigentlich ist
Das Daily Scrum existiert, um Team-Selbstorganisation zu unterstützen. Nicht Team-Reporting. Nicht Management-Sichtbarkeit. Nicht Stakeholder-Beruhigung. Selbstorganisation.
Ein Team, das das Daily Scrum wirklich nutzt, fragt: Wo stehen wir heute in Bezug auf unser Sprint-Ziel, und was ist die beste Nutzung der Zeit jeder Person für die nächsten vierundzwanzig Stunden? Das Gespräch, das diese Frage beantwortet, klingt nichts wie ein Drei-Fragen-Statusbericht. Es klingt wie ein Team, das seinen Arbeitsplan in Echtzeit anpasst, basierend auf gemeinsamen Informationen.
Wie ein echtes Daily aussieht
Ein echtes Daily Scrum ist nach den Standards der meisten Organisationen ungeordnet. Jemand beginnt damit, das Sprint-Board gemeinsam anzuschauen. Jemand anderes stellt fest, dass die laufende Arbeit die Kapazität übersteigt. Eine dritte Person sagt, sie ist blockiert und braucht Hilfe von jemandem Bestimmten. Zwei Personen beginnen sofort, die Abhängigkeit zu lösen. Der Scrum Master notiert einen Impediment, der eskaliert werden muss. Das Team einigt sich auf einen überarbeiteten Plan für den Tag. Das Ganze dauert acht Minuten, weil es viel zu koordinieren gab, oder vier Minuten, weil es das nicht gab.
Niemand spricht den Manager an. Niemand berichtet individuellen Status. Niemand wartet darauf, dass die nächste Person fertig ist, bevor er auf die Arbeit schaut. Das Gespräch dreht sich um die Arbeit, nicht um die Personen, die sie erledigen.
“Ein Daily Scrum, in dem niemand das Sprint-Ziel erwähnt, ist kein Scrum-Event. Es ist ein Standup mit geliehenem Vokabular.” Markus – agile-checksum.com
Fallstudien aus der Praxis
Das Anwesenheitsregister
Ein cross-funktionales Team in einem Telekommunikationsunternehmen hatte ein Daily Scrum, das jeden Morgen um 9:00 Uhr stattfand. Anwesenheit war Pflicht, wurde protokolliert und der Abteilungsleitung gemeldet. Das Meeting lief konsequent genau fünfzehn Minuten. Jedes Teammitglied sprach. Jedes Update wurde im gleichen Format geliefert. Es wurden nie Blocker genannt. Das Sprint-Board war immer grün.
Als ich das Team außerhalb des Dailys beobachtete, bemerkte ich, dass die eigentliche Koordination in kleinen Gruppengesprächem an den Schreibtischen stattfand. Teammitglieder hatten gelernt, dass das Daily ein Anwesenheitsregister und ein Statusbericht war. Sie machten ihre echte Koordination woanders, aus eigener Initiative, weil das offizielle Meeting diesem Zweck nicht diente.
Die Zeremonie war konform. Der tatsächliche tägliche Koordinationsmechanismus des Teams waren die informellen Gespräche, die die Organisation nie sanktioniert oder bemerkt hatte. Das Daily Scrum war Scrum Theatre.
Die Impediment-Minimierer
Ein Softwareteam in einer Bank hatte einen Product Owner, der bei jedem Daily teilnahm. Er war unterstützend und gut gemeint. Er hatte auch starke Meinungen zur Arbeit und eine Tendenz, sich zu jedem als Blocker genannten Thema zu äußern.
Das Team hörte innerhalb von drei Sprints auf, Blocker im Daily zu nennen. Nicht weil die Blocker verschwanden, sondern weil das Nennen eines Blockers eine fünfzehnminütige Diskussion auslöste, die das Meeting entgleisen ließ. Der effizientere Ansatz war, Blocker privat mit dem Scrum Master nach dem Meeting zu besprechen, wo der Product Owner nicht anwesend war.
Die Organisation hatte genaue Zeremonienmetriken: Das Daily lief pünktlich, Anwesenheit war vollständig, das Board war aktuell. Die Organisation hatte vollständig unsichtbare Impediment-Daten: Die Blocker, die still außerhalb der Zeremonie gehandhabt wurden, waren erheblich, akkumulierten sich und wurden gelegentlich katastrophal.
Wie man das Daily Scrum wiederherstellt
Für Scrum Master: Die Bedingungen für echte Koordination schaffen
- Die Frage ändern. Hör auf zu fragen “Was hast du gestern gemacht?” Beginne zu fragen: “Was muss das Team heute tun, um auf Kurs für das Sprint-Ziel zu bleiben?” Der Wechsel von individuellem Reporting zu kollektiver Planung ist der eigentliche Punkt.
- Das Sprint-Ziel explizit ansprechen. Bevor irgendetwas anderes – schau dir an, wo du in Bezug auf das Ziel stehst. Wenn das Team das Sprint-Ziel zu Beginn des Dailys nicht nennen kann, ist das das erste Problem zu lösen.
- Beobachter managen. Management-Anwesenheit beim Daily ist eine Entscheidung mit Konsequenzen. Führe das Gespräch mit deiner Führungskraft: “Deine Anwesenheit im Daily verändert das Verhalten des Teams. Können wir einen anderen Weg finden, dir die Transparenz zu geben, die du brauchst?”
Für Organisationen: Verstehe, was du verlangst
- Zeremonieneinhaltung von Zeremoniennutzen unterscheiden. Ein Daily, das jeden Tag um 9:00 Uhr mit vollständiger Anwesenheit und ohne genannte Blocker läuft, ist kein Beweis für effektive Agile-Praxis. Es kann Beweis für effektives Status-Theater sein.
- Sichtbarkeit woanders finden. Das Daily Scrum ist nicht dein Fortschrittsüberwachungswerkzeug. Sprint Reviews sind es. Burndown-Charts sind es. Wenn du tägliche Fortschrittsinformationen brauchst, designe einen Mechanismus dafür, statt das Daily als Berichtsmechanismus zu nutzen.
Das Takeaway: Die Zeremonie ist nicht das Problem
Das Daily Scrum ist nicht kaputt. Der Kontext, den Organisationen darum schaffen, ist es. Eine Zeremonie, die Team-Selbstorganisation unterstützen soll, wird als Statusberichtsmechanismus funktionieren, wenn die organisatorischen Bedingungen Statusberichterstattung erfordern. Die Form bleibt erhalten. Die Funktion wird ersetzt. Die Metriken sehen gut aus. Der Wert ist weg.
Führe die Checksum für dein Daily Scrum durch:
- Wann hat zuletzt jemand im Daily einen Blocker genannt, der von einem anderen Teammitglied im gleichen Meeting gelöst wurde?
- Kann jedes Teammitglied das aktuelle Sprint-Ziel nennen, ohne nachzuschauen?
- Wie viele Minuten wurden in den letzten fünf Daily Scrums mit individuellem Status versus kollektiver Planung verbracht?
Die Antworten zeigen dir, ob du ein Daily Scrum durchführst oder eines aufführst.
Im Artikel verwendete Glossarbegriffe
- Daily Standup – Das tägliche Scrum-Event für das Entwicklungsteam, um den Fortschritt in Richtung Sprint-Ziel zu überprüfen.
- Scrum Master – Die Scrum-Verantwortlichkeit für die Etablierung von Scrum und den Dienst am Team und der Organisation.
- Product Owner – Die Scrum-Verantwortlichkeit für die Maximierung des Produktwerts.
- Retrospektive – Eine Scrum-Zeremonie zur Überprüfung des Sprints und Identifizierung von Verbesserungen.
- Sprint – Ein Scrum-Event mit festem Zeitraum, in dem ein nutzbarer Produktzuwachs erstellt wird.
Kein Buzzword-Bingo. Nur echtes Agile.
Direkt in dein Postfach. Kein Spam.