1 Das 1×1 der Retrospektive
1.1 Was ist eigentlich eine Retrospektive?
Die Retrospektive (lat. retrospectare »zurückblicken«) bezeichnet im Allgemeinen einen Rückblick [Wikipedia 01]. Wenn man abends ins Bett geht und vor dem Einschlafen den Tag Revue passieren lässt, dann ist das eine Retrospektive. Wenn man mit der Familie beim Abendbrot miteinander über den vergangenen Tag spricht, die Kinder von der Schule erzählen und die Eltern von ihren Erlebnissen, dann ist auch das eine Retrospektive. Blickt man zurück auf das Lebenswerk eines Künstlers, eines Autors, eines Regisseurs oder anderer Personen, dann spricht man ebenfalls von einer Retrospektive. Dazu finden dann verschiedene Veranstaltungen statt, bei denen die verschiedenen Werke des Künstlers ausgestellt werden. Man sammelt alle wichtigen Werke an einem Ort zusammen, um ein komplettes Bild des Künstlers zu zeichnen. Auf diese Weise bekommt man einen sehr guten Gesamteindruck und hat die Möglichkeit, die verschiedenen Werke zu vergleichen oder in Relation zueinander zu setzen. Würde man nur eines der Werke zu sehen bekommen, wäre man dazu nicht in der Lage. Nur durch dieses Gesamtbild wird man in die Lage versetzt, das Ganze zu sehen, und bekommt die Möglichkeit, darüber zu spekulieren, warum der Künstler etwas so und nicht anders gemacht hat.
Auch im Fernsehen findet jedes Jahr eine Art Retrospektive statt, meist am Ende eines Jahres in Form des Jahresrückblicks. Dabei versuchen sich die verschiedenen TV-Sender gegenseitig zu überbieten, indem jede Sendeanstalt bestrebt ist, die besseren, schöneren, witzigeren oder bekannteren Leute zu diesen Sendungen einzuladen. Auf Vollständigkeit wird hier wenig Wert gelegt, vielmehr steht die Unterhaltung im Vordergrund. Das Gesamtbild eines Jahres ist also eher löchrig und nicht wirklich dazu geeignet, Rückschlüsse zu ziehen oder verschiedene Ereignisse miteinander in Verbindung zu setzen.
Wenn ich in diesem Buch von Retrospektiven spreche, meine ich etwas anderes. Diese Retrospektiven enthalten zwar auch einen Rückblick, aber das ist nur der erste Schritt. Viel wichtiger ist es, aus diesem Rückblick Erkenntnisse und Einsichten zu gewinnen. Diese Erkenntnisse und Einsichten sollen dann dabei helfen, aus der Vergangenheit zu lernen und entsprechende Veränderungen abzuleiten. Dabei lernt man sowohl aus den Erfolgen als auch aus den Fehlern. Denn oft können gute Dinge noch besser gemacht werden. Man könnte es auch mit der Evolution vergleichen. Dinge, die nicht funktioniert haben, sind ausgestorben, aber alles, was zum Erhalt der Art beigetragen hat, wurde beibehalten und weiterentwickelt. Jede dieser Veränderungen ist letztlich nichts anderes als ein Experiment, bei dem man noch nicht sicher weiß, was am Ende dabei herauskommt. Im besten Falle führen diese Experimente zu einer Verbesserung unserer derzeitigen Situation. Manchmal macht es die Sache aber nur noch schlimmer, aber dafür gibt es ja die nächste Retrospektive.
Jede Retrospektive wird von einem sogenannten Facilitator geleitet. Er moderiert die Retrospektive und sorgt dafür, dass die Gruppe ihre gesetzten Ziele erreicht. Er unterstützt die Gruppe dabei, ein tragfähiges Ergebnis zu erarbeiten, das als Basis für den zukünftigen Erfolg dienen soll. Der Facilitator selbst ist kein Teilnehmer (auch wenn sich das vor allem bei kleinen Teams nicht immer bewerkstelligen lässt). Er begleitet den Prozess, bringt jedoch selbst nicht aktiv Lösungen ein. Ein guter Facilitator ist ein entscheidender Faktor für eine erfolgreiche Retrospektive.
Das erste Mal wurde die Retrospektive in dieser Form im Buch »Project Retrospectives: A Handbook for Team Reviews« [Kerth 2001] von Norman Kerth beschrieben.
A retrospective is a ritual gathering of a community at the end of a project to review the events and learn from the experience. No one knows the whole story of a project. Each person has a piece of the story. The retrospective ritual is the collective telling of the story and mining the experience for wisdom.
Sein Buch, dessen aktuelle Ausgabe 2001 erschienen ist, erklärt, wie sich Retrospektiven von sogenannten »Postmortems« und »Lessons Learned« unterscheiden. Der Hauptunterschied ist, dass man bei Retrospektiven den Fokus auf positive Handlungen legt und diese als Katalysator für Veränderungen nutzt. Sie stellen nicht den Endpunkt des Projekts dar, sondern Meilensteine in einem kontinuierlichen Verbesserungsprozess.
Im Jahr 2001 trafen sich ein paar Leute in einer Skihütte, um ein Manifest der agilen Softwareentwicklung zu schreiben [Manifesto]. Es besteht aus vier Wertepaaren und zwölf Prinzipien, die die Basis des Manifests darstellen. Das letzte dieser Prinzipien beschreibt recht gut, was in einer Retrospektive gemacht wird.
In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und, passt sein Verhalten entsprechend an.
Genau dieses Manifest war einer der Hauptgründe, warum vor allem die agile Gemeinschaft die Retrospektive begeistert übernahm und in ihren Arbeitsablauf integrierte. Diese Menschen begriffen, dass sie nicht erst bis zum Ende eines Projekts warten müssen, um aus dem Geschehenen zu lernen und entsprechende Veränderungen vorzunehmen. Stattdessen veranstalten sie eine Retrospektive nach jeder Iteration, also nach einem festen Zeitraum, der möglichst nicht länger als 1 Monat sein sollte, da man sonst Gefahr läuft, den Feedbackzyklus zu groß zu setzen.
Was ist eine Iteration?
Das Wort Iteration kommt vom lateinischen »iterare«, was so viel bedeutet wie »wiederholen«. Iterationen werden in verschiedensten Bereichen angewendet, in denen es darum geht, ein Problem schrittweise zu lösen. In der Informatik spricht man von Iterationen, wenn verschiedene Schritte immer wiederholt werden, bis der gewollte Zustand erreicht wurde (z.B. mit einer FOR-Schleife). In der Bauökonomie ist ein iterativer Prozess das schrittweise Annähern von ursprünglichen Bauzielen an die machbare Umsetzung.
Wenn ich hier von Iteration spreche, meine ich den Prozess, ein Projekt in klar definierten, kurzen, sich wiederholenden Schritten durchzuführen. Nach jeder Iteration wird überprüft, ob und inwieweit man sich dem eigentlichen Projektziel genähert hat, und nimmt, wenn notwendig, Korrekturen am ursprünglichen Plan vor. Man versucht dadurch das Risiko von Ungewissheiten und Überraschungen so klein wie möglich zu halten. Das gleiche Verfahren lässt sich auch im Change Management verwenden.
Dies versetzt einen in die Lage, einen kontinuierlichen Verbesserungsprozess zu etablieren, bei dem ständig überprüft wird, ob man auf dem richtigen Weg ist, und gibt einem zusätzlich die Möglichkeit, rechtzeitig einzugreifen und die Prozesse anzupassen. Indem man feste Zeiten zur Reflexion einplant, hat man die Möglichkeit, Probleme sofort aus der Welt zu schaffen, anstatt bis zum Ende des Projekts zu warten. Wenn die Retrospektive erst am Ende eines Projekts stattfindet, läuft man Gefahr, dass das Gelernte bis zum nächsten Projekt wieder vergessen wurde. Außerdem wird so die Chance vertan, Dinge sofort geradezurücken, bevor es zu spät ist.
Was genau versteht man unter dem Begriff »agil« in diesem Kontext?
Im Deutschen hat das Wort »agil« die folgende Bedeutung: zu schnellen Bewegungen der Gliedmaßen fähig. Das Wort kommt vom lateinischen agilis, also »tun, machen, handeln«. Wie schon oben beschrieben, basiert diese Agilität auf dem Agilen Manifest [Manifesto], das wiederum auf 12 Prinzipien basiert. Das Agile Manifest lautet wie folgt: Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:
- Individuen und Interaktionen mehr als Prozesse und Werkzeuge
- Funktionierende Software mehr als umfassende Dokumentation
- Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
- Reagieren auf Veränderung mehr als das Befolgen eines Plans
Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.
Die dazugehörigen 12 Prinzipien sehen so aus:
1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufriedenzustellen.
2. Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
3. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
4. Fachexperten und Entwickler müssen während des Projekts täglich zusammenarbeiten.
5. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen, und vertraue darauf, dass sie die Aufgabe erledigen.
6. Die effizienteste und...
