Überlastung: Wenn es zu viel Zeremoniell gibt
Die dritte Schwachstelle des agilen Theaters: zu viel Zeremoniell. Die „Besprechungssteuer“, die Kosten für den Kontextwechsel, die die fünfzehn Minuten bei weitem in den Schatten stellen, und die Belastung durch den Rhythmus, die kurzen Sprints zunichte macht – und wie man das richtige Maß findet.
Die Kosten einer Feier bestehen nicht nur aus den fünfzehn Minuten im Kalender. Es sind diese fünfzehn Minuten plus die zwanzig Minuten, die man vor der Feier benötigt, um zur Ruhe zu kommen, und die 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 Stand-up-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 und belasten einen Arbeitstag, in dessen Lücken noch 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 man anhand von Zahlen diagnostizieren kann.
Die Tagungssteuer – ehrlich berechnet
Zählen Sie also alles zusammen – den gesamten Arbeitsstapel, nicht nur die täglichen Aufgaben. 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-Meeting, 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 – und Praktiker berechnen diese Summe in Personenstunden, denn das ist die Einheit, die das Management nachvollziehen kann: Fünfzehn Minuten Stand-up in einem Team von zwölf Personen sind nicht einfach nur fünfzehn Minuten, sondern drei Personenstunden, jeden Tag, die verloren gehen. Rechnet man dann noch den Teil hinzu, den der Kalender nie zeigt – das Ausklinken vor jeder dieser Unterbrechungen und das Wiedereinfinden nachher –, ergibt sich ein Fünftel der Arbeitswoche als konservative Schätzung, was genau dem Overhead entspricht, den Praktiker immer wieder melden.
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, denn das Meeting selbst ist der kostengünstige Teil. Der teure Teil ist der Kontextwechsel auf beiden Seiten. Ein Entwickler, der tief in ein Problem vertieft ist, teleportiert sich nicht einfach zum Stand-up und zurück – er taucht wieder auf, verliert das mentale Modell, das er aufgebaut hatte, und verbringt die erste Zeit danach damit, es wieder aufzubauen. Praktiker beschreiben das morgendliche Stand-up 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 Stand-up als verloren gilt. Die fünfzehn Minuten sind der Listenpreis; der Kontextwechsel ist die Rechnung.
Aus diesem Grund ist es ebenso wichtig, wann eine Besprechung stattfindet, wie wie lange sie dauert. Ein Stand-up-Meeting am Vormittag unterbricht den Arbeitsfluss eines Entwicklers zweimal; dasselbe Stand-up-Meeting an einer natürlichen Unterbrechungsstelle 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 Stand-ups darin besteht, einen Status zu erfassen, den die Tools ohnehin bereits enthalten, beseitigt ein asynchrones Stand-up die Unterbrechung, ohne dass Informationen verloren gehen, und eine kurze Live-Synchronisierung mehrmals pro Woche sorgt für die menschliche Koordination, die der asynchrone Thread nicht leisten kann. Unser Kapitel „So führen Sie ein tägliches Stand-up-Meeting durch“ befasst sich damit, wie Sie den Arbeitstag der Entwickler unabhängig von der von Ihnen gewählten Frequenz schützen können.
Trittfrequenzbelastung: Die Falle des 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 Arbeit dazwischen 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 Stand-up-Meetings 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 – Reflexion hat ihren eigenen natürlichen Rhythmus, und wenn man sie schneller erzwingt, als das Team Erkenntnisse sammeln kann, entsteht lediglich die „Abhak-Retro“ aus dem Kapitel Performance. 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 Fowler beschreibt in seinem Artikel „Flaccid Scrum“ jene Variante, bei der ein Team zwar alle Rituale durchführt, dabei jedoch die zugrunde liegende technische Disziplin vernachlässigt – es zahlt also den vollen „Meeting-Aufwand“, profitiert jedoch nicht von den Vorteilen bei der Umsetzung, da der Engpass nie in der Koordination lag. Und „Water-Scrum-Fall“, das von Dave West von Forrester benannte Muster, ist eine Verschärfung der Überlastung Power: ein Plan, dessen Umfang, Zeitrahmen und Kosten im Voraus feststehen und der dann in Sprints verpackt wird – sodass das Team sowohl den zeremoniellen Aufwand von agil als auch die Starrheit von Wasserfall trägt und dabei das Schlimmste aus beiden Welten erträgt.
Es lohnt sich, auch das Gegenargument ernst zu nehmen, denn es ist weit verbreitet und hat teilweise Recht. 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 zusammenarbeitendes Team. Die eigentliche Erkenntnis lautet nicht „die Zeremonien überspringen“ – sondern „die Zeremonie an den Koordinationsbedarf anzupassen, den die Arbeit tatsächlich erfordert“, der für manche Teams weitaus geringer 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 Umsetzungslücke, tritt ein, wenn selbst angemessen dimensionierte Zeremonien nichts bewirken.
Häufig gestellte Fragen
Wie viele Besprechungen sind im Scrum zu viel?
Es gibt keine festgelegte Zahl – entscheidend sind das Verhältnis und der Nutzen. Berechnen Sie den prozentualen Anteil der wiederkehrenden Zeremonien an der Arbeitswoche des Teams; liegt dieser über 20 % und kann das Team keine konkreten Veränderungen benennen, die sich dadurch ergeben haben, sind Sie überlastet. Eine Besprechung verdient ihren Platz nur dann, wenn sie zu einer Entscheidung oder einer Abstimmung führt, die für die Arbeit tatsächlich notwendig ist – und nicht, weil 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 sprunghaft an, 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, die 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 – vielmehr geht es darum, die Besprechung an den tatsächlichen Koordinationsbedarf anzupassen. Ein kleines Team, dessen Mitglieder am selben Standort arbeiten, benötigt weniger Abstimmung als ein großes, verteiltes Team, und das blinde Kopieren eines der beiden Extreme ist an sich schon ein Fehler.
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: Zu welcher Entscheidung oder Koordinierungsmaßnahme führt diese? Streichen oder legen Sie diejenigen zusammen, auf die es keine Antwort gibt, verlagern Sie die Statusberichte in die Tools, in denen diese bereits erfasst sind, und beschränken Sie die Teilnehmerzahl der verbleibenden Besprechungen auf die kleinste Gruppe, die tatsächlich anwesend sein muss. Das Ziel ist es, weniger Zeit mit Koordinierungsaufgaben und mehr Zeit mit der eigentlichen Arbeit zu verbringen.
Weiterführende Literatur
- Performance: die Zeremonie, die Sie für das Publikum inszenieren – die Zeremonie, deren Aufrechterhaltung wenig kostet, da niemand etwas von ihr erwartet.
- Die Leere nach dem Akt – wenn selbst eine angemessen gestaltete Zeremonie nichts bewirkt.
- Asynchrone und Remote-Stand-up-Meetings – die Statusmeldung aus dem synchronen Zeitrahmen herausnehmen.
- Sprint-Planungssitzung – eine Planung, die straff genug durchgeführt wird, um ihre Stunde zu rechtfertigen.
- Agile Zeremonien: Der vollständige Leitfaden – wozu die einzelnen Zeremonien dienen, damit Sie erkennen können, welche für die Arbeit tatsächlich erforderlich sind.
- Glossar zum agilen Theater – die vier definierten Fehlermodi.