Direkt zum Hauptbereich

Retrospektiven mit Ergebnissen

Die Sprint Retrospektive ist ein wichtiges und häufig unterschätztes Format. Es gibt einen zentralen Begriff, den gerade neue Teams übersehen: die Lieferfähigkeit.

Was ist Lieferfähigkeit?

Das Ziel der Sprint Retrospektive ist das Verbessern der Lieferfähigkeit. Die erste Frage ist also immer: Haben wir geliefert?  

  • Wenn nein: was können wir tun, um (überhaupt) zu liefern? 
  • Wenn ja: reicht das, um unser Produktziel zu erreichen und um die Stakeholder zufrieden zu stellen?

Die Lieferfähigkeit bezieht sich immer auf die Erwartungen der Stakeholder und nicht auf die Fähigkeiten des Scrum Teams. Es kann also sein, dass das Scrum Team etwas liefern sollte, wozu es (noch) nicht alle Fähigkeiten besitzt.

Sportler üben regelmäßig, um sich zu verbessern (Foto von Nicolas Hoizey bei Unsplash)

Die Stakeholder freuen sich, wenn sie etwas bekommen, dass ihnen Fortschritte in Richtung eines Ziels erlaubt:

  • Sie können Dinge tun, die sie vorher nicht tun konnten.
  • Sie können Dinge besser tun als vorher.
  • Sie machen weniger Fehler oder unerwünschte Dinge.

Jeff Sutherland fasst in einem Video bei YouTube zusammen, was für ihn die Retrospektive bedeutet./1/ Es ist wichtig, dass wir uns häufig - also nach jedem Sprint - zur Retrospektive treffen, um Verbesserungen direkt umzusetzen. Deswegen finde ich auch Release- oder Projektretros oder Lessons-Learned-Sitzungen nutzlos, weil wir kaum eine Chance haben, die Verbesserungen in die Tat umzusetzen.

Woran scheitert die Lieferfähigkeit?

Es gibt einige Punkte, die man sich in der Sprint Retrospektive ansehen kann. (Die Scrum.org legt auf den korrekten Begriff wert: Sprint Retrospektive, weil sie sich auf den Sprint bezieht.)

  • Dem Scrum Team fehlen die Fähigkeiten, um zu liefern. Dann kann man mit einer Skillmatrix anfangen und eine Strategie festlegen, wie man diese Lücken schließt.
  • Dem Scrum Team fehlen die Werkzeuge, um zu liefern. Dann kann die Sprint Retrospektive genutzt werden, um Werkzeuge zu suchen und um sich einzuarbeiten.
  • Das Scrum Team hat Abhängigkeiten zu anderen Abteilungen, die nicht oder nicht rechtzeitig geliefert haben. Hier lohnt sich es, mit diesen Abteilungen zusammen eine Retro zu machen.
  • Das Scrum Team wurde durch andere wichtige Dinge (z. B. Störungen) davon abgehalten zu liefern. Hier gibt es oft wiederkehrende Muster. Vielleicht sollte man sich weniger vornehmen.
  • Es gibt Konflikte im Scrum Team über das weitere Vorgehen.

Keiner erwartet, dass in der ersten Sprint Retrospektive alle Probleme gelöst werden. Man darf sich auch Hilfe holen. Aber es ist wichtig, dass sich das Scrum Team einen Plan macht, wie es seine Probleme konkret löst.

Wie setzt man sich Ziele für Verbesserungen?

Die guten Retrospektiven fangen mit einer konkreten Fragestellung an, z. B. "Wie bekommen wir das hin, dass wir innerhalb des Scrum Teams nicht von einzelnen Spezialisten abhängig sind, um Dinge fertig zu machen?"

Manchmal liegen die Ziele auf der Hand. Manchmal rätselt das Team. In solchen Fällen gibt eine eine einfache Regel: Das Gute verdoppeln, das Schlechte halbieren.

  • Wie können wir die gleichen Ergebnisse in der Hälfte der Zeit liefern?
  • Wie können wir in der gleichen Zeit die doppelte Menge an Features ausliefern?

Solche Fragen zwingen uns, grundsätzlich alles zu hinterfragen:

  • Welche Schritte brauchen wir, um zu liefern?
  • Was ist der Sinn der einzelnen Schritte? Brauchen wir sie wirklich?
  • Gibt es eine bessere Reihenfolge?
  • Wann, wie und wo tun wir diese Schritte? Welche Qualifikation ist dazu nötig?

Ich finde es ebenfalls sinnvoll, wenn sich das Scrum ein Mind Map macht, in der es sich die Zusammenhänge für die Lieferfähigkeit sichtbar macht. /2/

Was sind die Ergebnisse einer Sprint Retrospektive?

Hier ist eine Liste möglicher Ergebnisse:

  • Es gibt eine Skillmatrix mit den Fähigkeiten, die das Scrum Team braucht, um etwas zu liefern. Wir wissen, wer etwas kann, wie viele Leute wir mindestens für eine bestimmte Fähigkeit brauchen und wir haben eine Plan, wie wir die Wissenslücken schließen. /3/
  • Es gibt neue Musterdokumente oder Vorlagen, die wir für wiederkehrende Tätigkeiten nutzen können und dabei Zeit sparen.
  • Wir haben neue Werkzeuge (Software oder Skripte), mit denen häufige Schritte automatisiert wurden.
  • Wir haben mit anderen Abteilungen Vereinbarungen getroffen, um deren Zulieferungen sicher zu stellen.
  • Wir haben unsere Prozessveränderungen in einer neuen Version der Definition of Done festgehalten.

Ich mag offene Formate wie Open Space (wenn wir viele Scrum Teams haben) oder Lean Coffee für die Sprint Retrospektive. Sie werden immer mit der Frage eröffnet: Was müssen wir besprechen und vereinbaren, um unsere Lieferfähigkeit signifikant zu verbessern? 

Da kommen immer Ideen. Sportler:innen und Musiker:innen wissen, dass das regelmäßige Üben der Schlüssel zu besseren Leistungen ist. Daher machen gute Scrum Teams an jedem Sprintende eine Sprint Retrospektive.

Anmerkungen

  • /1/ Jeff Sutherland: Scrum: Inside the Sprint Retrospective, Aufzeichnung von OpenView Ventures vom 03.03.2011, abrufbar unter https://www.youtube.com/watch?v=MFLvQXMNrO8 
  • /2/ Jan Fischbach: Eine Anleitung zum Einstieg in kontinuierliche Verbesserung, Teamworkblog, erschienen am 14. Jun 2021, abrufbar unter https://www.teamworkblog.de/2021/06/eine-anleitung-zum-einstieg-in.html  
  • /3/ Das Buch "Toyota Talent" gibt hier eine ausführliche Anleitung. Liker, Jeffrey K. ; Meier, David: Toyota Talent : Developing Your People the Toyota Way. Madison: McGraw Hill Professional, 2007.

 

Kommentare

Beliebte Posts aus diesem Blog

Outlook-Aufgabenliste: bitte nicht die Aufgaben des ganzen Teams!

Am Tag der Arbeit kommt eine Lösung, nach der ich schon so oft gefragt wurde: Wie schaffe ich es, dass meine Outlook-Aufgabenliste nur meine eigenen Aufgaben anzeigt und nicht auch die E-Mails, die meine Kollegen gekennzeichnet haben oder Aufgaben, die einfach in einem gemeinsamen Postfach stehen?

Kategorien in Outlook - für das Team nutzen

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

E-Mail-Vorlagen gemeinsam nutzen (Outlook)

Mittlerweile wird praktisch alle Routine-Korrespondenz in Outlook erledigt. Was liegt da näher, als ein gutes Set von Vorlagen zu erstellen und diese gemeinsam in Team zu nutzen? Leider hat Microsoft vor diesen – an sich simplen – Wunsch einige Hürden gebaut.

Protokolle in OneNote - neue Ideen für's neue Jahr

Protokolliert Ihr Team seine Besprechungen in OneNote? Das geht einfach, schnell ist teamfähig und hat eine exzellente Suchfunktion. Die beliebte Fragen "Wann haben wir eigentlich beschlossen, dass..." ist so schnell beantwortet. Darum wird OneNote an dieser Stelle immer beliebter. In meinen Seminaren dazu sind gute Ideen entstanden, die ich hier weitergeben will.

Das Ubongo Flow Game

Spiele bieten eine gute Gelegenheit, zeitliche Erfahrungen zu verdichten und gemeinsam zu lernen. Karl Scotland und Sallyann Freudenberg haben im Mai 2014 das Lego Flow Game veröffentlicht. Wir haben die Spielidee übernommen, aber das Spielmaterial gewechselt. Statt Legosteinen benutzen wir Material aus Grzegorz Rejchtmans Ubongo-Spiel. Hier präsentieren wir die Anleitung für das Ubongo Flow Game.

OneNote Prinzipien: Zugriffsrechte und Speicherorte

OneNote ist praktisch – ohne jeden Zweifel. OneNote ist auch einfach und intuitiv zu bedienen… Ja… so am Anfang. Doch früher oder später kommen Fragen wie: - wer genau hat eigentlich wie Zugriff auf die Daten? Wie ist das mit Synchronisation zwischen Büro-PC und Smartphone oder iPad? Wie funktioniert OneNote auf dem SharePoint? Auf diese Fragen findet sich die Antwort nicht ganz so leicht. Ich versuche hier die nicht ganz so offensichtlichen Zusammenhänge deutlich zu machen und "gern genommene" Fallen zeigen.

Beispiel für eine Partyplanung mit Scrum

Wer sich neu mit Scrum beschäftigt, ist vielleicht überwältigt von den ganzen Fachbegriffen. Dann sieht man vielleicht gar nicht, wie einfach die einzelnen Elemente von Scrum sind. Deshalb hier ein einfaches Beispiel für die Vorbereitung einer Party mit Hilfe von Scrum.

Tooling #6: Take It To The Team

Gelegentlich fragen mich Menschen nach den wichtigsten Tools und Herangehensweisen für meine Arbeit. Einige davon habe ich  hier   im Blog schon vorgestellt. Heute stelle ich mein Schweizer Taschenmesser für erfolgreiche Zusammenarbeit vor: Take it to the team!

Warum Workflows so viel versprechen. Und warum sie fast nichts davon erfüllen.

Es gibt zunehmend Unternehmen und öffentliche Einrichtungen, die Dokumentenmanagementsysteme einführen. Die "DMS" sind längst aus ihrem Namen herausgewachsen - die guten Produkte unter ihnen "managen" nicht nur Dokumente, sondern Unternehmensinformationen aller Art. Und vor allem strukturieren sie sie so, dass sie auch die Vielzahl von Prozessen, Kontakten, Vorgängen, Notizen überschaubar halten. Es gab Vorschläge, die Bezeichnungen entsprechend zu ändern - ECM ("Enterprise Content Management") oder EIM ("Enterprise Information Management"). Aber keine hat sich so richtig durchgesetzt. Bleiben wir also bei DMS. Tendenziell ersetzt ein DMS Windows als allgegenwärtige Arbeitsoberfläche (oder besser: Arbeitsuntergrund). Bei der Einführung von DMS spielen aber falsche Erwartungen der Entscheidungsträger eine große Rolle. Es werden große Hoffnungen gesetzt in Features, über die DMS nicht verfügen. Und auf der anderen Seite werden Dinge, die uns das Le

Some simple questions to generate more value with Scrum

Scrum becomes more mainstream. I also see many implementations of Scrum, where key elements are missing. With this confusion the name Scrum is burnt, because the faulty implementation of the framework is causing more harm and does not bring the desired benefits. I see the root causes of this problem in strong biases and sticky working habits. But also in Scrum training sessions, in which participants struggle to understand how Scrum works and why it is different to their existing ways of working. In these cases, I see trainers becoming defensive and trying to convince participants of the superiority of Scrum. In this blog post I’d like to help with couple of questions, that could help new Scrum teams define useful Product Goals & Product Increments figure out small incremental steps to improve their way of working – either in their team or outside their team in the organization. They could also help trainers to flip the situation: Instead of trying to convince their audience they c