Scrum Retrospektiven richtig durchführen
Einer der zentralen Aspekte in der agilen Entwicklung ist die ständige Beobachtung und Verbesserung des Teams, der Prozesse und aller weiteren Teile des Entwicklungsprozesses. Dabei spielt die Retrospektive als Meeting die größte Rolle. Hier soll offenes, ehrliches Feedback ausgetauscht und gemeinsam Lösungen und Verbesserungsideen besprochen werden. Aber wie sorgt man dafür, dass alle Stimmen im Team gehört werden, ohne einzelne Personen zu einer Aussage zu drängen? Wie stellt man sicher, dass sich nicht immer die Ideen durchsetzen, die am lautesten gerufen werden? Wie kann man eine konstruktive Kritik herbeiführen, mit der sich keiner angegriffen fühlt?
Ein großer Teil des Erfolgs des Meetings liegt hier in den Händen des Scrum Masters. Daher werden wir uns nun mit wichtigen Aspekten der Retrospektive beschäftigen und Überlegungen anstellen, wie diese durch den Scrum Master bestmöglich behandelt werden können.
Wie wird eine Retrospektive gestaltet?
Generell hat eine Retrospektive keine vorgeschriebene Struktur. Dennoch gibt es Ideen zur Strukturierung einer Retrospektive. In diesem Artikel werde ich eine auf meine Teams angepasste Struktur vorstellen. Diese werde ich im Folgenden detaillierter ausführen.
- Rückblick auf die letzte Retro
- Erklärung des Ablaufs der folgenden Retro
- Feedback aus dem Team sammeln
- kurze Erklärung und Gruppierung der Informationen
- Diskussion im Team über die wichtigsten Punkte
- To-dos für den nächsten Sprint formulieren
- positives Ende finden
Diese Struktur ist eine reine Empfehlung und sollte keineswegs als feste Strukturvorgabe verstanden werden. Wenn es die Situation erfordert, sollte der Scrum Master nach eigenem Ermessen von dieser abweichen. Im Mittelpunkt steht weiterhin das Team mit all seinen Sorgen und Ideen.
1. Rückblick auf die letzte Retro
Am Anfang einer Retro sollte der Scrum Master die To-dos der letzten Retro nochmals gemeinsam mit dem Team besprechen. Einerseits kommt das Team so wieder in das Thema rein. Andererseits wird so auch überprüft, welche vereinbarten To-dos das Team durchgesetzt hat, welche noch nicht umgesetzt wurden und welche Maßnahmen vielleicht für das Team auch nicht zielführend waren. Auch wenn das Team die Maßnahme selbst beschlossen hat, kann es passieren, dass diese keinen Mehrwert für das Team bringt. Dann sollte diese Maßnahme auch wieder eliminiert werden. Diese Entscheidung sollte aber immer vom Team getroffen werden.
2. Erklärung des Ablaufs der folgenden Retro
Eine Retro sollte immer an das Team und seine momentane Situation angepasst werden. Es ist wichtig, ab und zu unterschiedliche Retrospektiven zu wählen. Jede Retro hat spezifische Fragen, die sie behandelt und bringt so verschiedene Problembereiche zutage. So werden einige Retrospektiven eher Prozessprobleme aufzeigen, während andere eher das Thema Teamwork behandeln usw. Auch wird sich das Team mit der Zeit langweilen und einfach immer wieder dieselben Antworten in der Retro ansprechen, wenn man immer nach dem gleichen Schema vorgeht. Daher sollte der Scrum Master sich Gedanken machen, wann welche Retro für welches Team passend sein könnte. In diesem Schritt erkläre ich kurz, wie die Retro heute ablaufen wird und was die Teilnehmer zu tun haben. Auch offene Fragen zum Ablauf sollten gleich hier mit dem Team geklärt werden.
3. Feedback aus dem Team sammeln
Nachdem der Ablauf der Retro erklärt wurde, gibt das Team seinen Input auf die in der jeweiligen Retro gestellten Fragen oder Aufgaben. Dieser wird meist auf Zettel, Karten oder Sticky Notes geschrieben. Dabei sollte der Scrum Master dem Team sowohl Zeit zum Nachdenken als auch zum Aufschreiben geben. Teilweise werden hier feste Zeitspannen, wie z. B. 10 Minuten vorgeschlagen. Oft macht es aber mehr Sinn auf das Team zu schauen und darauf zu achten, wer noch nachdenkt und wer noch am Schreiben ist. Wenn die 10 Minuten deutlich überschritten werden, sollte der Scrum Master die Zeit abbrechen, da im Anschluss noch genügend Zeit bleiben sollte, um das Feedback im Team zu besprechen und hilfreiche Maßnahmen daraus abzuleiten (siehe 4.). Bei Chrono24 beträgt der Zeitrahmen für die gesamte Retrospektive meist eine Stunde.
4. Kurze Erklärung und Gruppierung der Informationen
Nun geht das erste Teammitglied an die Pinnwand, das Flipchart oder Ähnliches. Hier stellt jeder seine Zettel nacheinander vor, erklärt in ein bis zwei Sätzen, wieso er diese Anmerkung aufgeschrieben hat und klebt die Zettel dann an die entsprechende Stelle. So trägt reihum jedes Teammitglied etwas zu dem Gesamtbild bei. Wenn alle ihre Zettel geklebt und erklärt haben, sollte das Team gemeinsam entscheiden, welche Zettel man nach Themen gruppieren könnte, da einige Punkte manchmal von mehreren Personen aufgeschrieben werden.
Danach bekommt jedes Teammitglied einige Klebepunkte, um die Wichtigkeit der zu diskutierenden Themen zu markieren. Ich variiere immer zwischen ein und zwei Klebepunkten. Je nachdem, wie groß das Team ist und wie viele Zettel an der Wand kleben. Jeder soll jetzt seinen Klebepunkt an den Zettel hängen, welchen er oder sie unbedingt diskutieren möchte. Dies sollte der Zettel sein, der für den nächsten Sprint so nicht weiter existieren sollte und für den wir unbedingt eine Maßnahme finden möchten. Man sollte mit der Anzahl an Punkten und Zetteln vorsichtig sein. Das Endresultat sollte nicht sein, dass jeder Teilnehmer den Punkt nur auf seinen eigenen Zettel klebt. Der positive Effekt hier ist, dass das Team selber entscheidet, wo die größten Pain Points liegen. So erhält man auch ein vollständiges Bild, weil jeder Teilnehmer dazu getrieben wird, sich an dem Inhalt zu beteiligen und seinen Teil dazu beizutragen. Wenn das Team selbst entscheidet, welche Themen es bearbeiten möchte, ist die Motivation zur Veränderung ebenfalls größer.
5. Diskussion im Team über die wichtigsten Punkte
Nun sind alle Punkte des Teams zusammengetragen und gemeinsam gewichtet. Der Scrum Master sollte jetzt den Zettel mit den meisten Klebepunkten auswählen und eine Person bitten, zur Einleitung des Themas kurz zu erklären, worum es genau geht. Danach entwickelt sich oft ganz automatisch eine Diskussion im Team, in der jeder seine Auffassung des Themas darstellen möchte. Lasst diese Diskussionsrunden gerne zu. Das ist eine positive Entwicklung. Als Scrum Master solltet ihr aber nach ein paar Minuten darauf achten, dass sich die Unterhaltung in eine lösungsorientierte Diskussion entwickelt. Ihr solltet sonst nur dann eingreifen, wenn die Art oder der Ton der Kommunikation beleidigend oder verletzend werden. Helft dem Team mit richtungsweisenden Fragen oder Anmerkungen bei der Findung einer Lösung. Notiert auf jeden Fall die Lösung, auf die sich das Team einigt.
Wählt insgesamt zwei bis vier Zettel aus, die so besprochen werden. Daraus ergeben sich dann die To-dos. Das sollte ausreichen, dass das Team eine Veränderung spüren kann, es sollte aber nicht so viel sein, dass nicht alle To-dos umgesetzt werden können. Die Themen, die übrig geblieben sind, sollte der Scrum Master natürlich im Hinterkopf behalten, diese werden aber auch ganz natürlich wiederauftauchen, wenn das Team dort einen Schmerz verspürt.
6. To-dos für den nächsten Sprint formulieren
Diese formulierten To-dos sollten festhalten, was das Team im nächsten Sprint ändern möchte. Im besten Fall solltet ihr eine Person benennen, die sich um diese Maßnahme kümmert und dafür verantwortlich ist. Sobald sich eine Person für die Durchsetzung verantwortlich fühlt, ist die tatsächliche Umsetzung auch realistischer. Alle To-dos sollten dokumentiert werden und jederzeit für die Teammitglieder zugänglich sein, falls sie ihre Verantwortlichkeiten nochmals nachlesen möchten. Nur weil eine Person für eine Maßnahme verantwortlich ist, bedeutet das nicht, dass sie sich keine Hilfe suchen kann. Es geht rein um die Verantwortlichkeit, sich darum zu kümmern. Dabei dürfen auch andere Personen diese Maßnahme umsetzen, wenn es Sinn macht.
7. Positives Ende finden
Wirklich wichtig ist es, dass das Team mit einem positiven Gefühl aus diesem Termin geht. Das Team hat gemeinsam Probleme oder Schwachstellen identifiziert. Diese haben wir im selben Meeting noch behandelt. Es gab eine produktive Diskussion und jetzt ist eine dedizierte Person dafür verantwortlich, diese Maßnahme auch durchzusetzen. Jeder sollte mit dem Ergebnis zufrieden sein. Es sollte das Gefühl entstehen, dass das Team heute etwas bewegt hat. Es wird sich etwas ändern! Beispielsweise kann man hier nochmal die vereinbarten To-dos vorlesen, eine kurze spielerische Stimmungsabfrage durchführen, jeden im Team noch mal das Erlebnis der letzten zwei Wochen nennen lassen, dass ihm am meisten Spaß gemacht hat, oder jeden im Team seinem direkten Nachbarn ein Kompliment machen lassen.
Kernaufgaben des Scrum Masters
Die Aufgaben des Scrum Masters in der Retrospektive wurden schon im Text kurz angesprochen, ich möchte sie aber gerne hier im Detail nochmals aufführen.
Die Kernaufgabe des Scrum Masters ist in diesem Fall natürlich die Moderation des Meetings. Dazu gehört es, die Struktur des Meetings zu überwachen, das Team durch die einzelnen Schritte der Retro zu führen, auf die Art und Weise der Kommunikation zu achten, Diskussionen produktiv voranzutreiben und kritische Fragen zu stellen, damit das Team auf eine sinnvolle, hilfreiche Maßnahme hinarbeitet. Dabei sollte er immer darauf achten, einen ruhigen Ton im Team zu wahren, sich in andere hineinzuversetzen und auch manchmal die zu unterstützen, die sich nicht so gut gegen das Team durchsetzen können. Das ist aber natürlich situationsabhängig.
Alles in allem ist die Arbeit des Scrum Masters ein herausfordernder Job, in dem man immer wieder auf neue Situationen und Einflüsse reagieren muss. Man muss sein Team kennen lernen und alle Meetings bestmöglich vorbereiten, um das Team optimal unterstützen zu können.
Um euch darüber hinaus ein paar Tipps und Unterstützung zu bieten, hier ein paar hilfreiche Links für alle Scrum-Interessierten:
- Hier werden verschiedene Arten von Retros vorgeschlagen.
- eine Einführung in Scrum und Agilität
- Was sind eigentlich die Aufgaben eines Scrum Masters?
Bildquellen
- Titelbild8-: Owned by the author