Meeting Overhead in Scrum reduzieren!?

Meeting Overhead in Scrum

"Wie können wir in Scrum den Meeting Overhead reduzieren?". Wenn ich diese Frage im Scrum-Umfeld bei Kunden höre, bildet sich bei mir schon eine Liste an möglichen Problemen in der Umsetzung des agilen Projektmanagement Framework Scrum.

Kommen Sie aus einer größeren Organisation und sind der Meinung, Overhead von Meetings in Scrum reduzieren zu müssen? Dann helfe ich Ihnen, wie Sie die Scrum Events richtig durchführen. Ich glaube fest daran, dass alle Scrum Events ausreichen, um komplexe Produkte zu entwickeln.

Sie sind der Agilist und der Meinung, das es keinen Overhead von Meetings in Scrum gibt, dann haben Sie ins Schwarze getroffen 🙂 Ich gehe auf das Symptom des Problems im Folgenden genau ein.

Mit "Meeting Overhead" wird folgender Sachverhalt bezeichnet: das Team das Gefühl, nur noch in Meetings zu sitzen und nicht mehr zum Arbeiten zu kommen. Diese Situation des "Meeting Overheads" findet sich nicht nur im agilen Projektmanagement Framework Scrum, sondern ist ein häufiges Problem von Teams und Individuen in Organisationen.

Aus meiner Erfahrung finden sich häufig drei Grundursachen bei Scrum. Ein "Meeting Overhead" entsteht immer dann, wenn...

  • ... Scrum "nebenbei" eingeführt wird und die Teams und Teammitglieder in mehreren Projekten arbeiten. Sie nehmen also mehr als eine Rolle in einem Projekt ein und sind dann überproportional mit Meetings belegt.
  • ... die Umsetzung der Scrum Events nicht richtig gelungen ist. Es werden mehr Meetings benötigt und diese dauern länger als gedacht. Damit sind die Meetings gefühlt und stundentechnisch einfach mehr, als nötig.
  • ... ein typischer "Roll-out" von Scrum in der ganzen Organisation durchgeführt wird. Es gibt keine Zeit für Experimente und alle müssen sich von einem Zeitpunkt x schnell umstellen.

Wieviel Meetings haben wir in Scrum?

Scrum als agiles Projektmanagement hat fünf Events. Davon sind vier typischerweise Meetings. Nehmen wir noch das Backlog Refinement als Meeting dazu, dann haben wir schon alles, was wir brauchen. Diese Meetings brauchen Sie, um Ihr Projekt verwalten und komplexe Produkte entwickeln zu können. Dabei sind alle Aktivitäten zur Verwaltung Ihrer Scrum Implementierung enthalten. Mehr hinsichtlich der Anzahl gibt es nicht. Eventuell haben Sie noch eigene Meetings, die Sie im konkreten Fall für Ihre Implementierung benötigen, aber grundsätzlich ist das alles.

Das Verhältnis von Events zu Entwicklungszeit

In diesem Abschnitt möchte ich mich dem "Meeting Overhead" einmal von den Fakten her nähern. Ich schaue mir die Vorgaben für die Events aus dem Scrum Guide an und setze diese Werte zu unterschiedlichen Sprintlängen in Beziehung.

Während es das agile Manifest mit

3. agiles Prinzip aus dem agilen Manifest

"Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und
bevorzuge dabei die kürzere Zeitspanne."

Quelle: Agiles Manifest, http://agilemanifesto.org

noch recht locker sieht, nimmt es der Scrum Guide mit

Scrum Guide

"Das Herz von Scrum ist der Sprint, eine Time Box von maximal einem Monat, innerhalb dessen ein fertiges ("Done"), nutzbares und potenziell auslieferbares ProduktInkrement hergestellt wird."

Quelle: Scrum Guide, www.scrumguides.org

schon etwas genauer. Er gibt aber nur die Obergrenze für die Dauer eines Sprints, nämlich ein Monat, an. In der Praxis haben sich neben der Maximallänge von einem Monat noch die Sprints von zwei und drei Wochen etabliert. Auch der Sprint mit der Länge von einer Woche findet ab und zu bei besonders innovativen und komplexen Produkten Anwendung. 

Meetings in Abhängigkeit der Sprintlänge

Nun werfen wir einen Blick auf die Länge der vorhandenen Events in Scrum, inklusive dem Backlog Refinement. Dabei stelle ich die Zeiten gegenüber, die in der Regel (und durch bloßes rechnen) Sinn ergeben. In der Praxis variieren diese Zeit teils sehr stark, abhängig von unterschiedlichen Rahmenbedingen. Das können zum Beispiel sein:

  • Was für ein Produkt wird konkret entwickelt
  • Wie reif ist das Team und welche Erfahrung hat das Team
  • Wie optimiert ist der bisherige Prozess
  • Wie gut sind Backlog Items vorbereitet
  • ...

Es hilft dennoch sehr, mit diesen Zeiten und Rahmenbedingungen zu starten. Dann werden Sie auch keinen Meeting Overhead in Scrum erleben!

Besonderheit Backlog Refinement

Das Backlog Refinement ist kein Event und hat keine Timebox wie die anderen Events. Das liegt daran, dass das Backlog Refinement eine aufwandsbezogene Tätigkeit ist. Das wird schnell klar, wenn wir überlegen, dass es schwieriger ist, mit 10 Entwicklern Stories zu verfeinern, als es mit 5 der Fall ist. Deswegen bezieht sich der Aufwand auf die Kapazität des Entwicklungsteams

Was bedeutet nun die Kapazität des Entwicklungsteams? Die Kapazität eines Teams ist die Zeit, die es in den Sprints real auch verbringt. Wenn wir zwei Wochensprints machen und dabei 10 Tage Kapazität von 10 Entwicklern haben, ergibt das eine Kapazität des Entwicklungsteams von 100. 10 Tage (10%) entfallen damit auf das genannte Refinement.

Dabei wird vom Scrum Guide offen gelassen, wer was wie macht. Deswegen entscheidet auch das Scrum Team darüber. Ein Beispiel:

  • Der Product Owner könnte von diesen 10 Tagen zum Beispiel eine gewisse Zeit für die Abstimmung mit dem Kunden sein (ohne Entwicklungsteam) und das Verfeinern und Aufnehmen von Backlog Items verwenden. Nehmen wir an, dies sind 3 Tage.
  • Der Rest könnten zusammen mit dem Entwicklungsteam für Schätzworkshops, Refinements, etc. verwendet werden. Dafür benötigt der Product Owner selbst noch zur Vor- und Nachbereitung 2 Tage und das Entwicklungsteam die restlichen 5 Tage für ein Meeting von einem halben Tag (10 Entwickler spendieren je einen halben Tag = 5 Tage).

Was auf den ersten Blick hoch erscheint, hilft Ihnen massiv bei der interativen und inkrementellen Entwicklung! Gerade wenn Sie Probleme in der Erstellung eines Inkrements haben, sollten Sie genauer auf Ihr Backlog Refinement schauen!

Die Sprints und die Zeiten im Überblick

Wenn Sie frisch mit Scrum starten, nutzen Sie bitte immer die aus dem Scrum Guide abgeleiteten Zeiten, so entgehen Sie dem Meeting Overhead in Scrum. Besonders wenn Sie merken, dass Sie deutlich mehr Zeit benötigen, als angegeben, ist es Zeit für eine Retrospektive bei Ihnen.

Sprint
Länge
1 Woche

Sprint Planning

2 Stunden

Daily Scrum

15 min

Sprint Review

1 Stunden

Sprint Retrospektive

0,75 Stunden

Backlog Refinement

4 Stunden
(Idealwert bei einem Mitglied! Multiplizieren mit Entwicklungsmitgliedern!)

Sprint
Länge
2 Wochen

Sprint Planning

4 Stunden

Daily Scrum

15 min

Sprint Review

2 Stunden

Sprint Retrospektive

1,5 Stunden

Backlog Refinement

8 Stunden * Teammitglieder
(Idealwert bei einem Mitglied! Multiplizieren mit Entwicklungsmitgliedern!)

Sprint
Länge
3 Wochen

Sprint Planning

6 Stunden

Daily Scrum

15 min

Sprint Review

3 Stunden

Sprint Retrospektive

2,25 Stunden

Backlog Refinement

12 Stunden * Teammitglieder
(Idealwert bei einem Mitglied! Multiplizieren mit Entwicklungsmitgliedern!)

Sprint
Länge
4 Wochen

Sprint Planning

8 Stunden

Daily Scrum

15 min

Sprint Review

4 Stunden

Sprint Retrospektive

3 Stunden

Backlog Refinement

16 Stunden *Teammitglieder
(Idealwert bei einem Mitglied! Multiplizieren mit Entwicklungsmitgliedern!)

Aus meiner Sicht hilft es, sich gleich zu Beginn eine Übersicht zu erstellen, wann welche Meetings stattfinden und diese Information muss dann in das (oder die) Team(s) gebracht werden, ebenso in die Organisation. Im folgenden sehen Sie beispielhaft so einen Sprint Meeting Plan (ohne Backlog Refinement).

Meeting Overhead? Der Sprint Plan für 4 Wochen Sprints

Was Sie weiter für den Meeting Overhead und die Sprints beachten müssen!

Es gibt neben den konkreten Zeiten für die Sprints noch weitere Dinge, die Sie in Betracht ziehen sollten. Dazu gehört es sich in der Organisation auf die Suche nach Synchronisationswegen zu machen. Kann Ihr Team alleine alles entscheiden, benötigt es keine Abstimmungen, keine Zulieferungen oder ähnliches? Dann ist es einfach, oft gibt es aber irgendein Ereignis, auf das Sie sich synchronisieren müssen.

Ihre Sprintlänge und auch der genaue Startpunkt muss dann überprüft und ggf. auch angepasst werden. Im folgenden Bild sehen Sie eine vereinfachte Darstellung für eine angepasste Sprint Planung auf den Wochentag Donnerstag. In dem Beispiel könnten andere Takte dazu führen, dass die Sprint Planung am Donnerstag beginnen muss.

Kein Meeting Overhead mit getacktetem Meetingplan in der Organisation

Large-Scale Scrum: Scrum erfolgreich skalieren mit LeSS
Preis: nicht verfügbar
Zuletzt aktualisiert am 17.01.2019

Wir brauchen eine Anpassung!

Seien Sie bitte mit Anpassung immer vorsichtig. Scrum funktioniert nur als Ganzes. Auch wenn Sie aus dem Scrum Guide lediglich Teile nutzen können, ist das Ergebnis dann kein Scrum. Anpassungen sind im zeitlichen Rahmen aber immer wieder mal nötig. Das hängt zum Beispiel von dem entwickelten Produkt ab, wie gut das Team zusammenarbeitet und ähnlichem.

Ich starte gerne mit den Vorgaben, die der Scrum Guide bereitstellt. Orientieren Sie sich bitte auch an den oben genannten Werte und Zeiten. Stellen Sie dann fest, dass Sie andere Bedarfe an die Zeiten haben, dann nutzen Sie Ihre Retrospektive und beleuchten Sie Ihren Prozess und Ihre Anforderungen genau. Scrum basiert auf der empirischen Prozesskontrolle, Sie machen also Erfahrungen und adaptieren auf Basis dieser gemacht Erfahrungen!

Fazit: Meeting Overhead in Scrum gibt es nicht!

Wie so oft gilt auch hier:  Scrum ist einfach aber nicht leicht. Es ist eben kein Problem den Scrum Guide am Wochenende durchzulesen. Es gehören aber unter Umständen aber Jahre dazu, diese Anwendung zu perfektionieren. Sie müssen Scrum richtig anwenden und werden dann auch keinen Meeting Overhead spüren. Denken Sie bitte daran, dass Sie einen Meeting Overhead wahrnehmen, dass Sie sehr wahrscheinlich  Anpassungen an Scrum vorgenommen haben, die nicht optimal sind. Das liegt häufig an der Parallelität von Scrum zu bestehenden Initiativen und an Teilzeitteams.

Leave a Reply 0 comments

Leave a Reply:







>
close

Der neue Online Scrum Kurs!

Der Online Scrum Kurs