In der Retrospektive beschäftigen wir uns mit dem abgelaufenen Sprint und reflektieren darüber, was nicht so gut funktioniert hat und erarbeiten Verbesserungen. Diese oder eine ähnlich nebulöse Formulierung finden Sie in jedem Buch. Damit ist es im allgemeinen jedoch getan. Oft gibt es noch den Hinweis darauf, dass der Scrum Master einige Moderationstechniken beherrschen sollte, um Diskussionen steuern zu können. Vielleicht ist es an der Zeit, uns die Sache einmal genauer zu betrachten.
Zunächst einmal sollten wir uns darauf einigen, dass nicht an der Retrospektive gespart wird. Ich begegne immer wieder Entwicklern, die mir sagen, dass in ihrem Unternehmen nur selten eine Retrospektive durchgeführt werde, weil man der Meinung sei, dass es sich für ein so kleines Team nicht wirklich lohne. Man verbringe sowieso schon so viel Zeit in Meetings, und wenn wichtige Dinge zu besprechen seien, dann würde man das eben spontan machen.
Scrum ist ein andauernder Verbesserungsprozess. Team, Unternehmen und Projekt entwickeln sich weiter, also müssen sich unsere Vorgehensweisen ständig anpassen. Auf die Retrospektive zu verzichten, bedeutet, mit dem Erreichten zufrieden zu sein. Die Retro dient jedoch nicht nur der Weiterentwicklung sondern auch der ständigen Überprüfung. Ohne dieses Treffen würden wir (und das garantiere ich Ihnen) im Laufe der Zeit immer nachlässiger werden, bis wir schließlich unseren Prozess soweit verwässert hätten, dass Scrum nur noch ein Name ohne Inhalt ist.
Für die Retrospektive bietet es sich an, sich großzügig bei einer Moderationstechnik mit Namen Metaplan zu bedienen. Dieses Vorgehen eignet sich besonders gut während der Einführungsphase, wenn es noch viele Dinge zu besprechen gibt. Die Schwierigkeit ist es dann meistens, all die Dinge zu ordnen, die vom Team kommen.
Ich bitte schon im Vorfeld alle Metaplan-Puristen um Entschuldigung. Wir nutzen nur einige grundlegende Elemente dieser Methode, um unsere Retrospektive in geordnete Bahnen zu lenken. Dabei verzichten wir bewusst auf die Feinheiten.
Vor allen Dingen benötigen wir jede Menge Karteikarten, die wir aufhängen können, und genügend Textmarker für alle. Es ist völlig egal, ob Sie mit Pinwänden arbeiten oder die Karten an die Wand kleben. Wichtig ist nur, dass Sie genug Platz haben, um eine Menge Karten irgendwo aufzuhängen. Der Vorteil bei der Arbeit mit Karteikarten ist nicht nur der, das alle Punkte automatisch schriftlich fixiert werden, auch werden die Beiträge der stilleren Kollegen ebenso wichtig wie die der Lautsprecher. Zusätzlich ist es hilfreich, wenn sich das Team noch nicht so gut kennt. Die Anonymität durch die Karte hilft dabei, Dinge zu sagen, die man in einer Runde von Unbekannten nicht laut aussprechen würde.
Bei der Retrospektive sollten das Team, der Product Owner und der Scrum Master anwesend sein. Es wird gelegentlich diskutiert, ob der PO Teil des Ganzen sein soll, dazu habe ich jedoch ein ganz klare Meinung: Der Product Owner ist Teil der Entwicklung, und die Retrospektive dient der Entwicklung, sich selbst zu verbessern. Er nimmt während der Retro keine Sonderrolle ein. Seine Meinung wird nicht stärker gewichtet als die aller anderen.
Zu Beginn, wenn alle endlich ihren Kaffee geholt und ihren Platz gefunden haben, kann der Scrum Master locker in das Treffen einführen. Beim ersten mal sollte er kurz das Vorgehen mit den Karten erklären, sollte sich aber noch zurückhalten, seine eigenen Eindrücke vom Sprint zu schildern. Wir möchten unsere Kollegen nicht beeinflussen.
Dann bekommt jeder einen Stapel Karteikarten und einen Marker. Der Scrum Master stellt die Frage, was im abgelaufenen Sprint gut gelaufen sei und was den Kollegen gefallen habe. Alle bekommen nun zehn Minuten Zeit, Stichpunkte auf die Karten zu schreiben. Ein Punkt pro Karte. Der Product Owner schreibt selbstverständlich ebenfalls. Es kann eine weit ausufernde Diskussion werden, ob der Scrum Master auch schreiben sollte. Ein Moderator sollte in jedem Fall neutral bleiben. Es ist seine Aufgabe, die Meinungen und Beiträge der anderen zu ordnen, ohne seine eigene Meinung einzubringen, weil er damit die Diskussion nur einfärben würde. Er würde ganz automatisch seine eigene Meinung stärker bewerten als die der anderen und damit die Diskussion in eine von ihm gewünschte Richtung lenken.
Auf der anderen Seite ist der Scrum Master der erste Beobachter des Vorgehens. Seine Eindrücke entstehen unter anderen Bedingungen als die der anderen. Er hat oftmals einen etwas umfassenderen Blick auf die Dinge. Daher gibt es mehrere Möglichkeiten:
1. Der Scrum Master schildert eingangs kurz seine Eindrücke, formuliert dies aber möglichst neutral und knapp, um seine Meinung nicht zu dominant werden zu lassen.
2. Der Scrum Master füllt selbst auch Karten aus. Dies erfordert jedoch viel Disziplin bei der folgenden Diskussion und Bewertung. Es ist recht schwer, nach dem Prinzip vorzugehen, dass die eigene Meinung nicht wichtiger ist als die der anderen.
3. Der Scrum Master schildert seine Eindrücke, wenn die Karten bereits hängen und macht das Team auf Punkte aufmerksam, die es seiner Meinung nach nicht beachtet hat. Dann fragt er die Kollegen, ob es diese Punkte mit berücksichtigen möchte.
4. Der Scrum Master hält sich zurück und bleibt der Rolle des reinen Moderators treu.
Ich selbst bevorzuge Option 2. Wir werden gleich sehen, dass es nicht wirklich schwer ist, die anderen darüber entscheiden zu lassen, ob sie die vom Scrum Master genannten Punkte für wichtig halten.
Wenn die zehn Minuten abgelaufen sind, sammelt der SM die Karten ein, mischt sie, liest eine nach der anderen vor und hängt sie auf. Dabei werden die Karten thematisch gruppiert. Wenn z.B. auf einer Karte steht, dass die Anforderungen leicht verständlich formuliert waren und ein anderer schreibt, dass die Anforderungen so aufgeteilt waren, dass man sie gut schätzen und schnell abarbeiten konnte, dann gehören diese thematisch zusammen. Keine Karte wird ignoriert. Auch doppelte Punkte werden aufgehängt. Wenn mehrere Personen eine Sache nennen, dann ist diese offensichtlich für mehrere Personen wichtig.
Den einzelnen Themen werden nun Überschriften zugeordnet. Das ist oftmals sehr eindeutig (in unserem Beispiel »Anforderungen«). Wenn es nicht vollkommen klar ist, spricht man kurz darüber. Die fertige Wand wird dokumentiert.
Die Frage nach den gut gelaufenen Dingen dient der Einführung, sollte aber nicht ignoriert werden. Zum einen ist es wichtig, ich auch mit den positiven Dingen zu beschäftigen, zum anderen gibt es auch die Frage, wie man die guten Dinge noch besser machen kann. Diese ist aber erst später relevant, wenn wir keine großen Baustellen mehr haben. Zu Einführung von Scrum kümmern wir uns vornehmlich um die Dinge, die noch nicht richtig funktionieren. Trotzdem kann man diese Frage zwischendurch einmal stellen. Vielleicht ergeben sich Verbesserungen, die man ohne großen Aufwand durchführen kann.
In der zweiten Runde stellt der Scrum Master die Frage nach den Dingen, die nicht gut gelaufen sind, und gibt den Kollegen erneut zehn Minuten Zeit, ihre Punkte auf Karten zu schreiben. Diese werden wieder eingesammelt, vorgelesen, geordnet aufgehängt und mit Überschriften versehen. Nun geht es an die Bewertung. Sie können z.B. jedem Kollegen drei Pins oder drei Post-Its geben, mit der er die Überschriften markiert, die ihm besonders wichtig sind. Er kann dabei seine drei Stimmen verteilen oder zwei oder alle drei auf eine konzentrieren, wenn ihm dieser Punkt besonders wichtig ist. Nun wird einfach gezählt, und die höchste Priorität hat der Themenkomplex mit den meisten Markierungen.
Wir haben nun, nach ungefähr der Hälfte der Zeit, wenn wir 90 Minuten angesetzt haben, eine priorisierte Liste der größten Baustellen. Nun nehmen wir uns den ersten Punkt vor. Manchmal ist es eindeutig, was zu tun ist. Vielleicht geht es darum, dass die Anforderungen im Backlog noch zu viele Fragen aufwerfen oder schlicht zu groß für einen Sprint sind. In diesem Fall setzen sich Scrum Master und Product Owner zusammen und arbeiten die Anforderungen so um, dass sie für das Team leichter verständlich werden.
Bei einigen Punkten ist eine Lösung des Problems jedoch nicht eindeutig und sofort ersichtlich. Hier nehmen wir uns die Zeit, gemeinsam eine Lösung zu erarbeiten. Der Scrum Master sollte Vorschläge machen, die das Team diskutiert, aber auch vom Team oder vom Product Owner sollten Ansätze kommen. Man kann sogar soweit gehen, für Lösungsvorschläge ein eigenes strukturiertes Brainstorming durchzuführen, muss sich jedoch im klaren darüber sei, dass es viel Zeit braucht.
Lässt sich während der Retrospektive kein Lösungsansatz erarbeiten, dann sollten wir diesen Punkt, wenn er als sehr wichtig erachtet wird, herausziehen und in einem eigenen Treffen genauer betrachten. Wir laufen sonst Gefahr, dass wir uns jeweils fünf Minuten mit die Lösung anderer Probleme und zwei Stunden mit der Lösung eines einzelnen befassen.
Zum Ende der Retrospektive haben wir eine Reihe von Punkten, die gut funktioniert haben, und eine priorisierte Reihe von Problemen mit Lösungsansätzen. Abschließend werden Aufgaben verteilt. Wer muss für diese Lösungen was tun? Diese Dinge werden zusätzlich mit einem Zeitmarker versehen. Wer muss was bis wann tun? All diese Dinge werden protokolliert und in der nächsten Retrospektive überprüft. Der Fortschritt all unserer Lösungsansätze wird überwacht und beobachtet.
Wenn die Retro inhaltlich abgearbeitet ist, können die Beteiligten noch einmal ihre EIndrücke zum Ablauf des Meetings selbst schildern. Haben sie den Eindruck, dass es was gebracht habe? Hat man sich irgendwo verrannt? Hat man Dinge, die eigentlich auch wichtig sind, ignoriert, weil die Zeit knapp wurde?
Ich rate auch immer dazu, eine Wartezone zu schaffen. Wenn in der Diskussion Dinge angesprochen werden, die zwar wichtig sind, im Moment jedoch in eine andere Richtung führen oder den Rahmen sprengen würden, werden diese notiert und ebenfalls dokumentiert, damit sie erhalten bleiben.
