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...
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:
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:
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).
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.
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.
