Windows Developer | Aus Projektfehlern lernen

Die Retrospektive als helfendes Ritual

Die Grundlage agilen Arbeitens ist das ständige Lernen aus dem eigenen Handeln. Mit Retrospektiven hinterfragen alle Beteiligten das eigene Vorgehen regelmäßig und optimieren dieses. Doch im stressigen Projektalltag verliert die Retrospektive oft an Bedeutung. Immer wieder begegnet uns ein: „Wir machen Scrum, aber für Retrospektiven haben wir keine Zeit.“  Der Verzicht auf Retrospektiven ist der Verzicht auf den Motor und Hebel für Prozessverbesserungen – ein Plädoyer für gute Retrospektiven.

Unsere Schulzeit lehrte uns durch Klassenarbeiten und Klausuren, dass sich Fehler negativ auf unsere Ergebnisse auswirken. Die Nachbetrachtung unserer Fehler hat selten stattgefunden. Nur durch eigenes Engagement und selbstständiges Auseinandersetzen mit den Fehlern konnten wir eine Lehre für uns ziehen. Im Schulalltag blieb für die Nachbetrachtung kaum Zeit. Stattdessen lernten wir, dass wir einfach mehr hätten leisten sollen. Dabei ist die genaue Betrachtung von Fehlern und die Auseinandersetzung mit der Frage „Was konkret hätte ich anders machen können?“ die einzig zielführende Frage. Bleibt es bei der einfachen Schuldzuweisung an sich selbst, findet keine bewusste Veränderung des Vorgehens statt. Das Ziel beim nächsten Mal mehr zu leisten, ist nicht messbar. Wann ist es genug? Was ist mehr? Und was konkret hätte uns in der Klassenarbeit oder Klausur weiter geholfen? 

Aus fehlern lernen

Agiles Arbeiten bietet mit der Retrospektive den passenden Methodenbaustein für die Beantwortung dieser konkreten Fragen. Es geht nicht darum, festzuhalten, wer an welcher Stelle an einem Fehler schuld ist, sondern darum, welche Veränderungen dazu beitragen können, die gemachten Fehler in Zukunft zu vermeiden.


Einer der Gründe, warum Retrospektiven schwer Einzug in den Projektalltag finden, sind die alten Schulerfahrungen. Es ist uns unangenehm, über Fehler zu sprechen. 

Routinen durchbrechen

Unbewusste Handlungen, die in Routinen übergegangen sind, erleichtern die tägliche Arbeit. Es kostet weniger Energie Handlungen unbewusst zu wiederholen, anstatt Energie dafür aufzuwenden die Handlungen in den Bewusstseinsraum zu holen und den gewählten Weg zu hinterfragen. Aus diesem Grund fallen Veränderungen, insbesondere die des eigenen Verhaltens, besonders schwer. Oft haben wir uns bestimmte Verhaltensweisen über Jahre selbst antrainiert. Wenn wir morgens aufstehen, machen wir uns nur selten Gedanken darüber, welche Handlungen notwendig sind, um erfolgreich Kaffee oder Tee zu kochen. Ebenso wenig, stehen wir wohl morgens im Badezimmer und müssen uns überlegen, welche Schritte notwendig sind, um unsere Zahnbürste erfolgreich und zielführend im Mund verschwinden zu lassen. Es sind Routinen und Automatismen.

Auch in Projekten entwickeln wir unsere eigenen Routinen. Unabhängig davon, ob wir allein oder im Team arbeiten. Wir lernen, dass gewisse Handlungen im Projektalltag notwendig und zielführend sind. Dadurch passiert es, dass ein Teil der Handlungen nicht mehr hinterfragt wird. Sei es der standardisierte Meilenstein-Plan, der von Projekt zu Projekt mitgeführt wird oder die ToDo-Listen, die seit Jahren im Unternehmen eingesetzt werden. Wir wählen die Methodenbausteine für unsere Projekte nur selten bewusst aus. "SWBLM" ("So wie beim letzten Mal") ist die Methode der Wahl. Im Unternehmen oder Projektteam existieren implizite Annahmen, wie Projekte umgesetzt und abgewickelt werden. Wenn sich Methodenbausteine und Rituale etabliert haben, laufen Projekte quasi von selbst – und scheitern trotzdem von Zeit zu Zeit.


Ein Grund für das Scheitern kann in SWBLM liegen.


Es wird übersehen, dass Projekte sich unterscheiden und aufgrund ihrer unterschiedlichen Anforderungen auch unterschiedliche Vorgehensweisen erfordern. Das heißt nicht, dass das Rad für jedes Projekt neu erfunden werden muss. Es bedeutet aber, dass die genutzten Methodenbausteine in jedem Projekt aus dem Unterbewusstsein in unseren Bewusstseinsraum geholt werden müssen, um sie zu hinterfragen und anzupassen. Immer dann, wenn die Antwort lautet „Das haben wir schon immer so gemacht“ oder „Das machen wir halt so“, ist es an der Zeit, das Vorgehen zu hinterfragen.

Mit Ritualen lernen

Doch, wie schafft Ihr es überhaupt Routinen und Automatismen als solche zu identifizieren? Ihr braucht ein Ritual. Ein Ritual, in dem Ihr Euch bewusst vornehmt, die impliziten Annahmen und Routinen aus ihrem Versteck zu holen. Nur, wenn Ihr Euch bewusst die Zeit dafür nehmt, kann Euer Vorhaben auch Erfolg haben.


Im täglichen Projektgeschäft ist die Zeit knapp. In den meisten Fällen gibt es strikte Deadlines, die es gilt zu erreichen. Doch in den wenigsten Fällen wird dieses Ziel erreicht – und wenn doch, dann oft außerhalb des festgelegten Budgets. Es beginnt ein Teufelskreis: Der Kreis des ständigen Drucks, in dem scheinbar keine Zeit für Dinge bleibt, die außerhalb des vorliegenden Projektplans liegen. Lessons Learned und Retrospektiven scheinen Zeitfresser zu sein, die keinen fassbaren Mehrwert liefern. Diese Einschätzung verleitet dazu, sie aufzuschieben, sie stark zu verkürzen oder gar ganz ausfallen zu lassen. Dabei ist das Ritual, Euch bewusst über Euren Prozess zu unterhalten der einzige Anker, der Euch  das Aufbrechen des Teufelskreises ermöglichen kann.


Das Ziel von Retrospektiven ist es, Euren Projektprozess kurzfristig zielgerichtet anpassen zu können. Wenn Ihr es schafft, Euren Projektprozess auf die individuellen Anforderungen eines Projekts auszusteuern, erhöht Ihr die Wahrscheinlichkeit eines erfolgreichen Abschlusses. Ihr brecht mit Euren Routinen. Ihr ermöglicht allen Teammitgliedern aus dem bisherigen Vorgehen zu lernen und Anpassungen für das laufende Projekt vorzunehmen. Gleichzeitig schafft Ihr es Gelerntes mitzunehmen und es auch für kommende Projekte anzuwenden.


Gute Retrospektiven geben Euch die Möglichkeit die Art, wie Ihr Eure produktive Arbeitszeit verwendet, deutlich zu verbessern.

Erfolgreiche Retrospektiven moderieren

Nicht-moderierte Meetings sind böse Meetings.

 

Dieser Grundsatz gilt insbesondere für Retrospektiven. Eine Retrospektive ist keine gemütliche Teerunde ohne Agenda. Sie folgt einem klaren Konzept und hat ein klares Ziel: Am Ende gemeinsam konkrete Veränderungen festlegen.

 

Retrospektiven müssen nicht den großen Wurf landen und alle Probleme vorangegangener Projekte beseitigen. Stattdessen hilft es sich auf konkrete Maßnahmen oder Teamregeln zu einigen, die kurzfristig umsetzbar sind. Retrospektiven finden in kurzfristigen, regelmäßigen Zeitintervallen statt, zum Beispiel nach jedem Sprint. Dieses eröffnet die Option neue Maßnahmen und Regeln einfach einmal auszuprobieren. Sollten sie nicht zu der gewünschten Verbesserung führen, lassen sich die Maßnahmen weiter optimieren oder zurückstellen. Wenn eine vereinbarte Maßnahme noch nicht zu dem gewünschten Erfolg geführt hat, war sie entweder noch nicht ausreichend oder hinter der benannten Schwierigkeit steckt doch noch etwas anderes. Andere Maßnahmen können dann sinnvoller sein. Die Regelmäßigkeit der Retrospektiven bietet die Chance, Euren eigenen kontinuierlichen Verbesserungsprozess konkret voranzutreiben.

 

Eine Retrospektive folgt einem festen Raster, um sicherzustellen, dass am Ende der Retrospektive konkrete Maßnahmen oder Teamregeln vereinbart werden. In der Realität hat sich der Ablauf in den folgenden sechs Phasen [Retrospektiven in agilen Projekten] bewährt:

1. Intro

Der Moderator beziehungsweise die Moderatorin stellt den Ablauf der Retrospektive vor, um allen Teilnehmerinnen und Teilnehmern mitzuteilen, was sie erwartet. Es ist außerdem der Zeitpunkt der Beschlusskontrolle: Habt Ihr die Maßnahmen und Regeln, die Ihr in der letzten Retrospektive vereinbart habt, umgesetzt und eingehalten?

 

Das Team wird außerdem an die in der Retrospektive geltenden Regeln erinnert:

  • Die Vegas-Regel und
  • die oberste Direktive. 

Die Vegas-Regel besagt:

„Alles, was wir in dieser Retrospektive besprechen, bleibt unter uns.“

Das Ziel ist es, dem Team auch bei sensiblen Themen einen sicheren Raum zur Diskussion zu bieten.

Jedes Team entscheidet selbst, welche Inhalte der Retrospektive im Anschluss veröffentlicht werden sollen. Das Veröffentlichen und Aufhängen entsprechender Ergebnis-FlipCharts hat sich im Alltag bewährt. Dennoch kann es auch Ergebnisse geben, die nicht öffentlich in den Büros zur Ausstellung kommen sollen. Grundsätzlich gilt, dass alle Diskussionsinhalte von der Vegas-Regel betroffen sind, es sei denn, das Team entscheidet sich bewusst für die Kommunikation einzelner Diskussionsinhalte und Äußerungen nach außen.

Die oberste Direktive besagt:

„Wir gehen davon aus, dass alle Beteiligten zu jedem Zeitpunkt nach bestem Wissen, Gewissen und Kenntnisstand gehandelt haben.“

Sie sorgt für eine lösungsorientierte Diskussion – ohne Schuldzuweisungen. Natürlich könnt Ihr in einer Retrospektive ausgiebige Diskussionen darüber führen, wer an dem Scheitern eines Projektes oder einem Fehler konkret schuld ist. Doch zum Einen bringt Euch die Schuldfrage im Detail keiner Lösung näher und zum Anderen lässt sich diese auch nicht immer eindeutig beantworten. Hat zum Beispiel ein einzelnes Teammitglied durch fehlerhaften Code für den Zusammensturz eines ganzen Systems gesorgt, kann das Team sich darüber ärgern. Die einfache Schuldzuweisung beantwortet aber noch nicht die Frage, wieso es bisher keinen teaminternen Prozess zur Qualitätssicherung gibt, damit ein solcher Fehler vor dem Release auffällt. Wenn Ihr wisst, wer möglicherweise Schuld hat, wisst Ihr noch immer nicht, was Ihr beim nächsten Mal anders machen könnt, damit der gleiche Fehler nicht wiederholt wird. Ihr seht also: Natürlich könnt Ihr über Schuld diskutieren, wenn Ihr aber konstruktiv an Euch und Eurem Prozess arbeiten wollt, bietet Euch die Beantwortung der Schuldfrage keinen Mehrwert.

Die Vegas-Regel

Um allen Teilnehmerinnen und Teilnehmern ein sicheres Diskussionsumfeld zu schaffen, gilt in Retrospektiven die Vegas-Regel: „Alles, was wir hier besprechen, bleibt unter uns.“ - Jedes Team entscheidet im Einzelfall, ob und in welcher Art Inhalte einer Retrospektive für andere wichtig sind und entsprechend veröffentlicht werden sollten.

2. Set the Stage

Das Intro "gehört" dem Moderator oder der Moderatorin. Die nachfolgende Phase stimmt nun die Teilnehmerinnen und Teilnehmer auf die Retrospektive ein. „Set the Stage“ sammelt erste Eindrücke und verschafft einen Überblick über die aktuelle Stimmung. Hierbei können verschiedene Vorgehensweisen zum Einsatz kommen. Beispielsweise könnte zum Einstieg mit den Fragen: „Wie geht es Dir heute?“ und „Wie schätzt Du die aktuelle Stimmung im Projektteam ein?“ begonnen werden. Die Ergebnisse werden auf einer FlipChart visualisiert. Geübte Teams können ihre aktuelle Stimmung auch in selbstgemalten Bildern ausdrücken oder sogar kneten.

3. Gather Data

Die dritte Phase dient der Faktensammlung:

  • Was lief im letzten Sprint oder dem festgelegten Zeitraum gut, und was lief nicht so gut
  • Konkrete Daten und Fakten sind genauso gefragt, wie Bauchgefühle.
  • Manchmal eröffnet das Bauchgefühl eines Einzelnen neue Perspektiven und fördert unausgesprochene Gefühle anderer zu Tage. 

Die Äußerungen werden von dem Moderator oder der Moderatorin gesammelt. Hierbei werden verschiedene Visualisierungsmöglichkeiten eingesetzt. Die Themen können zum Beispiel in Kleingruppen oder von jedem Einzelnen auf Moderationskarten geschrieben werden, um sie anschließend an einer FlipChart oder freien Wand zu sammeln.


Manche Teams neigen dazu, bereits in dieser Phase Diskussionen über mögliche Ursachen zu führen oder sogar bereits nach Lösungsvorschlägen zu suchen. Der Moderator oder Moderatorin kann die genannten Themen bereits mitschreiben, falls sie in den kommenden Phasen wieder benötigt werden sollten. Dennoch ist es wichtig, diese Diskussionen zu bremsen, um eine Vermischung der Themen zu vermeiden und keine vorschnellen Schlüsse zu ziehen.

4. Generate Insights

Das Team wählt eine begrenzte Anzahl an Themen aus der vorherigen Phase aus, um diese Themen weiter zu bearbeiten. Die Abstimmung dieser Themen kann je nach Teamphase [2] und Teamstruktur [3] durch einfaches Handzeichen, geheime Wahl oder andere Abstimmungsmöglichkeiten erfolgen. Solange es fair zugeht, sind der Fantasie keine Grenzen gesetzt. Es hat sich bewährt, nicht mehr als zwei Themen in einer Retrospektive intensiv zu bearbeiten. Dies zum Einen aufgrund der festgelegten Dauer einer Retrospektive, zum Anderen aber auch, um die Themen in einer entsprechenden Tiefe bearbeiten zu können. 

 

Nun ist es an der Zeit die Ursachen der genannten Themen  herauszufinden. Manche Teams neigen dazu die Ursachen nicht weiter zu ergründen und stattdessen direkt in die Diskussion von Lösungsvorschlägen einzusteigen. Aufgabe der Moderatorin beziehungsweise des Moderators ist es die Teilnehmerinnen und Teilnehmer durch Einsatz der richtigen Fragestellungen an die Hand zu nehmen und einen Weg zu leiten. Eine weitere Schwierigkeit kann auch in der Tiefe der Ursachen auftreten. Manchmal blockieren „Elefanten im Raum“ [4] eine ehrliche Diskussion über Ursachen. So haben manche Teilnehmerinnen und Teilnehmer eine Ursache im Kopf, trauen sich aber nicht, diese zu äußern. Sie befürchten möglicherweise, damit Anwesenden oder auch Vorgesetzten auf die Füße treten. Besonders große Elefanten können einige Retrospektiven überleben. Hier gilt es Geduld zu haben. Als außenstehender Moderator oder Moderatorin glauben wir manchmal mögliche Ursachen bereits erkannt zu haben. Doch um die Nachhaltigkeit der Handlungsoptionen in der folgenden Phase „Decide what to do“ sicherzustellen, ist es von großer Bedeutung, dass das Team aus sich selbst heraus festlegt, was für ihre Themen ursächlich ist.  

5. decide What To Do

In dieser Phase entwickelt das Team Handlungsoptionen für die genannten Themen und Ursachen. Dabei können diese einfach per Zuruf auf einer FlipChart gesammelt werden. Manchmal bietet sich auch die Arbeit in Kleingruppen an, um eventuelle leise Stimmen zu stärken und sicherzustellen, dass alle gleichermaßen die Chance erhalten, Handlungsoptionen einzubringen. Bei den Handlungsoptionen kann es sich um ein konkretes ToDo handeln, welches von einer Person oder auch mehreren einmalig umgesetzt wird. Es kann aber auch eine Teamregel sein, die in Zukunft für alle Teammitglieder gilt. Entscheidend ist, dass die vereinbarten Maßnahmen umsetzbar sind. Nur dann ist im Anschluss nachvollziehbar, welche Wirkung sie hatten.


Die vereinbarten Maßnahmen oder Teamregeln werden entsprechend festgehalten. Allen Beteiligten muss klar sein, was konkret zu tun ist.


Das Ziel der Retrospektive ist es im Anschluss das eigene Verhalten zu ändern. Deshalb hat es sich bewährt nicht mehr als zwei bis drei konkrete Maßnahmen oder Teamregeln zu verabschieden. Dies stellt sicher, dass es nicht zu einer Überforderung bei der Umsetzung kommt. Wenn die in der Retrospektive vereinbarten Maßnahmen dauerhaft nicht umgesetzt werden können, kann dies ein Frustrationsfaktor sein und die Qualität Eurer Retrospektiven massiv beeinflussen.

6. Closing The Retrospective

In der sechsten und letzten Phase lassen die Teammitglieder die vorangegangene Retrospektive Revue passieren. Eine mögliche Frage des Moderators oder der Moderatorin könnte zum Beispiel lauten:

  • „Wie schätzt Du die Umsetzbarkeit der vereinbarten Maßnahmen ein?“ oder
  • „Wie ist Dein Gefühl nach der Retrospektive?“ 

Der Moderator oder die Moderatorin sollte die Phase nutzen, um bereits jetzt mögliche Themen für kommende Retrospektiven zu hören und eventuell vorhandene Elefanten zu erkennen.

Unsere Retrospektiven haben keinen Mehrwert: "Wir jammern nur"

Hinterfragt die Maßnahmen und Regeln, die Ihr in der Retrospektive vereinbart. Achtet darauf, dass sie möglichst konkret sind und von allen Beteiligten verstanden wurden. Dabei ist wichtig, dass die Veränderung von den Teammitgliedern abhängt -- und nicht von Außenstehenden.

Auch zu viele Vereinbarungen in nur einer Retrospektive können für Frustration sorgen, weil sie nicht alle gleichzeitig umgesetzt werden können. Viele Maßnahmen sind nicht gleichzeitg zu schaffen.

"Good is enough" ist nicht "done"

Der agile Grundsatz „Good is enough“, der auch bei der Vereinbarung von Retrospektiven-Ergebnissen genutzt werden sollte, wird häufig missverstanden. Bei der agilen Entwicklung ist:  „Geht's auch einfacher?“ eine immer wiederkehrende Frage, um gemeinsam herauszufinden, welche Anforderungen ein konkretes „must have“ und welche möglicherweise nur „nice to have“ sind. Viele Teams tun sich mit diesem Grundsatz und der Fragestellung schwer, weil sie „Good is enough“ mit einem Qualitätsanspruch verwechseln. Bei der Fragestellung „Geht's auch einfacher?“ geht es nicht darum am Ende qualitativ minderwertigen Code abzuliefern oder gar mit Bugs live zu gehen. Es geht stattdessen darum genau herauszufinden, was hinter den Anforderungen steckt und stets zu hinterfragen, ob diese wirklich gewollt oder insbesondere in großen Projekten auch wirklich noch erforderlich sind.

 

Ist das Minimal Viable Product erst einmal erschaffen und live, kann dies das Ende des Projektes bedeuten. Wenn das Budget aufgebraucht ist, die Umsetzung bereits den gewünschten Mehrwert liefert oder Features einfach nicht mehr gebraucht werden, wird die Entwicklung des Projekts nicht fortgesetzt. Für das Projektteam ist dies nicht gleichbedeutend mit „Fertig“. Ein agiles Team ist erst dann fertig, wenn nach Projektabschluss eine entsprechende Retrospektive stattgefunden hat, die Learnings für kommende Projekte entwickelt.


Wenn Ihr die Abschluss-Retrospektive beziehungsweise Projekt-Supervision übergeht und mit dem Livegang auch für Euch ein „Fertig“ an das Projekt schreibt, überseht Ihr mit aller Wahrscheinlichkeit Möglichkeiten Euren Prozess weiter zu verbessern. Während Ihr in den Sprint-Retrospektiven immer einen kurzen Zeitraum überblickt und Veränderungen im Prozess oder Teamregeln möglicherweise nur für das laufende Projekt gelten, bietet die Abschluss-Retrospektive die Chance das gesamte Projekt zu überblicken. Sie bietet die Möglichkeit den Verlauf des Projekts in Gesamtheit zu betrachten und sich die Frage zu stellen: „Wenn ich zu Beginn des Projekts den heutigen Wissenstand gehabt hätte – was hätte ich anders gemacht?“. Die Antwort auf diese Frage kann Euch dabei helfen Hindernisse zu identifizieren, die sich stets durch Eure Projekte ziehen im Einzelnen aber gar nicht so auffallen. 

Die Projekt-Supervision zum Abschluss

Während die Sprint-Retrospektive eine festgelegte Dauer von 90 Minuten hat, darf die Projekt-Supervision zum Abschluss eines Projekts auch einen größeren Zeitrahmen einnehmen. Je nach Größe und Umfang eines Projekts kann sie bis zu vier Stunden dauern. Dabei werden die einzelnen Phasen der Retrospektive entsprechend verlängert.


Der Artikel ist eine Zweitveröffentlichung des gleichnamigen Artikel von Julia Schmidt in der Zeitschrift "Windows Developer 05.2015". Abweichend vom Original ist die Anrede in diesem Artikel "Ihr", während im Zeitschriften-Artikel gesiezt wird.


Kommentar schreiben

Kommentare: 0