Retrospektive Remote – Team-Reflexion im Home-Office

Der Schmerz sich Trennen zu müssen ist nichts gegen die Freude, sich wieder zu treffen – Charles Dickens

Die Retrospektive steht an, aber dein Team ist im Home-Office? Das ist kein Grund die virtuelle Flinte ins virtuelle Korn zu werfen. Produktive Retrospektive können online auch ohne teure Tools durchgeführt werden.

Eine gute Retrospektive besteht aus folgenden 5 Phasen, an denen ich mich hier orientieren möchte. Gerade online Retros sollten kurz und knackig sein, ich gehe hier von 60 min aus.

1. Ankommen (Set the stage) – 6 min
2. Daten sammeln (Gather data) – 20 min
3. Einsichten erzeugen (Generate insights) – 20 min
4. Entscheidungen treffen (Decide what to do) – 12 min
5. Retrospektive abschließen (Close the retrospective) -2 min

Vorbereitung

Wähle ein Kommunikationsmittel: Skype, Teams, Zoom oder auch das gute alte Telefon. Jeder Teilnehmer sollte einen Computer mit Internetverbindung haben. Ich benutze hier außerdem ein Tool für virtuelle Boards, z.B. Trello oder MeisterTask. Verschicke vorab an alle Teilnehmer die entsprechenden Links und verifiziere, dass alle ihren Zugang getestet haben.

Es sollte einen expliziten Moderator geben, z.B. den ScrumMaster des Teams. Dieser sollte eine Liste der Teilnehmer vorliegen haben. Online ist es für den Moderator eine besondere Herausforderung allen Teilnehmern Aufmerksamkeit zu schenken, insbesondere wenn man gemeinsam auf eine Präsentation oder ein Online-Board schaut. Für die Teilnehmer ist es einfacher, wenn sie die Liste sehen. Wenn man z.B. der Reihe nach dran ist, weiß jeder Teilnehmer an welcher Position er steht.

In den folgenden Schritten gehe ich davon aus, dass du der Moderator bist!

1. Ankommen – drei Worte

Um die Teilnehmer zu aktivieren sollte beim Ankommen jeder mindestens einmal kurz zu Wort kommen, z.B. in einem Blitzlicht über den letzten Sprint:

• Herzlich Willkommen zu unserer Retrospektive. Lasst uns zum Ankommen den letzten Sprint mit maximal drei Worten beschreiben, z.B. “Eine perfekte Welle.” oder “Panik, Weltuntergang, Auferstehung.” Ihr bekommt jetzt 1 Minute Zeit, so dass ihr euch eure drei Worte überlegen könnt. Fragen? Nein? Dann los.

Frag nach einer Minute, ob alle fertig sind und verlängere bei Bedarf um eine weitere Minute. Dann ruf den ersten Teilnehmer von der Liste auf. Ist die Reihenfolge klar können sich die Teilnehmer dann das Wort selber übergeben. Ansonsten ruf jeden Teilnehmer explizit auf, damit keine Zeit verloren geht.

Die drei Worte sind ein erster Hinweis, ob der Sprint eher gut oder schlecht gelaufen ist.

2. Daten Sammeln – Mad, Sad, Glad

Um sinnvoll Daten zu sammeln bietet sich Tool-Unterstützung an. Tools für virtuelle Boards wie Trello oder MeisterTask haben schon in der kostenlosen Version ausreichend Funktionalität für eine Retro.

• Lasst uns nun mit dem Sammeln der Daten beginnen. Wir nutzen die Methode Mad, Sad, Glad. Denkt an die letzte Iteration und überlegt was euch glücklich gestimmt hat (das sind die Glad-Karten), womit ihr unzufrieden wart (Sad) und was euch in den Wahnsinn getrieben oder regelrecht wütend gemacht hat (Mad). Jeder von euch darf insgesamt maximal drei Karten schreiben, überlegt euch also was am wichtigsten für uns ist. Bitte ordnet die Karten in die richtige Spalte ein und markiert sie mit einem farbigen Label. Ihr bekommt 5 Minuten Zeit. Fragen? Nein? Los gehts!

Strukturiere das Board für Mad, Sad, Glad zum Beispiel wie in der folgenden Abbildung:

Die Teilnehmer sollten nun die ersten drei Spalten für die drei Kategorien Glad, Sad und Mad mit Karten füllen. In der Regel entstehen zu viele Karten, als dass man alle besprechen könnte, d.h. wir müssen die bestehenden Karten Priorisieren. Bei manchen virtuellen Boards gibt es die Möglichkeit Abstimmungen durchzuführen. Wenn das nicht möglich ist, kann man sich mit der Zuordnung von Personen zu den Karten behelfen, die normalerweise für die Aufgabenverteilung gedacht ist.

• Die Zeit ist um. Lasst uns nun die Karten priorisieren. Jeder von euch darf drei mal seinen Avatar vergeben. Wählt die drei Karten aus, die aus eurer Sicht heute besprochen werden sollten und zieht euren Avatar auf die Karte, so als wolltet ihr die Aufgabe übernehmen. Das dient im Moment nur der Priorisierung. Ob und wer die Karte dann bearbeitet entscheiden wir später.

Jetzt sollten auf den Karten die Avatare der Teilnehmer erscheinen. Am Ende sollte jeder Teilnehmer maximal drei Avatare verteilt haben. Sortiere nun die Karten mit den meisten Avataren in den Spalten nach oben und ziehe dann die 2-4 am höchsten priorisierten Karten in die Spalte “Priorisiert”, unabhängig davon, ob diese vorher in der Mad-, Sad- oder Glad-Spalte gehangen haben. Wo die Karte herkam, sollte am Label sichtbar sein.

3. Einsichten erzeugen – Root Cause Analysis

Jetzt kann die Analyse beginnen. Ziehe die erste Karte in die Spalte “in Diskussion”.

• Lasst uns über die Karte “zu wenig automatische Tests” sprechen. Bevor wir mit Lösungsvorschlägen kommen, würde ich gerne die Ursachen besser verstehen. Was glaubt ihr ist das Problem?

Anstatt nun wieder alle Karten zu den Ursachen schreiben zu lassen, bevorzuge ich an dieser Stelle die offene Kommunikation und schreibe mögliche Ursachen als Stichworte mit in die Beschreibung der Karte.

4. Entscheidungen treffen – SMART Goals

Sind die Ursachen geklärt, muss sich das Team auf sinnvolle Maßnahmen zur Lösung einigen. Bei Trello kann man das z.B. mit einer Checkliste machen, die man später abhaken kann.

• Lasst uns nun überlegen, welche Maßnahmen wir treffen wollen. Diese sollten möglichst SMART sein, also specific (=konkret), measurable (=messbar), attainable (=erreichbar), relevant, timely (=termingebunden). Was schlagt ihr vor?

Ihr könnt schließlich festlegen, wer sich um die Maßnahmen kümmert, indem ihr die Avatare, die vorher für die Abstimmung benutzt wurden entfernt und durch die Verantwortlichen für die Maßnahme ersetzt.

5. Abschluss

Zum Abschluss frage ich meistens nur, was gut lief und was man für die nächste Retrospektive verbessern könnte.

Für alle Phasen kann man sich vom Retromat inspirieren lassen, der dutzende Methoden zusammenfasst, die aber meistens für offline Retros gedacht sind.

Wenn man zuvor Retros durchgeführt hat, ist ein wichtiger Schritt natürlich zu überprüfen, ob die Maßnahmen vom letzten Mal umgesetzt wurden.

Nachdem ihr mein Vorgehen gelesen habt, würde mich natürlich interessieren, wie ihr Retrospektiven durchführt. Welche Tools verwendet ihr? Welche Methoden sind erfolgreich?

Literatur:

(1) Derby, Esther 2006: Agile Retrospectives*: Making Good Teams Great (Pragmatic Programmers)

(*) Affiliate-Links.

Holger Tewis ist Agile Enterprise Coach
www.holgertewis.de

Feedback-Methoden – 4 Augen bis 360 Grad

Je nach Anlass und Konstellation kann man Feedback auf unterschiedliche Arten einholen. Als Fortsetzung unserer Feedback-Reihe seien hier einige Methoden vorgestellt:

4-Augen-Feedback

Das 4-Augen-Feedback eignet sich, wenn man jemandem persönliches Feedback zu einem konkreten Verhalten geben möchte. Das sollte möglichst zeitnah passieren. Je länger man wartet und je mehr Beobachtungen sich aufstauen, umso schwerer wird es konstruktiv Feedback zu geben.

Wenn man selbst wissen möchte, wie man in einer Situation gewirkt hat, kann man natürlich aktiv nach Feedback fragen. Auch dafür sollte man möglichst konkrete Fragen stellen. Studien haben ergeben, dass Menschen es vorziehen sich zurückzuhalten oder gar Notlügen zu erzählen, nur um kein unangenehmes Feedback geben zu müssen (2). Zudem sollte man Speichellecker oder ewige Nörgler vermeiden, sondern Personen wählen, die ein ernsthaftes Interesse an konstruktiver Kritik haben.

Spontan 4-Augen Feedback zu geben oder zu bekommen kostet am meisten Überwindung. Deswegen führen viele Teams und Organisationen regelmäßig Feedback-Sessions durch. Die Regelmäßigkeit macht es dann auch einfacher ad hoc Feedback zu geben.

Um sein Feedback strukturiert vorzubereiten kann man z.B. den Feedback-Planner von Jerome (3) verwenden: LINK.

360-Grad-Feedback

Beim 360-Grad-Feedback bekommt eine Person Rückmeldungen aus verschiedensten Richtungen, also bei einer Führungskraft z.B. von Mitarbeitern, Kollegen auf der gleichen Führungsebene und vom Vorgesetzten. Dies kann anonym passieren, z.B. über ein HR-Tool oder offen z.B. nach dem Prinzip des heißen Stuhls: Ein Meeting von maximal 30 Minuten wird einberufen, in dem ein Teilnehmer Feedback (Empfänger) von den anderen Teilnehmern (Geber) erhält. Zur Vorbereitung füllt jeder Feedback-Geber einen Feedback-Bogen aus.  (z.B. was der Empfänger Starten, Stoppen und Weitermachen soll). Auf dem Meeting liest dann jeder Feedback-Geber dem Empfänger seinen ausgefüllten Bogen vor. Der Empfänger erhält den Bogen um später darüber reflektieren zu können. Er darf Verständnisfragen stellen, aber er darf sich nicht rechtfertigen. Zudem hat der Empfänger am Ende die Möglichkeit eine offene lösungsorientierte Diskussion zu starten.

Für 360°-Feedback verwende ich meinen eigenen Feedback-Bogen, den man hier herunterladen kann: Start Stop Continue 360 Grad Feedback.

Kollegiale Beratung

Eine Variante ist die sogenannte Kollegiale Fall-Beratung. Auch hier sitzt eine Person (Fall-Erzähler) auf dem heißen Stuhl und kriegt Feedback von den anderen Teilnehmern (Berater). Der Unterschied liegt jedoch im Ablauf:

Nach der Verteilung der Rollen und der Darstellung der Situation dürfen die Berater Verständnisfragen stellen. Dann ziehen sie sich zur Identifikation zurück. Der Fall-Erzähler geht aus der Runde und darf nur zuhören und sich Notizen machen, während sich die Berater in seine Lage versetzen und ihre Wünsche und ihr Erleben schildern. Dann fangen die Berater an sich über Hypothesen und Vermutungen auszutauschen. Der Fall-Erzähler hört weiterhin zu und macht sich Notizen. In der Stellungnahme bekommt er dann Gelegenheit Ergänzungen und Korrekturen zu dem gehörten zu machen. Die Berater korrigieren evt. Ihre Hypothesen. Für die Lösungssuche geht der Fall-Erzähler wieder aus der Runde, hört zu und notiert sich wichtige Punkte. Jeder Berater sagt nun, was er in der Situation tun würde, ohne zu diskutieren. Schließlich kommen wieder alle zusammen und der Fall-Erzähler teilt mit welche Ideen er umsetzen will. Im Abschluss gibt es noch eine Feedback-Runde. Alle Einheiten sind mit 5 bis max. 15 Minuten absichtlich knapp getaktet, so dass man ins 60-90 Minuten auf den Punkt kommen muss.

Weiterführende Informationen zur kollegialen Beratung findet man z.B. bei Tietze/Thun* (5).

Retrospektiven

Auf Teamebene seien hier natürlich noch Retrospektiven genannt, in denen z.B. nach Scrum mindestens 1 Mal pro Monat reflektiert wird, wie die Zusammenarbeit im Team war. Die Retrospektiven können bei Bedarf z.B. für 360-Grad-Feedback genutzt werden, sollten sich aber nicht darauf beschränken. Für agile Retrospektiven gibt es eine etablierte Phasen-Struktur, die zum Beispiel im gleichnamigen Buch (1) beschrieben wird. Eine große Auswahl von Methoden findet man im Retromaten.

Im nächsten Beitrag beleuchte ich die Themen Selbst-Reflexion, Selbst-Erkenntnis und Achtsamkeit: LINK.

Links/Literatur

(1) Derby, Esther 2006: Agile Retrospectives*: Making Good Teams Great (Pragmatic Programmers)

(2) Eurich, Tasha 2017: Insight*: The Surprising Truth About How Others See Us, How We See Ourselves, and Why the Answers Matter More Than We Think (English Edition): Currency

(3) Jerome, Paul J. 1999: Coaching Through Effective Feedback*: Pfeiffer

(4) Rosenberg, Marshall B. 2016: Gewaltfreie Kommunikation*: Eine Sprache des Lebens: Junfermann

(5) Tietze, Kim-Oliver 2003: Kollegiale Beratung*: Problemlösungen gemeinsam entwickeln (Miteinander reden Praxis): Rowohlt Taschenbuch

(*) Affiliate-Links.

Holger Tewis ist Agile Enterprise Coach
www.holgertewis.de

Satisfaction Histogram

Das Bauchgefühl des Entwicklungsteams kann ein wichtiger Indikator für Engpässe im Entwicklungsprozess sein.

Esther Derby und Diana Larsen beschreiben in ihrem Buch Agile Retrospectives: Making Good Teams Great* die Methode des Satisfaction Histograms. Bei CoreMedia habe ich die Methode über einige Sprints als Teil der Retrospektive genutzt und möchte hier darüber berichten. Auch die anderen ScrumMaster haben die Methode in ihren Teams übernommen.

Je nach Team wurden verschiedene Aspekte bewertet:

• Teamwork
• Sprint Deliverable Quality
• Product Quality
• Product Vision

Bei der Benotung habe ich mich an den im Buch vorgegebenen Beispiel für Teamwork orientiert. Hier z.B. meine Formulierungen für Product Vision und Product Quality:

Product Vision
1 = The vision is brilliant and directs to amazing success.
2 = I believe following the vision will lead to success. It motivates me.
3 = The vision is clear and understandable, but it doesn’t help much.
4 = To me the vision is not plausible. It doesn’t encourage me at all.
5 = I don’t know the product vision or I think following it is a complete waste of time.

Product Quality
1 = I think we have a perfect product! It is absolutely flawless.
2 = I am fully satisfied with the quality of our product.
3 = I’m fairly satisfied. Overall the quality is nothing to be ashamed of.
4 = We didn’t ignore quality, but it was not enough.
5 = I’m unhappy and dissatisfied. I lie awake at night because of our poor product quality.

Das Team hat anonym abgestimmt, den Durchschnitt berechnet und in ein Diagramm eingetragen, in dem man den bisherigen Verlauf sehen konnte. Anschließend wurde darüber reflektiert, insbesondere bei großen Ausschlägen oder wenn das Ergebnis überraschend ausfiel. Der Product Owner durfte mit abstimmen. Ich als ScrumMaster habe nicht mitgestimmt.

Mit der Zeit entstanden Verlaufskurven wie die folgende:

Die Abstimmung und das Diagramm dienten in vielen Fällen als Katalysator für Diskussionen: Schlechte Werte oder Tendenzen nach unten bildeten einen guten Ausgangspunkt für die Frage nach dem Warum. Oft hat die Diskussion Gründe aufgezeigt, die nicht offensichtlich waren. So hatte zum Beispiel ein starkes Absinken der Product Quality und Sprint Deliverable Quality (Sprint F) keine Ursache in technischen Veränderungen, sondern in verstärkter Analyse. Weniger überraschend war, dass die Qualität des Sprint-Deliverables stärker schwankt als die Qualität des Produkts insgesamt. Zum Teil waren die Tendenzen dort sogar gegenläufig (Sprint C), wenn z.B. nicht alle für den Sprint geplanten Stories umgesetzt werden konnten, aber ein unangenehmer Performance-Bug entfernt werden konnte. Die Messung der Product Vision zeigte, wann diese wieder aufgefrischt werden muss, wenn das Team sie im Tagesgeschäft mit der Zeit aus dem Blick verloren hat. Wichtig ist aber auch die Ergebnisse nicht überzuinterpretieren. Je nachdem wer gerade anwesend ist und je nach Tagesstimmung schwanken die Ergebnisse.

Insgesamt halte ich das Histogram für ein nützliches Mittel um ein objektiviertes Gefühl für verschiedene Aspekte des Entwicklungsprozesses zu bekommen. Mehr als vier Bereiche würde ich dabei nicht gleichzeitig betrachten, damit die Methode leichtgewichtig bleibt.

Im Buch wird empfohlen die Messungen nur alle paar Iterationen durchzuführen. Es ist richtig, dass sich mit der Zeit ein gewisser Ermüdungseffekt einstellt. Ich fand es allerdings wertvoll jeden Sprint einen Messwert zu haben, um Trendwenden zeitnah mitzubekommen.Wenn man feststellt, dass die Werte konvergieren bzw. kaum noch neue Erkenntnisse produzieren, sollte man die betrachteten Bereiche variieren.