Die Kosten einer Feier bestehen nicht nur aus den fünfzehn Minuten im Kalender. Es sind diese fünfzehn Minuten, zuzüglich der zwanzig Minuten, die man vor der Feier benötigt, um zur Ruhe zu kommen, und der zwanzig Minuten, die man danach benötigt, um wieder in Schwung zu kommen – multipliziert mit der Anzahl aller Anwesenden.

Überlastung ist der Fehlermodus, der sich vor aller Augen verbirgt, da jede einzelne Zeremonie auf den ersten Blick harmlos wirkt. Eine viertelstündige Standup-Besprechung, eine Stunde Planung, eine Stunde Retrospektive. Wer könnte schon etwas dagegen haben? Das Problem ist, dass diese nicht einzeln auftreten. Sie häufen sich in regelmäßigen Abständen auf einem Arbeitstag, in dessen Lücken echte konzentrierte Arbeit untergebracht werden muss. Im Gegensatz zu den anderen drei Formen geht es bei der Überlastung nicht um eine festgefahrene oder ausgehöhlte Zeremonie; selbst eine vollkommen sinnvolle Zeremonie kann immer noch eine zu viel sein. Es ist die einzige Form, die Sie anhand von Zahlen diagnostizieren können.

Die Tagungssteuer – ehrlich berechnet

Rechnen Sie also nach: den gesamten Arbeitsaufwand, nicht nur das tägliche Stand-up. Ein zweiwöchiger Sprint umfasst in der Regel zwei bis vier Stunden Sprintplanung, ein bis zwei Stunden Review, ein bis zwei Stunden Retrospektive, ein bis zwei Verfeinerungssitzungen sowie ein fünfzehnminütiges tägliches Stand-up – was über zehn Tage hinweg weitere zweieinhalb Stunden ergibt. Rechnen Sie das zusammen, und Sie kommen auf fast einen ganzen Arbeitstag pro Entwickler und Sprint, noch bevor auch nur eine einzige Zeile Code geschrieben wurde. Praktiker berechnen diese Summe in Personenstunden, denn das ist die Einheit, die das Management nachvollziehen kann: Fünfzehn Minuten Standup-Meeting in einem Team von zwölf Personen sind nicht einfach fünfzehn Minuten, sondern drei Personenstunden – jeden Tag, die verloren gehen. Rechnet man dann noch den Teil hinzu, den der Kalender nie anzeigt (das Ausklinken vor jeder dieser Unterbrechungen und das Wiedereinfinden nachher), ergibt sich ein Fünftel der Arbeitswoche als konservative Schätzung – und genau diesen Mehraufwand melden Praktiker immer wieder.

the 20% line ceremonies ≈ 1 day in 5 focused work One working week: a fifth goes to ceremony before a line of code.
Zählen Sie den gesamten Arbeitsaufwand ehrlich zusammen (Planung, Nachbesprechung, Retrospektive, Verfeinerung und die tägliche Arbeit), und selbst bei einer vorsichtigen Schätzung entfällt ein Fünftel der Woche – also jeder fünfte Tag – bereits, bevor Sie überhaupt mit der eigentlichen Arbeit beginnen können.

Das ist nicht automatisch falsch. Koordination hat einen echten Wert, und drei gut investierte Personenstunden können im weiteren Verlauf weitaus mehr einsparen. Aber es handelt sich um eine Abgabe, und die berechtigte Frage bei jeder Abgabe lautet: Was erhalten Sie dafür? Ein Team, das keine getroffene Entscheidung, keine vermiedene Kollision oder kein beseitigtes Hindernis als Ergebnis einer Zeremonie vorweisen kann, zahlt diese „Steuer“ umsonst. Der Aufwand ist nur dann vertretbar, wenn der Nutzen konkret benannt werden kann.

Der Kontextwechsel ist der eigentliche Kostenfaktor

Der Kalender unterschätzt jedoch die Kosten, da das Meeting selbst der kostengünstige Teil ist. Der kostspielige Teil ist der Kontextwechsel auf beiden Seiten. Ein Entwickler, der tief in ein Problem vertieft ist, teleportiert sich nicht einfach zum Standup-Meeting und wieder zurück. Er taucht wieder auf, verliert das mentale Modell, das er aufgebaut hatte, und verbringt die erste Zeit danach damit, es wiederherzustellen. Praktiker beschreiben den morgendlichen Standup als Mittel, um den Start in den Tag einzuläuten: Die Arbeit beginnt erst wirklich, wenn es vorbei ist, sodass die gesamte Stunde vor dem Standup als verloren gilt. Die fünfzehn Minuten sind der Listenpreis; der Kontextwechsel ist die Rechnung.

A fifteen-minute standup time-box versus a meeting that overruns ≈ 15 min Time-box 15 min The meeting that overruns…
Das fünfzehnminütige Zeitfenster ist der Teil, den jeder sieht. Die Zeitüberschreitung sowie die Vor- und Nachlaufzeiten auf beiden Seiten sind der Teil, der tatsächlich den ganzen Tag kostet.

Aus diesem Grund ist es ebenso wichtig, wann eine Besprechung stattfindet, wie wie lange sie dauert. Ein Standup-Meeting am Vormittag unterbricht den Arbeitsfluss eines Entwicklers zweimal; dasselbe Standup-Meeting an einer natürlichen Grenze verursacht nur eine minimale Unterbrechung. Und dies ist das stärkste Argument dafür, den Statusbericht vollständig aus dem synchronen Zeitplan herauszunehmen: Wenn die eigentliche Aufgabe des täglichen Standups darin besteht, einen Status zu erfassen, den die Tools ohnehin bereits enthalten, beseitigt ein asynchroner Stand-up die Unterbrechung, ohne dass Informationen verloren gehen, und eine kurze Live-Synchronisierung mehrmals pro Woche gewährleistet die menschliche Koordination, die der asynchrone Ablauf nicht leisten kann. Unser Kapitel „So führen Sie ein tägliches Standup-Meeting durch“ befasst sich damit, wie Sie den Arbeitstag der Mitarbeiter unabhängig von der von Ihnen gewählten Häufigkeit schützen können.

Trittfrequenzbelastung: Die Falle der Kurzsprints

Dann gibt es noch den Multiplikator, den niemand einkalkuliert: die Dauer des Sprints. Jede Zeremonie, die „einmal pro Sprint“ stattfindet, findet bei einem einwöchigen Sprint doppelt so oft statt wie bei einem zweiwöchigen. Halbiert man den Sprint, verdoppelt sich die Anzahl der Planungssitzungen, der Reviews und der Retrospektiven, doch die dazwischen anfallende Arbeit wird nicht halbiert, sodass das Verhältnis von Zeremonien zu Arbeit stark ansteigt. Teams mit einwöchigen Sprints bezeichnen dies unverblümt als schlecht: Planung und Retrospektive jede einzelne Woche, wobei die Reflexion oft ins Leere läuft, da eine Woche nicht lang genug ist, um etwas Neues gelernt zu haben.

Die Lösung besteht darin, die Kadenz nicht mehr als einen einzigen Regler zu betrachten. Die Dauer der Sprints, die Häufigkeit der Standups und die Häufigkeit der Retrospektiven müssen nicht im Gleichschritt erfolgen. Ein Team, das wöchentliche Retros als sinnlos empfindet, kann die Retrospektive alle zwei oder drei Sprints durchführen, ohne dabei etwas zu verlieren. Die Reflexion hat ihren eigenen natürlichen Rhythmus, und wenn man sie schneller erzwingt, als das Team Erkenntnisse sammelt, entsteht lediglich die „Abhak-Retro“ aus dem Kapitel „Leistung“. Passen Sie jede Zeremonie an das Intervall an, in dem sie tatsächlich etwas bewirkt.

Wenn sich „Overload“ mit den anderen Modi überlagert

Überlastung tritt selten allein auf. Martin Fowlers „Flaccid Scrum“ bezeichnet jene Variante, bei der ein Team zwar alle Zeremonien durchführt, jedoch die zugrunde liegende technische Disziplin vernachlässigt; somit zahlt es den vollen Preis für die Meetings, ohne den Nutzen in Form von Lieferergebnissen zu erzielen, da der Engpass nie in der Koordination lag. Und „Water-Scrum-Fall“, das von Dave West von Forrester benannte Muster, ist eine Verschlimmerung der Überlastung durch „Power“: ein Plan, dessen Umfang, Zeitrahmen und Kosten von vornherein feststehen und der dann in Sprints verpackt wird, sodass das Team sowohl den zeremoniellen Aufwand von agil als auch die Starrheit des Wasserfallmodells trägt – mit den schlimmsten Aspekten beider Ansätze.

Es lohnt sich, auch das Gegenargument ernst zu nehmen, da es weit verbreitet ist und zur Hälfte zutrifft. Praktiker weisen gerne darauf hin, dass viele hochkarätige Entwicklungsorganisationen den „Ceremony-Stack“ kaum anwenden: Ingenieure leiten Projekte, Teams wählen ihre eigene Methode, und Continuous Delivery liefert schnelleres Feedback als jede wöchentliche Besprechung. Gehen Sie mit dieser Beobachtung vorsichtig um: „Regeln gelten nicht für uns“ ist keine Strategie, und ein großes, verteiltes Team benötigt tatsächlich mehr Abstimmung als ein kleines, an einem Standort tätiges Team. Die eigentliche Erkenntnis lautet nicht „die Zeremonien überspringen“, sondern „die Zeremonie an den Koordinationsbedarf anzupassen, den die Arbeit tatsächlich erfordert“ – was für manche Teams weit weniger ist, als das Standard-Playbook annimmt, und für andere genau dem Standardumfang entspricht. Eine Überlastung entsteht, wenn man das Playbook kopiert, anstatt den Bedarf individuell zu bemessen. Der letzte Modus, die „Lücke bei der Umsetzung“, entsteht, wenn selbst angemessen dimensionierte Zeremonien nichts bewirken.

Häufig gestellte Fragen

Wie viele Besprechungen sind in Scrum zu viele?

Es gibt keine festgelegte Zahl. Der Maßstab sind das Verhältnis und der Nutzen. Rechnen Sie die Zeit für wiederkehrende Zeremonien als Prozentsatz der Arbeitswoche des Teams zusammen; liegt dieser Wert über 20 % und kann das Team keine konkreten Veränderungen benennen, die sich dadurch ergeben haben, sind Sie überlastet. Eine Besprechung verdient ihren Platz dadurch, dass sie zu einer Entscheidung oder einer Abstimmung führt, die für die Arbeit tatsächlich notwendig ist – und nicht dadurch, dass sie auf der Standardliste steht.

Sind einwöchige Sprints zu kurz für all diese Zeremonien?

Oftmals ja. Wenn jede Woche eine Planung und eine Retrospektive stattfinden, steigt das Verhältnis von Zeremonie zu Arbeit ins Unermessliche, und erfahrene Teams finden häufig nicht so schnell etwas Neues, worüber sie reflektieren könnten. Passen Sie den Rhythmus entsprechend an: Führen Sie die Retrospektive alle zwei oder drei Sprints durch, wenn die wöchentliche Reflexion zu wenig Ertrag bringt, und verlagern Sie die Statusbesprechung auf asynchrone Formate, damit die tägliche Besprechung nicht den gesamten Vormittag in Anspruch nimmt.

Warum scheinen die großen Technologieunternehmen Scrum-Zeremonien auszulassen?

Viele Elite-Teams arbeiten tatsächlich schlanker: Ingenieure leiten Projekte, Teams wählen ihre eigene Methode, und CI/CD sowie Feature-Flags liefern schnelleres Feedback, als es eine wöchentliche Besprechung könnte. Die Lehre daraus lautet jedoch nicht, dass Regeln für uns nicht gelten, sondern dass die Besprechung auf den tatsächlichen Koordinationsbedarf abgestimmt werden muss. Ein kleines, am selben Standort tätiges Team benötigt weniger Abstimmung als ein großes, verteiltes Team, und das blinde Nachahmen eines der beiden Extreme ist ein Fehler an sich.

Wie kann ich den Aufwand für agile Besprechungen reduzieren, ohne dass die Koordination darunter leidet?

Überprüfen Sie jede regelmäßig stattfindende Besprechung anhand einer einzigen Frage: Welche Entscheidung oder welche Koordinierungsmaßnahme ergibt sich daraus? Streichen Sie diejenigen, auf die es keine Antwort gibt, oder legen Sie sie zusammen; verlagern Sie die Statusberichte in die Tools, in denen diese Informationen bereits erfasst sind, und beschränken Sie die verbleibenden Besprechungen auf die kleinste Gruppe, die tatsächlich daran teilnehmen muss. Das Ziel ist es, weniger Zeit mit Koordinierungsaufgaben und mehr Zeit mit der eigentlichen Arbeit zu verbringen.

Weiterführende Literatur