Retrospektiven auf den Rest des Unternehmens ausweiten

Das Produktentwicklungsteam bei Driftrock nutzt Retrospektiven und sie haben sich für uns sehr bewährt. In dieser Zeit haben wir zahlreiche Verbesserungen und Änderungen an unserer Arbeitsweise vorgenommen. Diese reichen von kleinen Anpassungen an unseren Prozess bis hin zu großen, noch ungewissen Ideen, die wir für einen begrenzten Zeitraum ausprobieren. Unser Ablauf für eine Retrospektive ist (meiner Erfahrung nach) ziemlich typisch: Wir führen sie alle zwei Wochen durch und wechseln uns in der Moderatorenrolle ab, wobei jeder die Sitzung nach eigenem Ermessen leitet. Wichtig ist, dass wir unser Bestes tun, um sicherzustellen, dass wir einige gut verständliche Maßnahmen (etwa 1–4) mit klaren Verantwortlichen festlegen und die Erwartung haben, dass diese bis zur nächsten Retrospektive abgeschlossen oder zumindest in sinnvoller Weise vorangetrieben werden.

Unerwartet war dabei, dass auch die übrigen Bereiche des Unternehmens außerhalb der Softwareentwicklung zunehmend Interesse daran zeigten, zu verstehen, wie Retrospektiven ihnen helfen könnten. Dies ging so weit, dass wir nun regelmäßig Retrospektiven mit unserem Growth-Team durchführen, das sich aus Vertriebsmitarbeitern, Kundenbetreuern und Performance-Marketern zusammensetzt. Wir haben auch eine unternehmensweite Retrospektive abgehalten, die sich speziell mit Leistungsbeurteilungen und deren Verbesserung befasste.

Die Zeitleiste

Als ich damals zu Driftrock kam, hatte ich – wie jeder Neue in einem Team – ein paar Ideen, wie wir die Dinge anders angehen könnten, aber es gab keine Möglichkeit, diese dem Team vorzuschlagen und mit ihm zu besprechen. Die einzige wirkliche Option bestand darin, eine Idee an unseren Vorgesetzten weiterzuleiten und die Zustimmung von oben einzuholen, was in einem kleinen Team aus erfahrenen Ingenieuren mit vielen Ideen etwas unnötig erschien.

Und so kam es zur Retrospektive. Wir fingen ganz einfach an: Wir wollten zunächst eine einzige Retrospektive durchführen und dann weitersehen. Als Moderator versuchte ich, während unserer ersten Retrospektive so viel Wissen wie möglich zu vermitteln. Um das restliche Team nicht zu überfordern, hielten wir auch diese einfach und konzentrierten uns auf drei Hauptpunkte:

• Es geht hier nicht darum, Schuld zuzuweisen. Es ist wichtig, ein Umfeld zu schaffen, das psychologische Sicherheit fördert und Schuldzuweisungen zerstören diese. Dinge laufen schief, das wissen wir, also lasst uns offen darüber sprechen, wie wir uns als Team verbessern und dieselben Fehler vermeiden können.
• Dies ist kein weiteres Treffen, bei dem wir uns nett unterhalten und sich nichts ändert. Konkrete Maßnahmen sind ein entscheidender Ergebnis unserer Diskussion, ebenso wie deren Umsetzung.
• Wir haben uns auf das Wesentliche besonnen und die Sitzung um die vier Schlüsselfragen.

Das lief recht gut, und daraufhin einigten wir uns darauf, regelmäßige Retrospektiven durchzuführen. Das war leichter gesagt als getan, denn es bedurfte immer noch mindestens einer Person, die dafür sorgte, dass die nächste Retrospektive stattfand, die Verantwortlichen für die Maßnahmen im Auge behielt und den Lernprozess weiter vorantrieb. Mit der Zeit fanden wir einen guten Rhythmus für zweiwöchentliche Retrospektiven, begannen, unsere Maßnahmen zu dokumentieren, und sobald das Team den Nutzen erkannte, etablierte sich diese Praxis von selbst.

Es folgten weitere Retrospektiven, und das Team wuchs mit jeder kleinen Verbesserung, ebenso wie das Interesse von außerhalb des Teams. Dies führte zu einer kurzen Präsentation vor dem gesamten Unternehmen über Retrospektiven und darüber, wie wir sie eingesetzt hatten. Daraufhin änderte sich meine Rolle ein wenig, sodass ich einen Teil meiner Zeit darauf verwenden konnte, dem Growth-Team beim Einstieg in Retrospektiven zu helfen.

Was habe ich gelernt?

Retrospektiven für Teams durchzuführen, die keine Software entwickeln, war für mich eine neue Erfahrung. Die vielleicht deutlichste Erkenntnis war, dass das Growth-Team, obwohl es Überschneidungen zwischen den Rollen gibt, in seiner Arbeit recht unabhängig ist. Daher ist es viel schwieriger, bei der Reflexion über einen bestimmten Zeitraum eine gemeinsame Basis zu finden. Es ist viel wahrscheinlicher, dass sie eine Reihe von Aufgaben unabhängig voneinander bearbeiten, im Vergleich zu den Mitgliedern eines Entwicklungsteams, die im Allgemeinen auf dieselben Ergebnisse hinarbeiten, möglicherweise am selben Problem, und deren Rollen sehr ähnlich sind. Stattdessen stellten wir fest, dass es weitaus wertvoller war, sich auf ein Thema zu konzentrieren. So hatten wir beispielsweise zuvor Retrospektiven, die sich auf das Account-Management konzentrierten, und eine weitere auf Rollen und Verantwortlichkeiten.

Als Außenstehender sind einem realistisch gesehen Grenzen gesetzt, was man alles erreichen kann. Es ist viel schwieriger, so etwas zu organisieren, wenn man niemanden im Team hat, der sich dafür einsetzt und einen Teil der Verantwortung übernimmt. Darüber hinaus muss das Team den Wunsch haben, sich zu verbessern, den Nutzen frühzeitig erkennen, aber auch seinen eigenen Weg finden.

Wenn ich auf den gesamten Weg zurückblicke, fallen mir selbst bei dem scheinbar einfachen Schritt, in einem Entwicklungsteam mit Retrospektiven zu beginnen, noch einige weitere Erkenntnisse ein:

• Moderation – Es ist keine leichte Aufgabe, in seinem eigenen Team als unparteiischer Moderator voranzugehen. Aus diesem Grund ziehen wir es vor, dass die Moderation von einer Person übernommen wird, die nicht zum Team gehört. Dies hat den zusätzlichen Vorteil, dass die Kommunikation und der Wissensaustausch zwischen den Teams verbessert werden und gleichzeitig eine externe Kontrolle gewährleistet ist, falls die Diskussion zu sehr ins Detail geht.
• Das Positive hervorheben – Es ist unglaublich wichtig, dass jeder die Auswirkungen einer abgeschlossenen Maßnahme oder eines wichtigen Gesprächs erkennt. Geht zu Beginn jeder Retrospektive auf die Maßnahmen ein, sprecht in den Standup-Meetings darüber, macht sie sichtbar und hebt die besten Beispiele besonders hervor.
• Es wird Skeptiker geben – natürlich werden manche den Nutzen anzweifeln, das ist verständlich und in Ordnung. Diese Kritik ist ein nützliches Mittel zur Verbesserung.
• Sei beharrlich – wenn du an etwas glaubst, bleib dabei. Achte aber auf andere, nimm die Stimmung im Team wahr und passe dich entsprechend an.
• Seien Sie ein Vorbild – Setzen Sie bei der Teilnahme an diesen Sitzungen Maßstäbe. Seien Sie präsent und bringen Sie sich voll und ganz ein.

Was gut gelaufen ist

Das Growth-Team empfindet diese zweiwöchentliche Sitzung als eine willkommene Auszeit vom täglichen Hektik und Stress des Kampagnen- und Kundenmanagements. In dieser Sitzung haben sie die Zeit, Trends bei den verschiedenen laufenden Aufgaben zu erkennen. So können sie ihre Vorgehensweise entsprechend anpassen und in der nächsten Sitzung überprüfen, wie sich dies ausgewirkt hat.

Mir ist wieder bewusst geworden, dass die Retrospektive ein wirkungsvolles Instrument zur Förderung der Eigenverantwortung sein kann. Wenn sie gut läuft, ist sie ein hervorragendes Forum, in dem Einzelne Bedenken äußern, Änderungen vorschlagen und diese auch umsetzen können.

Allgemeiner betrachtet hat die Retrospektive dazu beigetragen, einen grundlegenden Aspekt der Unternehmenskultur von Driftrock sichtbar zu machen, der zwar schon immer vorhanden war, aber selten erwähnt wurde. Da wir uns in letzter Zeit mit unseren zentralen Unternehmenswerten beschäftigt haben (bleiben Sie dran), ist deutlich geworden, dass die Bereitschaft zu lernen und sich zu verbessern – die diese Praxis wirklich verkörpert – ein wesentlicher Bestandteil dieser Organisation ist.

Wenn du Feedback oder Fragen hast oder etwas Ähnliches gemacht hast, melde dich gerne bei mir @dan_badge.

Einige nützliche Links:
Retrospektive-Wiki – viele praktische Ideen zur Moderation
Retromat – Kombinieren Sie verschiedene Sitzungen
Agile Retrospektiven – Gute Teams großartig machen
50 schnelle Ideen zur Verbesserung Ihrer Retrospektive

‍