Skip to main content

Die 3 Arten von Scrum Meetings: So moderierst du als Scrum Master jedes Meeting sicher

September 23, 2024

Gibt es für Scrum Meetings eine Blaupause?

Diese Frage stellt sich wohl jeder Scrum Master. Ich habe viele Jahre nach der Antwort gesucht. Nach einer Anleitung, mit der sich jedes Scrum Event souverän moderieren lässt, wenn ich nur diese Schritte befolge. Bist du auch auf der Suche?

Dann muss ich dich leider enttäuschen.

Was in Scrum Events passiert, lässt sich nicht vorhersagen. Gespräche können hitzig werden oder im Sande verlaufen. Die Zusammenarbeit in einem Team ist einfach zu dynamisch.

Aber nur weil es keine Meeting-Blaupause gibt, heißt das nicht, dass du dich nicht auf die Meetings vorbereiten kannst. Ich nutze hierfür Modelle. Modelle helfen mir, zu überlegen, was passieren könnte, und mich gezielt darauf vorzubereiten. Modelle helfen mir im Meeting, die Gespräche zu einem gemeinsamen Ergebnis zu lenken. Modelle helfen mir am Ende zu reflektieren. Dabei sehe ich, was diesmal gut lief. Außerdem erkenne ich, an welcher Stelle sich das Meeting im Kreis gedreht hat.

Bereit? Dann erkläre ich dir meine drei wichtigsten Modelle, mit denen du jede Art von Scrum Event facilitieren kannst:

Los geht’s mit Entscheidungen:

Scrum Meeting #1: Entscheidungen treffen

Was haben Sprint-Planning, Daily Scrum, Sprint-Review und Sprint-Retrospektive gemeinsam?

Das Ziel ist immer eine Entscheidung.

Betrachten wir die Events und deren Ziel im Detail:

  • Sprint-Planning: Das Scrum Team definiert ein Sprint-Ziel und einen anfänglichen Sprint-Backlog, um das Ziel zu erreichen.
  • Daily Scrum: Die Entwickler beschließen, woran sie heute arbeiten wollen, um dem Sprint-Ziel näher zu kommen.
  • Sprint-Review: Die Stakeholder und das Scrum Team betrachten die aktuelle Version des Produkts. Sie beschließen, was im nächsten Sprint das Wichtigste sein sollte.
  • Sprint-Retrospektive: Das Scrum Team reflektiert die Arbeitsweise des Sprints und beschließt eine Verbesserung für den nächsten Sprint.

Wenn das Ziel jedes Scrum Events eine Entscheidung ist, was bedeutet das als Scrum Master für die Facilitation des Events?

Unser Ziel sollte es sein, die Entscheidungsfindung im Team zu erleichtern. Entscheidungen im Team verlaufen in der Regel in zwei Phasen: 

Die erste Phase wird als „divergentes Denken“ und die zweite Phase als „konvergentes Denken“ bezeichnet.

Hier einige Beispiele für divergentes Denken:

  • Alternativen generieren
  • offene Diskussionen
  • Sammeln verschiedener Perspektiven
  • Vorschläge zunächst nicht bewerten

Und hier einige Beispiele für konvergentes Denken:

  • Alternativen bewerten
  • Zusammenfassung der wichtigsten Punkte
  • Ideen in Kategorien sortieren
  • Beurteilung von Lösungen
  • Entscheidungen treffen

Wie verläuft der Übergang zwischen den Phasen?

Erfahrungsgemäß nicht immer reibungslos. Das Ergebnis ist nicht immer eine Entscheidung, hinter der wirklich jeder im Team steht. Stattdessen „knirscht“ es. Deshalb ist es unsere Aufgabe als Facilitator, jedem im Team den Übergang zwischen divergentem und konvergentem Denken zu erleichtern. Nur wenn alle am Ende des Meetings in der konvergenten Phase angekommen sind, wird eine Entscheidung getroffen. Diese Entscheidung setzt jeder aus freien Stücken um.

Sprint-Planning, Daily Scrum, Sprint-Review und Sprint-Retrospektive sind alles Meetings zur Entscheidungsfindung. Du fragst dich bestimmt, ob es wirklich noch andere Arten von Meetings gibt.

Die gibt es:

Scrum Meetings #2: Lernen steht im Mittelpunkt

Bei welchen Meetings steht für das Scrum Team Lernen im Mittelpunkt und weniger eine Entscheidung?

Mir fallen Schulungen aller Art ein. Zum Beispiel Schulungen für:

  • Entwickler zum Mob-Programming,
  • die Stakeholder und Product-Owner zu unterschiedlichen Schätzverfahren,
  • Mitarbeiter im Unternehmen zu den Scrum Verantwortlichkeiten.

Wo steht Lernen noch im Mittelpunkt? In Communities-of-Practice oder beim Scrum-Master-Austausch. Und ich habe auch schon Sprint-Retrospektiven so gestaltet, dass das Augenmerk darauf lag, dass das Scrum Team etwas lernte. Beispielsweise habe ich in einer Sprint-Retrospektive „Right Sizing“ und Fluss-Metriken erklärt.

Seitdem ich über „Training from the Back of the Room“ gelesen habe, nutze ich dieses vierstufige Modell. Ich verwende es für die Gestaltung und Durchführung jeder Schulung. Das Modell beruht auf den neuesten wissenschaftlichen Erkenntnissen darüber, wie Menschen von Natur aus und normalerweise lernen. Und das Beste:

Das Modell funktioniert für jeden Lerntyp.

Ich muss mir also keine Gedanken machen, wie ich jeden einzelnen Teilnehmer am besten einbeziehe. Mithilfe des Modells kann jeder am meisten aus der Session mitnehmen.

Hier die vier Schritte des Modells in der Übersicht:

  • Verbindungen: Beginne jede Schulung mit „Verbindungen“. Gib dazu den Teilnehmern Zeit, zu rekapitulieren, was sie bereits zum Thema wissen, was sie persönlich lernen wollen und mit wem sie heute in der Schulung sind. Ich starte jede Schulung hierfür mit einer Runde Pair-Share.
  • Konzept: Jetzt kannst du den Lerninhalt erklären. Welche neuen Konzepte sollen die Teilnehmer lernen? Achte beim Erklären darauf, möglichst viele Sinne anzusprechen. Dazu gehören Hören, Sehen, Anfassen, Diskutieren, Schreiben, Nachdenken, Vorstellen, Mitmachen und Weitergeben an andere.
  • Konkrete Praxis: Damit Lernen wirklich passiert, müssen die Teilnehmer ihr neues Wissen auch anwenden. Deshalb solltest du im dritten Schritt der Schulung den Teilnehmern dazu die Möglichkeit geben. Vermittelst du in deiner Schulung keine Fähigkeiten, sondern Informationen, dann nutze für diesen Schritt die Teach-Back-Methode.
  • Schlussfolgerungen: Gib zum Schluss jeder Lerneinheit den Teilnehmern die Möglichkeit, zu reflektieren, was sie gelernt haben und wie sie das Gelernte in Zukunft in ihrer Arbeit integrieren wollen. Deshalb beende ich jede Lerneinheit mit einer Reflexion.

Zum Abschluss noch eine dritte Art von Meeting, der häufig zu wenig Beachtung geschenkt wird:

Scrum Meetings #3: Verbesserung am Produkt entdecken

„Frage niemals Kunden, was sie wollen.“

So oder so ähnlich lautet eine wichtige Faustregel im Produktmanagement.

Diese Faustregel soll Scrum Teams daran erinnern,

  • nicht blind Experten zu vertrauen,
  • sich nicht von Vorurteilen lenken zu lassen,
  • sich für andere Möglichkeiten zu öffnen.

Denn der Erfolg eines Scrum Teams besteht darin, eine Überschneidung aus Wirtschaftlichkeit, Kundenwünschen und Machbarkeit zu finden. Es geht darum, die beste Kombination aus Design, Code, Test und Kundensupport zu finden. Diese Kombination soll sowohl Nutzern als auch dem CFO ein Lächeln ins Gesicht zaubern.

Im Produktmanagement nennen wir das „Entdeckung und Validierung“.

Und diese Aktivitäten finden im Scrum Team im Refinement statt. Als Scrum Master ist es unsere Aufgabe, auch beim Product-Backlog-Refinement zu helfen. Durch Facilitation können wir dem Scrum Team diese Aktivität erleichtern. Ein hilfreiches Modell, um „Entdeckung und Validierung“ zu beschreiben, ist das Doppel-Diamant-Modell. Ursprünglich wurde es von der britischen Regierung entwickelt. Aus meiner Erfahrung eignet es sich gut, um das Spannungsfeld bei „Entdeckung und Validierung“ zu navigieren. In diesem Spannungsfeld befinden sich das Scrum Team und die Stakeholder. Das Ziel von „Entdeckung und Validierung“ ist es, von Ungewissheit und Kreativität zu Gewissheit und Innovation zu gelangen.

Hier die vier Phasen des Doppel-Diamant-Modells:

  • Entdeckung des Problems: Als Erstes geht es darum, das Problem aus Unternehmenssicht zu formulieren. Dazu werden Stakeholder einbezogen und Markt- und Unternehmensdaten analysiert.
  • Validierung des Problems: Nachdem ein Unternehmensproblem „entdeckt“ wurde, stellt sich die Frage: „Welche Bedürfnisse, Wünsche oder Probleme haben unsere Nutzer?“ In diesem Schritt geht es darum, das Problem auch aus der Perspektive der Kunden zu validieren.
  • Entdeckung von Lösungen: Ein gut verstandenes und validiertes Problem ermöglicht dem Scrum Team, Möglichkeiten zur Lösung zu betrachten. Hierbei trägt die vorab erfolgte Validierung dazu bei, dass das Team sich nur Gedanken zu wertvollen Problemen macht. Die Entdeckung von Lösungen kann hier vom Brainstorming bis hin zum Experimentieren reichen.
  • Validierung der Lösung: Abschließend werden die Lösungsoptionen durch das Entwerfen, Durchführen und Lernen aus Experimenten validiert. Experimente bedeuten hier schlussendlich auch die Entwicklung, Lieferung und Messung von Features oder neuen Produkten.

Zum Abschluss: So kannst du noch mehr über die drei Arten von Scrum Meetings lernen

Das Ziel bestimmt die Art des Scrum Meetings. Für Scrum Teams gibt es nur drei relevante Arten von Meetings.

Wir unterscheiden zwischen Meetings

  • zur Entscheidungsfindung,
  • zum Lernen oder
  • als Bestandteil von „Entdeckung und Validierung“.

Manchmal wird noch der Statusreport als vierte Art genannt. Dem kann ich nicht zustimmen. Für den bloßen Austausch von Informationen sollten keine Meetings durchgeführt werden. Dies kann auch kostengünstiger mit dem Ausfüllen einer Tabelle erreicht werden, ohne dazu alle Teammitglieder in einem Raum zu versammeln.

Falls du nach mehr Informationen zu den einzelnen Modellen suchst, findest du hier einige weiterführende Angebote von mir:


What did you think about this post?