Arbeitet man im Team zusammen, bietet es sich an nach einem Arbeitsabschnitt (wie einem Sprint, wenn man nach der SCRUM-Methodik arbeitet) eine Retrospektive zu machen, kurz Retro. Das sind Rückblicke, zu denen man idealerweise das ganze Team versammelt und jeden aufzählen lässt, was seiner/ihrer Meinung nach gut lief und was verbessert werden kann. Das sorgt erstens dafür, dass das Team Gehör findet und zweitens kann man Probleme identifizieren und idealerweise werden diese dann nicht wiederholt. Als Scrum Master brauchte ich neulich mal zwei „analoge“ Retros, d.h. welche bei denen das ganze Team in einem Raum anwesend ist und habe verschiedene ausprobiert – mit unterschiedlichen Erkenntnissen.

Retrospektive: Sailboat

Die Sailboat/Segelboot-Retro erzählt quasi eine kleine Geschichte. Im Zentrum des Geschehens sitzt das Team – wir. Und alle sitzen sprichwörtlich in einem Boot 😉 Einem Segelboot eben. Wir haben alle ein gemeinsames Ziel – hier dargestellt als idyllische Insel mit Sonnenschein, kühlen Drinks, einer Palme oder was man sich auch immer unter idyllisch vorstellen mag. Die See ist aber rau. Es gibt unsichtbare Gefahren, die uns fast zum Verhängnis geworden wären – oder tatsächlich wurden. Die werden hier durch einen spitzen Felsen dargestellt, den wir aus unserem Boot heraus nicht sehen konnten, gegen den wir aber eventuell fahren und Leck schlagen könnten. Der Fels steht für unsichtbare Gefahren, versteckte oder auch externe Abhängigkeiten. Anders sind die internen Gefahren, d.h. welche die wir selber kontrollieren können. Die werden hier als Anker dargestellt. Wir können schließlich selber entscheiden, ob wir den auswerfen und stoppen oder auf voller Fahrt weiter unterwegs sind. Natürlich gibt es aber auch etwas, dass uns antreibt – das wird durch den Wind visualisiert. Sehr bildlich das alles, oder? 🙂 Wenn das Team unsicher ist, ob ein Problem eher ein Fels- oder ein Anker-Fall ist, dann hilft die Frage: hättet ihr es beeinflussen können? Wenn nicht, dann ist es von außen an das Team herangetragen worden und ein „Fels“. Wenn es doch in der Hand des Teams lag, dann ist ein typischer „Anker“.

Retrospektive: DAKI

DAKI steht für Drop, Add, Keep und Improve. Die Namen erklären sich fast von selbst. Drop steht für Verhalten und Umstände, die man besser sein lassen soll. Vielleicht hat etwas nicht den Effekt, den es haben sollte? Oder etwas hat wenig Gewinn bei einem hohen Aufwand? (In der IT: ist das branching Konzept zu aufwendig? Sind die Tools zur Datenmodellierung umständlich?) Add steht für etwas, dass das Team noch gar nicht hat oder bisher nicht versucht hat und damit doch einfach mal anfangen sollte. Also etwas, das bisher ganz fehlt. (In der IT eventuell: Testautomatisierung? Neue Konzepte? Dokumentation!!!) Keep ist Verhalten, das top war und unbedingt beibehalten werden soll. 🙂 Vielleicht das Miteinander im Team? Was bereichert den Alltag? Improve steht für etwas, das wichtig ist, aber noch besser gehandhabt werden kann. Das ganze kann unterschiedlich visualisiert werden. Der einfachste Ansatz ist das Tafelbild ein vier Quadranten zu teilen. Ich verstehe, dass das nach Segelboot schon fast langweilig ist 😉 Aber es tut, was es tun soll.

… der Rest ist Geschichte

Den meisten, die sich in diesen Artikel verirren muss man wahrscheinlich nicht mehr erklären wie eine Retro durchgeführt wird. Der Geschlossenheit halber mache ich es trotzdem. 😉 Nachdem man den Zweck der Retro erklärt hat (identifizieren was gut lief, um es weiter so gut zu machen und was verbessert werden kann, um es in Zukunft besser zu machen – bitte auch auf die positiv konnotierte Wortwahl achten 😉 ), muss man wohl ein paar Worte zum Vorgehen verlieren. Segelboot hat eben eine Geschichte, die erzählt wird im Gegensatz zu DAKI. Dann gibt man den Teilnehmern Zeit zum „sammeln“. Sie können sich ihre Punkte für die jeweiligen Kategorien der Retros vorher überlegen und dann gemeinsam anbringen oder man bittet sie gleich an die „Tafel“. Ab einer gewissen Teamstärke oder bei sehr mitteilungsbedürftigen Kollegen (manche wachsen bei Retros über sich hinaus, manche gehen kaum aus sich heraus) empfehle ich als Regel für alle Teilnehmer beispielsweise (fix oder maximal) drei Punkte pro Kategorie zu nennen. Es ist zu erwarten, dass das Team ähnliche Punkte nennt, die man dann clustern kann. Mit Post-its geht das sehr schön. Nach dem Sammeln kann man jeden seinen Punkt vorlesen und ggf erklären lassen. Dabei empfehle ich gern mit den negativeren Punkten bzw. Kategorien anzufangen (Fels/Anker oder Drop/Improve/…) und erst dann die positiven (Wind oder Add/Keep) durchzugehen, damit die Teilnehmer gerade diese positiven Punkte stärker in Erinnerung behalten, wenn sie aus dem Raum gehen. Der Effekt kann enorm sein.

Egal wann, aber wenn man die zu verbessernden, negativ konnotierten Punkte durchgeht, sollten diese geclustert werden. Haben Probleme eine ähnliche Ursache? Dann clustern. Das Team muss gefragt werden wie man das besser macht und eine Aktion für die Zukunft definiert werden. Idealerweise sollte auch festgelegt werden, wer diese Aktion umsetzt. Allerdings kann es sein, dass es zuviele Aktionen werden. In einem solchen Fall hilft es eine Top-3 oder Top-5 festzulegen – zum Beispiel indem das Team abstimmt. Und dann – naja, muss darauf geachtet werden, dass die Aktionen umgesetzt werden. Manche beflügeln die Aktionen ohne nachtreten, andere müssen daran erinnert werden. In unserem Team werden die Aktionen jetzt immer an ein Flipchart geschrieben und an die Wand ins Büro gehängt.

Sailboat oder DAKI – Wie wähle ich die richtige Retro für die Situation des Teams aus?

In meinem Fall habe ich zuerst die Segelboot-Retro gemacht und bei der nächsten Retro DAKI. Der Gedanke dabei war der folgende: Im Zuge des Segelboots wollten wir herausfinden, was innerhalb und außerhalb des Teams los ist. Die externen Abhängigkeiten und Probleme habe ich als Scrum Master gesammelt und bei der Projektleitung angesprochen. Nur für die internen haben wir Aktionen definiert. (Bei den externen kann man natürlich auch festlegen wie man damit als Team umgeht.) Manchmal muss sich das Team einfach mental davon lösen, was in der Außenwelt passiert – man kann es eh kaum oder schwer beeinflussen. In der nächsten Retro haben wir DAKI gemacht und dabei nur betrachtet, was das Team innerhalb beobachtet hat. DAKI richtet sich mehr an Verhalten – alleine schon durch die Wortwahl. Drop, Improve, … etc. So entsteht nicht der Eindruck der Ohnmacht, sondern des „Wie können wir unseren Kram gut handhaben?“ Und das hat sich ziemlich schön ergänzt.

Die Herangehensweisen sind aber vielfältig. DAKI ist ein ziemlicher Alleskönner, der in vielen Situationen angewendet werden kann. Segelboot ist etwas spezieller, da er in externe Einflüsse (Fels) und interne (Anker) unterscheidet, d.h. welche die das Team beeinflussen kann und welche, die einfach auf das Team zukommen und worauf man nur reagieren und das beste hoffen kann. Daher bietet sich eine Segelboot-Retro an, um überhaupt solche externen Abhängigkeiten erstmal zu erkennen. Das eignet sich gut, wenn Teams das erste Mal zu einer Retro zusammen kommen oder viel schief lief, ohne dass offensichtlich ist, warum. Beide Retros haben aber ihre Gefahren. Grundsätzlich laden Retros zum jammern und meckern ein. Es schadet zwar nicht sich Luft zu machen, aber ist nicht immer konstruktiv – hier ist der Moderator gefragt. Besonders die externen Abhängigkeiten sind oftmals ein ziemliches Jammertal und stets „gut gefüllt“. Erkennt ein Team nur extern auf sie einstürzende Probleme, dann sollte der Moderator/die Moderatorin fragen: und wie seid ihr damit umgegangen? Zu Konflikten gehören auch immer zwei Seiten – vielleicht kann man hier etwas drehen, damit es für alle Seiten besser klappt. DAKI hingegen kann etwas zu „einsilbig“ sein. Falls den Teilnehmern nichts zu den vier Kategorien einfällt, kann der Moderator das noch weiter ausformulieren – siehe Beispiele oben. Falls die Teilnehmer trotzdem wenige Punkte zusammentragen, ist das ein deutliches Zeichen es bei dem Team das nächste Mal mit weniger Kategorien zu versuchen, beispielsweise dem klassischen „Was lief gut? Was könnte besser laufen?“

Vielleicht ist ja das Segelboot oder DAKI etwas für euer Team? Habt ihr die Retros eventuell sogar schon mal ausprobiert? Was hat gut für euch geklappt, was nicht? Man kann sich darüber streiten, ob Scrum, Vorgehensmodelle und Techniken wie Retrospektiven in meiner Kategorie „Netzgeflüster“ richtig aufgehoben sind. Aber es gehört eben zu meinem Alltag als Softwareentwicklerin und Scrum Master(in) dazu. Und desto länger ich das mache, desto mehr frage ich mich wie wir überhaupt mal ohne all das arbeiten konnten. Arbeitet ihr im Team? Gibt es dort ein ähnliches Vorgehensmodell oder zumindest Retrospektiven oder Feedbackrunden? Interessanterweise habe ich übrigens zumindest die Sailboat-Retro neulich auch bei einem Team gemacht, das nichts mit IT tut und nicht nach Scrum arbeitet, aber es hat genauso gut funktioniert. Ob Scrum oder nicht, denke ich, dass eine Retro unverzichtbar ist, wo Menschen auf ein gemeinsames Ziel hinarbeiten.

Netzgeflüster ist eine Kategorie meines Blogs in der ich mich immer zwischen dem 10. und 15. eines jedes Monats Themen aus IT, Forschung, Netzwelt und Internet widme genauso wie Spaß rund um die Arbeit mit Bits und Bytes. 🙂