Alternativen zum Daily Standup: Belege und Formulierungen

Jemand in deinem Team hat die Nachricht schon getippt. Irgendetwas in der Nähe von „Ich glaube, das Daily Standup funktioniert für uns nicht.“ Dann ein Blick darauf, ein kurzer Gedanke daran, wie sie ankommen würde, löschen, und rein in den Call.

Dieses Löschen ist das eigentliche Thema dieses Textes. Die Forschung zu Standups ist nicht schwer zu finden, und das meiste davon zeigt in dieselbe Richtung. Schwer ist der Satz. Du versuchst, etwas zu sagen, das drei verschiedene soziale Risiken auf einmal trägt, und alle drei hängen an dir persönlich.

Risiko eins: Du klingst faul. Jede Bitte, ein Meeting zu streichen, liest sich erst einmal wie eine Bitte, weniger beobachtet zu werden.

Risiko zwei: Du klingst, als wärst du kein Teamplayer. Das Standup gilt als das, was alle auf demselben Stand hält. Einwände dagegen klingen wie Einwände gegen den gemeinsamen Stand.

Risiko drei: Du greifst eine Person an, keinen Prozess. Irgendjemandem gehört dieses Meeting. Einem Scrum Master, einem Manager oder der Person, die es vor zwei Jahren eingeführt hat. Sie wird Kritik am Ritual als Kritik an ihrem Urteil hören, denn in den meisten Räumen ist sie genau das.

Also sagen die Leute nichts, und das Meeting läuft weiter, getragen allein davon, dass niemand die Worte gefunden hat.

Die gute Nachricht: Die Worte existieren, und sie sind nicht kompliziert. Sie müssen nur in einer bestimmten Reihenfolge zusammengesetzt werden, und die Reihenfolge zählt mehr als die Belege.

Der Dreh, mit dem du das Argument gewinnst

Argumentiere nicht, dass das Standup Zeitverschwendung ist. Dieses Argument verliert, jedes Mal, aus den drei Gründen oben.

Argumentiere stattdessen, dass die Version, die euer Team fährt, nicht das Meeting ist, das es sein soll, und biete ein umkehrbares Experiment an, um das zu beheben.

Der Scrum Guide steht dabei auf deiner Seite, und das ist der Teil, den die meisten nie nachlesen. Der Guide von 2020¹ definiert das Daily Scrum als einen 15-minütigen Termin für die Entwickler des Scrum-Teams, um den Fortschritt Richtung Sprintziel zu inspizieren und den Plan anzupassen. Er ist nicht als Bericht an einen Manager definiert. Die Revision von 2020 hat außerdem die drei vorgeschriebenen Fragen entfernt, die die meisten Teams immer noch jeden Morgen aufsagen.¹

Wenn euer Standup als Kreis läuft, in dem alle der ranghöchsten Person im Raum Gestern und Heute berichten, verteidigst du nicht Scrum, indem du es behältst. Du betreibst etwas, das das Regelwerk längst gestrichen hat, und das kannst du laut sagen, ohne irgendjemandem irgendetwas vorzuwerfen.

Das ist der ganze Zug. Du verlangst nicht weniger Verantwortlichkeit. Du verlangst, das Meeting so zu führen, wie das Framework es beschreibt, und zu testen, ob ein günstigeres Format mithält.

Teil 1: Die Gründe, die einer Prüfung standhalten

Ich habe viele der Zahlen gestrichen, die zu diesem Thema kursieren. Am Ende steht eine Anmerkung dazu, welche und warum. Was folgt, ist das, was ich einem skeptischen Manager vorlegen würde.

1. Es ist zu einem Statusbericht nach oben geworden, und das Framework sagt, dass es das nicht sein soll. Die am besten dokumentierte Fehlform. Die Grounded-Theory-Studie zu Daily Stand-ups von Stray, Sjøberg und Dingsøyr fand, dass die Teilnehmenden sie für Informationsaustausch und gemeinsames Problemlösen schätzten und negativ reagierten, wenn das Meeting zum Statusbericht an einen Manager wurde oder zu häufig und zu lang lief.² Derselbe Befund taucht in der Praxisliteratur derselben Forschungsgruppe auf.⁴

2. Die drei Fragen erzeugen Erzählung statt Koordination. „Gestern habe ich am Ticket gearbeitet, heute mache ich am Ticket weiter.“ Niemand fragt nach. Nichts ändert sich dadurch. Das Format fördert eine Aufführung von Aktivität statt einer Inspektion des Fortschritts Richtung Ziel, und genau deshalb hat der Guide von 2020 die Fragen gestrichen.¹

3. Senior-Entwickler und große Teams haben am wenigsten davon. Stray und Kollegen befragten professionelle Entwickler und fanden Bewertungen, die sich insgesamt um neutral gruppierten, wobei Junior-Entwickler positiver waren und Senior-Entwickler sowie Mitglieder größerer Teams eher wenig Wert darin sahen.³ Wenn deine erfahrensten Leute die am wenigsten beteiligten im Raum sind, ist das ein Signal über das Format, nicht über sie.

4. Es zerschneidet den Vormittag. Paul Grahams Argument von 2009¹³ gilt immer noch. Menschen, die Dinge bauen, brauchen lange ununterbrochene Blöcke, und ein einzelnes Meeting mitten am Vormittag kann den ganzen Vormittag ruinieren, weil es ihn in zwei Stücke schneidet, die beide zu klein für harte Arbeit sind. Ein Standup um 10:30 ist das kanonische Beispiel. Dazu kommen die Kosten der Erwartung. In den 45 Minuten davor fängt niemand mehr etwas Tiefes an.

5. Der Wechsel zwischen Aufgaben verschlechtert die Arbeit auf beiden Seiten des Meetings. Sophie Leroys Forschung hat den Begriff der Attention Residue eingeführt: Wenn du von einer Aufgabe zur nächsten wechselst, bleibt ein Teil deiner Aufmerksamkeit bei der ersten hängen, und deine Leistung bei der zweiten leidet.⁵ Ein Standup erzwingt diesen Wechsel zweimal pro Person, einmal rein und einmal raus.

6. Zurück in die Arbeit zu finden kostet echte Zeit. Gloria Marks Forschung zu Unterbrechungen ist die Quelle der viel zitierten Zahl von rund 23 Minuten, bis man zu einer unterbrochenen Aufgabe zurückfindet, und ihre Arbeit mit Gudith und Klocke fand außerdem, dass Menschen Unterbrechungen durch schnelleres Arbeiten kompensieren, um den Preis von mehr Stress, Frust und gefühlter Arbeitslast.⁶ Zitiere diese Zahl mit Vorsicht. Sie ist die am meisten missbrauchte Zahl der ganzen Produktivitätsdebatte, und ein Manager, der ihre Zerlegung schon gesehen hat, wird sie gegen dich verwenden.

7. Blocker werden benannt, aber nicht gelöst. Achte in deinem eigenen Team darauf. Jemand sagt, er hängt fest, alle nicken, und die eigentliche Lösung passiert vierzig Minuten später in einer Direktnachricht zwischen zwei Leuten. Wenn das das Muster ist, hat das Meeting den Blocker nicht gelöst. Es hat nur das Gespräch terminiert, das ihn gelöst hat.

8. Meetinglast baut sich physiologisch auf. Microsofts Human Factors Lab hat Teilnehmende in direkt aufeinanderfolgenden Meetings per EEG gemessen und fand Stressmarker, die sich über die Sequenz hinweg aufbauen, während kurze Pausen diesen Aufbau reduzieren.⁸ Steven Rogelbergs Meetingforschung dokumentiert dasselbe von der Umfrageseite her, zusammen mit der Erholungszeit, die Menschen nach einem schlechten Meeting mit Dekomprimieren verbringen und die auf die Länge des Meetings noch obendrauf kommt.⁷

9. Es passt nicht zu verteilten Teams. Irgendjemand sitzt immer zu einer schlechten Uhrzeit drin. GitLabs All-Remote-Handbuch¹⁴ ist das vollständigste öffentliche Argument dafür, Status stattdessen asynchron zu handhaben, und es ist gerade deshalb eine nützliche Referenz, weil es von einem Unternehmen kommt, das so im großen Maßstab arbeitet, und nicht aus einem Blog.

10. Ein täglicher Takt verlangt einen täglichen Preis, ob es etwas zu koordinieren gibt oder nicht. In Teams, deren Arbeit lose gekoppelt ist, ist der echte Koordinationsbedarf punktuell. Mit dem festen Meeting zahlst du an jedem ruhigen Tag zu viel.

Teil 2: Die Gegenbelege, die du selbst mitbringen solltest

Geh mit dem fertigen Fall gegen dich selbst ins Gespräch. Es ist der schnellste Weg, ernst genommen zu werden, und es erspart deinem Manager das Gefühl, das Meeting allein verteidigen zu müssen.

Gut geführte Standups leisten drei Dinge, die schwer zu ersetzen sind.

Sie machen Blocker früh sichtbar. Ein Problem, das um 09:30 auf den Tisch kommt und sonst einen ganzen Tag gefressen hätte, ist die fünfzehn Minuten allein schon wert. Das ist die Funktion, die dein Ersatz unbedingt abdecken muss.

Sie bauen ein gemeinsames Bild davon, wer woran arbeitet, was doppelte und widersprüchliche Arbeit reduziert. Stray und Dingsøyr dokumentieren das als einen der echten Vorteile, von denen Menschen berichten.²

Sie stützen psychologische Sicherheit. Rietze und Zacher fanden einen positiven Zusammenhang zwischen Daily Stand-ups und psychologischer Sicherheit, die wiederum mit Arbeitszufriedenheit und wahrgenommener Teamleistung zusammenhing.¹⁰ Das sitzt auf Edmondsons grundlegender Arbeit auf, die psychologische Sicherheit mit Lernverhalten in Teams verbindet.⁹ Ein regelmäßiger Berührungspunkt ohne Fallhöhe tut etwas für das Vertrauen, gerade in neuen oder verteilten Teams.

Also gib den Punkt zu, wo er stimmt. Wenn dein Team klein, eng gekoppelt, jung oder drei Wochen alt ist, verdient das Standup seine Kosten wahrscheinlich, und das solltest du auch so sagen.

Teil 3: Hol dir eigene Zahlen, bevor du den Mund aufmachst

Zwei Wochen. Drei Dinge. Mach das vor dem Gespräch, denn Meinung gegen Ritual verliert, und Arithmetik gegen Ritual verliert nicht.

Miss die echte Länge, nicht die geplante. Stopp die Zeit, jeden Tag. Die meisten Teams stellen fest, dass das 15-Minuten-Meeting ein 22-Minuten-Meeting ist.

Rechne die Gehälter durch. Teilnehmerzahl mal tatsächliche Dauer in Stunden mal Arbeitstage im Jahr. Ein Team von acht bei echten 15 Minuten sind 2 Personenstunden am Tag, etwa 10 pro Woche, rund 460 Personenstunden im Jahr. Bei Vollkosten von 60 Euro pro Stunde sind das etwa 27.000 Euro, und diese Zahl ignoriert die Erholungskosten davor und danach. Nimm die Zahlen deines eigenen Teams, damit niemand über die Eingaben streiten kann.

Zähl die Blocker. Schreib zehn Arbeitstage lang jeden Blocker auf, der im Standup genannt wird, und markiere, ob er im Meeting gelöst wurde oder irgendwo anders danach. Das ist meistens die Zahl, die die Debatte beendet.

Frag das Team anonym. Eine Frage. Hilft dir das Standup bei deiner Arbeit, ja oder nein, und warum. Die Anonymität ist das, was dir die ehrliche Antwort holt, und sie bedeutet außerdem, dass du für das Team sprichst statt für dich selbst, was Risiko zwei von der Liste oben streicht.

Teil 4: Die Formulierungen

Vier Situationen, vier Skripte. Pass die Details an, behalte die Struktur, denn die Struktur macht die Arbeit.

Jedes davon folgt denselben vier Schritten. Bestätige, was dein Gegenüber wirklich braucht. Benenn die Kosten in seinen Begriffen. Schlag etwas Umkehrbares mit festem Zeitrahmen vor. Nimm die Beweislast und die Einrichtungsarbeit auf dich.

An deinen Manager, im Einzelgespräch

„Ich will die Fokuszeit des Teams schützen, ohne dass du an Sichtbarkeit verlierst, und ich habe zwei Wochen Daten dazu, wie unser Standup tatsächlich genutzt wird. Es dauert 22 Minuten, nicht 15. Das sind bei uns acht rund 675 Personenstunden im Jahr. In zehn Tagen wurden sechs Blocker angesprochen, und einer davon wurde tatsächlich im Meeting gelöst. Der Rest wurde danach in Direktnachrichten geklärt.

Ich würde das gern vier Wochen lang so fahren: schriftliche Updates bis 09:30 in einem gemeinsamen Kanal, die du lesen kannst, wann du willst, ein eigener Blocker-Kanal, in dem dich alle direkt markieren, sobald etwas feststeckt, und ein Live-Sync pro Woche. Ich messe die Zeit bis zur Lösung von Blockern und vergleiche sie mit heute. Wird sie schlechter, gehen wir zurück, und ich sage das in der Retro auch so. Ich richte alles ein.“

An deinen Scrum Master

„Ich habe den Guide von 2020 noch einmal gelesen. Er definiert das Daily Scrum als Termin für die Entwickler, und er hat die drei Fragen gestrichen. Unseres ist zu einer Update-Runde geworden, die sich an die ranghöchste Person im Raum richtet, also genau an das, was der Guide ausdrücklich verhindern will.

Könnten wir es für einen Sprint am Board entlang laufen lassen statt reihum, und die Entwickler danach fragen, ob es für sie nützlicher geworden ist?“

Beachte, was das macht. Es reicht ihnen das Framework als Autorität, nicht dich, und es macht sie zu der Person, die die Praxis wiederherstellt, statt zu der Person, die eine kaputte Version davon verteidigt.

An deine Kollegen, bevor du irgendetwas anderes tust

„Sag es mir ehrlich. Hilft dir das Standup wirklich, oder sitzt du es nur ab? Ich will das Thema ansprechen, und ich will das nur tun, wenn ich für das Team spreche und nicht nur für mich.“

Mach das zuerst. Immer. Wenn zwei Leute sagen, das Standup sei die einzige Gelegenheit, bei der sie um Hilfe bitten können, muss dein Vorschlag genau das erhalten, und jetzt weißt du das, bevor du dich öffentlich auf eine Position festgelegt hast.

In einer Retrospektive

„Ich möchte heute eine Sache inspizieren. Ich habe unser Standup zwei Wochen lang mitverfolgt. Das hier kostet es, und so viele Blocker hat es tatsächlich gelöst. Ich schlage nicht vor, es abzuschaffen. Ich frage, ob wir das Format für einen Sprint ändern und uns die Zahlen anschauen, bevor wir irgendetwas dauerhaft entscheiden.“

Als schriftlicher Vorschlag

Betreff: Experiment über vier Wochen, asynchrones Standup

Unser Daily Standup dauert derzeit 22 Minuten mit acht Leuten, das sind rund 675 Personenstunden im Jahr. In den letzten zehn Arbeitstagen wurden darin sechs Blocker angesprochen, einer davon wurde im Meeting gelöst.

Vorschlag, vier Wochen, vollständig umkehrbar:

Schriftliche Check-ins in #team-standup bis 09:30, drei Zeilen pro Person. Fortschritt Richtung Sprintziel, Fokus für heute, was blockiert ist. Blocker werden in dem Moment, in dem sie auftauchen, direkt bei der zuständigen Person markiert, statt bis zum nächsten Morgen aufgehoben zu werden. Ein Live-Sync von 30 Minuten am Montag für Planung und alles, was ein Gespräch braucht.

Ich messe die Blocker-Lösungszeit, die Cycle Time und einen kurzen Team-Puls und bringe alle drei in die Retro am [Datum] mit. Wird die Blocker-Lösungszeit schlechter, kehren wir um. Ich richte das Tooling ein und betreue den Testlauf.

Die ausdrückliche Umkehrbedingung ist die wichtigste Zeile in dieser Nachricht. Sie macht aus deinem Vorschlag einen Test statt einer Änderung, und sie ist meistens das, was dir das Ja holt.

Teil 5: Was sie dir entgegnen werden

„Ich brauche Sichtbarkeit darüber, was alle machen.“ Schriftliche Updates geben dir mehr davon als ein Meeting. Sie sind durchsuchbar, sie bleiben stehen, und du kannst sie um 07:00 oder um 19:00 lesen, statt um 09:30 in einem Raum zu sitzen.

„Blocker bleiben dann liegen.“ Das Gegenteil. Ein Blocker, der in dem Moment gepostet wird, in dem er auftaucht, bekommt schneller Aufmerksamkeit als einer, der bis zum nächsten Morgen aufgehoben wird. Genau diese Kennzahl schlage ich zum Messen vor, und sie ist die, bei der ich den Testlauf selbst abbrechen würde.

„Es sind doch nur fünfzehn Minuten.“ Es sind fünfzehn Minuten mal acht Leute, an jedem Arbeitstag, plus die Zeit, die jeder braucht, um wieder in seine Arbeit zu finden. Hier ist die Zahl fürs Jahr.

„Scrum verlangt ein Daily Scrum.“ Scrum verlangt ein Daily Scrum für die Entwickler, und der Guide von 2020 hat die drei Fragen gestrichen, die wir immer noch benutzen. Was wir machen, ist nicht das, was der Guide beschreibt.¹

„Das Team verliert den Zusammenhalt.“ Das ist ein echtes Risiko, und genau deshalb bleibt der wöchentliche Sync. Ich messe während des Testlaufs außerdem einen Team-Puls. Wenn der Zusammenhalt sinkt, sehen wir es also, statt darüber zu raten.

Teil 6: Fünf Wege, dieses Argument zu verlieren

Es so zu rahmen, als wolltest du weniger tun. Das bestätigt genau den Verdacht, mit dem dein Gegenüber ins Gespräch gekommen ist.

Das Meeting zu streichen, ohne einen Ersatz zu benennen. Das Chaos danach wird dir persönlich zugeschrieben, und zwar zu Recht.

Allein zu entscheiden. Ein Teamritual ändert sich als Teamentscheidung, oder es ist innerhalb eines Monats wieder da.

Den Testlauf und die Kennzahlen zu überspringen. Das macht aus einem überprüfbaren Vorschlag einen Meinungswettstreit gegen den Status quo, und den gewinnt der Status quo.

Die Menschen zu ignorieren, für die es funktioniert. Wenn der Junior im Team sich darauf verlässt, plane um ihn herum und sag das auch im Raum. Es kostet dich nichts, und es räumt den stärksten Einwand aus, bevor ihn jemand erhebt.

Teil 7: Was an seine Stelle tritt

	Tägliches Live-Standup	Asynchrone schriftliche Updates	Wöchentlicher Sync plus Blocker-Kanal
Zeitkosten	Hoch, wächst mit der Teamgröße	Synchron nahe null	Niedrig
Unterbrechungskosten	Hoch, täglich, mitten am Vormittag	Minimal, selbst getaktet	Niedrig, ein fester Punkt
Blocker-Tempo	Bis zu 24 Stunden Wartezeit	Sofort, wenn markiert wird	Sofort, wenn markiert wird
Dokumentation	Keine, außer jemand schreibt mit	Durchsuchbar von Haus aus	Teilweise
Über Zeitzonen hinweg	Schlecht	Gut	Passabel
Zusammenhalt	Gut, wenn gut geführt	Allein zu schwach	Gut

Sieben Optionen, jede mit dem ehrlichen Nachteil daneben.

Asynchrone schriftliche Check-ins über einen Bot. Geekbot, Standuply oder Range erinnern jede Person und posten in einen gemeinsamen Kanal.¹⁷ Funktioniert über Zeitzonen hinweg und hinterlässt eine durchsuchbare Dokumentation. Kann zu ungelesenem Status-Theater verkommen, wenn niemand auf das reagiert, was gepostet wird.

Standups zweimal pro Woche. Behält den Live-Sync, senkt die Frequenz. Leicht zu verkaufen, weil es eine kleine Änderung ist. Braucht einen Begleitkanal für alles Dringende.

Am Board entlang statt reihum. Geh die Arbeitspakete von rechts nach links durch und sprich über die Tickets statt über die Personen. Beendet die persönliche Berichtsdynamik sofort. Funktioniert nur, wenn das Board wirklich aktuell ist.

Ein eigener Blocker-Kanal. Das wertvollste einzelne Element und das billigste obendrein. Verlangt die Disziplin, wirklich zu posten, und jemanden, der den Kanal im Blick behält.

Pairing auf Zuruf. Die schnellstmögliche Lösung, ohne Publikum. Reduziert die Sichtbarkeit fürs ganze Team, braucht also eine schriftliche Spur.

Ein tiefer Sync pro Woche. Raum für die Gespräche, die in einem 15-Minuten-Meeting keinen Platz haben. Zu selten, um allein zu funktionieren.

Meetingfreie Tage. Shopifys Kalenderbereinigung von 2023 ist das meistzitierte Beispiel aus einem Konzern, berichtet wurde von Tausenden wiederkehrenden Meetings, die aus dem Firmenkalender gelöscht wurden.¹⁵ Das ist eine Fokus-Richtlinie und kein Koordinationsmechanismus, sie muss also mit einem der Punkte oben kombiniert werden.

Die Kombination, die am häufigsten funktioniert: schriftliche Updates für das tägliche Bild, ein Blocker-Kanal für alles Dringende, ein Live-Sync pro Woche für den Rest.

Teil 8: Den Testlauf so bauen, dass er die Retro überlebt

Wähl deine Erfolgskennzahlen, bevor du anfängst, und wähl welche, an die dein Manager ohnehin schon glaubt.

Lieferleistung. Eine Kennzahl im DORA-Stil, meistens Lead Time for Changes oder Deployment-Frequenz.¹² Cycle Time funktioniert, wenn ihr nicht oft deployt.

Blocker-Lösungszeit. Deine Absicherung gegen das Hauptrisiko. Das ist die Kennzahl, die das Experiment beenden können muss, und genau das laut auszusprechen ist es, was das Experiment glaubwürdig macht.

Team-Puls. Eine Frage, wöchentlich, anonym. Das entspricht der Zufriedenheitsdimension des SPACE-Frameworks, das genau deshalb existiert, weil Produktivitätsmessung mit einer einzigen Kennzahl schiefgeht.¹¹ Ohne ihn kannst du den Durchsatz steigern und dabei leise Leute verheizen, ohne es je zu merken.

Vier Wochen sind die richtige Länge. Zwei sind zu kurz, um mehr als den Neuigkeitseffekt zu sehen. Acht sind so lang, dass ein Rückzieher sich wie ein öffentliches Scheitern anfühlt, und dann verteidigen Leute den Testlauf, statt ihn ehrlich zu lesen.

Der Teil, der wirklich schwer ist

Alles oben steht jedem offen, der einen Nachmittag mit Lesen verbringt. Die meisten, die es brauchen, werden die Nachricht trotzdem nicht abschicken.

Es sind nicht die Belege, die fehlen. Was fehlt, ist eine Version des Satzes, die sagt, dass das Meeting nicht funktioniert, ohne mitschwingen zu lassen, dass die Person, die es leitet, nicht funktioniert. Und die ist deutlich schwerer zu schreiben als eine Liste von Quellenangaben. Sie wird sechsmal im Slack-Entwurfsfeld umgeschrieben und dann aufgegeben.

Diese Lücke ist der Grund, warum wir Subtext bauen. Die meisten Nachrichten, die Menschen nicht abschicken können, sind inhaltlich nicht kompliziert. Es sind Nachrichten, bei denen Rechthaben nicht reicht und die Formulierung das ganze Risiko trägt. Ein Standup-Vorschlag ist eine kleine davon. Dieselbe Form taucht auf, wenn du nach einer Gehaltserhöhung fragst, zusätzliche Aufgaben ablehnst, einem Gründer sagst, dass die Roadmap falsch ist, oder einem Freund Nein sagst.

Wenn du eine Sache mitnimmst: Schick die Nachricht mit der Umkehrbedingung darin ab. „Wird die Blocker-Lösungszeit schlechter, gehen wir zurück, und ich sage das auch so.“ Dieser eine Halbsatz räumt den Grund weg, den irgendjemand hatte, Nein zu sagen.

Eine Anmerkung zu den Zahlen, die ich weggelassen habe

Mehrere Zahlen kursieren breit zu diesem Thema, und ich konnte nicht hinter ihnen stehen, deshalb stehen sie oben nicht im Text.

Die Behauptung, 80 % der Entwickler nennten irrelevante Updates als ihren größten Standup-Frust, taucht in der Stray-Umfrage, der sie üblicherweise zugeschrieben wird, nicht auf. Die Behauptung, 80 % der Action Items aus Meetings würden nie erledigt, reist ohne Quelle. Die oft zitierte Statistik „40 % länger und 50 % mehr Fehler“, die einem aktuellen Paper im Journal of Experimental Psychology zugeschrieben wird, scheint eine verstümmelte Version von Rubinstein, Meyer und Evans aus dem Jahr 2001 zu sein, die Task-Switching im Labor gemessen hat und sich nicht ohne Weiteres auf ein Morgenmeeting übertragen lässt.¹⁸ Diverse jährliche Dollarbeträge pro Team für verschwendete Meetingzeit hängen komplett an den Annahmen dahinter, und genau deshalb rechnet Teil 3 mit den Zahlen deines eigenen Teams.

Noch eine ehrliche Lücke. Ich habe keine rigorose kontrollierte Studie gefunden, die asynchrone schriftliche Statusupdates direkt mit synchronen Statusmeetings in Bezug auf Lieferergebnisse vergleicht. GitLab, Doist und Basecamp argumentieren alle für die schriftliche Variante, und alle drei haben eine Position zu verteidigen. Wenn dein Manager nach diesem Vergleich fragt, ist die korrekte Antwort, dass es ihn offenbar noch nicht gibt, und dass dein vierwöchiger Testlauf genau der Weg ist, ihn für dein eigenes Team zu erzeugen.

Findest du, dass euer Standup seine Kosten wert ist, oder dass ich die Belege falsch lese? Sag es mir auf LinkedIn.

Samet Durgun ist Mitgründer von Subtext, einer App, die den emotionalen Ton deiner Nachrichten erkennt und sie in deinen eigenen Worten neu schreibt. Er lebt in Berlin.

Quellen

Jeder Link oben führt zur Primärquelle, wo es eine gibt.

The Scrum Guide (2020), Ken Schwaber and Jeff Sutherland, scrumguides.org. Das nützlichste einzelne Dokument für dieses Argument. Lies den Abschnitt zum Daily Scrum direkt und zitiere ihn wörtlich. Belegt, dass der Termin für die Entwickler ist, 15 Minuten dauert und dass die drei Fragen in der Revision von 2020 gestrichen wurden.
Stray, V., Sjøberg, D. I. K., and Dingsøyr, T. (2016). “The daily stand-up meeting: A grounded theory study.” Journal of Systems and Software, volume 114. Peer-reviewed. Dokumentiert sowohl den Wert (Informationsaustausch, gemeinsames Problemlösen) als auch die Fehlformen (Statusberichte an einen Manager, zu hohe Frequenz und Dauer). Schick diese Studie einem Scrum Master.
Stray, V., Moe, N. B., and Bergersen, G. R. (2017). “Are Daily Stand-up Meetings Valuable? A Survey of Developers in Software Teams.” XP 2017, Lecture Notes in Business Information Processing. Umfrage unter professionellen Entwicklern. Zu den berichteten Zahlen gehören 87 % agiler Teams mit täglichen Standups bei im Schnitt neutralen Bewertungen, Junior-Entwickler positiver, Senior-Entwickler und größere Teams weniger. Ich habe den Richtungsbefund verwendet, nicht die Prozentzahl.
Stray, V. and Moe, N. B., practitioner writing in IEEE Software on adapting daily stand-up practice. Argumentiert, dass starre Standup-Rituale an das Team angepasst statt standardmäßig befolgt werden sollten. Der genaue Titel und das Jahr sind unbestätigt, und die online kursierende Version enthält Teilnehmerzahlen, die ich nicht bestätigen konnte.
Leroy, S. (2009). “Why is it so hard to do my work? The challenge of attention residue when switching between work tasks.” Organizational Behavior and Human Decision Processes, volume 109, issue 2. Der Ursprung der Attention Residue. Starker Beleg außerhalb der Agile-Welt dafür, dass der Wechsel zwischen Aufgaben die Qualität dessen verschlechtert, was danach kommt.
Mark, G., Gudith, D., and Klocke, U. (2008). “The Cost of Interrupted Work: More Speed and Stress.” CHI 2008. Und Mark, G. (2023). Attention Span. Hanover Square Press. Quelle der Befunde zu unterbrochener Arbeit und der Zahl von rund 23 Minuten bis zur Wiederaufnahme, die überall kursiert. Die Zahl ist echt, wird aber häufig präziser zitiert, als die zugrunde liegende Forschung trägt. Zitiere also die Primärarbeit und formuliere es als „über 20 Minuten“.
Rogelberg, S. G. (2019). The Surprising Science of Meetings. Oxford University Press. Das Standardwerk zu Meeting-Verschwendung und zur Erholung nach Meetings. Ich habe den qualitativen Befund verwendet statt einer bestimmten Prozentzahl, weil die Zahlen je nach Umfrage schwanken.
Microsoft Human Factors Lab, EEG study on breaks between meetings, published via Microsoft WorkLab and the 2021 Work Trend Index. Physiologischer Beleg dafür, dass sich Stress über aufeinanderfolgende Meetings hinweg aufbaut und Pausen ihn reduzieren. Nützlich, weil es Messung ist und keine Umfrage.
Edmondson, A. (1999). “Psychological Safety and Learning Behavior in Work Teams.” Administrative Science Quarterly. Die grundlegende Zitation zu psychologischer Sicherheit. Es geht um Teams im Allgemeinen, nicht speziell um Standups, also behaupte keinen kausalen Zusammenhang, den die Arbeit nicht hergibt.
Rietze, S. and Zacher, H., research on daily stand-up meetings, psychological safety, work satisfaction and team performance perceptions, European Journal of Work and Organizational Psychology. Das stärkste veröffentlichte Argument für Standups, und genau deshalb solltest du es selbst mitbringen. Das Erscheinungsjahr ist unbestätigt. Die kursierende Version nennt ein Datum von 2025, das ich nicht unabhängig bestätigen konnte.
Forsgren, N., Storey, M.-A., Maddila, C., Zimmermann, T., Houck, B., and Butler, J. (2021). “The SPACE of Developer Productivity.” ACM Queue. Frei lesbar. Nutze die Dimension Zufriedenheit und Wohlbefinden, um zu begründen, dass du neben Lieferkennzahlen einen Team-Puls misst.
Forsgren, N., Humble, J., and Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press. Quelle der vier DORA-Lieferkennzahlen. Nutze eine davon als Durchsatzmaß, damit die Kennzahl verteidigbar ist statt für den Anlass erfunden.
Graham, P. (2009). “Maker’s Schedule, Manager’s Schedule.” paulgraham.com/makersschedule.html. Kurz, kostenlos und das überzeugendste Stück, das du einem unentschlossenen Kollegen weiterleiten kannst.
GitLab all remote handbook, about.gitlab.com/company/culture/all-remote. Eine große Organisation, die öffentlich mit asynchronen Statusupdates arbeitet. Beleg, dass das Modell im großen Maßstab funktioniert, auch wenn GitLab ein Interesse an dem Argument hat.
Shopify calendar purge, January 2023, as reported by Bloomberg, Fortune and others. Berichtet wurde von Tausenden wiederkehrenden Meetings, die aus dem Firmenkalender entfernt wurden, und einem Verbot wiederkehrender Meetings mit mehr als zwei Personen an Mittwochen. Die konkrete Zahl zurückgewonnener Stunden stammt vom Unternehmen selbst, also schreibe sie Shopify zu, statt sie als gemessene Tatsache hinzustellen.
Atlassian Agile Coach, standup guidance. Branchenleitfaden, der empfiehlt, Standups knapp zu halten und an die Bedürfnisse des Teams anzupassen, inklusive asynchroner Formate. Nützlich, weil die Quelle bei deinem Manager in Sachen Agile vermutlich schon Vertrauen genießt.
Tools: Geekbot und Standuply für asynchrone Standups in Slack und Teams, Range für Team-Check-ins. Prüfe aktuelle Preise und Produktstatus, bevor du eins davon intern empfiehlst.
Rubinstein, J. S., Meyer, D. E., and Evans, J. E. (2001). “Executive Control of Cognitive Processes in Task Switching.” Journal of Experimental Psychology: Human Perception and Performance. Der tatsächliche Ursprung der Behauptung von „bis zu 40 % der produktiven Zeit“ durch Task-Switching. Hier aufgeführt, damit du es selbst nachprüfen kannst, statt die verstümmelte Version zu wiederholen.