Wenn Scrum zur Meeting-Maschinerie wird
Agiles Projektmanagement soll Wertschöpfung beschleunigen, nicht sie im Kalender ersticken.
Lesedauer: ca. 7 Minuten
Scrum ist in seiner originären Form kein schwerfälliger Verwaltungsapparat, sondern ein leichtes Führungs- und Arbeitsgerüst. Gerade darin liegt sein Reiz: klare Rollen, klare Takte, klare Verantwortlichkeiten.[1] Und doch erleben viele Unternehmen etwas völlig anderes: Der Tag beginnt mit dem Daily, wird fortgesetzt mit Refinement, Stakeholder-Call, Abstimmungsrunde, Steering, Review-Vorbereitung und endet dort, wo die eigentliche Arbeit erst anfängt – am Abend.
Um Missverständnisse zu vermeiden: Agile Methoden können sehr wohl zu besseren Ergebnissen führen. Eine große quantitative Untersuchung über 1.002 Projekte zeigt einen positiven Zusammenhang zwischen agilem Vorgehen, Effizienz und Stakeholder-Zufriedenheit.[11] Das Problem ist also nicht Agilität an sich. Das Problem ist ihre schlechte Ausführung.
Wer die beschriebene Lage kennt, spürt das Problem nicht nur organisatorisch, sondern auch körperlich. Nach einem Tag voller Termine ist man geistig ermüdet, obwohl man formal „viel getan“ hat. Man war beschäftigt, aber nicht zwingend wirksam. Entwickler beschreiben produktive Tage typischerweise gerade nicht als Tage voller Unterbrechungen, sondern als Tage, an denen sie wesentliche Aufgaben mit möglichst wenigen Kontextwechseln voranbringen.[4]
„Einfachheit — die Kunst, die Menge nicht getaner Arbeit zu maximieren — ist essenziell.“
Prinzipien hinter dem Agilen Manifest[2]
Wenn Agilität falsch verstanden wird
Ein schlechtes Scrum erkennt man nicht daran, dass Menschen miteinander sprechen. Man erkennt es daran, dass Kommunikation zum Ersatz für Führung, Priorisierung und saubere Produktarbeit wird. Dann wird jedes offene Thema in einen Termin verwandelt. Das Backlog ist unscharf, also diskutiert man live. Die Verantwortlichkeiten sind nicht sauber getrennt, also sitzen zu viele Menschen mit am Tisch. Der Product Owner ist faktisch ein Ausschuss, also wird Priorisierung permanent neu verhandelt. Der Daily Scrum wird zur Statusshow für das Management, obwohl er in Wahrheit der täglichen Anpassung der Arbeit in Richtung Sprint Goal dient.[1]
Hinzu kommt ein zweiter Irrtum: Viele Unternehmen verwechseln agile Sichtbarkeit mit permanenter Verfügbarkeit. Doch Sichtbarkeit entsteht nicht dadurch, dass alle überall dabei sind. Sichtbarkeit entsteht durch klare Ziele, gute Artefakte, verlässliche Entscheidungen und dokumentierte Ergebnisse. Werden stattdessen Meetings zum primären Steuerungsinstrument, verlagert sich die Arbeit aus dem Produkt in den Kalender.
Die Forschung beschreibt genau diesen Mechanismus. Microsoft berichtet, dass die Hälfte aller Meetings in genau jenen Zeitfenstern stattfindet, in denen viele Menschen natürliche Leistungsspitzen haben; zugleich zeigt die Auswertung, wie stark Fokusarbeit durch ein Gemisch aus Terminen, Nachrichten und Benachrichtigungen fragmentiert wird.[3] Die Entwicklerforschung ergänzt: Unterbrechungen und Kontextwechsel gelten nicht als Randthema, sondern als zentrale Einflussgrößen für das Erleben von Produktivität.[4]
Noch deutlicher wird der Preis solcher Fragmentierung in der Unterbrechungsforschung: Menschen arbeiten unter Unterbrechungen bisweilen schneller, zahlen dafür aber mit mehr Stress, höherer Frustration, stärkerem Zeitdruck und größerem Aufwand.[5] Neuere Forschung aus der Softwaretechnik zeigt ebenfalls, dass Art und Dringlichkeit von Unterbrechungen Bearbeitungszeit und Stressreaktionen messbar verändern können.[6]
Muss das immer so sein?
Nein. Und fachlich betrachtet darf es auch nicht so sein, wenn man Scrum ernst nimmt. Der Scrum Guide beschreibt Scrum ausdrücklich als leichtgewichtiges Framework mit klar timeboxierten Ereignissen. Diese Ereignisse sollen Regelmäßigkeit schaffen und den Bedarf an zusätzlichen Meetings gerade minimieren.[1] Ein Daily Scrum ist auf 15 Minuten begrenzt. Sprint Planning, Review und Retrospektive haben ebenfalls klare Maximaldauern. Scrum ist also nicht als Meeting-Kultur konzipiert, sondern als Rhythmus zur Konzentration auf Wertschöpfung.
Auch das Agile Manifest denkt nicht in Dauerhektik, sondern in nachhaltiger Leistungsfähigkeit. Agile Prozesse sollen ein gleichmäßiges Tempo auf unbegrenzte Zeit ermöglichen.[2] Ein Team, das nach jedem Sprint nur noch erschöpft ist, arbeitet nicht agil, sondern auf Verschleiß.
Gerade diese Unterscheidung ist im Management entscheidend. Hohe Taktung kann sinnvoll sein. Dauernde Reibung ist es nicht. Ein sportlicher Organismus lebt von Belastung und Erholung, nicht von Dauerpuls. Unternehmen übrigens ebenso.
Woran gutes Scrum wirklich zu erkennen ist
Gut geführtes Scrum erzeugt nicht mehr Meeting-Zeit, sondern bessere Entscheidungen in kürzerer Zeit. Der erste Prüfstein ist das Zielbild. Wenn Product Goal und Sprint Goal unscharf sind, vervielfacht sich die Abstimmung automatisch. Sind sie präzise, sinkt der Besprechungsbedarf spürbar, weil das Team innerhalb klarer Leitplanken selbst entscheiden kann.[1]
Der zweite Prüfstein ist die Teamarchitektur. Scrum ist auf kleine, fokussierte, selbstmanagende Teams angelegt; der Scrum Guide nennt typischerweise zehn oder weniger Personen.[1] Werden Teams größer, heterogener oder in zu viele Abhängigkeiten gedrückt, explodiert der Koordinationsaufwand. Das ist kein Charakterfehler des Teams, sondern ein Designfehler des Systems.
Forschung zu großer agiler Programmarbeit zeigt genau das: Mit der Zahl der Teams steigt der Bedarf an Koordination deutlich an. Deshalb müssen Koordinationspraktiken bewusst auf den Kontext zugeschnitten werden, statt einfach immer neue Routinen anzubauen.[10]
Der dritte Prüfstein ist der Umgang mit Unterbrechungen. Agile Arbeit bringt naturgemäß mehr Interaktion mit sich. Das ist nicht per se schlecht. Studien zu agilen Teams zeigen, dass Unterbrechungen sowohl positive als auch negative Folgen haben können: Sie können Klarheit, Feedback und schnellere Informationsflüsse ermöglichen, aber auch Stress, Verzögerungen, Ablenkung und Qualitätsverluste erzeugen. Entscheidend ist daher nicht, Interaktion abzuschaffen, sondern sie zu filtern, zu bündeln und über Rollen sauber zu kanalisieren.[7]
Was Unternehmen jetzt konkret ändern sollten
Wer Scrum und agiles Projektmanagement behalten, aber die Meeting-Müdigkeit beenden will, sollte nicht hektisch das nächste Framework suchen. Meist reicht es, die vorhandene Logik wieder sauber auszuführen:
- Ziele schärfen. Product Goal und Sprint Goal müssen so klar sein, dass sie Entscheidungen ersetzen können, statt neue Termine zu erzeugen.[1]
- Den Daily Scrum zurückholen. Kein Reporting an Führungskräfte, keine Problemlösungsorgie, kein Ausweiten auf 30 oder 45 Minuten. Fünfzehn Minuten, fokussiert auf Fortschritt, Hindernisse und den nächsten Arbeitstag.[1]
- Stakeholder-Kontakt kanalisieren. Kunden- und Fachbereichsimpulse sind wertvoll, sollten aber bevorzugt über Product Owner, Sprint Review und sauber gepflegte Backlogs ins System kommen, statt das Team spontan im Tagesgeschäft zu überfahren.[1][7]
- Meetings nur mit Ziel und Vorbereitung. Eine einfache Regel wirkt oft Wunder: keine Agenda, kein Termin. Gute remote-erprobte Meeting-Praxis fordert genau das – inklusive klarer Zielsetzung, vorbereiteter Unterlagen und dokumentierter Ergebnisse.[9]
- Asynchron arbeiten, wo keine Echtzeit nötig ist. Statusupdates, Kommentare, Vorab-Feedback, Entscheidungen mit geringer Konfliktdichte und Review-Vorbereitung gehören häufig in Dokumente, Tickets, Videos oder schriftliche Kommentare – nicht in einen Live-Termin.[8]
- Optionalität ernst nehmen. Nicht jeder muss in jedem Termin sitzen. Wer nur informiert werden soll, kann ein Protokoll, eine Aufzeichnung oder einen Live-Doc-Eintrag erhalten.[9]
- Fokusfenster verteidigen. Wenn die besten Arbeitszeiten systematisch mit Meetings belegt sind, wird aus Agilität bloße Reaktivität. Sinnvoll sind geschützte Blöcke für konzentrierte Wertschöpfung – programmatisch im Kalender verankert, nicht nur rhetorisch gewünscht.[3]
- Die Rolle des Scrum Masters ernst nehmen. Ein guter Scrum Master verwaltet keine Zeremonien, sondern schützt die Arbeitsfähigkeit des Teams, hält Timeboxen ein, entfernt Hindernisse und verhindert Prozessverwilderung.[1][7]
„No agenda, no attenda.“
GitLab Handbook, Meeting-Prinzip[9]
Mein Fazit
Agilität ist dann stark, wenn sie Disziplin mit Beweglichkeit verbindet. Nicht jedes Gespräch ist Verschwendung. Nicht jede Unterbrechung ist schädlich. Aber ein Unternehmen, das Wertschöpfung fortlaufend für Koordination opfert, führt sein System falsch. Scrum soll Komplexität beherrschbar machen. Wenn es stattdessen Erschöpfung produziert, liegt das Problem meist nicht in Scrum, sondern in seiner bequemen Fehlinterpretation.
Die gute Nachricht lautet: Man muss Agilität nicht abschaffen, um wieder produktiv zu werden. Man muss sie präziser führen. Weniger Ritual. Mehr Zielklarheit. Weniger Präsenzpflicht. Mehr dokumentierte Entscheidungen. Weniger Meeting-Moral. Mehr Arbeitsfähigkeit. So sieht ordentliches, übertragbares und wirtschaftlich vernünftiges Scrum aus.
Quellen
- Scrum Guides: The Scrum Guide.
- Prinzipien hinter dem Agilen Manifest sowie Manifest für Agile Softwareentwicklung.
- Microsoft WorkLab: Breaking down the infinite workday.
- Meyer et al.: Software Developers’ Perceptions of Productivity.
- Mark, Gudith, Klocke: The Cost of Interrupted Work: More Speed and Stress.
- Ma, Huang, Leach: Breaking the Flow: A Study of Interruptions During Software Engineering Activities.
- Wiesche: Interruptions in Agile Software Development Teams.
- GitLab Handbook: Asynchronous communication for remote work.
- GitLab Handbook: All-Remote Meetings.
- Dingsøyr, Moe, Seim: Coordinating Knowledge Work in Multiteam Programs.
- Serrador, Pinto: Does Agile work? A quantitative analysis of agile project success.
