🇩🇪 Zu viele Meetings in Scrum!? 🇩🇪

(Germany)

August 9, 2021

“Ich bin ja ein großer Fan von Scrum, aber ... viel zu viele Meetings!”

"Ich komm vor lauter Meetings nicht zum Arbeiten!"

"Unsere Entwickler halten nichts von Dailys - und die Retrospective machen wir nur alle paar Monate."

Sätze, die ich häufiger von Vorgesetzten, von Entwicklern und auch von Scrum Mastern und Product Ownern höre. Daher diskutieren wir in meinen Professional Scrum Master Trainings immer wieder darüber..

... wie wir die eingesetzte Meeting-Zeit „verrechnen“
... wie wir Entwickler motivieren, an den Scrum Events teilzunehmen
... wie wir Vorgesetzte überzeugen, kein Scrum Event zu streichen!

Woher kommt die Grundhaltung, Scrum sei ja gut aber viel zu „meetingintensiv?“

In diesem Blog untersuchen wir, woher diese Grundhaltung kommt, zeigen, wie wir damit umgehen können, leisten Überzeugungsarbeit und bieten Experimente an, d. h. wir
… erklären wozu die Scrum Events gut sind,
… zeigen wie wir mit ihnen Zeit sparen können.
… und geben konkrete Tipps zur Revitalisierung.

Wozu Scrum Events da sind..

In der komplexen Arbeitswelt ist in der Regel mehr bekannt als unbekannt. Aus der Praxis wissen wir, dass wir in Situationen mit großer Unsicherheit besser in kleinen Schritten voranschreiten, kontinuierlich unsere Umgebung beobachten und besser Entscheidungen auf Basis der Dinge treffen, die wir selbst beobachtet, erfasst und bewertet haben. Die Scrum Events ermöglichen und implementieren diese empirische Prozesskontrolle. Jedes Scrum Event ist eine Möglichkeit zur Inspektion und Anpassung.

Im Sprint Planning inspizieren wir im Product Backlog was vor uns liegt; diskutieren wozu das erreicht werden soll und planen grob, wie wir es erreichen können.
Im Daily Scrum inspizieren wir unseren Fortschritt und adaptieren unseren Plan – wenn nötig – für den Tag.
Im Sprint Review inspizieren wir, was fertig wurde und diskutieren mit unseren Stakeholdern zusammen was das Produkt als nächstes noch wertvoller macht – um es ggfls. gleich im nächsten Sprint in Angriff zu nehmen.
Schließlich diskutiert das Scrum Team in der Sprint Retrospektive was in der Vorgehensweise selbst schon gut funktioniert und was noch weiter verbessert werden kann.

Die Scrum Events bilden damit alles ab, was benötigt wird, um erfolgreich zu liefern. Sie machen auch viele andere konventionelle Meetings überflüssig. Zeit, die wir produktiv nutzen können.

Alle Scrum Events sind darauf ausgelegt, Risiken zu minimieren: Das Risiko, die Arbeit mit zu viel versteckter Komplexität, Ungewissheit oder Abhängigkeiten zu beginnen (Sprint Planning). Das Risiko, auseinander zu laufen, Arbeit doppelt, falsch oder gar nicht zu machen, oder nicht rechtzeitig über neue Erkenntnisse informiert zu werden (Daily Scrum). Das Risiko, etwas zu entwickeln, was keiner braucht (Sprint Review) und Verbesserungspotential nicht auszuschöpfen. Das Risiko sich keine Zeit zu nehmen Dinge in Frage zu stellen und neu/anders zu denken, daraus zu lernen und damit die richtigen Dinge richtig zu tun (Sprint Retrospective).
Die Scrum Events minimieren diese potentiellen Möglichkeiten für Verschwendung und sparen damit Zeit und Mehraufwand.

Alle Scrum Events fördern schnelle und schlanke Entscheidungen. In kleinen Schritten und in regelmäßigen Zeitintervallen werden Fragen zusammen geklärt: in crossfunktionalen, selbst verwalteten Teams und mit Unterstützung ihrer Stakeholder.

Weiterhin erzeugen die Scrum Events mit Ihrer Regelmäßigkeit einen Takt, einen Rhythmus, der Struktur gibt und Fokus ermöglicht. Fokus, weil wir uns formalisiert mit einem maximalen Zeitrahmen und einer Absicht treffen. Alle Scrum Events haben eine maximale Timebox, d.h. alle Events gehen maximal so lang, aber nicht länger. Das respektiert die Arbeitszeit aller – und macht sie auch wieder planbar(er).. Die Timebox hilft, Nebendiskussionen zu kanalisieren und den Blick auf das jetzt Sinnvollste im Fokus zu halten. Oft wird Fokus auch durch die Moderation des Product Owner, des Scrum Masters oder der Developer weiter unterstützt.

Die Regelmäßigkeit der Scrum Events reduziert Komplexität. Damit ist nicht nur das sonst oft qualvoll lange Suchen nach einem gemeinsamen Termin hinfällig, durch die konstant gleichen Planungsintervalle - bis morgen im Daily, bis zum nächsten Refinement, in den nächsten x Wochen im Sprint Planning - sorgt dieser Takt auch für bessere und schnellere Planbarkeit und Right-Sizing der Inhalte.

Und natürlich sind alle Scrum Events dafür da, um zusammen zu arbeiten. Am Wozu, am Was und am Wie. Sie geben einen Rahmen, miteinander und füreinander am gemeinsamen Ziel zu arbeiten, Unsicherheiten und Abhängigkeiten schnell aufzudecken, sich gegenseitig zu unterstützen und zur Zusammenarbeit zu ermutigen.

Alle Scrum Events dienen dazu, Feedback einzufordern und aus dem Feedback zu lernen, gemeinsam zu lernen und sich kontinuierlich zu verbessern. Pro Planungszyklus. Pro Tag. Pro ausgeliefertem Produktinkrement. Fehlt eins dieser Scrum Events ist eine dieser Feedbackschleifen nicht geschlossen. Damit steigt das Risiko verdeckte Komplexität, Fehleinschätzungen, Entwicklungsfehler, versteckte Abhängigkeiten zu spät zu entdecken und gemachte Annahmen nicht rechtzeitig zu validieren und damit zeit- und kostenintensive Extrarunden zu drehen.

Scrum Events kosten also keine Zeit – ja, sie sparen sogar Zeit!

Scrum Events Arbeitszeit zu Meetingzeitverteilung — Nur 12% der Zeit wird für die Scrum Events verwendet

Warum wird Scrum dennoch als meetingintensiv wahrgenommen? Haben wir wirklich zu viele Meetings in Scrum?

Rein rechnerisch haben wir – nach Abzug der Maximallänge aller geforderten Scrum Events – knapp 9/10 der Zeit im Sprint (88%) zur Arbeit zur Verfügung.

Rein rational betrachtet haben wir also eine Menge Zeit zur Arbeit neben den Scrum Events.

Warum werden sie dann als Zeitfresser angesehen?

Meetings unterbrechen / fragmentieren den Arbeitsfluss

Meetings unterbrechen unseren Arbeitsfluss. Sorgen dafür, das wir einen Contextwechsel in unserer Konzentration haben.
Aus der Arbeitsforschung wissen wir, das wir bis zu 25 Min. brauchen, bis wir nach einer Unterbrechung wieder da weitermachen, wo wir aufgehört haben.

Ist nun unser Arbeitstag durch viele Meetings fragmentiert, ist die Wahrnehmung verständlich, vor lauter Meetings nicht mehr zum Arbeiten zu kommen. Vor allem, wenn die Scrum Events on-top zu den bisher etablierten Meetings kommen und nicht hinterfragt wird, welche Meetings jetzt durch Scrum Events hinfällig werden, bzw. nun durch Scrum Events abgedeckt werden.

Meetings wo man hin „muss“ – ohne erkennbaren Zweck

Meetings sind oft Pflichtveranstaltungen, an denen man teilnimmt, weil man muss. Oft fehlt der eigene Anreiz zur Teilnahme oder er besteht einfach nur darin, nicht durch Abwesenheit aufzufallen und vom Vorgesetzten ermahnt zu werden. Meetings werden daher häufig als sinnlose Rituale wahrgenommen, deren eigentlicher Zweck dahinter nicht (mehr) klar ist.

Schlecht / nicht moderierte Meetings

Wer kennt sie nicht, Meetings die eigentlich besser in Form von einer E-Mail hätten abgebildet werden können? Oder Meetings, wo klar ein Moderator benötigt wird, weil zu viel von zu wenigen (oder zu wenig von zu vielen) gesagt wird. Meetings, die am Thema vorbei ausfransen, oder gar kein erkennbares Thema haben. Und dann sind da noch Meetings, die nicht oder schlecht vor- und nachbereitet werden. Nicht zu vergessen die Meetings, die schlichtweg stocklangweilig sind und viel zu lange dauern.

Wir haben alle meist zu viel zu tun, da sind solche Meetings oft einfach nur ärgerliche Zeitverschwendung.

Manchmal hat der Glaubenssatz „Scrum hat zu viele Meetings“ auch garnichts mit den Scrum Events zu tun, sondern hat andere Gründe.

Zuordnung zu mehreren Teams

In seinem Buch Quality Software Management: Systems Thinking beschreibt Gerald Weinberg die Verschwendung, die durch Contextwechsel entsteht. Mit jedem gleichzeitig begonnen Projekt verliert man 20% seiner Arbeitszeit durch Contextwechsel; die Zeit, die ich benötige, um mich zwischen den beiden Projekten zu bewegen, mich aus dem einen Projekt heraus- und in das andere Projekt hineinzudenken.

Bei Zuordnung zu 3 Teams schrumpft die verfügbare Arbeitszeit rapide — Als Mitglied in drei Teams schrumpft die Arbeitszeit auf 23%

Hier sind nicht die Scrum Events das Problem, sondern der fehlende Fokus, einer der Kernwerte in Scrum. Dieses Problem ist organisatorisch zu lösen.

Was ist der Hintergrund für diese Mehrfachzuordnung? Ist nicht verteiltes Spezialistenwissen, bzw. Konzentration von zu viel Wissen auf zu wenige Spezialisten, die dann auf zu vielen Hochzeiten tanzen (müssen), das eigentliche Problem?

Oder begünstigt der derzeitige Produktschnitt diese Mehrfachzuordnung von Personen? Kann das Produkt (und damit das Scrum Team) günstiger geschnitten werden, so dass die Abhängigkeiten zu kritischen Personen reduziert werden kann? Macht ein feinerer oder ein groberer Produktschnitt mit mehr Crossfunktionalität Sinn?

Wir sind kein Team

Sind die anderen Kernwerte von Scrum wie Offenheit, Respekt, Commitment und Courage nicht ausgeprägt oder arbeitet das Team nicht an einem gemeinsamen Ziel, so haben wir kein Team.

Ist das Team eigentlich eine Gruppe von Spezialisten, die alle eigene Ziele haben, wird das gemeinsame „meeten“ oftmals ebenfalls zur Zeitverschwendung, da ich mich für die Arbeit des Anderen gar nicht interessiere – ja meist auch gar nicht interessieren muss, und oft sowieso selbst viel zu viel zu tun habe.

Scrum Events sind keine "Meetings"

Wir sprechen in Scrum daher auch nicht von Meetings, sondern von Events. Ein Meeting ist durch die Punkte oben oft bereits negativ verknüpft. Zu einem Meeting muss man hin. Ein Event ist etwas, da will ich hin. Ein Event ist etwas Besonderes. Ein Konzert, eine Hochzeit, vielleicht sogar auch eine Scheidung – etwas wo ich hinwill, weil ich mir dadurch einen persönlichen Benefit verspreche.

Wie können wir also Meetings in Scrum (wieder) zu echten Scrum Events machen?

Klarheit und Sinn schaffen

Werdet Euch klar, wozu die Scrum Events gut sind. Wovon wir als Team und als Einzelpersonen von Ihnen profitieren. Und wenn ihr davon (im Moment) nicht profitiert: was muss anders werden, was kann ausprobiert werden, um wieder zu einem Event zu kommen?

Werdet Euch auch klar, was ihr erreichen wollt. Für wen ihr das macht, welches Bedürfnis ihr damit erfüllt, welches Problem ihr lösen wollt. Und was möglich wird, wenn es gelöst ist.. Fokussiert Euch (wieder) auf gemeinsame Ziele. Und wenn ihr noch keine gemeinsamen Ziele habt, dann findet welche. Nutzt die strukturgebenden Ziele in Scrum, das Product Goal als mittelfristige und die Sprint Goals als unmittelbare Orientierungs- und Alignmenthilfe.

Arbeitet an der Struktur Eurer Events

Probiert mehr Struktur zu geben:

in dem ihr eine Agenda habt
ihr Working Agreements vereinbart - und nachhaltet , z. B. via „Elmo“, einer Meeting Etikette (Beispiel), Team Charter (Beispiel) oder Definition of Fun (Beispiel)
ihr für Eure Gesprächspunkte Zeitfenster vereinbart
ihr einen Moderator habt.

Das muss nicht immer der Scrum Master sein, das kann eine Rolle sein, die rotiert. Von Meeting zu Meeting, von Woche zu Woche, von Sprint zu Sprint.

Oder probiert weniger Struktur zu geben:

Richtig, manchmal macht auch weniger Struktur Sinn. So sind die drei Daily Scrum Fragen aus dem Scrum Guide schon länger optional - und inzwischen ganz verschwunden: Platz für ein Blick auf das Sprint Goal: „Was wollen wir als Team heute tun, um das Sprint Goal zu erreichen?“. „Was hindert uns heute, die wichtigste Story fertigzustellen?“, „Wer kann dabei helfen?“ (gehört von Peter Fischbach) – findet Eure wichtigste Frage!

Verlasst den gewohnten Meeting Modus

Jimmy Janlien's Productivity Hack

Ein immer gleicher Ablauf lädt ein zur Langeweile. Gerade bei Regelmäßigkeit kommt schnell Monotonie auf.

Lasst also Raum für Abwechslung. Warum nicht über das Learning-of-today, Shortcut-of-today oder wegen mir auch den (Agile-Coach) Joke-of-today zu Beginn oder am Ende sprechen?

Beginnt mit etwas, was funktioniert

“Man denkt während des ganzen Meetings besser, wenn man als Allererstes etwas Wahres und Positives darüber gesagt hat, wie die eigene Arbeit oder die Arbeit der Gruppe läuft.”
(Nancy Kline)

Probiert also, mit etwas Wahrem und Positivem in das Event zu starten. Die Konzentration auf etwas Positives zu Beginn hilft, gute Ausgangsbedingungen zu schaffen um dann auch die Dinge zu besprechen, die gelöst werden sollen. Wenn jeder am Anfang über etwas Positives berichtet, erhöhen sich auch die Chancen, dass ruhigere Teilnehmer während der weiteren Diskussion wieder sprechen werden. Gute Einstiegsfragen gibt’s bei den Freunden von coach und coach.

Variiert die Meetingstruktur

Facilitation Cards - Moderationsaufgaben verteilt

Variiert Moderationsformate, nutzt vielleicht die Facilitation Cards, mit den man die Moderationsaufgaben zu Beginn verteilt.

Auch die Retrospektiven müssen nicht immer gleich ablaufen: Hier kann der Retromat von Corinna Baldauf auf Knopfdruck Inspiration aus derzeit 141 Aktivitäten geben.

Auch Lean Coffee hilft einladungsbasierte, selbstorganisierte Meetings zu strukturieren.

Liberating Structures bieten ebenfalls eine wunderbare Möglichkeit der Variation. Liberating Structures sind 33 einfach anzuwendende Strukturen für die Interaktion in Gruppen jeder Größe, über alle Hierarchien hinweg. 1-2-4-all, Impromptu networking, Conversation Café, TRIZ, 15% Solutions , Trojka Consulting und einige mehr passen super zur Variation der einzelnen Scrum Events. Gerade in Kombination miteinander! Hier haben sich die Liberators bereits viele gute Gedanken gemacht (1,2,3)!

Und auch Sharon Bowman’s 4Cs aus dem Training from the back of the Room helfen sowohl in der Vorbereitung wie in der Durchführung von abwechslungsreichen Arbeitstreffen mit hohem Engagement und Beteiligung aller. Auch sie geben gleichzeitig hilfreiche Struktur und Raum für freie Zusammenarbeit.

Macht den Dialog sichtbar

Visualisiert worüber ihr sprecht! Das macht Unsichtbares sichtbar, Unbegreifliches greifbar und gibt Diffusem eine Form. Und es gibt allen die Möglichkeit, daran anzuknüpfen und mit weiteren Ideen anzureichern. Gemeinsam ein gemeinsames Verständnis entwickeln. UZMO - Denken mit dem Stift und die bikablo Bücher sind gute Einstiegspunkte in die Welt der Visualisierung.

Hilfreich ist es auch, wichtige Informationen bereits vorab für alle im Raum sichtbar zu machen. Am Flipchart, am Sprint Backlog, an der Glaswand zum Gang. Jimmy Janlien’s Buch gibt Inspiration und Ideen wie’s geht.

Meetings on top?

Die zeitsparendsten Meetings sind die, die nicht stattfinden müssen.

Fragt Euch daher bevor ihr zu einem zusätzlichen Meeting einladet: in welchem Scrum Event kann ich das Thema anbringen? Brauch ich dafür wirklich synchronen Austausch (=Meeting) oder kann das auch asynchron per Mail, per Slack, per anderem Tool passieren?
Das könnt ihr im Übrigen auch mit Euren bestehenden Meetings machen: Wie können wir sie in unseren Scrum Events abbilden?

Wenn ihr Euch für ein zusätzliches Meeting entscheidet, dann fragt Euch, was rauskommen soll, wer dabei sein muss, was entschieden werden soll. Überlegt Euch auch, was die Teilnehmenden (oder ihre Vorgesetzten) überzeugen würde, teilzunehmen. Dann stellt sicher, dass jeder der teilnehmen soll im Vorfeld Klarheit hat, um was es geht, welchen Beitrag er/sie dazu leisten kann – und was für ihn oder sie (oder ihre Vorgesetzten ;-) drin ist.

Kommuniziert nach dem Meeting, was ihr erreicht habt. Das hilft denen, die nicht dabei waren. Wählt schlanke Formen der Dokumentation, wie z. B. visuelle Informationsradiatoren oder stark frequentierte Plätze im Büro. Pre-Corona war das die Teeküche oder der Flur vom Ausgang. Stellt sicher, dass die Dokumentation auch dort zu finden ist, wo die Frage aufkam – und nicht irgendwo im Meetingminutes-Ordner auf Confluence verschimmelt.

Take it to the team

Schließlich: Nehmt Euch Zeit zur Reflexion und zur Verbesserung.

Jedes Scrum Event muss für die Teilnehmenden einen Wert haben, damit es als sinnvoll wahrgenommen wird. Und wer als die Teilnehmenden selbst könnte besser entscheiden, ob das so ist?

Daher: Fragt, wie wertvoll das Scrum Event für sie war. Und wie es noch wertvoller sein würde. Und wie man das das nächste Mal erreichen könnte. Und was sie selber dazu beitragen könnten. Was funktioniert schon gut, was können wir das nächste Mal weiter nutzen und was können wir besser machen? Was wären konkrete Anzeichen, daß es besser ist? Woran würden wir das merken? Was benötigen wir dazu? Wer kann uns dabei helfen? Was könnten wir tun, um das Event das nächste Mal in der Hälfte der Zeit zu schaffen?

Was wollen wir ausprobieren – ab wann und bis wann?

Eine festgelegter Experimentiertzeitrahmen schafft sowohl Verbindlichkeit als auch Sicherheit, das es sich hier um etwas handelt, was ausprobiert – und gegebenenfalls auch wieder verworfen wird.

Skalen- oder ROTI (Return-of-time-invest) Fragen helfen hier:

„Auf einer Skala von 1-10, wobei 10 für wirklich wertvoll und 1 für das genaue Gegenteil steht – wie wertvoll war das <Scrum Event> für Dich? Was würde es das nächste Mal noch wertvoller machen?“

Nutzt die Fragen oben und das daraus gewonnene Feedback und experimentiert. Inspiziert und adaptiert Eure Events so wie sie für Euch sinnvoll sind - ohne ein Event wegzulassen.

Und wenn wir schon gerade dabei sind:

Auf einer Skala von 1-10, wobei 10 für wirklich wertvoll und 1 für das genaue Gegenteil steht – wie wertvoll war das Lesen dieses Blogartikels für Dich?

Schreib mir doch Deine Zahl in die Kommentare unten.

Und schreib mir doch auch dazu, was den Blogpost für Dich noch etwas besser gemacht hätte, so dass Du auf Deiner Skala einen Schritt weiter gegangen wärst... :-)

Mehr?

Wenn Du mehr zu lösungsfokussierten, engagierten und effektiven Meetings, nein Events lernen willst, besuch gerne einen meiner Workshops zur Lösungsfokussierung oder schau in meinen PSM I oder PSM II Trainings vorbei.

What did you think about this post?

Share with your network

Blog Comments