Früher dachte ich, ich würde die Scrum Events erfolgreich moderieren, wenn ich folgende Punkte beachtete:
- Ich wiederholte das Ziel des Meetings, um sicherzustellen, dass es von allen verstanden wird.
- Ich erarbeitete im Voraus die Meeting-Agenda und präsentierte sie dann lediglich dem Team.
- Ich entschied, welche Themen zum Meeting passten und welche auf den Themen-Parkplatz verschoben werden sollten.
- Während des Meetings lenkte ich jede Diskussion, die Konfliktpotenzial barg, auf den Themen-Parkplatz.
- Wenn ich das Team innerhalb der festgelegten Zeit durch die Agenda moderierte, war ich besonders stolz auf meine Effizienz.
Häufiges Resultat dieses Vorgehens:
- Ein Sprint-Ziel, hinter dem nicht jeder im Team stand.
- Im Sprint Planning wurde die Arbeit nur koordiniert, aber wirkliche Zusammenarbeit im Sprint fehlte.
- Halbherzige Retrospektiven-Verbesserungen, die meist schon am nächsten Tag keine Beachtung mehr fanden.
Was ist das Problem bei diesem Vorgehen?
Über die Jahre habe ich gelernt, dass dieser Ansatz effizient erscheinen mag, aber keinesfalls Erfolg verspricht.
Es fehlt an Commitment des Teams.
Ich glaube, Commitment entsteht immer dann, wenn die Mitglieder im Team selbst entscheiden dürfen. Wenn sie ihre Arbeit selbst managen dürfen. Seitdem ich das realisiert habe, gestalte ich Scrum Events anders. Ich gestalte sie so, dass sie Selbstmanagement fördern. Meine Facilitation soll zum Mitmachen und sich Einbringen anregen.
Wie mir das gelingt?
Die Anatomie der Scrum Events
Eigentlich ist es nicht schwer. Schauen wir uns gemeinsam die Events in Scrum an. Betrachte ihre Anatomie, dann wird dir auffallen, dass sie alle einem ähnlichen Muster folgen.
In jedem Event
- gibt es einen klaren Zweck,
- werden Artefakte überprüft,
- werden Artefakte angepasst,
- gibt es eine feste Timebox,
- geht es um die Zusammenarbeit.
Betrachten wir diese Anatomie mal am Beispiel des Sprint Plannings:
Im Sprint Planning
- gibt es einen klaren Zweck: Definition des Sprint-Ziels und Erstellung des Sprint Backlogs,
- werden Artefakte überprüft: Product Backlog,
- werden Artefakte angepasst: Sprint Backlog,
- gibt es eine feste Timebox: bis zu 8 Stunden, bei einem Sprint von 4 Wochen,
- geht es um die Zusammenarbeit: Product Owner und Entwickler erarbeiten zusammen ein Ziel für diesen Sprint, Entwickler erarbeiten einen Plan, wie das Ziel erreicht wird (Sprint Backlog), und Stakeholder sind nach Einladung erwünscht.
Ähnliches gilt für Daily Scrum, Sprint Review und Sprint Retrospektive. Das bedeutet, verstehst du die Anatomie der Events, kannst du ein universelles Vorgehen entwerfen, jedes Event zu facilitieren. Du erhältst eine Blaupause für die Facilitierung der Scrum Events.
Meine Blaupause besteht aus diesen vier Schritten:
- Wie lautet der Zweck des Events?
- Agenda erstellen und Timeboxen festlegen
- Zusammenarbeit in den einzelnen Timeboxen fördern
- Verbesserungen für das nächste Mal finden
Ich nenne diese Schritte eine Blaupause, da sie dir ermöglichen, mit der Facilitation der Scrum Events zu beginnen. Am Anfang kannst du dein Vorgehen abpausen und dann Schritt für Schritt weiterentwickeln.
Besprechen wir die Schritte der Blaupause nun im Detail:
Schritt 1: Wie lautet der Zweck des Events
Um Selbstmanagement zu ermöglichen, brauchen wir ein Ziel, welches wir erreichen wollen.
Deshalb wiederhole zu Beginn des Termins noch mal den Zweck des Scrum Events. Ich verwende dazu gerne diese Einladung für das Sprint Planning:
„Vielen Dank, dass ihr zur Planung des Sprints gekommen seid. Ziel dieses Events ist es, das Ziel für diesen Sprint zu finalisieren und einen Plan für die Erreichung des Ziels zu erarbeiten.“
Diese Einladung hilft allen, im Termin anzukommen und sich auf die bevorstehende Aufgabe einzustellen.
Schritt 2: Agenda erstellen und Timeboxen festlegen
Auch Selbstmanagement benötigt einen Rahmen.
Ein häufiger Irrglaube ist, dass Selbstmanagement ohne Regeln oder Rahmenbedingungen stattfindet. Wenn es keine Grenzen gibt, innerhalb derer sich das Team selbst organisiert, dann gleicht die Arbeit einem Chaos. Um Selbstmanagement zu fördern, kann dieser Rahmen auch gemeinschaftlich gesetzt werden. In einem Scrum Event mit diesen drei Fragen:
- Welche Themen sollten wir besprechen, um den Zweck des Events zu erreichen?
- Wie viel Zeit sollten wir uns für jeden dieser Punkte nehmen?
- Wie gehen wir damit um, wenn die Zeit für einen Punkt aufgebraucht ist oder neue Agendapunkte auftauchen?
Stelle deinem Team diese drei Fragen und halte die Antwort in Form einer Agenda für den Termin fest.
Hier ein Beispiel eines Sprint Plannings:
- Der Product Owner stellt noch mal die wichtigsten User-Stories vor (15 min).
- Die Entwickler überlegen, wie viele der Einträge in diesem Sprint realistisch sind, basierend auf Kapazitätsplanung (15 min).
- Entwickler brechen die Einträge in Tasks herunter (90 min).
- Das Team definiert ein Ziel für diesen Sprint (15 min).
- Mini-Retrospektive (15 min)
(Wenn wir für einen Punkt mehr Zeit brauchen, dann verlängern wir die Timebox um 15 min. Die gesamte Timebox ist 3 h.)
Dir fällt bestimmt sofort auf, dass das Team das Sprint-Ziel am Ende festlegen will. Dies kann aus vielerlei Hinsicht problematisch sein. Da es sich um ein reales Beispiel von mir handelt, lasse ich es so. Es bietet uns später die Möglichkeit zu erklären, wie du mit solchen Situationen umgehen kannst. Aber erst mal gilt die Facilitation-Devise:
Als Facilitator unterstützt du das Team, indem du ihm hilfst, möglichst einfach das Ziel des Events zu erreichen.
Schritt 3: Zusammenarbeit in den einzelnen Timeboxen fördern
Nachdem das Team seine eigene Agenda erstellt hat, wie es den Zweck des Scrum Events erreichen will, unterstütze ich als Facilitator bei der Zusammenarbeit.
Dazu frage ich die Mitglieder des Teams vor jedem Agendapunkt, wie sie diesen erreichen wollen und ob sie Unterstützung bei der Moderation brauchen. Diese Form einer dynamischen Facilitation des Termins hilft, auf etwaige Konflikte und Probleme einzugehen.
Hier ein Liste von Facilitation-Techniken, die beim Sprint Planning zum Einsatz kommen:
Agendapunkt 1: Der Product Owner stellt kurz die Einträge vor und dann hat jeder Entwickler reihum die Möglichkeit, eine Frage zu stellen. Hier kann ein Redetoken helfen.
Agendapunkt 2: Offene Diskussion mit einer Uhr im Hintergrund, damit das Team die Zeit nicht aus den Augen verliert.
Agendapunkt 3: Jeder Entwickler schreibt die Tätigkeiten, die aus seiner Sicht für die Erledigung des Product-Backlog-Eintrags nötig sind, auf einzelne Zettel. Danach gruppiert das Team die Zettel, eliminiert Duplikate und stellt eine Liste an Tasks auf. Diese Technik ist auch als „All eyes, all ears“ bekannt.
Agendapunkt 4: 1-2-4-All oder offene Diskussion und römisches Voting, damit jeder seine Idee einbringen kann. Wenn alle im Team zustimmen, wurde ein Ziel gefunden.
Wenn du dich jetzt fragst, was das alles für Techniken sind, dann wirf gerne einen Blick auf diese Liste. Und da wir gerade dabei sind: In meinem „Professional Scrum Facilitation Skills“-Training zeige ich dir, wie du diese Techniken Schritt für Schritt anwendest.
Nachdem der Agendapunkt 4 abgeschlossen ist, kommen wir zum letzten Punkt im Sprint Planning:
Schritt 4: Verbesserungen für das nächste Mal finden
Dies geschieht mit einer kurzen Mini-Retrospektive.
Oben habe ich bereits angedeutet, dass ich – obwohl ich es als Scrum Master problematisch fand, dass das Sprint-Ziel am Ende definiert wurde – erst mal nichts eingewendet habe. Es fiel mir sehr leicht, da ich gleichzeitig den Agendapunkt „Mini-Retrospektive“ auf die Agenda genommen hatte.
Dieser Punkt bietet dem Team die Möglichkeit, das Event beim nächsten Mal besser zu machen.
Im ersten Schritt bitte jeden im Team Feedback zu geben. Hierfür kannst du einen ROTI-Feedback-Strahl mit der folgenden Frage verwenden:
„Hat sich deine investierte Zeit für dieses Scrum Event gelohnt – in Relation zu dem erzielten Nutzen für deine tägliche Arbeit?“
Mit folgenden Auswahlmöglichkeiten:
- Wertlos. Die investierte Zeit ist verloren.
- Geringer Nutzen, es wurde zu viel Zeit für zu wenig Nutzen investiert.
- Ausgewogenes Verhältnis zwischen Nutzen und investierter Zeit.
- Der Nutzen überwiegt die investierte Zeit.
- Wertvoll. Der Nutzen ist groß im Verhältnis zur investierten Zeit.
Im zweiten Schritt bitte die Mitglieder im Team spezifische Verbesserungsvorschläge zu geben. Hier hast du nun auch die Möglichkeit, als Scrum Master Vorschläge zu machen. Etwa das Sprint-Ziel zu Beginn des Sprint Plannings zu definieren. Als Team solltet ihr euch auf eine Verbesserung für das nächste Mal einigen.
Und nun kommt der wichtigste Punkt:
Frage das Team, ob du sein Einverständnis hast, zu Beginn des nächsten Events, die Verbesserung umzusetzen.
Angenommen das Scrum Team hat sich darauf geeinigt, im nächsten Sprint Planning mal damit zu beginnen, ein Sprint-Ziel zu definieren, dann solltest du es im Schritt 2 „Agenda erstellen und Timeboxen festlegen“ darauf hinweisen und den Punkt auf die Agenda nehmen sowie an die passende Stelle im Meeting setzen.
Nun siehst du auch, wie die Blaupause funktioniert.
Die vier Schritte sind immer die gleichen, aber die konkrete Umsetzung ändert sich basierend auf dem Feedback des Teams, was das Event beim nächsten Mal noch besser machen könnte. Mit diesem Vorgehen hilfst du deinem Team Schritt für Schritt einen Prozess zu entwickeln, wie es sich selbst managen kann.
Ich hoffe, meine Blaupause hilft dir bei der Arbeit mit deinen Team. Wenn du Fragen oder Anregungen hast, schreibe sie mir bitte in die Kommentare.