"The Daily Standup Theater"

Jeden Morgen, in Büros und auf Videocalls rund um die Welt, versammeln sich Teams für fünfzehn Minuten, um drei Fragen zu beantworten. Die meisten führen die Bewegungen aus. Manche wissen es. Fast niemand spricht darüber.

---

Der Hook: Das Meeting, das niemand abgesagt hat

Das Daily Standup ist die am weitesten verbreitete Scrum-Zeremonie. Es ist auch die, die am universellsten falsch durchgeführt wird. In zwanzig Jahren Enterprise-Agile-Arbeit habe ich Hunderte davon besucht. Die wirklich effektiven kann ich an zwei Händen abzählen.

Das ist keine Übertreibung. Es ist eine Diagnose.

Das Daily Scrum – um seinen korrekten Namen aus dem Scrum Guide zu verwenden – wurde als Planungsevent konzipiert. Fünfzehn Minuten, für die Developers, um den Fortschritt zum Sprint Goal zu inspizieren und den Sprint Backlog für die nächsten vierundzwanzig Stunden anzupassen. Es ist kein Statusbericht. Es ist kein Fortschritts-Update für den Scrum Master. Es ist kein Management-Briefing. Es ist ein Team-Planungsevent.

Was es in den meisten Organisationen geworden ist: ein Statusmeeting im Stehen.

---

Die Realität: Drei Akte des täglichen Theaters

Akt Eins: Die Rezitation

Die Szene ist vertraut. Neun Personen in einem Videocall oder stehen unbeholfen vor einem Board. Der Scrum Master – oder manchmal ein selbsternannter Moderator, oder manchmal wer zuerst spricht – leitet an. Einer nach dem anderen beantwortet jedes Teammitglied die drei Fragen:

• Was habe ich gestern gemacht?
• Was werde ich heute machen?
• Gibt es Blocker?

Jede Person schaut auf ihr Jira Board, während sie spricht. Jede Person berichtet dem Raum im Allgemeinen – oder genauer gesagt, dem Scrum Master, der nickt und gelegentlich tippt. Niemand hört dem anderen zu. Sie warten auf ihre Runde. Wenn die letzte Person fertig ist, sagt alle „danke” und gehen. Das Ganze dauert zweiundzwanzig Minuten, weil ein Entwickler auf ein technisches Problem im Detail eingeht, das nur für zwei der neun Anwesenden relevant ist.

Das ist kein Daily Scrum. Das ist Anwesenheitskontrolle.

Akt Zwei: Das Manager-Briefing

Eine Variante des obigen, mit einem wesentlichen Unterschied: der Manager ist anwesend. Nicht weil der Scrum Guide das empfiehlt – tut er nicht. Sondern weil der Manager wissen möchte, was passiert, und das Daily Standup der effizienteste Ort ist, das herauszufinden.

Der Effekt auf das Teamverhalten ist sofort und konsistent. Menschen berichten sorgfältiger. Blocker, die das Team schlecht dastehen lassen könnten, werden in positiverer Sprache beschrieben. Fortschritte werden optimistisch gerahmt. Das ehrliche „Ich stecke fest und weiß nicht warum” wird zu „Ich arbeite mich durch etwas Komplexes, sollte morgen ein Update haben.”

Der Manager bekommt ein tägliches Briefing. Das Team verliert das einzige Forum, in dem eine ehrliche Einschätzung ihrer Situation stattfinden sollte.

Wenn dein Manager an deinem Daily Standup teilnimmt: Frag warum. Wenn die Antwort lautet „um informiert zu bleiben” oder „um bei Blockern zu helfen” – das sind Warnsignale, keine Beruhigungen. Ein Manager, der an Daily Standups teilnehmen muss, um informiert zu bleiben, hat ein Vertrauensproblem. Ein Manager, der teilnimmt, um bei Blockern zu helfen, macht den Job des Scrum Masters, was eine andere Frage aufwirft.

Akt Drei: Der Blocker, der nie gelöst wird

Der tragischste Akt des Daily Theaters. Jemand bringt einen Blocker vor. Der Scrum Master notiert ihn. Das Team geht weiter. Am nächsten Tag bringt dieselbe Person denselben Blocker vor. Der Scrum Master notiert ihn erneut. Das geht eine Woche lang so. Manchmal zwei. Der Blocker wird schließlich gelöst – entweder indem das Team darum herumarbeitet, indem jemand außerhalb des Teams ihn bemerkt und behebt, oder indem der Sprint endet und das Thema weitergetragen wird.

Das Daily Standup hat den Blocker jeden Tag identifiziert. Es hat nichts dazu beigetragen, ihn zu lösen.

Das ist die grundlegende Verwirrung im Kern der meisten Daily Standups: sie sind zu Reporting-Mechanismen statt zu Koordinationsmechanismen geworden. Zu berichten, dass ein Problem existiert, ist nicht dasselbe wie es zu lösen. Das Daily Scrum wurde dafür konzipiert, Handlungen auszulösen – dem Team die Information zu geben, die es braucht, um seinen Plan für die nächsten vierundzwanzig Stunden anzupassen. Wenn es zu einem Forum für das Berichten von Status ohne das Auslösen von Anpassungen wird, hat es seinen Kernzweck verfehlt.

---

Der Checksum: Was der Scrum Guide tatsächlich sagt

Der Scrum Guide 2020 beschreibt das Daily Scrum in klaren Worten. Einige erwähnenswerte Punkte:

Was der Scrum Guide sagt	Was die meisten Teams tun
15-Minuten-Timebox	Läuft regelmäßig 20-30 Minuten
Für die Developers	Besucht von Scrum Master, Manager, manchmal Stakeholdern
Fortschritt zum Sprint Goal inspizieren	Über individuellen Aufgabenstatus berichten
Sprint Backlog bei Bedarf anpassen	Keine Backlog-Änderungen während oder nach dem Standup
Drei Fragen sind ein mögliches Format, nicht erforderlich	Drei Fragen als obligatorisches Ritual behandelt
Fördert Selbstmanagement	Verstärkt das Berichten an den Scrum Master

Dieser letzte Punkt im Scrum Guide ist betont hervorhebenswert: die drei Fragen – was habe ich gestern gemacht, was werde ich heute machen, gibt es Blocker – werden als ein mögliches Format beschrieben, nicht als Anforderung. Der Scrum Guide stellt ausdrücklich fest, dass Developers jede Struktur und Technik auswählen können, die sie möchten, solange ihr Daily Scrum sich auf den Fortschritt zum Sprint Goal konzentriert und einen umsetzbaren Plan produziert.

Die meisten Teams wissen das nicht. Sie behandeln die drei Fragen als Scrum-Gesetz. Die drei Fragen sind die Zeremonie geworden. Das Sprint Goal – darum geht es eigentlich – ist häufig ein Nachgedanke.

„Das Daily Standup sollte die nützlichsten fünfzehn Minuten im Tag eines Entwicklers sein. In den meisten Organisationen ist es die vorhersehbarste Verschwendung davon.” Markus – agile-checksum.com

---

Praxisbeispiele: Fallstudien aus der Praxis

Das Standup mit zwanzig Personen

Eine große Telekommunikationsorganisation hatte ein tägliches Standup für ihr Produktprogramm. Dreiundzwanzig Personen nahmen teil. Jede beantwortete die drei Fragen. Durchschnittliche Dauer: fünfundvierzig Minuten. Als ich das Team fragte, was ihr Sprint Goal sei, konnten sieben der dreiundzwanzig richtig antworten. Die anderen sechzehn gaben mir eine Beschreibung ihrer individuellen Aufgaben.

Das Standup war organisch von einem ursprünglichen Team von acht zu einem programmweiten Koordinationsmeeting über achtzehn Monate gewachsen. Niemand hatte eine bewusste Entscheidung getroffen, es zu erweitern. Es war einfach gewachsen, weil es einfacher ist, Menschen zu einem bestehenden Meeting hinzuzufügen als ein neues zu erstellen. Jede Ergänzung hatte das Meeting etwas weniger nützlich und etwas länger gemacht. Niemand hatte jemandem die Einladung entzogen, weil das unangenehm gewesen wäre.

Als ich empfahl, es auf das Kernteam von acht zu reduzieren und einen separaten, optionalen Programm-Sync für Abhängigkeitsmanagement zu erstellen, war die Antwort des Senior Managements: „Aber wie werden wir dann wissen, was alle machen?” Diese Frage – und die Annahme dahinter – war das eigentliche Problem.

Das Standup ohne Sprint Goal

Ein Produktteam, mit dem ich arbeitete, hatte ein Daily Standup, das effizient lief, innerhalb von fünfzehn Minuten blieb und echte Konversation statt Rezitation beinhaltete. Nach den meisten beobachtbaren Maßstäben war es ein gutes Standup. Es gab ein Problem: das Team hatte kein Sprint Goal. Jeder Sprint war eine Sammlung nicht zusammenhängender Backlog-Items. Es gab kein einzelnes Ziel, zu dem Fortschritt inspiziert werden konnte.

Ohne Sprint Goal verliert das Daily Scrum seinen primären Zweck. Du kannst keinen Fortschritt zu einem Ziel inspizieren, das nicht existiert. Das Team koordinierte ihre individuellen Aufgaben – das ist nicht nichts – aber sie taten nicht, wofür das Daily Scrum konzipiert wurde. Sie hielten ein gut geführtes Meeting über die falsche Sache ab.

Der Blocker, der drei Sprints dauerte

Ein Entwicklungsteam hatte eine Abhängigkeit von einer externen API, die noch nicht verfügbar war. Das wurde als Blocker im Daily Standup gemeldet. Jeden Tag für elf Wochen. Der Scrum Master notierte es. Der Product Owner war sich bewusst. Das externe Team, das für die API verantwortlich war, war sich bewusst. Niemand mit der Autorität, die Abhängigkeit zu eskalieren und eine Lösung zu erzwingen, nahm am Standup teil oder las das Impediment-Log.

Der Blocker wurde schließlich gelöst, als ein Senior Developer ihn beiläufig in einem Flurgespräch mit einem Director erwähnte. Der Director machte ein Telefonat. Die API war innerhalb einer Woche verfügbar.

Elf Wochen täglicher Standup-Reports. Ein Flurgespräch. Die Lektion ist nicht, dass Flurgespräche effektiver sind als Standups. Die Lektion ist, dass einen Blocker zu identifizieren nicht dasselbe ist wie einen Plan zu haben, ihn zu lösen – und das Daily Standup, wie praktiziert, hatte beides verwechselt.

---

Wie ein echtes Daily Scrum aussieht

In den Teams, in denen ich das Daily Scrum wie beabsichtigt funktionieren sah, hat es mehrere konsistente Eigenschaften.

• Es beginnt mit dem Sprint Goal – jemand liest es laut vor, oder es ist für alle sichtbar. Das Gespräch beginnt mit „sind wir auf Kurs, das zu erreichen?” anstatt „was hat gestern jeder gemacht?”
• Es bringt echte Probleme ans Licht – weil das Team einander genug vertraut, um „ich bin blockiert und brauche Hilfe” zu sagen anstatt „ich arbeite mich durch etwas Komplexes.”
• Es endet mit einem Plan, keinem Bericht – das Team verlässt es wissend, wer was für die nächsten vierundzwanzig Stunden macht, und etwaige Backlog-Anpassungen wurden vereinbart.
• Blocker lösen sofortige Aktion aus – keine Notiz im Impediment-Log. Jemand besitzt die Lösung bevor das Standup endet.
• Manager sind nicht anwesend – oder wenn sie es sind, sind sie dort zum Beobachten und Helfen, nicht um ein Briefing zu erhalten.

Ein einfaches Experiment: Beginne beim nächsten Standup damit, das Sprint Goal laut vorzulesen und „sind wir auf Kurs?” zu fragen. Sieh, was passiert. Wenn das Team selbstbewusst und spezifisch antworten kann, funktioniert dein Standup wahrscheinlich. Wenn Menschen unsicher wirken, ihre Boards prüfen oder vage Antworten geben – hast du das Problem gefunden. Das Sprint Goal ist der Punkt. Alles andere ist Kontext.

---

Das Fazit: Den Zweck reparieren, nicht das Format

Die meisten Versuche, defekte Daily Standups zu reparieren, konzentrieren sich auf das Format. Die drei Fragen ändern. Stattdessen das Board ablaufen. Es asynchron durchführen. Im Kreis stehen. Ein Redeobjekt verwenden. Diese Interventionen helfen gelegentlich. Sie adressieren das zugrundeliegende Problem nicht.

Das zugrundeliegende Problem ist, in fast jedem Fall, eines von zwei Dingen: entweder hat das Team kein klares Sprint Goal, an dem es sich orientieren kann, oder das Standup ist zu einem Reporting-Mechanismus für Personen außerhalb des Teams geworden, anstatt zu einem Koordinationsmechanismus für das Team selbst.

Das Sprint-Goal-Problem lösen und das Standup wird zweckvoll. Das Audience-Problem lösen und das Standup wird ehrlich. Beides lösen und du hast vielleicht – vielleicht – ein Daily Scrum, das dem ähnelt, was der Scrum Guide beschreibt.

Führe den Checksum für dein Daily Standup durch:

1. Kann jede Person im Standup das Sprint Goal aus dem Gedächtnis nennen, jetzt gerade, ohne nachzuschlagen?
2. Wann hat das Standup das letzte Mal zu einer tatsächlichen Änderung des Sprint Backlogs geführt?
3. Würde sich das Team im Standup anders verhalten, wenn der Manager nicht anwesend wäre?

Wenn die Antwort auf Frage drei ja lautet – hast du kein Daily-Scrum-Problem. Du hast ein Psychological-Safety-Problem. Und kein Standup-Format wird das beheben.

„Das Daily Standup ist ein Spiegel. Was du darin siehst, ist eine Reflektion der tatsächlichen Beziehung deines Teams mit seiner Arbeit, seinen Zielen und einander. Die meisten Teams mögen nicht, was sie sehen. Also schauen sie stattdessen auf das Board.” Markus – agile-checksum.com

---

In diesem Artikel verwendete Glossarbegriffe

• Daily Standup – Ein 15-minütiges tägliches Scrum-Event für die Developers, um den Fortschritt zu inspizieren und den Sprint Backlog anzupassen.
• Sprint – Eine feste Timebox von 1-4 Wochen, in der ein Scrum-Team ein potenziell auslieferbares Increment liefert.
• Scrum Master – Die Scrum-Verantwortlichkeit, die dafür zuständig ist, Scrum zu etablieren und dem Team zu dienen.
• Psychological Safety – Die gemeinsame Überzeugung, dass es sicher ist, zwischenmenschliche Risiken innerhalb eines Teams einzugehen.
• Backlog – Eine geordnete Liste von Arbeitselementen, die alles darstellt, woran ein Team arbeiten könnte.