Meeting Overhead in Scrum reduzieren!?

Meeting Overhead in Scrum
Von Sebastian Schneider // 23.11.2017 // 0 Kommentare

Meeting Overhead in Scrum

Die Events in Scrum sind optimiert. Sie erzeugen keinen Meeting Overhead. Dieser entsteht in der Regel immer dann, wenn du Scrum anpasst, nicht sauber aufsetzt oder fehlerhaft in deine Scrum Skalierung gehst. 

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

Bist du der Agilist und der Meinung, das es keinen Overhead von Meetings in Scrum gibt, dann hast du bereits 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 Framework Scrum, sondern ist ein häufiges Problem von Teams und Individuen in Organisationen.

Aus meiner Erfahrung liegt das häufig an 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 Framework hat fünf Events. Davon sind vier typischerweise Meetings. Wenn wir auch noch davon ausgehen, dass das Backlog Refinement als regelmäßiges Meeting durchgeführt wird, dann haben wir alles, was wir brauchen.

Diese Meetings brauchst du, um dein komplexes Produkt zu entwickeln. Dabei sind alle Aktivitäten zur Verwaltung deiner Scrum Implementierung enthalten. 

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."

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."

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 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 Rahmenbedingungen. 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 wirst du 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 uns ü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 es nun, wenn wir von der Kapazität des Entwicklungsteams sprechen? Die Kapazität eines Teams ist die Zeit, die es in den Sprints tatsächlich verbringt. Wenn wir zwei Wochensprints durchführen 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.
  • Die restliche Zeit könnten der Product Owner mit dem Entwicklungsteam für Schätzworkshops, Refinements, etc. benötigen. Zudem verwendet 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 wie in die Organisation. Im folgenden siehst du beispielhaft so einen Sprint Meeting Plan (ohne Backlog Refinement).

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

Was du weiter für den Meeting Overhead und die Sprints beachten musst!

Es gibt neben den konkreten Zeiten für die Sprints noch weitere Dinge, die du in Betracht ziehen solltest. Dazu gehört es sich in der Organisation auf die Suche nach Synchronisationswegen zu machen. Kann dein 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

Wir brauchen eine Anpassung!

Sei bitte mit Anpassung immer vorsichtig. Scrum funktioniert nur als Ganzes. Auch wenn du aus dem Scrum Guide lediglich Teile nutzen kannst, 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. Orientiere dich  bitte an den oben genannten Werte und Zeiten. Stellst du dann fest, dass du andere Bedarfe an die Zeiten hast, dann nutze bitte unbedingt deine Retrospektive und beleuchte deinen Prozess und deine Anforderungen genau. Scrum basiert auf der empirischen Prozesskontrolle, du machst also Erfahrungen und adaptierst 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 unter Umständen Jahre dazu, diese Anwendung zu perfektionieren. Du musst Scrum richtig anwenden und wirst dann auch keinen Meeting Overhead spüren. Denke bitte daran, wenn du einen Meeting Overhead wahrnimmst, dass du sehr wahrscheinlich Anpassungen an Scrum vorgenommen hast, die nicht optimal sind. Das liegt häufig an der Parallelität von Scrum zu bestehenden Initiativen und an Teilzeitteams.

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt.

Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben.

Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen.

Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

>