Vor einiger Zeit habe ich einen Scrum-Pulse-Webcast für Scrum.org aufgenommen und es hat mir riesigen Spaß gemacht.
Wenn du den Vortrag und die Q&A in voller Länge sehen möchtest, kannst du sie hier ansehen.
Eine der Fragen, die mir am Ende gestellt wurden, hat mich allerdings zum Nachdenken angeregt – und ich habe seitdem immer wieder darüber nachgegrübelt.
Die Frage lautete (48:37 im Webcast):
„Verbesserungen in der Retrospektive betreffen oft grundlegende Probleme, die sich nicht in einem Sprint lösen lassen. Wie geht man mit solchen Verbesserungen um?“
Ich bleibe bei meiner Antwort aus der Q&A: Der Schlüssel für Veränderung ist anzufangen!
Diese Frage wird mir oft gestellt – von angehenden Scrum Mastern, aber auch von bereits erfahrenen Agilen Coaches. Die Realität ist jedoch, dass sich die meisten Menschen nicht einmal dessen bewusst sind, was sie wirklich fragen.
Was sie wirklich fragen, ist: „Wie kann ich wirkungsvolle Retrospektiven durchführen?“
Also Retrospektiven, die auch zu Veränderungen im Team und in der Organisation führen. Nicht einfach nur Retrospektiven-Termine, bei denen im schlimmsten Fall verfahrene Diskussionen stattfinden und im besten Fall lediglich ein weiterer Termin ansteht.
Sondern Retrospektiven mit konkreten Ergebnissen wie:
- Die Stakeholder von Sales und Marketing nehmen auch an „Buy a Feature“-Workshops im kommenden Refinement-Termin teil.
- Nachdem wir unsere Probleme mit der Infrastruktur in einem firmenweiten „Impediment-Newsletter“ geteilt haben, haben wir vielfältiges Feedback von anderen Teams erhalten.
- Indem wir den Punkt „Wir respektieren einander“ des Working-Agreements umformuliert haben, wird klar, dass es kein respektvolles Verhalten ist: „Nicht zum Daily zu kommen, ohne vorher die Team-WhatsApp-Gruppe zu benachrichtigen“. Allerdings ist es respektvoll, „drei Minuten vor 9 mit einem Kaffee im Teamraum zu erscheinen“. So wird greifbar, was „Respekt“ für uns im Team bedeutet.
- Ein Task, der unseren Deployment-Prozess weiter automatisiert, wurde bis zum Ende des Sprints abgeschlossen.
- Die Definition of Done wurde um den neuen Eintrag erweitert: „Pair-Programming: Wenn nicht im Pair gearbeitet wird, muss es dazu einen triftigen Grund geben! ‚Das ist schnell erledigt, das mache ich kurz allein‘, ist keiner!“
Viele Scrum Master werden mit ihrem Team niemals Retrospektiven durchführen, die solche Ergebnisse erzielen.
Dafür gibt es viele Gründe:
- In der Community of Practice der Scrum Master hören sie auf ihre Kollegen, die alle davon berichten, dass Agilität in großen Unternehmen niemals funktionieren wird.
- Im Scrum Training haben sie nicht gelernt, dass die Sprint-Retrospektive wie jedes andere Scrum Event dazu da ist, eine Feedbackschleife zu schließen. Und das passiert nicht ohne die Umsetzung einer konkreten Verbesserung.
- Ihre „Scrum Mentoren“ haben ihnen erklärt, dass Scrum Master reine Coaches sind. Und Coaches arbeiten niemals selbst mit, sondern versuchen durch geschickte Fragen, das Team zum Arbeiten zu motivieren.
- Wenn sie googeln: „Wie führe ich gute Retrospektiven durch?“, erhalten sie immer nur die gleichen Tipps: Um die Teammitglieder zu motivieren, müssten sie das Format der Retrospektive häufig wechseln.
- Aber der wohl gravierendste Grund: Es gibt keine Anleitung dafür, wie sie als Scrum Master eine wirkungsvolle Retrospektive durchführen können. Es gibt Bücher über die unterschiedlichen Phasen von Retrospektiven, aber keines, das zeigt, wie Verbesserungsideen in die Tat umgesetzt werden.
Dies sind alles Gründe, auf die ich in den ersten Jahren als Scrum Master gestoßen bin. Sie haben mich lange in meiner Karriere als Scrum Master zurückgehalten.
Lange Zeit dachte ich, ich mache einen wirklich guten Job als Scrum Master. Stolz berichtete ich meinem Mentor, welche tollen Moderationstechniken ich bei der letzten Sprint-Retrospektive angewandt habe und wie viele Notizzettel jedes Teammitglied beschrieben hat. Daraufhin stellte er mir nur nüchtern die Frage: „Wie häufig hat dein Team in diesem Sprint Software zum Kunden geliefert und wie waren die Rückmeldungen der Nutzer?“
Meine Antwort lautete: „Kein einziges Mal.“
An diesem Tag stellte ich mir zum ersten Mal die Frage:
„Wie kann ich als Scrum Master wirklich wirkungsvoll sein?“
Seit diesem Tag versuche ich, die Frage zu beantworten und einen Weg zu finden, wie ich als Scrum Master wirkungsvoll sein kann.
Dabei bin ich zu vier Einsichten gekommen, wie du als Scrum Master in Retrospektiven wirkungsvoll arbeiten kannst.
- Sei konkret und spezifisch, um zum Handeln einzuladen.
- Ein stehendes Schiff lässt sich nicht steuern.
- Halte das Schiff in Bewegung.
- Verantwortung zu übernehmen ist kein Spaziergang.
Nun lass uns die Einsichten eine nach der anderen besprechen:
Einsicht 1: Sei konkret und spezifisch, um zum Handeln einzuladen.
„Verbesserungsvorschlag gefunden. Puh. Geschafft! Meine Aufgabe als Moderator ist getan.“
Für Moderatoren mag dies zutreffen, aber für Scrum Master, die wirkungsvoll sein wollen, nicht. Damit die Wahrscheinlichkeit steigt, dass aus der Idee auch konkrete Handlungen entstehen, müssen wir sie als Team konkretisieren. Das können wir erreichen, indem wir im Team mindestens drei konkrete Aktionspunkte aufschreiben. Der erste Punkt sollte einfach und reibungslos umzusetzen sein. Die anderen beiden können mehr Aufwand bedeuten oder auch das Einbeziehen von Personen außerhalb des Teams erfordern.
Hierbei hilft die Daumenregel für den Aufwand:
- Aktionspunkt 1: 30 Minuten
- Aktionspunkt 2: 1 Tag
- Aktionspunkt 3: 1 Woche
Ideen ohne konkrete Handlungen sind wertlos. Damit das Team handelt, hilft es, wenn die ersten Punkte konkret und spezifisch sind.
Wenn dein Team als Verbesserung identifiziert hat, einen „Buy a Feature“-Workshop mit den Stakeholdern im Refinement durchzuführen, dann könnte der 30-Minuten-Aktionspunkt aus folgenden Aktivitäten bestehen:
- Eine Liste der Stakeholder anfertigen, die eingeladen werden sollen.
- Einen Meetingraum reservieren.
- Eine Einladung formulieren und an die Stakeholder verschicken.
Durch das Konkretisieren der Lösungsidee sinkt die Hemmschwelle, die Idee auch umzusetzen.
Einsicht 2: Ein stehendes Schiff lässt sich nicht steuern.
Wenn die Retrospektive drei Stunden dauert, sollte die Verbesserungsidee bereits nach einer Stunde gefunden sein.
Der entscheidende Schlüssel für eine wirkungsvolle Retrospektive ist die Aufteilung der Zeit. Teile die Zeit einer Retrospektive in drei gleich lange Abschnitte auf:
- Herausforderungen formulieren und Lösungsideen generieren
- Aktionspunkte konkretisieren
- Ersten Aktionspunkt umsetzen
Du hast richtig gelesen: „Ersten Aktionspunkt umsetzen“ ist Teil der Retrospektive. Veränderungen im Team und in der Organisation sind wie Schiffe. Wenn sie stillstehen, lassen sie sich nicht steuern. Daher solltest du das letzte Drittel der Retrospektive für die Umsetzung des 30-Minuten-Aktionspunkts reservieren.
Damit setzt du das Schiff in Bewegung.
Einsicht 3: Halte das Schiff in Bewegung.
Nachdem das Schiff in Bewegung ist, gilt es, den Kurs sichtbar zu machen. Dazu wird die Herausforderung zusammen mit der Verbesserungsidee und den Aktionspunkten im Sprint Planning in den Sprint Backlog aufgenommen. Nur wenn die Arbeit sichtbar ist, lässt sie sich weiterverfolgen und managen.
Im Daily Scrum kann dann die Arbeit am Aktionspunkt geplant und der Fortschritt sichtbar gemacht werden. In unserem Beispiel gibt es vielleicht schon am ersten Tag des nächsten Sprints eine Rückmeldung, welche Stakeholder am „Buy a Feature“-Workshop teilnehmen werden. Mit dieser Rückmeldung kann das Team die Durchführung des Workshops im Anschluss an das Daily Scrum im Refinement weiter konkretisieren, indem der 1-tägige Aktionspunkt detailliert geplant wird:
- Überprüfen, ob die relevanten Einträge des Product Backlogs verständlich geschrieben sind
- Product-Backlog-Einträge als Karten ausdrucken
- Spielgeld beschaffen
- Agenda für den Workshop erstellen
- Folie mit den „Spielregeln“ des Workshops vorbereiten
Der Fortschritt bei der Umsetzung der Punkte ist dann Gegenstand des morgigen Daily Scrums. Dadurch bleibt das Schiff immer in Bewegung.
Hör nicht auf zu rudern!
Einsicht 4: Verantwortung zu übernehmen ist kein Spaziergang.
Scrum Master zu sein ist eine Führungsposition.
Wenn ich von Führung spreche, meine ich nicht unbedingt disziplinarische Führung, sondern eine Vorbildfunktion. Vorbild zu sein bedeutet: Wenn du eine Idee hast und damit in die Welt gehst und dich umdrehst und dir andere folgen, dann bist du ein Vorbild. Wenn du allein bist, dann warst du nur spazieren.
Als Scrum Master bist du ein Vorbild im agilen Arbeiten.
Agiles Arbeiten bedeutet sich Ziele zu setzen und auf dem Weg dorthin neue Dinge zu entdecken, indem man Dinge tut, innehält, reflektiert und den Kurs anpasst. Agilität beginnt damit, Dinge zu tun, nicht darüber zu reden oder sie zu analysieren. Diese Idee ist auch tief in Scrum verankert. Sie steckt in der Regel, dass ein Sprint nicht länger als einen Monat dauern darf.
Somit bedeutet Scrum Master zu sein, dass du als Erster damit beginnst, die Verbesserungen umzusetzen.
Du fängst damit an, zu überprüfen, ob die relevanten Einträge des Product Backlogs verständlich geschrieben sind. Du fängst damit an, Product-Backlog-Einträge als Karten auszudrucken. Du fängst damit an, Spielgeld zu beschaffen. Du fängst damit an, die Agenda für den Workshop zu erstellen. Du fängst damit an, die Folie mit den „Spielregeln“ des Workshops vorzubereiten. Du bist verantwortlich für die Effektivität des Scrum Teams. Und Verantwortung bedeutet am Ende:
Wenn es niemand macht, dann mache ich es!
Das unterscheidet Scrum Master von Agilen Coaches. Scrum Master übernehmen Verantwortung dafür, dass die Verbesserungen auch umgesetzt werden, und überlassen das Ergebnis der Veränderung nicht ihren Klienten!
Was hilft dir, damit Retrospektiven-Verbesserungen auch umgesetzt werden? Schreibe es in die Kommentare!