Das Retrospektive Meeting

Durchführung eines Retrospektive Meetings

Am Ende eines Sprint-Zyklus werden ein Sprint Review Meeting und eine Sprint Retrospektive abgehalten. Das Sprint Review Meeting dient der Begutachtung des am Ende des Zyklus fertig gestellten Projektteils mit dem gesamten Team (nebst Product Owner und Scrum-Coach) sowie den Stakeholdern. Hier geht es ausschließlich um das Produkt. Demgegenüber wird bei der Sprint Retrospektive dem Team eine feste Zeit eingeräumt, sich mit der eigenen Arbeitsweise auseinanderzusetzen. Dieses Meeting ist vergleichbar mit einem klassischen "Lessons Learned" am Ende eines Projekts, nur dass es nach jedem Sprint erfolgt und sich so die positiven Folgen der teameigenen Optimierung schon während der Projektphase selbst niederschlagen. Damit bildet die Retrospektive einen großartigen Hebel für die stetige Verbesserung der Arbeitsweise des Teams und damit auch mittelbar des gesamten Projektergebnisses. Die typischen Fragestellungen im Retrospektive Meeting sind:

„Wenn Sie nur einen einzigen Punkt der Scrum-Methodik übernehmen wollen, dann doch bitte die Retrospektive.“

• Was hat an diesem Sprint besonders gut funktioniert? Was wollen wir auch weiterhin machen? • Was hat nicht gut funktioniert? Wo müssen wir etwas ändern? • Was sollten wir beginnen zu tun und was sollten wir verbessern?

Mentos, Scrum Coach ist die Vorbereitung der einzelnen Teilnehmer unabdingbar.

Bei einem Retrospektive Meeting nehmen alle Team-Mitglieder teil (Abb. 1). Neben den Projektteilnehmern und dem Scrum-Master auch der Product Owner. Oftmals gibt es Vorbehalte, da der Product Owner meist auch Führungskraft ist. Für den Erfolg einer Retrospektive ist ein Umfeld notwendig, bei dem frei diskutiert werden kann. Nach meiner Erfahrung bewährt es sich, den Product Owner erst zur zweiten Hälfte des Meetings dazu zu bitten. Falls bestimmte Themen angesprochen werden sollen, die die Zusammenarbeit mit Kollegen außerhalb des Projektteams betreffen, ist es sinnvoll, dass auch diese Kollegen teilnehmen.

Dazu gehört das Festlegen eines Themenfokus. Dieser ergibt sich aus den gemachten Erfahrungen des letzten Sprints (der letzten 2-4 Wochen). In der Anfangsphase eines Projektes wird es meist weniger konkrete Themen geben, sondern eher die generelle Zusammenarbeit innerhalb des Teams zu diskutieren sein. Nach einer Phase des Einpendelns und der Umsetzung der gemachten Erkenntnisse verlagert sich der Verbesserungsfokus meist auf speziellere Themen.

Die Teilnehmer bereiten sich individuell auf diesen Themenfokus vor und sammeln konkrete Beispiele. Dabei geht es nicht nur um Dinge, die schlecht liefen und verbessert werden müssen, sondern auch um Beispiele von Vorgehensweisen, die gut liefen. Auch Ideen, die das Team ohne konkreten Anlass im nächsten Sprint probieren möchte, werden thematisiert.

Das Meeting ist üblicherweise mit 90 Minuten angesetzt. Damit diese Zeit gewinnmaximierend genutzt werden kann,

Während des Meetings findet dann die Auswertung der durch die Teilnehmer mitgebrachten Einsichten statt. Hier hat sich ein "Insight-Board" bewährt (Abb. 2). Die Themen werden dabei nach drei Kategorien geordnet:

¥ -.%/%(012"#* ¥ 345%267%*8%9%)%* ¥ :"45%267%* ;,.&(%./"()%(* ¥ <%&4%##%&"()#= 4,>291)*

• Dinge, die weiter so gemacht werden sollen. • Dinge, die unbedingt verändert werden müssen. • Dinge, die das Team ohne konkreten Anlass probieren möchte.

Durch diese Anordnung fallen schnell Themen auf, die von mehreren Teammitgliedern zugleich eingebracht werden und damit eine höhere Priorität bei der Auswertung erfahren sollten (z. B. Abb. 2 Nr. 1). Aus diesen gewonnenen Einsichten werden im nächsten Schritt nun konkrete Maßnahmen abgeleitet. Es hat sich bewährt, diese Maßnahmen ebenso mit User Stories zu hinterlegen, da auch deren Umsetzung Zeit in Anspruch nimmt. Meist gibt es mehr abgeleitete Maßnahmen, als Zeit zur Verfügung steht. Nach wie vor steht die Entwicklung eines Produktes oder die Durchführung eines Projekts im Vordergrund. Die nicht sofort umsetzbaren User Stories werden in einem "Insight Backlog" gespeichert und beim nächsten Retrospektive Meeting mit den neuen Maßnahmen neu priorisiert.

Risiken

Vorteile von Retrospektive und Scrum

Ein Meeting zur Besprechung der Arbeitsweise und der Definition von abgeleiteten Maßnahmen ist nichts Neues. Aufgrund des hohen Workloads und weil

2)$3%)45)#6'

¥ :>&"/*-%,/** ¥ !(@%&%*D&15%2'/B',&4%B'%&*("&** **$%((*%B()%9,@%(*

!"#$%&'()&#*+"),-.)'

¥ <%&?(@%&"()#+9,(* !"#$%&'"()* ¥ 8,>291)A* <%&4%##%&"()#= B@%%(* ¥ :'?&2"()*@%#* -%,/)%0C.9#* !(+,##"()* die Retrospektive keinen unmittelbaren Mehrwert am Produkt/Projektergebnis zu haben scheint, wird dieses Meeting oft aufgrund vermeintlich dringenderer fachlicher Themen verschoben. Die Scrum Retrospektive wird nach jedem Sprint durchgeführt. Man nimmt sich Zeit dafür. Dem agilen Ansatz Rechnung tragend, können Erfahrungen und Einsichten direkt und schon in der Anfangsphase umgesetzt werden. Damit wird das Team leistungsstärker. Dies schlägt sich direkt im Projektergebnis nieder.

• Es gibt ein großes Hindernis/Problem, aber es wird nicht angesprochen, beispielsweise aus Angst vor Konsequenzen. Hier muss gerade der Scrum- Master vermitteln und seiner Rolle gerecht werden. • Das Meeting wird genutzt, um Anschuldigungen zu platzieren. Darum geht es aber nicht. Es wird nicht nach einem Schuldigen gesucht, sondern nach einer Lösung. Auch hier ist der Scrum-Master gefragt. • Bei vielen Retrospektive-Meetings wird die Zeit genutzt, Probleme beim Produkt bzw. fachliche Projektprobleme zu diskutieren. Dies findet im Sprint-Review statt. • Das wohl größte Problem ist, wenn geplante Maßnahmen nicht umgesetzt, sondern für fachliche User Stories zurückgestellt werden. Hier hat es sich bewährt, vor dem allerersten Sprint festzulegen, wie viele User Stories aus der Retrospektive in einen Sprint aufgenommen werden.

Auch die emotionale Komponente, dass Mitarbeiter spüren, dass es nicht nur um das Ergebnis geht, sondern auch um den Weg dorthin, ist ein oftmals angesprochener Punkt. Durch eine offene und direkte Kommunikation untereinander wird zugleich das Teamgefühl gestärkt und die Akzeptanz der Fehlerkultur deutlich verbessert.

Beim Retrospektive Meeting sollten Sie die Risiken, welche den Erfolg gefährden können, im Auge behalten. Die Risiken sind:

Ergebnis Scrum-Methode

Am Ende meiner Serie zum Thema Scrum möchte ich die Gelegenheit nutzen und ein paar Erfahrungen teilen.

• Das Meeting wird verschoben, da es sich nicht „direkt mit dem Produkt/ Projekt auseinandersetzt“.

Es gibt viele Projektmanagement-Methoden. Scrum ist eine davon, es gibt auch andere. Scrum passt nicht in jede Organisationsform. Gerade am Anfang hat man das Gefühl, durchgetaktet zu sein und viele Vorschriften befolgen zu müssen. Lassen Sie sich nicht abschrecken. Vielleicht lassen Sie einen Mitarbeiter zu einem Scrum-Master ausbilden. Probieren Sie es, aber setzen Sie sich den Rahmen, ein Projekt komplett nach Scrum durchzuführen bis zum Ende. Beurteilen Sie danach den Erfolg.

Things to keep doing Things to stop doing Things to try

Jochen Wenz arbeitet seit 2007 in den Themenfeldern Lean und Six Sigma. Durch seine Tätigkeiten bei Unternehmen wie Daimler, BASF, Roche und Hornbach konnte er in vielen verschiedenen Anwendungsbereichen sein Wissen vertiefen. Inzwischen arbeitet Jochen Wenz als Lean Plant Manager für Gardner Denver. Neben der Arbeit leitet er den Lean Stammtisch Mannheim und moderiert die größte Lean-bezogene Gruppe auf Xing "Lean for Professionals" mit nahezu 5.000 Mitgliedern.

Scrum ist agil. Nutzen Sie es. Es sagt niemand, dass man die Methode immer genauso befolgen muss, wie die Theorie es verlangt. Finden Sie Ihren eigenen Weg. Aber auch hier: Wenn Sie nichts nutzen wollen, probieren Sie zumindest die Retrospektive. die typischen 75% Abarbeitungskreise, da Themen derart herunter gebrochen werden, dass anstelle des Dreiviertel-Kreises 3 Stories beendet sind und nur eine noch Offene übrig bleibt. Die Transparenz über die noch offenen Themen ist gerade als Projektleiter ein Zugewinn.

Für mich ist Scrum eine Möglichkeit, Geschwindigkeit in die Abarbeitung von Aufgaben zu bekommen. Ich verbanne

Am Ende zählt die Qualität des Ergebnisses für den Kunden (extern/intern). Ich bin inzwischen von agilen Ansätzen überzeugt. Ich bleibe flexibel und kann jederzeit auf neue Einflüsse reagieren. Einem empirischen Prozess folgend entwickelt sich Scrum in der eigenen Organisation stetig weiter. Eine Einführung von Scrum ist deshalb nie beendet. Es impliziert, dass wir permanent hinterfragen und verbessern. Ziel ist es dabei, dem optimalen Prozess möglichst nahe zu kommen, also einem Prozess, der Wert für einen Kunden frei von jeglicher Verschwendung schafft. Genau hier liegt für mich die Verbindung zu Lean.