Daily Scrum für Entwickler

Survival-Kit für Entwickler Teil 1 von 8 Zur Übersicht

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 deine obligatorischen 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.

Die Lösung heißt Walk the Board und rückt das in den Mittelpunkt, worauf es ankommt: die Arbeit, nicht die Person.

Walk the Board: Warum Tickets wichtiger sind als Personen

Ich halte Walk the Board für die deutlich bessere Alternative zu den klassischen Daily-Fragen. Einfach mal ausprobieren. Was soll schon schief gehen?

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

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

Und so läuft es ab: Statt dass Personen nacheinander reden, geht ihr das Board von rechts nach links durch. Ihr fangt bei den Tickets an, die fast „Done“ sind.

Warum rechts nach links? Weil es wichtiger ist, Dinge abzuschließen, als neue Arbeit anzufangen. Stop starting, start finishing.

Die Frage lautet immer: „Was braucht dieses Ticket noch, um heute in 'Done' zu wandern?“ Das verändert die Psychologie massiv. Ihr redet nicht mehr über die Auslastung von Entwickler Klaus, sondern über den Fortschritt des Produkts. Der Fokus liegt auf dem Staffelstab, nicht auf dem Läufer.

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. Es spricht also nicht gegen den Scrum Guide, wenn ihr die drei klassischen Fragen weglässt.

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, zu planen, wie ihr als Team heute den nächsten Schritt macht.

Pro-Talk

Souverän bleiben, wenn das Daily von außen zum Status-Meeting gemacht wird

Wenn jemand sagt...Deine Antwort als Profi-Dev
„Ich brauche aber den Status für meinen Bericht.“„Das Board zeigt dir jederzeit den Status. Im Daily planen wir gerade, wie wir die restlichen Hürden für das Sprint-Ziel heute gemeinsam lösen.“
„Warum dauert Ticket #123 so lange?“„Guter Punkt für das After-Scrum! Lass uns das Daily erst für alle beenden, dann zeige ich dir kurz die technische Hürde im Detail.“
„Wir müssen heute auch noch über Feature X sprechen.“„Feature X ist wichtig, gehört aber ins Refinement. Lass uns jetzt den Fokus auf den heutigen Tag legen, damit wir den Kopf frei haben für den Code.“

Die drei Fragen neu interpretiert: Fokus auf Blocker

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

Wenn ihr bei den drei Fragen bleiben wollt, dreht den Fokus um. Hört auf, über erledigte Kleinstaufgaben zu reden, und konzentriert euch auf das, was zählt:

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

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

Die 15-Minuten-Regel knallhart durchziehen

Warum fünfzehn 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.

Bleibt stehen. Der Name Stand-up ist Programm: Wer sitzt, wird gemütlich, wer steht, will das Meeting beenden. Fangt zur exakt gleichen Zeit an und wartet nicht auf Nachzügler. Fowler schlägt „Last Arrival Speaks First“ vor, wer zu spät kommt, moderiert. Das heilt Unpünktlichkeit meistens schnell. Und 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 debattieren über zwei Library-Versionen, während die anderen fünf gelangweilt Löcher in die Luft starren.

Die Lösung ist das After-Scrum, auch Parking Lot genannt. Sobald eine Diskussion tiefer geht als eine Minute, schneidet jemand aus dem Team das Thema ab: „Das klingt wichtig, aber es betrifft nur euch beide. Packen wir es ins After-Scrum.“

Nach den fünfzehn 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 und erlaubt trotzdem den notwendigen Deep Dive.

Moderations-Hacks für genervte Devs

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. Sieben Hacks aus der Praxis von Martin Fowler und Jason Yip, die du morgen ausprobieren kannst.

1. Die Two Hand Rule gegen Labertaschen. Wenn sich jemand im Detail-Dschungel verliert, hebt ein Teammitglied eine Hand. Sobald ein zweites ebenfalls die Hand hebt, wird die Diskussion sofort gestoppt und ins After-Scrum verschoben. Das ist ein lautloses Signal, niemand muss unhöflich unterbrechen, und die Gruppe entscheidet gemeinsam, wann es genug ist.

2. Der Talking Token in der Dev-Edition. Nur wer den Gegenstand hat, darf reden, und wer ihn hat, bestimmt, wer ihn als nächstes bekommt. Das zwingt zum Aufpassen, weil jeder jederzeit dran sein kann.

3. ELMO steht für „Enough, Let’s Move On“. Wenn eine Diskussion im Kreis läuft, ruft jemand „ELMO“. Es ist ein etablierter Code und weniger persönlich als „Du redest zu viel“.

4. Last Arrival Speaks First. Wer als Letzter in den Raum kommt, fängt an. Heilt chronische Unpünktlichkeit ohne erhobenen Zeigefinger.

5. Der Visible Timer. Stellt ein Tablet mit einem riesigen 15-Minuten-Countdown auf. Der Timer ist der Bösewicht, nicht der Moderator. Läuft die Zeit ab, bricht das Meeting ab. Punkt.

6. Das Parking-Lot-Board. Ein Blatt Papier neben dem Board, oder ein Bereich in Miro. Sobald ein Thema zu tief geht, schreibt es jemand auf. Der Sprecher fühlt sich gehört, der Flow bleibt. Danach wird geschaut, wer für welches Thema wirklich dableiben muss.

7. Roman Voting für schnelle Entscheidungen. Daumen hoch heißt ja, Daumen zur Seite egal, Daumen runter nein. Beendet „Ja, aber“-Diskussionen in drei Sekunden, weil das Ergebnis sofort sichtbar ist.

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. Und wenn einer der sieben Hacks bei euch funktioniert hat, schreib mir das auf Mastodon. Ich nehme ihn in die Liste auf.

Falls du hier gerade nickst: genau solche Sachen nehme ich mir in NBA Kompakt vor – ein Thema pro Folge, fünf bis zehn Minuten, jede Woche. Wenn du das im Ohr statt im Feed willst: hier abonnieren.

Aktualisiert: