Daily Scrum für Entwickler

Du kennst das: Du bist gerade im Flow, hast den ersten Kaffee getrunken und eine komplexe Logik-Kette im Kopf. Dann kommt die Kalender-Benachrichtigung: „Daily Stand-up in 5 Minuten“.

Du trottest zum Board (oder in den Zoom-Call), schaltest dein Gehirn auf Standby und wartest, bis du dein obligatorisches Sätzchen aufsagen darfst. Es fühlt sich an wie eine morgendliche Beichte beim Pfarrer (Scrum Master) oder ein Rechtfertigungsbericht beim Chef (Product Owner).

Hand aufs Herz: Wenn dein Daily so abläuft, ist es Zeitverschwendung.

Aber hier ist die gute Nachricht: Laut Scrum Guide ist das Daily Scrum explizit für die Developer gedacht. Es ist nicht dazu da, das Management zu beruhigen. Es ist dein Werkzeug, um den restlichen Tag weniger genervt zu sein.

In diesem Guide zeig ich dir, wie du das Daily vom Agile-Theater zum taktischen Briefing umbaust.

Das Problem: „Gestern habe ich Tickets geschoben“

Der klassische Fehler im Daily ist das Status-Reporting. Jeder rattert seine drei Fragen herunter: Was habe ich gestern gemacht? Was mache ich heute? Habe ich Blocker?
Das Problem dabei? Niemand hört zu. Während Gunnar über das Refactoring der API redet, überlegt Petra schon, wie sie ihr eigenes Update formuliert. Martin Fowler nennt das den „Reporting to the Leader“-Smell. Wenn alle zum Scrum Master schauen, während sie reden, ist es kein Team-Meeting, sondern ein Kontroll-Event.

Ein Daily ist kein Statusbericht. Wenn der PO wissen will, wie weit ein Ticket ist, soll er aufs Board schauen. Das Daily ist dazu da, um zu planen, wie ihr als Team heute den nächsten Schritt macht.

Die 3 Fragen neu interpretiert: Fokus auf Blocker

Der Scrum Guide ist hier eigentlich sehr offen: Er schreibt die drei Fragen gar nicht mehr zwingend vor. Er sagt nur: „The Developers can select whatever structure and techniques they want.“

Wenn ihr bei den drei Fragen bleiben wollt, dann dreht den Fokus um. Hört auf, über erledigte Kleinstaufgaben zu reden („Ich habe E-Mails gelesen“). Konzentriert euch auf das, was zählt:

• Gestern: „Was habe ich beigetragen, damit wir dem Sprint-Ziel nähergekommen sind?“
• Heute: „Was werde ich heute tun, um das Ziel zu erreichen?“
• Blocker: „Wo hänge ich fest oder wo gefährden wir das Ziel?“

Pro-Tipp: Fangt mit den Blockern an. Wenn jemand blockiert ist, hat das höchste Priorität. Ein Team, das im Daily keine Blocker nennt, lügt entweder oder arbeitet an zu einfachen Aufgaben.

Walk the Board: Warum Tickets wichtiger sind als Personen

Hier kommt einer der stärksten Hacks von Jason Yip und Martin Fowler: Walk the Board. Ich halte das für die deutlich bessere Alternative zu den klassischen Daily Fragen. Mein Tipp ist klar: Einfach mal ausprobieren - was soll schon schief gehen?

Ich habe mit der Umstellung auf Walk the board im Team sehr gute Erfahrungen gemacht. Wir sprechen - ganz natürlich - über unsere Arbeit. Die Identifikation mit Stories und Tasks ist enorm gestiegen. Das Verständnis, dass es darum geht gemeinsam Arbeit fertig zu stellen ist enorm gestiegen.

Wenn du willst, hör auch gerne meine Podcast-Folge zu dem Thema an.

Und so läuft "Walk the board" ab.

Statt dass Personen nacheinander reden (Round Robin), geht ihr das Board von rechts nach links durch. Wir fangen bei den Tickets an, die fast „Done“ sind.

Warum rechts nach links? Weil es wichtiger ist, Dinge abzuschließen (Stop Starting, Start Finishing), als neue Arbeit anzufangen.

Der Fokus: Wir fragen: „Was braucht dieses Ticket noch, um heute in 'Done' zu wandern?“

Das verändert die Psychologie massiv. Wir reden nicht mehr über die Auslastung von Entwickler Klaus, sondern über den Fortschritt des Produkts. Wir fokussieren uns auf den „Baton“ (das Ticket), nicht auf den „Runner“ (den Entwickler).

Die 15-Minuten-Regel knallhart durchziehen

Warum 15 Minuten? Weil Context Switching teuer ist. Je länger das Meeting dauert, desto länger brauchst du danach, um wieder in den Code-Tunnel zu kommen.

Wie du das Daily kurz hältst:

• Stehen bleiben: Der Name „Stand-up“ ist Programm. Wer sitzt, wird gemütlich. Wer steht, will das Meeting beenden.
• Pünktlichkeit: Fangt zur exakt gleichen Zeit an. Wartet nicht auf Nachzügler. Fowler schlägt vor: „Last Arrival Speaks First“ – wer zu spät kommt, moderiert. Das heilt Unpünktlichkeit meistens sehr schnell.
• Kein Socializing: Das Daily ist kein Kaffeeklatsch. Wer über das Wochenende reden will, macht das davor oder danach.

After-Scrum: Wo die eigentliche Technik besprochen wird

Der größte Zeitfresser im Daily sind technische Detail-Diskussionen. Zwei Entwickler fangen an, über die Vor- und Nachteile von zwei Library-Versionen zu debattieren, während die anderen fünf gelangweilt Löcher in die Luft starren.

Die Lösung: Das „After-Scrum“ (oder der Parking Lot). Sobald eine Diskussion tiefer geht als eine Minute, schneidet der Facilitator (oder jeder andere im Team) das Thema ab: „Das klingt wichtig, aber es betrifft nur euch beide. Packen wir es ins After-Scrum.“

Nach den 15 Minuten ist das offizielle Daily vorbei. Wer gehen will, geht coden. Wer für die technische Diskussion gebraucht wird, bleibt da. Das respektiert die Zeit aller Beteiligten und erlaubt trotzdem den notwendigen Deep Dive.

Moderations-Hacks für genervte Devs (Die „No Bullshit“ Toolbox)

Du musst kein Scrum Master sein, um ein schlechtes Daily zu fixen. Als Developer hast du das größte Interesse daran, dass das Meeting schnell vorbei ist. Hier sind konkrete Hacks aus der Praxis von Martin Fowler und Jason Yip, die du morgen ausprobieren kannst:

1. Die „Two Hand Rule“ (Gegen Labertaschen)
Wenn ein Kollege sich im Detail-Dschungel verliert oder eine Diskussion ausartet, hebt ein Teammitglied eine Hand. Sobald ein zweites Teammitglied ebenfalls die Hand hebt, muss die Diskussion sofort gestoppt und ins After-Scrum verschoben werden.
Warum das inklusiv ist: Es ist ein lautloses Signal. Niemand muss den anderen unhöflich unterbrechen, und die Gruppe entscheidet kollektiv, wann es „genug“ ist.

2. Der „Talking Token“ (Dev-Edition)
Nur wer den Gegenstand hat, darf reden. Aber statt einem langweiligen Ball nutzt ihr etwas aus eurem Tech-Alltag: Eine alte mechanische Tastatur, eine kaputte Festplatte oder – klassisch – eine Gummiente.
Der Hack: Wer den Token hat, bestimmt, wer ihn als nächstes bekommt (Pass the Token). Das zwingt die Leute, aufzupassen, weil sie jederzeit „gepasst“ bekommen könnten.

3. ELMO: „Enough, Let’s Move On“
ELMO ist das Akronym für „Genug, lass uns weitermachen“. Wenn eine Diskussion im Kreis läuft, ruft jemand einfach „ELMO“.
Warum das funktioniert: Es ist ein etablierter Code. Es ist weniger persönlich als zu sagen „Du redest zu viel“. Es ist ein technischer Terminus für: „Wir verschwenden gerade Ressourcen.“

4. Die „Last Arrival Speaks First“-Regel
Wer als Letzter zum (virtuellen) Meetingraum kommt, fängt an.
Der Effekt: Es heilt chronische Unpünktlichkeit ohne erhobenen Zeigefinger. Wer nicht moderieren will, sorgt dafür, dass er pünktlich ist.

5. Der „Visible Timer“
Stellt ein Tablet oder einen Monitor mit einem riesigen 15-Minuten-Countdown auf.
Der Hack: Der Timer ist der „Bösewicht“, nicht der Moderator. Wenn die Zeit abläuft und ihr seid nicht fertig, bricht das Meeting ab. Punkt. Das schärft das Bewusstsein für präzise Updates enorm.

6. Das „Parking Lot“ Board
Hängt ein einfaches Blatt Papier neben das Board (oder nutzt einen Bereich im Miro/Mural). Sobald ein technisches Thema aufkommt, das zu tief geht, schreibt es jemand kurz auf das Parking Lot.
Der Vorteil: Der Sprecher fühlt sich gehört und ernst genommen („Wir notieren das“), aber der Flow des Dailys wird nicht unterbrochen. Nach dem Daily wird geschaut: Wer muss für welches Thema vom Parkplatz wirklich dableiben?

7. Die „Roman Voting“-Methode für schnelle Entscheidungen
Wenn im Daily kurz eine Entscheidung getroffen werden muss (z.B. „Machen wir das After-Scrum heute direkt danach?“): Daumen hoch (Ja), Daumen zur Seite (Egal), Daumen runter (Nein).
Warum das gut ist: Es beendet „Ja, aber“-Diskussionen in 3 Sekunden. Das Ergebnis ist sofort sichtbar, ohne dass jeder einzeln seine Meinung referieren muss.

Fazit: Das Daily gehört euch

Das Daily Scrum ist kein notwendiges Übel, das man „übersteht“. Es ist die tägliche Synchronisation einer Spezialeinheit. Wenn es euch nichts bringt, ändert das Format. Ihr seid die Developer – ihr entscheidet, wie ihr arbeitet.

Hört auf, Statusberichte zu liefern. Fangt an, euren Tag zu planen.

Schau als nächstes, was du noch im Entwickler Guide Agile für Entwickler für dich findest.