Retrospektiven in der Praxis E-Book

Marc Löffler

• Herausgeber: dpunkt
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2014

Seitenzahl: 299

Beschreibung

Retrospektiven sind eine der tragenden Säulen einer erfolgreichen agilen Transition und eines der wichtigsten Werkzeuge, um die notwendigen kulturellen Veränderungen in einer Organisation zu initiieren und zu begleiten. Aber nicht nur im agilen Kontext sind Retrospektiven eine wertvolle Hilfe. Sie können überall dort eingesetzt werden, wo ein kontinuierlicher Verbesserungsprozess etabliert werden soll: z.B. in Lessons-Learned-Workshops im traditionellen Projektmanagement oder als Begleitung von Change-Management-Prozessen. Retrospektiven sind immer dann ein sinnvolles Werkzeug, wenn es darum geht, das Vergangene zu reflektieren und darauf basierend mögliche Veränderungen zu erarbeiten. Der Autor behandelt praxisnah und mit vielen Beispielen, wie Retrospektiven vorbereitet, moderiert und ergebnisorientiert durchgeführt werden. Er geht dabei auch auf verteilte Retrospektiven, lösungsorientierte Retrospektiven und systemische Retrospektiven ein und zeigt typische Probleme und Fallstricke auf. Aus dem Inhalt: • Das 1x1 der Retrospektive • Retrospektiven vorbereiten • Die erste Retrospektive • Der Retrospektiven-Facilitator • Von der Metapher zur Retrospektive • Change Management mit Retrospektiven

Leseprobe

Marc Löffler arbeitet als selbständiger Coach, Trainer und Facilitator. Seine Leidenschaft ist es, Menschen zum Lachen zu bringen und unsere Welt jeden Tag ein kleines bisschen zu verändern. Dabei stellt er Dinge gerne spielerisch auf den Kopf, um völlig neue Blickwinkel zu erzeugen. Er spricht regelmäßig auf agilen Konferenzen in Deutschland und Europa und schreibt Artikel zu agilen Themen auf seinen Blogs in Englisch unter blog.scrumphony.com und auf Deutsch unter www.marcloeffler.eu. In seiner Freizeit spielt er Saxofon in einem großen sinfonischen Blasorchester.

Retrospektiven in der Praxis

Veränderungsprozesse in IT-Unternehmen effektiv begleiten

Marc Löffler

Marc Löffler

[email protected]

Lektorat: Christa Preisendanz

Copy-Editing: Ursula Zimpfer, Herrenebrg

Herstellung: Birgit Bäuerlein

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie;

detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Buch 978-3-86490-144-7

PDF 978-3-86491-460-7

ePub 978-3-86491-461-4

1. Auflage 2014

Copyright © 2014 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

    Für Andrea, Nico und Ben    

Geleitwort

Neulich las ich in einer Tageszeitung folgende Geschichte: In Amman, Jordanien wartet ein Geschäftsmann in einem Hotel vor einem Hotelaufzug. Es handelt sich um eines der großen, noblen Hotels, bei denen sechs Aufzüge nebeneinander platziert sind, um der Kundennachfrage besser gerecht zu werden. Dieser Geschäftsmann wartet und wartet und der Aufzug kommt nicht. Das Problem ist, dass der Geschäftsmann so dicht vor dem Aufzug steht, den er angefordert hat, dass er noch nicht einmal bemerkt, dass einige der anderen Aufzüge längst auf seiner Etage angekommen sind. Wäre er zwei Schritte zurückgegangen, hätte er sein Ziel schneller erreicht.

Diese Geschichte macht deutlich, wie wir Menschen oft dazu tendieren, an einer getroffenen Entscheidung oder an einer einmal gemachten Erfahrung (z.B. der, dass der angeforderte Aufzug kommt und nicht ein anderer) festzuhalten. Dabei wird dann auch blind der einmal eingeschlagene Weg weiterverfolgt – »das haben wir schon immer so gemacht« oder »das war schon immer so« –, anstatt diesen kritisch zu beurteilen.

Die Grundidee von Retrospektiven ist, mit ihrer Hilfe innezuhalten, über den eingeschlagenen Weg nachzudenken und mittels einer (meist kleinen) Veränderung den Weg zu korrigieren, um dadurch zukünftig besser voranzukommen. Diese Vorgehensweise ist eigentlich in unserer DNA sogar verwurzelt – denn die korrekte lateinische Bezeichnung der menschlichen Rasse ist nicht, wie landläufig geglaubt wird, Homo Sapiens, sondern Homo Sapiens Sapiens. Das bedeutet der Mensch, der über das Denken nachdenkt (oder auch der Mensch, der zweimal überlegt). Genau dieses Nachdenken über unsere normalen, täglichen Erfahrungen und Aktionen steht im Mittelpunkt der Retrospektiven.

Oftmals ist in Projekten oder Firmen die Situation jedoch die, dass die einzelnen Mitarbeiter sehr wohl wissen, was alles zu verbessern wäre. Meist jedoch fehlt die Zeit, sich im Detail um diese Verbesserungsmöglichkeiten zu kümmern, und dadurch, dass sich nichts verändert, fehlt meist noch mehr Zeit. Das heißt, man befindet sich in einem Teufelskreis, der am treffendsten wohl mit der alten Volksweisheit ausgedrückt wird: Wir haben keine Zeit, die Säge zu schärfen, wir müssen sägen.

Retrospektiven sollten somit auch als Teil des Risikomanagements verstanden werden. Denn durch die ständige Analyse der Begebenheiten und den daraus folgenden Kurskorrekturen können Risiken schnell erkannt und entsprechend angegangen werden. Auch wenn sich Retrospektiven insbesondere in der agilen Softwareentwicklung etabliert haben und ihre Anwendung dort überhaupt erst für die Agilität sorgt – so können auch andere Bereiche von der regelmäßigen Durchführung von Retrospektiven profitieren.

Dies unter anderem aus dem Grund, dass – wie eine andere alte Volksweisheit ausdrückt – man aus Fehlern klug wird. Viele Unternehmen sind jedoch der Ansicht, dass Fehler machen ein Fehler sei und man es stattdessen doch gleich richtig machen sollte (englisch: Do it right the first time). Aber in unserer zunehmend komplexer werdenden Welt besteht nicht nur der größte Teil der Softwareentwicklung darin herauszufinden, was überhaupt benötigt wird. Auch in anderen Bereichen muss erst eruiert werden, welcher Weg am ehesten zum Ziel führt. Dazu müssen auch »falsche« Wege beschritten werden, da man andernfalls nicht herausfinden kann, welches überhaupt die richtigen Wege sind. Die richtigen Entscheidungen lassen sich deterministisch nur dann treffen, wenn wir so ein System schon einmal entwickelt haben, dann kann man sich allerdings fragen, warum wir dieses Unterfangen überhaupt nochmals auf uns nehmen. Das heißt, die Exploration ist inhärenter Bestandteil von Softwareentwicklung und heutzutage auch von vielen anderen Bereichen.

Darüber hinaus beinhaltet die Entwicklung oder Akzeptanz einer Fehlerkultur auch die Forderung, ständig dazuzulernen und dies auch zu wollen. Somit leisten Retrospektiven durch ihren Fokus auf ständiger Verbesserung auch einen Beitrag zur Etablierung einer lernenden Organisation.

Eine Retrospektive bietet nun nicht nur die Möglichkeit, zu überprüfen, was alles zu verbessern ist, sondern sich auch bewusst zu machen, was alles bereits gut funktioniert und was man bisher erreicht hat.

Manchmal macht sich ja auch eine große Frustration breit, weil die Mitarbeiter den Eindruck haben, dass alles schiefläuft. Beschäftigen sie sich dann in einer Retrospektive damit, was wirklich wie gemacht wird, so wird eigentlich immer festgestellt, dass einiges auch ganz gut funktioniert. Dies trägt dann wiederum zur höheren Motivation der Mitarbeiter bei.

Als mir Marc das erste Mal von seinem Vorhaben erzählt hat, war ich sofort total begeistert. – Begeistert deshalb, da dieses Buch überfällig war! Endlich gibt es ein umfassendes Buch zu Retrospektiven auf Deutsch. Darauf habe zumindest ich schon lange gehofft. Dafür bin ich ihm sehr dankbar!

Marc ist es mit diesem Buch gelungen, einen wirklich umfangreichen Überblick zu Retrospektiven zu geben, der nicht nur bewährte konkrete Methoden beinhaltet, sondern auch neueste Entwicklungen aufgreift und auf ihre tägliche Anwendbarkeit überprüft. Er behandelt auch nicht ganz einfache Themen, wie verteilte, systemische oder lösungsorientierte Retrospektiven, und macht diese praxistauglich.

Damit hat Marc ein Werk geschaffen, das für sich steht, das heißt, das ein solides Fundament bietet, durch das Retrospektiven für diejenigen konkret werden, für die dieses Thema noch neu ist. Darüber hinaus finden aber gerade auch die erfahrenen Retrospektiven-Moderatoren umfangreiche Anregungen, um die Retrospektiven effektiver zu gestalten und damit zu kontinuierlichem Lernen und Verbessern im Unternehmen beizutragen. Freuen Sie sich darauf, mit diesem Buch einen neuen Weg einzuschlagen oder einen bestehenden zu korrigieren!

Jutta Eckstein

Autorin von Agile Softwareentwicklung in großen Projekten und Agile Softwareentwicklung mit verteilten Teams

Vorwort

Schon bei meinem ersten Kontakt mit agilen Methoden hatten es mir die Retrospektiven besonders angetan. Für mich waren sie von Anfang an der Inbegriff des kontinuierlichen Verbesserungsprozesses: Eine dedizierte Besprechung mit einer klaren Struktur, die in regelmäßigen Abständen stattfindet und bei der man gemeinsam über die letzten Wochen und Monate reflektiert, um potenzielle Verbesserungen daraus abzuleiten. Leider wird dieses regelmäßige Reflektieren in unserer Arbeitswelt allzu oft vergessen. Dadurch wird das verfügbare Potenzial gar nicht oder zu spät genutzt. An dieser Stelle fällt mir die Metapher mit dem Holzfäller ein. Dieser versucht einen Baum mit einer stumpfen Axt zu fällen. Statt sich die Zeit zu nehmen, danach zu forschen, warum er nur schwer vorankommt, macht er einfach weiter, weil er schnell fertig werden will. Würde er sich die Zeit zur Reflexion nehmen, würde er sofort feststellen, dass die Axt geschärft werden muss, und wäre somit am Ende schneller fertig. Mit Retrospektiven will man genau das unterstützen. Anstatt an der augenblicklichen, eventuell suboptimalen Arbeitsweise festzuhalten, sucht man gezielt nach Wegen, wie man diese verbessern kann.

Aus meiner Sicht sind Retrospektiven eine der tragenden Säulen eines erfolgreichen kontinuierlichen Verbesserungsprozesses und eines der besten Werkzeuge, um kulturelle Veränderungen in einer Organisation zu bewerkstelligen. Auch in traditionellen Change-Management-Initiativen können Retrospektiven einen wichtigen Beitrag leisten. Im Projektmanagement finden sie ihre Verwendung z.B. in »Lessons Learned«-Workshops. Natürlich kann man Retrospektiven auch im privaten Umfeld einsetzen. Sei es als Silvesterretrospektive mit der Familie am Ende des Jahres oder im Verein z.B. nach dem Jahreskonzert.

Da es sich bei einer Retrospektive nicht um eine normale Besprechung handelt, sondern vielmehr um einen Workshop, gibt es einige Dinge, die man beachten muss, damit man davon profitieren kann. Gleichzeitig hat man es bei Retrospektiven immer auch mit Veränderungen (in der Organisation) zu tun und wer sich mit diesem Thema schon beschäftigt hat, weiß, dass das nicht immer einfach ist. In diesem Buch habe ich versucht, all die Dinge zusammenzutragen, die für die Durchführung einer Retrospektive und das Etablieren eines kontinuierlichen Verbesserungsprozesses notwendig sind.

Obwohl Retrospektiven ein wichtiges Instrument sind, werden sie oft nur stiefmütterlich behandelt. Leider bin ich schon oft Zeuge von schlechten Retrospektiven geworden. Sei es, weil sie im »Zombie-Modus« abgehalten worden sind, schlecht moderiert und vorbereitet wurden oder schlicht keine Struktur hatten. Eine Retrospektive besteht eben nicht nur aus der Frage an das Team: »Also, was ist im letzten Sprint alles schlecht gelaufen?« Zu einer guten Retrospektive gehört mehr. Eine gute Retrospektive macht Spaß, ist abwechslungsreich, hat ein klares Ziel, ist sinnvoll und berücksichtigt das System, in dem das Team agiert. Beachtet man diese Dinge, ist man auf einem guten Weg. Mit diesem Buch möchte ich Sie auf diesem Weg begleiten und Ihnen dabei helfen, die Herausforderungen in Ihrem Umfeld zu bewältigen. Ich hoffe, dass dieses Buch für Sie eine wertvolle Hilfe beim Durchführen von Retrospektiven sein wird, und wünsche Ihnen viel Spaß beim Lesen.

Danksagungen

An dieser Stelle möchte ich mich bei allen bedanken, die direkt oder indirekt zu diesem Buch beigetragen haben. Vor allem bei all den Teams in den letzten Jahren, bei denen ich eine Retrospektive durchführen durfte.

Ein großer Dank geht an Ralph Miarka und Veronika Kotrba, die das Kapitel über lösungsorientierte Retrospektiven beigesteuert haben. Sie haben mir dadurch einiges an Recherche und Schreibarbeit abgenommen. Dieses Kapitel ist eine Bereicherung für dieses Buch.

Danke auch an Jutta Eckstein, die das Manuskript durchgesehen und mir wertvolle Hinweise gegeben hat, wie ich das Buch besser machen kann, und eine Expertenbox zum Buch beigesteuert hat. Es freut und ehrt mich sehr, dass sie das Geleitwort für dieses Buch geschrieben hat.

Ebenfalls bedanken möchte ich mich bei Christoph Pater, der das Buch von Anfang an unterstützt und bereits sehr frühe Versionen des Manuskripts durchgelesen hat. Seine hilfreichen Kommentare haben mir in dieser Anfangsphase sehr geholfen.

Bedanken möchte ich mich auch bei den beiden Rezensenten Rolf Dräther und Thorsten Oliver Kalnin, die durch ihre offene Kritik und Hinweise einen großen Anteil daran haben, wie das Buch heute vor Ihnen liegt.

Ich danke dem dpunkt.verlag, dass er es mir überhaupt erst ermöglicht hat, meinen Traum von einem eigenen Buch zu verwirklichen. An dieser Stelle geht ein besonderer Dank an Christa Preisendanz, die sich sehr für das Buch eingesetzt hat.

Ganz besonders möchte ich mich bei meiner Frau Andrea bedanken, die mir für das Buch den Rücken frei gehalten und mir dadurch erst ermöglicht hat, dieses Buch zu schreiben. Ohne sie hätte ich es nicht geschafft. Danke auch an meine Kinder Nico und Ben, die in den letzten Monaten häufiger auf ihren Papa verzichten mussten.

Über Ihr Feedback, Ihre Anregungen oder praktischen Erfahrungen bei der Anwendung der im Buch beschriebenen Praktiken, freue ich mich sehr. Dazu schreiben Sie mir am besten eine E-Mail an [email protected]. Besuchen Sie außerdem die Internetseite zum Buch mit zusätzlichen Informationen, Neuigkeiten zum Thema Retrospektiven und nützlichen Checklisten unter www.retrospektiveninderpraxis.de.

Marc Löffler

Brigachtal, November 2013

Inhaltsverzeichnis

1      Das 1×1 der Retrospektive

1.1       Was ist eigentlich eine Retrospektive?

1.2       Silvesterretrospektive

1.3       Das Retrospektiven-Phasenmodell

1.3.1       1. Phase: Den Boden bereiten

1.3.2       2. Phase: Hypothesen überprüfen

1.3.3       3. Phase: Daten sammeln

1.3.4       4. Phase: Einsichten gewinnen

1.3.5       5. Phase: Nächste Experimente und Hypothesen definieren

1.3.6       6. Phase: Abschluss

1.3.7       Zusammenfassung

1.4       Wo finde ich Aktivitäten für die Phasen?

1.4.1       Buch »Agile Retrospectives«

1.4.2       Retr-O-Mat

1.4.3       Retrospektiven-Wiki

1.4.4       Tasty Cupcakes

1.4.5       Buch »Game Storming«

1.5       Die »Prime Directive«

1.6       Zusammenfassung

2      Retrospektiven vorbereiten

2.1       Die Vorbereitung

2.1.1       Um welchen Zeitraum handelt es sich?

2.1.2       Wer soll an der Retrospektive teilnehmen?

2.1.3       Gibt es ein Thema?

2.2       Die richtige Zeit, der richtige Ort

2.3       Geeignetes Material

2.3.1       Die richtigen Stifte

2.3.2       Die richtigen Post-its

2.3.3       Das richtige Flipchartpapier

2.4       Essen

2.5       Die Agenda

2.6       Zusammenfassung

3      Die erste Retrospektive

3.1       Die Vorbereitung

3.2       Den Boden bereiten: Autovergleich

3.3       Daten sammeln: Mad, Sad, Glad, Afraid

3.4       Einsichten gewinnen: 5 Warums

3.5       Nächste Experimente definieren: Brainstorming

3.6       Abschluss: ROTI

4      Der Retrospektiven-Facilitator

4.1       Wie werde ich ein guter Facilitator?

4.2       Visual Facilitation

4.2.1       Das 1x1 der visuellen Gestaltung

4.2.2       Visuelle Retrospektiven

4.2.3       Inspirationsquellen für Visual Facilitation

4.3       Intern oder extern?

4.3.1       Tipps für interne Facilitatoren

4.3.2       Externe Facilitatoren

4.4       Nach der Retro ist vor der Retro

5      Von der Metapher zur Retrospektive

5.1       Die Orchesterretrospektive

5.1.1       Den Boden bereiten

5.1.2       Daten sammeln

5.1.3       Einsichten gewinnen

5.1.4       Experimente und Hypothesen definieren

5.1.5       Abschluss

5.2       Die Fußballretrospektive

5.2.1       Vorbereitung

5.2.2       Den Boden bereiten

5.2.3       Daten sammeln

5.2.4       Einsichten gewinnen

5.2.5       Nächste Experimente und Hypothesen definieren

5.2.6       Abschluss

5.3       Die Zugretrospektive

5.3.1       Den Boden bereiten

5.3.2       Daten sammeln

5.3.3       Einsichten gewinnen

5.3.4       Nächste Experimente und Hypothesen definieren

5.3.5       Abschluss

5.4       Die Küchenretrospektive

5.4.1       Den Boden bereiten

5.4.2       Daten sammeln

5.4.3       Einsichten gewinnen

5.4.4       Nächste Experimente und Hypothesen definieren

5.4.5       Abschluss

5.5       Die Piratenretrospektive

5.5.1       Den Boden bereiten

5.5.2       Daten sammeln

5.5.3       Einsichten gewinnen

5.5.4       Nächste Experimente und Hypothesen definieren

5.5.5       Abschluss

6      Systemische Retrospektiven

6.1       Systeme

6.1.1       Statische und dynamische Systeme

6.1.2       Kompliziert und komplex

6.2       Systemdenken

6.2.1       Causal-Loop-Diagramme

6.2.2       Current Reality Tree

6.2.3       Grenzen des systemischen Denkens

6.3       Komplexitätsdenken

6.3.1       Martie – das Management-3.0-Modell

6.3.2       Das ABIDE-Modell

7      Lösungsorientierte Retrospektiven

Veronika Kotrba MC und Dr. Ralph Miarka MSc

7.1       Retrospektiven? Wir schauen nach vorne!

7.2       Der lösungsorientierte Ansatz

7.3       Eine lösungsorientierte Retrospektive in fünf Schritten

7.3.1       Eröffnen

7.3.2       Ziel setzen

7.3.3       Sinn finden

7.3.4       Handlungen initiieren

7.3.5       Ergebnisse prüfen

7.3.6       Eine lösungsorientierte Kurzretrospektive

7.3.7       Zwischen den Retrospektiven

8      Verteilte Retrospektiven

8.1       Formen verteilter Retrospektiven

8.1.1       Mehrere verteilte Teams

8.1.2       Teams mit einzelnen verteilten Mitarbeitern

8.1.3       Verstreutes Team

8.2       Die richtigen Tools

8.2.1       Web Whiteboard

8.2.2       Stormz Hangout

8.2.3       Lino

8.3       Allgemeine Tipps für verteilte Retrospektiven

9      Alternative Vorgehensweisen

9.1       Arbeitsretrospektiven

9.1.1       Den Boden bereiten

9.1.2       Aufgaben sammeln

9.1.3       Arbeitsphase

9.1.4       Erfahrungen

9.2       Glückskeks-Retrospektive

9.3       Powerful Questions

10    Typische Probleme und Fallstricke

10.1     Schlechte Vorbereitung

10.2     Viel diskutiert, aber keine Ergebnisse

10.2.1     Gegensätzliche Meinungen

10.2.2     Entscheidungsschwäche

10.2.3     Keine klaren Zeitrahmen

10.3     Zu viele Ergebnisse

10.4     Desinteresse für (weitere) Verbesserungen

10.4.1     Verbesserungen werden nie umgesetzt

10.4.2     Verbesserungen haben keinen Effekt

10.4.3     Das Team bekam nicht genügend Zeit

10.5     Fokus auf Negatives

10.6     Fokus auf sachliche Themen

11    Change Management mit Retrospektiven

11.1     Agiles Change Management

11.2     Veränderungsprozesse initiieren

11.2.1     Den Boden bereiten

11.2.2     Daten sammeln

11.2.3     Einsichten gewinnen

11.2.4     Nächste Experimente und Hypothesen definieren

11.2.5     Abschluss

11.3     Veränderungsprozesse begleiten

11.3.1     Den Boden bereiten

11.3.2     Hypothesen überprüfen

11.3.3     Daten sammeln

11.3.4     Einsichten gewinnen

11.3.5     Nächste Experimente und Hypothesen definieren

11.3.6     Abschluss

11.4     Zusammenfassung

Quellenverzeichnis

Index

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 WerkzeugeFunktionierende Software mehr als umfassende DokumentationZusammenarbeit mit dem Kunden mehr als VertragsverhandlungReagieren 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 effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.

7.   Funktionierende Software ist das wichtigste Fortschrittsmaß.

8.   Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.

9.   Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.

10. Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.

11. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.

12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an.

Wie man sehen kann, zielen manche der Prinzipien direkt auf Softwareentwicklung ab. Die meisten Prinzipien lassen sich aber auch auf andere Bereiche problemlos anwenden. Die Agilität basiert auf der Grundidee, dass wir in einer komplexen und nicht vorhersehbaren Welt leben. Deshalb macht es auch wenig Sinn, einen detaillierten Projektplan über mehrere Monate oder gar Jahre zu erstellen. Wie die meisten Menschen wissen, die schon einmal einen Projektplan erstellt haben, hat dieser schon nach kurzer Zeit wenig mit der Realität zu tun. Agilisten kennen dieses Risiko und versuchen dieses mit kurzen Feedbackzyklen und enge Einbindung des Kunden zu minimieren.

Basierend auf dem Agilen Manifest wurden verschiedene Frameworks und Prozesse entwickelt. Dazu gehören u.a. Scrum, XP, DSDM und OpenUP, wobei Scrum das derzeit populärste Framework ist. Mittlerweile haben sich die Ideen aus der agilen Softwareentwicklung auch in andere Bereiche ausgebreitet. So gibt es u.a. das Buch »The Leader’s Guide to Radical Management« von Stephen Denning [Denning 2010], das die Ideen aus dem Agilen Manifest aufgreift und deren Anwendung auf den Managementbereich beschreibt.

1.2 Silvesterretrospektive

Vor ein paar Jahren haben wir eine neue Tradition bei uns zu Silvester eingeführt. Wir nennen sie die Silvesterretrospektive. Sie macht nicht nur einen Riesenspaß, sondern hilft auch die Zeit bis Mitternacht zu überbrücken, besonders mit Kindern. Bei uns läuft das Ganze folgendermaßen ab. Zu Beginn der Retrospektive sitzen wir alle zusammen vor dem Fernseher und sehen uns Bilder und manchmal auch ein paar kurze Videos des letzten Jahres an. Dazu habe ich vorab eine CD vorbereitet und die Fotos des Jahres vorselektiert. Diese Phase unserer Retro macht immer einen Heidenspaß und ist mit vielen Lachern verbunden.

Nachdem wir dann das Jahr nochmal Revue passieren ließen, schauen wir uns unsere Maßnahmen und Hypothesen des letzten Jahres an. Dies ist ein wichtiger Teil, denn nur so kann man feststellen, ob die Vorsätze des letzten Jahres den gewünschten Effekt hatten. Wenn dem nicht so ist, kann man sich überlegen, ob man sich das Thema nochmal vorknöpft und eine andere Maßnahme beschließt. Im Anschluss daran fangen wir an, die Dinge zu sammeln, die uns besonders im Gedächtnis geblieben sind. Dazu nutzen wir 3 Kategorien:

Was hat mir dieses Jahr Spaß gemacht?

Was fand ich dieses Jahr überhaupt nicht gut oder hat mich geärgert?

Danke

In die erste Kategorie fallen alle Dinge, die im vergangenen Jahr glücklich oder einfach nur Spaß gemacht haben, wie z.B. der gemeinsame Familienurlaub in einer kirgisischen Jurte. In die zweite Kategorie fallen alle negativen Ereignisse. Hier tauchen auch Dinge wie herumliegende Socken oder nervende Eltern auf. Die dritte Kategorie dient ganz einfach dazu, »Danke« zu sagen. Danke an die Frau oder Mama, danke an die Kinder oder Geschwister usw. immer verbunden mit einem konkreten Fall. Also z.B. »Danke, dass ich mit deinen Skylandern spielen durfte« oder »Danke, dass du mir jeden Morgen ein Pausenbrot richtest«. Anschließend erzählt jeder kurz ein paar Sätze zu seinem Beitrag.

Danach geht es darum, Erkenntnisse und Einsichten zu gewinnen. Jedes Familienmitglied darf sich ein Thema aussuchen, das es besonders wichtig findet. Nach und nach wird jedes Thema besprochen und nach den Grundursachen gesucht. Dafür hat sich bei uns im Augenblick die 5-Warum-Fragetechnik bewährt. Bei dieser Methode beginnt man mit der Frage »Warum ist X passiert oder passiert X ständig?«. Die Antwort dient als Futter für die nächste WarumFrage und so gräbt man immer tiefer, bis man hoffentlich die eigentliche Ursache gefunden hat. Diese Ursache schreiben wir auf einen Zettel, der uns als Basis für die nächste Phase dient. Diese Methode ist schon um die 100 Jahre alt und geht zurück auf Sakichi Toyoda [Wikipedia 02], den Gründer von Toyota. Er hat diese Methode entwickelt, um Problemen in der Produktion auf den Grund zu gehen, um zu verhindern, dass diese wieder auftreten.

Jetzt geht es um konkrete, messbare Vorsätze für das nächste Jahr, basierend auf unseren Ergebnissen der vorherigen Phase. Dazu machen wir pro Thema ein kurzes Brainstorming mit Ideen. Man glaubt gar nicht, auf was für geniale Ideen Kinder kommen können, auch für Themen, die Mama und Papa auf dem Herzen liegen. Wieder stellt jeder seine Ideen vor und danach wird pro Thema die erfolgversprechendste Idee gewählt. Dazu nehmen wir Klebepunkte, die auf die einzelnen Ideen geklebt werden. Diese Technik nennt man »Mehr-Punkt-Abfrage«. Jeder hat drei Klebepunkte, die er beliebig verteilen darf. Die gewählten Maßnahmen bekommen dann einen prominenten Platz: auf unserem Familienboard im Flur des Hauses, das eine visuelle To-do-Liste darstellt. Es gibt nichts Schlimmeres als Ergebnisse, die später nicht sichtbar sind. Unser Board hilft uns, diese Maßnahmen im Auge zu behalten und sicherzustellen, dass diese auch tatsächlich umgesetzt werden. Ganz wichtig bei den einzelnen Maßnahmen sind die damit verbundenen Hypothesen. Jede Maßnahme ist mit einer testbaren Hypothese verbunden, die wir in der nächsten Retrospektive überprüfen können.

Natürlich braucht eine Retrospektive auch einen würdigen Abschluss. Das ist in diesem Fall ganz einfach: das Silvesterfeuerwerk.

1.3 Das Retrospektiven-Phasenmodell

Wenn Sie im vorherigen Kapitel aufgepasst haben, wird Ihnen vielleicht aufgefallen sein, dass wir bei der Silvesterretrospektive durch 6 Phasen gegangen sind.

Abb. 1–1 Die 6 Phasen einer Retrospektive

Sie bilden die Struktur einer Retrospektive und basieren auf dem ursprünglichen Phasenmodell im Buch von Esther Derby und Diana Larsen [Derby & Larsen 2006], das ich hier erweitert habe. Der große Unterschied besteht darin, dass ich den Schritt »Hypothese überprüfen« eingeführt und den Schritt »Nächste Experimente definieren« um die Definition der Hypothesen erweitert habe. Die Gründe hierfür erläutere ich im weiteren Verlauf dieses Buches. Im Folgenden werde ich diese Phasen etwas genauer erklären.

1.3.1 1. Phase: Den Boden bereiten

Die erste Phase einer Retrospektive sollte den Boden für die Retrospektive bereiten. Diese Phase ist deshalb so wichtig, weil jeder Teilnehmer von einem anderen Ort geistig abgeholt werden muss. Ohne diese Phase besteht das Risiko, dass der ein oder andere Teilnehmer noch seine letzte Aufgabe im Kopf hat, die er gerade noch an seinem Arbeitsplatz bearbeitet hat, und noch nicht bereit wäre, sich auf die Retrospektive einzulassen. Sie dient dazu, alle Teilnehmer der Retrospektive abzuholen und auf die Retrospektive einzustimmen. Am besten startet man mit einem kurzen Willkommen und bedankt sich bei den Teilnehmern, dass sie sich Zeit für diesen Event genommen haben. Man erklärt kurz den Grund und das Ziel der Retrospektive sowie den vorgesehenen Zeitrahmen und die Agenda. Die Agenda ist wichtig, weil schließlich jeder wissen möchte, worin er seine Zeit investiert.

Praxistipp

Sorgen Sie dafür, dass jeder im Raum kurz etwas sagt. Wenn jemand in dieser Phase schweigt, ist die Gefahr groß, dass er es auch den Rest der Retrospektive machen wird. Es ist aber von sehr großer Bedeutung, dass jede Stimme gehört wird, denn nur dann erhält man ein Gesamtbild. Es geht gar nicht darum, dass man eine lange Story erzählt, es reichen schon ein paar Worte pro Person. Dies kann z.B. der eigene Name sein oder dass man in einem Wort die Erwartungen an die Retrospektive beschreibt. Interessanterweise funktioniert diese einfache Technik in den meisten Fällen so gut, dass sich auch die ruhigeren und schweigsamen Teammitglieder an den Diskussionen beteiligen.

Auch der letzte Schritt dieser Phase ist sehr wichtig. Hier geht es darum, eine Atmosphäre zu schaffen, in der auch schwierige Themen angesprochen werden können. Ebenso muss es möglich sein, unangenehme Dinge anzusprechen und zu diskutieren, die sonst eventuell unter den Tisch fallen. Nur in einer solchen Atmosphäre ist es möglich, den Dingen tatsächlich auf den Grund zu gehen und die wahren Probleme anzusprechen. Und dies ist schließlich die Basis für eine erfolgreiche Retrospektive.

Um diese Atmosphäre zu schaffen, gilt es jetzt die Regeln für die Zusammenarbeit festzulegen. Im Englischen spricht man hier von einem »Working Agreement«. Manche Teams haben bereits definierte Werte, die sie für ihre tägliche Arbeit festgelegt haben. Wenn dem so ist, sollten Sie diese Werte nutzen und das Team nochmals daran erinnern. Eventuell müssen ein paar Werte an die Retrospektive angepasst werden. Das Gleiche gilt natürlich, wenn das Team bereits Regeln für die Zusammenarbeit definiert hat. Viele agile Teams erstellen hierfür zu Beginn ihrer Zusammenarbeit eine Teamcharta.

Was ist eine Teamcharta?

Eine Teamcharta legt alle Regeln für die Zusammenarbeit in einem Team fest. Sie definiert die Kommunikationsregeln, Verhaltensregeln sowie Zeitpunkt und Länge der regelmäßig stattfindenden Besprechungen. In Softwareentwicklungsteams enthält sie zusätzlich eine Liste der eingesetzten Entwicklungstools und eventuell die Links zu weiterführenden Infos. Die Teamcharta ist u.a. ein guter Startpunkt für neue Teammitglieder. Sie sollte ein lebendes Dokument sein, das iterativ erweitert wird. Wenn das Team das Gefühl hat, sie müsste angepasst werden, dann sollte man das tun. Jede Anpassung sollte allerdings im Team abgesprochen und gemeinsam beschlossen werden.

Sollte es noch keinerlei Regeln für die Zusammenarbeit geben, ist jetzt der richtige Zeitpunkt, diese zu definieren. Aber warum sind diese Regeln so wichtig? Hier ein kurzes Beispiel:

Praxistipp

Sollte das Team noch keine Teamcharta haben, laden Sie gleich nach der Retrospektive zu einem dedizierten Workshop ein, um diese zu erarbeiten.

Nehmen wir an, Ihr Arbeitskollege Dieter hat die Angewohnheit, seinen Laptop in jede Besprechung mitzunehmen. Die Zeit in den Besprechungen nutzt er u.a., um seine E-Mails zu beantworten oder im Netz zu surfen. Startet man jetzt die Retrospektive ohne vorher festgelegte Regeln, wird er das vermutlich auch jetzt wieder machen. Es wird jeden stören, aber keiner hat eine Grundlage, um ihn darauf hinzuweisen und ihn zu bitten, den Laptop zu schließen. Hat man allerdings gemeinsam die Regeln im Vorhinein festgelegt, kann man ihn jederzeit darauf hinweisen. Ein weiterer Vorteil von Regeln zur Zusammenarbeit ist, dass sich alle in der Verantwortung sehen, diese einzuhalten und zu kontrollieren. Das macht es dem Facilitator der Retrospektive wieder ein bisschen einfacher, sich auf die eigentliche Arbeit zu konzentrieren.

Leider ist es genau diese Phase der Retrospektive, die am häufigsten übersprungen wird. Man will Zeit sparen und sofort loslegen. Aus meiner Erfahrung kann ich sagen, dass ich es noch nie bereut habe, das Team durch diese Phase zu begleiten. Wenn das Team schon länger zusammenarbeitet, dauert es häufig nicht länger als fünf Minuten. Das sind fünf Minuten, die das Risiko minimieren, dass jemand nicht zu Wort kommt. Fünf Minuten, die dafür sorgen, dass alle das Gefühl haben, in einer sicheren Umgebung diskutieren und arbeiten zu können. Fünf Minuten, um alle abzuholen und den Kopf frei zu machen für dieses wichtige Meeting. Manchmal können es auch fünf Minuten Spaß sein. Sie können z.B. fragen, mit welchem Auto Ihre Teammitglieder den Zeitraum vor der Retrospektive vergleichen würden. Nur ein bis zwei Wörter und alle sind dabei.

Check-in

Die hier beschriebene Technik nennt sich Check-in und wird im Buch von Derby und Larsen [Derby & Larsen 2006, S.42] beschrieben. Sie wird eingesetzt, nachdem man die Teilnehmer begrüßt hat und das Ziel der Retrospektive vorgestellt hat. Der Facilitator stellt eine kurze Frage, die jeder Teilnehmer der Reihe nach, möglichst kurz beantwortet. Hier ein paar Beispiele für eine solche Frage:

In ein oder zwei Worten, was erhoffst du dir von dieser Retrospektive?Wenn du die letzte Iteration mit einem Auto vergleichen müsstest, was für ein Auto wäre es?Mit welcher Großwetterlage (Sonnig, Bewölkt, Regnerisch, Gewitter) würdest du deinen jetzigen Gemütszustand beschreiben?

Es ist o.k., wenn ein Teilnehmer »Ich passe« sagt. Schon dieser Satz reicht, damit seine Stimme gehört wurde.

Zur Erinnerung: Bei der Silvesterretrospektive bereite ich den Boden, indem wir uns die Bilder und Videos des vergangenen Jahres ansehen. Und glauben Sie mir, das macht eine Menge Spaß!

1.3.2 2. Phase: Hypothesen überprüfen

Die Idee dieser Phase ist es, die eigenen Hypothesen der letzten Retrospektive zu überprüfen. Diese Hypothesen werden idealerweise zusammen mit den beschlossenen Experimenten der vorherigen Retrospektive definiert (siehe Abschnitt 1.3.5). Warum aber ist dieser Schritt so wichtig?

Nehmen wir einmal an, dass Sie in der letzten Retrospektive das Problem diskutiert haben, dass die Kommunikation mit Ihrem Produktmanagement sehr schlecht ist. Fragen werden nur mit großen Verzögerungen beantwortet und das Produktmanagement ist nur schwer erreichbar. Am Ende der Retrospektive haben Sie dann beschlossen, dass der Produktmanager dem Team jeden Tag eine dedizierte Stunde zur Verfügung steht. In dieser Stunde sollen die offenen Fragen diskutiert und beantwortet und die Verzögerungen auf ein Minimum reduziert werden. Die Hypothese, die Sie mit dieser Maßnahme verbinden, ist vielleicht die folgende: »Offene Fragen werden nun in weniger als 24 Stunden beantwortet.« Das wäre schon eine ordentliche Verbesserung zum gegenwärtigen Prozess, bei dem das Team teilweise mehrere Wochen auf eine Antwort gewartet hat. Ein paar Wochen vergehen und die nächste Retrospektive steht an. Nachdem der Boden bereitet wurde, geht das Team daran, die Hypothesen zu überprüfen. Es stellt sich heraus, dass die Hypothese falsch war. Es scheint zwar, dass das Beantworten etwas besser geworden ist, aber von den 24 Stunden ist man noch weit entfernt. Das Problem ist also noch nicht aus der Welt geschafft. Somit wird das Team im weiteren Verlauf der Retrospektive versuchen, die Ursachen dafür zu erarbeiten und entweder die Maßnahme anzupassen oder neue Maßnahmen zu definieren. Dabei könnte sich z.B. herausstellen, dass der Produktmanager nicht einbezogen wurde und einfach vor vollendete Tatsachen gestellt wurde. Dies hat ihn eher verärgert als zu einer besseren Zusammenarbeit mit dem Team motiviert. Mithilfe von Hypothesen wird das Team in die Lage versetzt, so lange an einem Thema zu arbeiten, bis das Problem entweder gelöst oder auf ein erträgliches Maß reduziert wurde.

Praxistipp

Nutzen Sie die nächsten Phasen der Retrospektive gezielt dafür, danach zu forschen, warum eine oder mehrere Hypothesen nicht so eingetreten sind wie erwartet.