Antipatterns in Retrospektiven E-Book

Aino Vonge Corry

• Herausgeber: dpunkt.verlag
• Kategorie: Fachliteratur
• Sprache: Deutsch
• Veröffentlichungsjahr: 2022

Seitenzahl: 308

Beschreibung

Verbessern Sie mit Retrospektiven die agilen Prozesse und die Zusammenarbeit in Teams!

• Eine Auswahl von hilfreichen Tipps, Erfahrungen und Anleitungen für die Moderation
• Effektive Lösungen für festgefahrene Routinen im Arbeitsalltag
• Für lebenslanges Lernen und die kontinuierliche Zusammenarbeit von Teams

Bei Retrospektiven geht es darum, Teams durch die Reflexion im Rahmen eines strukturierten Meetings dabei zu unterstützen, leistungsfähiger zu werden. Retrospektiven sind für kontinuierliches Lernen und Verbesserung – gerade in Lean-, Agile- und DevOps-Kontexten – unverzichtbar. 24 Antipatterns (Antimuster) helfen dabei, die eigene Moderation zu reflektieren und neue Lösungsansätze anzuwenden.
Aino Vonge Corry zeigt auf, wie festgefahrene Retrospektiven wieder in produktive Arbeitsrituale umgewandelt werden können, und geht dabei auf fehlerhafte Planung sowie strukturelle und zwischenmenschliche Probleme in den Retrospektiven ein. Sie berichtet von Fallen, in die sie getappt ist, und Fehlern, die sie in ihrer jahrelangen Erfahrung als Moderatorin von Retrospektiven gemacht hat, und stellt anschließend bewährte Lösungen vor, die für das Team und die Menschen in unterschiedlichen Kontexten bereits funktioniert haben.
Mit diesen Erkenntnissen und Anleitungen können Sie Retrospektiven durchführen, die konkrete Verbesserungen und echten Mehrwert bringen – die effektiv sind und auch Spaß machen!

Leseprobe

Copyright und Urheberrechte:

Die durch die dpunkt.verlag GmbH vertriebenen digitalen Inhalte sind urheberrechtlich geschützt. Der Nutzer verpflichtet sich, die Urheberrechte anzuerkennen und einzuhalten. Es werden keine Urheber-, Nutzungs- und sonstigen Schutzrechte an den Inhalten auf den Nutzer übertragen. Der Nutzer ist nur berechtigt, den abgerufenen Inhalt zu eigenen Zwecken zu nutzen. Er ist nicht berechtigt, den Inhalt im Internet, in Intranets, in Extranets oder sonst wie Dritten zur Verwertung zur Verfügung zu stellen. Eine öffentliche Wiedergabe oder sonstige Weiterveröffentlichung und eine gewerbliche Vervielfältigung der Inhalte wird ausdrücklich ausgeschlossen. Der Nutzer darf Urheberrechtsvermerke, Markenzeichen und andere Rechtsvorbehalte im abgerufenen Inhalt nicht entfernen.

Aino Vonge Corry

Antipatterns in Retrospektiven

Aus Erfahrung lernen

Mit einem Geleitwort von Diana Larsen

Aus dem Englischen von Daniela Schubert

Aino Vonge Corry

[email protected]

Lektorat: Christa Preisendanz

Lektoratsassistenz: Julia Griebel

Übersetzung: Daniela Schubert

Copy-Editing: Ursula Zimpfer, Herrenberg

Satz: inpunkt[w]o, Haiger (www.inpunktwo.de)

Herstellung: Stefanie Weidner, Frank Heidt

Illustrationen: Nikola Korać; mit freundlicher Genehmigung von Aino Corry

Umschlaggestaltung: Helmut Kraus, www.exclam.de unter Verwendung einer Illustration von Nikola Korać; mit freundlicher Genehmigung von Aino Corry

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:

Print

978-3-86490-912-2

PDF

978-3-96910-918-2

ePub

978-3-96910-919-9

mobi

978-3-96910-920-5

1. Auflage 2023

Translation Copyright für die deutschsprachige Ausgabe © 2023 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Authorized translation from the English language edition, entitled RETROSPECTIVES ANTIPATTERNS

1st Edition by Aino Vonge Corry, published by Pearson Education, Inc, publishing as Addison Wesley

© @2021 Pearson Education, Inc.

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc.

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 Autorin noch Verlag noch Übersetzer*in 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

Dieses Buch ist meiner besten Freundin Ellen Agerbo gewidmet, die aufgrund ihrer Erfahrungen mit mir aus der Zeit, als wir am Abschluss unseres Informatikstudiums, unserer gemeinsamen Masterarbeit und einem Teil des Doktorandenprogramms arbeiteten, nie geglaubt hätte, dass ich in der Lage sein würde, ein Buch zu schreiben. Um sie zu zitieren: »Du hattest schon immer hervorragende Ideen, aber das Schreiben war noch nie deine Stärke.«

Geleitwort

In diesem Buch beschreibt Aino den Beginn unserer gemeinsamen Geschichte, die noch viel mehr zu bieten hat. Es ist die Geschichte, wie sich unsere Beziehung in den folgenden Jahre fortgesetzt und vertieft hat und gereift ist. Im Laufe der Zeit ist Aino mehr für mich geworden als eine Person, die ich damals als Mentorin begleitet habe. Für mich ist sie heute eine hochgeschätzte Kollegin und Freundin.

Aino weiß, dass ich bei der Moderation von Retrospektiven manchmal übervorsichtig sein kann. Als Autorin und frühe Befürworterin des lebenslangen Lernens und der Verbesserung von Teams möchte ich, dass Teambesprechungen diese wertvollen Ergebnisse jedes Mal liefern. Ich ermutige Teamverantwortliche dazu, sich Zeit für Retrospektiven zu nehmen. Ich möchte, dass Teams (und ihre Organisationen) einen immer größeren Nutzen aus ihren Retrospektiven ziehen.

Leider höre ich oft von Retrospektiven, die nur oberflächlich dem Namen nach durchgeführt werden oder die hauptsächlich dazu dienen, den Haken hinter das To-do »Retrospektive« zu setzen, oder von Retrospektiven, die darauf beschränkt werden, die Antworten auf zwei oder drei Fragen aufzulisten, was nur zu wenigen oder gar keinen umsetzbaren Plänen führt. Die Menschen, die mir davon berichten, empfinden diese Treffen hauptsächlich als Zeitverschwendung und ich kann es ihnen nicht verdenken. Natürlich nehmen sie das so wahr. Diese Treffen kosten Zeit, ohne dem Team den versprochenen Nutzen zu bringen. In meiner überfürsorglichen Art möchte ich darauf hinweisen, dass das keine Meetings sind, die meiner Vorstellung von Retrospektiven entsprechen.

Als Konsequenz stehe ich im regelmäßigen Austausch mit Kolleg*innen, die über die Durchführung effektiver Retrospektiven berichten. Es hilft mir zu wissen, dass ich nicht alleine bin mit meinen Vorstellungen. Und wann immer ich Aino Corry heutzutage auf einer Konferenz oder einem anderen Event zu dem Thema »Retrospektiven« referieren höre, bin ich nicht nur begeistert, sondern weiß auch, dass ich beruhigt sein kann. Ihre Zuhörerschaft (und auch die Teams, mit denen sie enger zusammenarbeitet) erhält von Aino wertvolle Informationen über den Weg zu einer dauerhaften Teamverbesserung. Ich empfehle ihre Trainings gerne jeder Person weiter, die danach fragt.

Und deshalb empfehle ich auch so gerne dieses Buch. In diesem hat Aino eine solide, kuratierte Liste von Antipatterns1 zusammengestellt und erklärt, wie man sie vermeiden kann. (Die erfahrenen Agile Coaches werden sie kennen. Ich bin mit den meisten von ihnen auch bestens vertraut.) Sie vermittelt darüber hinaus so viel mehr als nur Tipps und Techniken. Wenn Sie dieses Buch aufmerksam lesen, werden Sie eine Schatztruhe finden – mit wertvollen Anregungen, einschließlich ihrer persönlichen Erfahrungen, effektiven Moderationsressourcen und Hinweisen, wie Sie sich selbst und Ihr Team befreien können, wenn Sie in einem Antipattern feststecken.

Nehmen Sie dieses Buch in die Hand. Schauen Sie sich die Antipatterns genau an. Identifizieren Sie diejenigen, die bei Ihnen am häufigsten auftauchen. Planen Sie für Ihre nächste Retrospektive, Lösungen von Aino einzubeziehen und Retrospektiven konsequent zu verbessern. Sie werden es nicht bereuen.

Ich wünsche Ihnen alles Gute für Ihre zukünftigen Retrospektiven,

Diana Larsen,Co-Autorin von Agile Retrospectives: Making Good Teams Great2 sowie Co-Gründerin und CCO des »Agile Fluency Project LLC«

Vorwort

Dieses Buch ist für Sie

Ich wollte dieses Buch schon seit längerer Zeit für Sie schreiben. Eigentlich habe ich so lange daran gearbeitet, dass es zu einem Running Gag innerhalb der Familie und meinen Bekannten wurde.

Ich stelle mir vor, wie Sie abends auf dem Sofa sitzen, frustriert über all die Dinge, die Sie in der Retrospektiven-Moderation erlebt haben, und nicht alleine sein wollen mit diesen schmerzhaften Erfahrungen. Wenn das der Fall ist, dann ist dieses Buch genau das Richtige für Sie. Ich werde Ihnen von all meinen Fehlern erzählen, die sich in einem Ausmaß wiederholten, sodass es mir möglich war, Muster zu erkennen und nun darüber zu schreiben.

Lassen Sie sich nicht davon abschrecken, dass ich sie als Antipatterns beschreibe: Zu jedem Muster gibt es auch eine Lösung, die Teil der Beschreibung des Antipatterns ist. Bei den meisten Lösungen geht es darum, die Dinge beim nächsten Mal anders zu planen; ich kann Ihnen zum Beispiel Ideen an die Hand geben, wie Sie daran denken können, den Grund für eine Aktivität zu erklären. Aber es gibt auch einige Lösungen für den Einsatz in Echtzeit, die spontan als Reaktion auf Ereignisse während der Retrospektive angewendet werden können – zum Beispiel Ideen, wie man Menschen zum Reden ermutigen kann, wenn sie schweigen.

Bei der Lektüre dieses Buches werden Sie vielleicht feststellen, dass die meisten der von mir beschriebenen Antipatterns im Rahmen einer Retrospektive auch bei anderen Arten von Meetings im realen Leben zu finden sind. Ich würde behaupten, dass die in den Antipatterns beschriebenen Lösungen für jede Art von Meeting, das Sie leiten, gelten. Denn Sie haben doch eine Moderation für alle Ihre Meetings, oder? Jutta Eckstein stellt in ihrem Buch Retrospectives for Organizational Change[Eckstein 2019] ebenfalls die Behauptung auf, dass die Struktur einer Retrospektive in mehr Bereichen als dem zyklischen Team-Check-in, das in meinem Kontext beschrieben wird, verwendet werden kann. Sie beschreibt, wie Retrospektiven Ihnen auch dabei helfen können, eine organisatorische Veränderung in einem viel größeren Rahmen als dem Scrum-Team umzusetzen, mit dem wir das Konzept der Retrospektive oft in Verbindung bringen.

Wenn Sie noch neu als Moderator*in1 arbeiten, ist es eine gute Idee, mein Buch zu lesen, denn dann wissen Sie, auf welche Herausforderungen Sie stoßen können. Andererseits, wem wollen wir etwas vormachen? Wir lernen fast nie etwas, bevor wir es brauchen, also werden Sie auch selbst Fehler machen müssen, bevor Sie dieses Buch zu schätzen wissen. Wenn Sie es jetzt lesen, müssen Sie vielleicht nur schmunzeln und fragen sich: »Hat sie das wirklich getan?« oder: »Wie um alles in der Welt kam sie auf die Idee, so etwas zu sagen?«. Auch Lachen ist wichtig und vermutlich kann auch das wertvoll sein für Ihr zukünftiges Lernen.

Wie dieses Buch entstand

Zu Beginn dieses Jahrtausends war ich Mitorganisatorin und Programmleiterin der JAOO-Konferenz (jetzt GOTO) in Aarhus, Dänemark, zu der Linda Rising als Referentin eingeladen war. Linda Rising ist unter anderem Co-Autorin von Fearless Change: Patterns for Introducing New Ideas[Rising & Manns 2005] – zusammen mit Mary Lynn Manns – und sie erzählte mir von Norm Kerths bahnbrechendem Buch Project Retrospectives: A Handbook for Team Reviews[Kerth 2001]. Ich höre mir immer gerne Vorträge von Linda Rising an, aber dieser war etwas Besonderes. Die Idee der Retrospektiven faszinierte mich, und ich konnte mir vorstellen, dass sie für viele Teams in den Organisationen unserer Kundschaft sowie für Teams in unserem eigenen Unternehmen sehr nützlich sein könnten. Die Lektüre des Buches nach der Konferenz hat mich nicht entmutigt, und so begann ich seit dem Jahr 2007 selbst einige Retrospektiven zu moderieren.

Die nächste Station auf meiner Reise war eine Teilnahme an einem Workshop von Diana Larsen über die Moderation von Retrospektiven. Dieser hat mir einmal mehr die Möglichkeiten, aber auch Herausforderungen eben jener Retrospektiven aufgezeigt. Ich hatte das Glück, Diana bei späteren Kursen in Dänemark zu assistieren, und in der lehrenden Rolle lernt man noch mehr als in der lernenden. Seitdem fasziniert mich der Gedanke, Menschen und Teams beim Reflektieren und Lernen zu unterstützen. Ich begann, mehr Retrospektiven zu moderieren, zunächst für meine Kolleg*innen in der IT-Branche und später in anderen Unternehmen und Umfeldern. In den letzten 10 Jahren habe ich Hunderte von Retrospektiven in Dutzenden von Unternehmen moderiert und Vorträge über Retrospektiven auf Konferenzen, Geek Nights und offen gesagt, überall dort gehalten, wo die Menschen keine Chance hatten, mir und meinen Vorträgen zu entkommen.

Ich habe viele Bücher und Artikel gelesen und mir zahlreiche Präsentationen angesehen, sowohl online als auch auf Präsenzveranstaltungen. Ich lernte natürlich eine Menge dazu, aber ich verstand bald, dass es bei einer guten Moderation von Retrospektiven nicht nur darum geht, die richtigen Aktivitäten zu kennen – es gehört viel mehr dazu. Ich verbrachte einige Zeit damit, etwas über Körpersprache zu lernen, und The Definitive Book of Body Language[Pease & Pease 2004]2 vermittelte mir viele Erkenntnisse zur Bedeutung von Augenkontakt, Händedruck und die unterschiedlichen Auswirkungen auf andere Personen. Ich habe mich von zahlreichen Büchern inspirieren lassen, die nicht direkt auf die Moderation von Retrospektiven ausgerichtet sind (siehe »Literatur« im Anhang des Buches).

Angeregt durch den Hinweis meines Mannes, dass ich mir Dinge nicht gut merken kann, machte ich mir im Laufe der Jahre Notizen über das, was ich sah und hörte, während ich Retrospektiven anleitete. In einem kleinen schwarzen Notizbuch notierte ich die Techniken, die ich ausprobierte, was funktionierte und was nicht, um den Teams dabei zu helfen, Fortschritte zu machen und nicht in einem Trott stecken zu bleiben. Wenn ich improvisierte, um eine Diskussion, die sich im Kreis drehte, umzulenken, schrieb ich ein paar Sätze dazu auf. Wenn eine Gruppe von Entwickler*innen einen Anstoß in die richtige Richtung brauchte, um ihre Besprechungen konstruktiv und nützlich zu halten, benutzte ich das kleine schwarze Notizbuch, um mich daran zu erinnern, was ich bereits ausprobiert hatte und ob es funktionierte. Wenn ich ein albernes Spiel oder eine Übung erfunden oder mir abgeschaut hatte, die die Teilnehmenden in Bewegung brachte, wenn sie vom vielen Sitzen und Reden müde waren, notierte ich es. Die Retrospektiven in diesen Notizbüchern summieren sich bis heute auf 296, die ich für 68 verschiedene Teams in 27 verschiedenen Unternehmen moderiert habe, und ich weiß, dass ich noch eine Menge mehr Retrospektiven leitete, bevor ich anfing, mir Notizen zu machen.

Als ich mit meinen Aufzeichnungen begann, erwies sich das Notizbuch nicht nur als hilfreich, um mich später daran zu erinnern, was von den Dingen, die ich gemacht hatte, funktionierte und nicht funktionierte, sondern auch, um Experimente weiterzuverfolgen, die ein Team in früheren Retrospektiven beschlossen hatte. Ich schrieb auch die Pläne A und B für jede Retrospektive auf, damit ich alle meine Pläne an einem Ort hatte und mich von meiner früheren Arbeit inspirieren lassen konnte. Manche Leute verlassen sich vielleicht auf ihr Gedächtnis, wenn es um vergangene Erfolge und Fehler geht, aber das ist für mich keine Option. Als ich anfing, Online-Retrospektiven zu moderieren, verwendete ich Online-Tools und vergaß anfangs, das Notizbuch zu benutzen. Nach einigen weniger erfolgreichen Online-Retrospektiven lernte ich, dass das Notizbuch hierbei ebenso nützlich ist, weil es mir einen schnellen Überblick verschafft und mir hilft, mich zu erinnern.

Dieses Buch, das ich im Oktober 2013 zu schreiben begann, ist die Zusammenfassung meines kleinen schwarzen Notizbuches – oder besser gesagt, aller Notizen. Es ist das Ergebnis der schlecht gelaufenen Dinge, denn es ist ein Buch der Antipatterns. Das sind die Fallen, in die Menschen getappt sind, die Fehler, die ich gemacht habe, und meine besten Tipps, um den Fallen zu entkommen und die Fehler zu vermeiden. Dabei gleicht die Durchführung einer Retrospektive niemals einer anderen; und wenn doch, dann ist das in sich bereits ein Antipattern. Ich möchte nie aufhören zu lernen, wie man Meetings sinnvoller gestalten kann und wie man Teams dazu bringt, besser zusammenzuarbeiten. Es macht mir weiterhin große Freude, skeptischen Softwareentwicklerteams, die einfach nur in Ruhe gelassen werden wollen, um Code zu programmieren, zu zeigen, was sie davon haben, wenn sie einen kleinen Teil ihrer Arbeitswoche mit ihren Kolleg*innen kommunizieren.

Obwohl der Lernprozess nie endet und ich immer noch lerne, möchte ich das, was ich bis jetzt gelernt habe, mit einem größeren Kreis teilen. In Büchern und im Internet findet sich viel großartiges Material darüber, wie man eine gute Retrospektive durchführen kann, aber im Laufe der Jahre habe ich gesehen, dass viele Menschen immer wieder mit den gleichen Problemen zu kämpfen haben. Deshalb habe ich beschlossen, dieses Buch als eine Sammlung von Antipatterns zu erstellen. Retrospektiven sind nicht einfach zu gestalten und können leicht ruiniert oder zumindest weniger effizient abgehalten werden, und ich denke, die Zeit ist reif für ein Buch über Antipatterns. Aber lassen Sie sich nicht von der Negativität von Antipatterns abschrecken. Jedes Antipattern enthält eine Überarbeitung, die für mich und die Teams, die ich unterstützt habe, funktioniert hat.

Und wenn Sie die Abschnitte Refactoring-Lösung in diesem Buch lesen, denken Sie daran, Ihren eigenen Kontext zu berücksichtigen, bevor Sie meinen Vorschlag anwenden. Wie Diana Larsen immer zu sagen pflegte, wenn ich sie fragte, was ich in einer Retrospektive tun sollte: »Es kommt darauf an«, womit sie meinte, dass es immer auf den Kontext ankommt.

Vorwissen

Ich gehe davon aus, dass Sie, da Sie dieses Buch lesen, mit Retrospektiven und der Rolle der Moderation an sich vertraut sind. Wenn Sie eine Auffrischung benötigen, können Sie etwas Zeit damit verbringen, im Internet über Retrospektiven zu lesen und natürlich das Buch Agile Retrospectives: Making Good Teams Great[Larsen & Derby 2006]3.

Ich habe viele Infokästen in das Buch eingefügt, um Konzepte zu erklären, die Sie vielleicht nicht kennen oder vergessen haben. Sie können sie gerne überspringen, wenn Sie bereits wissen, worum es bei den verschiedenen Modellen geht.

Was ist eine Retrospektive?

Eine Retrospektive ist eine Gelegenheit für ein Team, im Rahmen eines strukturierten Meetings über die Vergangenheit nachzudenken und daraus zu lernen. Das Hauptziel besteht darin, die Situation zu analysieren und mit der Realität abzugleichen. Überprüfen und Anpassen (Inspect & Adapt) ist der Kern eines jeden agilen Prozesses und wurde erstmals mit dem japanischen Wort Kaizen in The Machine That Changed the World[Womack et al. 1990] bekannt gemacht. Um eine echte Reflexion zu erhalten und in der Lage zu sein, sich an eine Situation zu erinnern, müssen wir eine vertrauensvolle Atmosphäre schaffen, in der die Menschen ihre Erfahrungen teilen können. Die Person, die moderiert, sorgt dafür, dass jede Stimme in irgendeiner Weise gehört wird und dass das Team gemeinsam entscheidet, worüber es diskutieren oder eine Ursachenanalyse durchführen will. Das Ergebnis einer Retrospektive sind oft einige Experimente, die das Team machen kann, um seine Arbeitsweise zu verbessern. Oder wie Diana Larsen und Esther Derby es ausdrücken: Bei Retrospektiven geht es darum, »gute Teams großartig zu machen« [Larsen & Derby 2006]. Eine Retrospektive ist auch eine Gelegenheit, sich mit Ihrem Team darüber auszutauschen, wie Sie die verschiedenen Ereignisse seit der letzten Retrospektive erlebt haben, und ein klares Verständnis füreinander zu entwickeln. Wie mein verstorbener Vater schon zu sagen pflegte: »Alles zu verstehen, bedeutet, alles zu verzeihen.«

Die fünf Phasen einer Retrospektive

Unter den verschiedenen Definitionen von Retrospektiven beschreibt Agile Retrospectives: Making Good Teams Great[Larsen & Derby 2006] den Ablauf einer Retrospektive in fünf Phasen:

Den Rahmen schaffen (

Set the stage): Die moderierende Person schafft eine vertrauensvolle Atmosphäre, stellt sicher, dass alle zu Wort kommen, schaut sich frühere Experimente an, definiert das Thema für die Retrospektive und erledigt alle anderen Aufgaben, die für den Beginn der Retrospektive notwendig sind.

Daten sammeln (

Gather Data): Das Team sammelt Informationen und Daten (über Erfahrungen, Ereignisse, Tests, Verkäufe usw.) für den Zeitraum, auf den sich die Retrospektive konzentriert.

Erkenntnisse gewinnen (

Generate Insights): Das Team blickt auf die gesammelten Informationen, um die Ursachen und Hintergründe herauszufinden. Diese Phase kann in Form einer freien Diskussion oder einer Ursachenanalyse durchgeführt werden.

Entscheiden, was zu tun ist (

Decide what to do): Das Team entscheidet gemeinsam, welche Experimente ausprobiert und durchgeführt werden sollen, um die Zusammenarbeit zu verbessern.

Die Retrospektive abschließen (

Close the Retrospective): Das Team entscheidet, wer für die Weiterverfolgung der nächsten Schritte verantwortlich ist. Die moderierende Person fasst zusammen, was passiert ist, und gibt vielleicht eine Bewertung der Retrospektive ab, wenn dies für sinnvoll gehalten wird – eine Retrospektive über die Retrospektive.

Oft höre ich Menschen behaupten, dass es bei kurzen Sprint-Retrospektiven keinen Sinn macht, alle fünf Phasen zu durchlaufen. Aber genau diese Denkweise führt zu einer voreiligen Entscheidungsfindung, wie später in Kapitel 1 »Das Glücksrad« ausführlich beschrieben wird.

Was ist ein Pattern?

Ein Pattern, oder auch Muster, ist eine abstrakte Lösung für ein häufig wiederkehrendes Problem. Muster sind ein Mittel, um Erfahrungen in eine Art schematische und lesbare Form zu bringen. Die Namen der Muster bilden ein gemeinsames Vokabular für das Design, die Programmierung oder den jeweiligen Bereich, für den die Muster Lösungen beschreiben. Ein Muster kann eine Möglichkeit sein, zu beschreiben, wie Dinge in einer Organisation gemacht werden. Ein Muster enthält immer eine Beschreibung des Kontexts und der Einflüsse, die das zu lösende Problem definieren, ein Muster als Lösung sowie die Vorteile und Konsequenzen der Anwendung des Musters. Häufig verweist ein Muster auch auf andere Muster, weil die Folgen mit einer ähnlichen Lösung aus einem anderen Muster behoben werden könnten.

Abb. 1Bestandteile eines Patterns

Das Konzept der Muster wurde von dem Architekten Christopher Alexander und seinen Co-Autoren entwickelt und ist in A Pattern Language: Towns, Buildings, Construction[Alexander et al. 1977] nachzulesen. Etwas mehr als ein Jahrzehnt später wurden Muster von Kent Beck in einem Artikel im Smalltalk Report A Short Introduction to Pattern Language[Beck 1999]4 für die Verwendung in der Software eingeführt – mit dem Schwerpunkt auf Kommunikation. Zwei Jahre später wurde das Konzept durch das Buch: Design Patterns: Elements of Reusable Object-Oriented Software[Gamma et al. 1995]5 populär gemacht, das heute »GoF-Buch« genannt wird, weil die Autoren gemeinsam als »Gang of Four« bekannt wurden.

Bei der Arbeit mit Mustern wie »Observer«, »Composite« und »Strategy« [Gamma et al. 1995] ist es nützlich, sich auf die Namen von Mustern zu beziehen, anstatt ein Design oder Konzept von Grund auf erklären zu müssen. Die Wirksamkeit von Mustern beruht auf der Art und Weise, wie das Gehirn mit Mustererkennung und Routinen arbeitet. Wenn wir etwas lernen, werden die Details dieses neuen Wissens in Ihrem Langzeitgedächtnis als »Schablone« abgespeichert. Zusammen mit der Mustererkennung, die uns hilft, die Situation als eine Situation zu erkennen, in der wir gelernt haben, wie wir uns verhalten sollen, werden auch die Routinen, d.h. die Art und Weise, wie wir auf das Muster reagieren sollen, im Gehirn eingeprägt. Mein ehemaliger Vorgesetzter Michael Caspersen, der mir fast alles beigebracht hat, was ich über das Lernen weiß, hat in seiner Dissertation [Caspersen 2007] viele Beispiele und Verweise auf Mustererkennungen und Routinen des Gehirns aufgeführt.

In meiner Dissertation [Cornils 2001]6 ging es um Softwaremuster, und mir ist aufgefallen, dass ich immer Muster in allem sehe – was bei Menschen nicht ungewöhnlich ist.

Was ist ein Antipattern?

Ein Antipattern ist eine spezifische Art, Erfahrungen zu beschreiben. Das Antipattern als Konzept wurde erstmals von William J. Brown und seinen Co-Autoren in dem Buch AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis[Brown et al. 1998] benannt und beschrieben. Es handelt sich dabei um die Beschreibung einer Lösung für ein häufig auftretendes Problem, bei dem die Folgen den Nutzen überwiegen.

Die Antipatterns in diesem Buch sind das Ergebnis einer moderierenden Person, die es nicht besser wusste oder nicht die Zeit oder Gelegenheit hatte, das Richtige zu tun. Vielleicht hat die Lösung einmal für die Moderation in einer anderen Gruppe funktioniert, weil die Gruppenmitglieder eine andere Art der Kommunikation hatten oder sich besser kannten, aber dann hat sie in einem neuen Kontext unerwartet nicht funktioniert.

Zur Einführung in die Thematik möchte ich Ihnen zwei Beispiele für Antipatterns geben. Das erste ist ein altes Muster, das zu einer berühmten Katastrophe führte. Am späten Abend des 14. April 1912 rammte die RMS Titanic einen Eisberg und sank in den frühen Morgenstunden des 15. April, wobei mehr als 1.500 der 2.224 Menschen an Bord – Passagiere und Besatzung – ums Leben kamen. Um zu verstehen, warum das Schiff gesunken ist, muss man eine Reihe von kleinen Dingen betrachten, die in ihrer Gesamtheit zu einer Katastrophe führten. Das, auf was ich mich konzentrieren möchte, ist das Antipattern, das man als »Befolgen von Befehlen eines uninformierten Vorgesetzten« (»following orders from an uninformed superior«) bezeichnen könnte. Auf Wikipedia7 findet sich dazu auch folgende Erklärung: »Vorgesetzte Befehle, auch bekannt als die Nürnberger Verteidigung oder das Befolgen von Befehlen, ist ein Plädoyer vor Gericht, dass eine Person – sei es ein Mitglied des Militärs, der Strafverfolgungsbehörden, der Feuerwehr oder der Zivilbevölkerung – nicht für schuldig befunden werden sollte, Handlungen zu begehen, die von einem vorgesetzten Offizier oder Beamten angeordnet wurden.« Dieses Antipattern wurde an zahlreichen Orten und zu verschiedenen Zeiten festgestellt, und zufälligerweise auch mitten in der Geschichte der Titanic.

Die beiden Funker auf der Titanic arbeiteten für die Marconi Wireless Telegraph Company. Ihr Auftrag war es, Nachrichten der Reisenden von und zu Bekannten und Verwandten an Land weiterzuleiten, um den von der Marconi Company angebotenen drahtlosen Kommunikationsdienst zu demonstrieren. Das Ausschlaggebende für die Funker dabei war, dass sie für jede weitergeleitete Nachricht von oder an Passagiere eine zusätzliche Vergütung der Marconi Company erhielten. Somit wurde ihr Einkommen durch die Bevorzugung von Nachrichten von und an Passagiere erhöht. Deshalb priorisierten sie diese Tätigkeit höher als die Schiff-zu-Schiff-Meldungen. Fast von Beginn der Reise an hatten sie Warnungen über Eisberge erhalten und die meisten dieser Nachrichten an die Brücke weitergeleitet. Leider gingen einige der an die Titanic gesendeten Nachrichten verloren, weil sich die Funker darauf konzentrierten, die Befehle ihrer Firma zu befolgen. Ihr Vorgesetzter war der Eigentümer der Funkgesellschaft, nicht der Kapitän.

Dies erklärt, warum die Mesaba, ein Schiff, das in denselben Gewässern wie die Titanic fuhr, um 21.40 Uhr eine Warnung vor einem Eisberg sendete, die die Brücke aber nie erreichte. Um 22.55 Uhr meldete ein anderes, in der Nähe befindliches Kreuzfahrtschiff, die Californian, dass sie angehalten hatte, nachdem sie von Eis umgeben war. Aber einer der Funker der Titanic schimpfte über die Californian, weil sie ihn unterbrochen hatte, da er mit der Bearbeitung von Passagiermeldungen beschäftigt war. Infolgedessen wurde der Kapitän nicht gewarnt, dass die Eissituation schlimmer war als erwartet, und er fuhr mit voller Geschwindigkeit weiter. Erst um 23:40 Uhr, als ein Eisberg aus dem Ausguck gesichtet wurde, änderte das Schiff seine Route. Die Brückenbesatzung begann, den Kurs der Titanic zu ändern, aber da sie ein großes Schiff war, das mit hoher Geschwindigkeit fuhr, war es zu spät. Die Titanic schrammte mit der Seite am Eisberg entlang, und das Schiff zerbrach. Wir wissen, wie diese Geschichte ausgeht.

Oft kann ein Muster in einem Kontext gleichzeitig ein Antipattern in einem anderen Kontext sein. Im Fall der Titanic zum Beispiel waren die Funker verpflichtet, die Befehle ihrer Vorgesetzten zu befolgen. Hätten sie jedoch gewusst, dass sich der Kontext geändert hatte und das Schiff sich in einer Notlage befand, hätten sie die Befehle nicht blindlings befolgt – dies wäre ein Antipattern gewesen.

Auch Muster können im Laufe der Zeit zu Antipatterns werden, wenn sich Technologien und Prozesse ändern und verbessern. Wenn eine gute Lösung durch eine bessere ersetzt wird, kann die ursprüngliche Lösung als schlechte Lösung für ein wiederkehrendes Problem angesehen werden.

Das zweite Beispiel ist das Microservices-Pattern, ein von Martin Fowler und James Lewis [Lewis & Fowler 2014] beschriebenes Design, bei dem Entwickler*innen eine Reihe kleiner Dienste mit jeweils eigener Funktionalität erstellen. Das Microservices-Pattern hat sich in Softwarearchitekturen als wartbar, flexibel und belastbar erwiesen und wurde als die beste Sache seit geschnittenem Brot (und Design Patterns) angepriesen. Dieses Muster förderte die Entwicklung von unabhängig voneinander einsetzbaren, wiederverwendbaren Komponenten und ermöglichte es Entwickler*innen, skalierbare Systeme mit Microservices zu erstellen. Der Erfolg dieser Systeme führte zur Umstellung vieler monolithischer Systeme auf Microservices-Architekturen.

Dann geschah das, was manchmal mit Mustern passiert: Das Muster wurde überstrapaziert8. Microservices können negative Auswirkungen haben, wenn die Organisation nicht über das erforderliche Fachwissen für die Wartung des Systems, einen Bereich, der von dieser Implementierung profitieren würde, oder klar definierte Grenzen zwischen den Services verfügt. Eine erhöhte Komplexität ist eine der Hauptfolgen einer Microservices-Architektur, und unter den falschen Umständen wird das System zu einem komplexeren Monolithen anstatt zu einer Reihe kleinerer, gut definierter Microservices. Alle erwarteten Vorteile wie Skalierbarkeit, Unabhängigkeit und Wiederverwendbarkeit gehen verloren, und wenn das Microservices-Pattern im falschen Kontext verwendet wird, wird es zu einem Antipattern. Der Kontext, in dem Sie ein Muster verwenden, ist ausschlaggebend, und es wird immer einen Kontext geben, in dem die Lösung für ein Muster nicht anwendbar ist, was zu einem Antipattern führt.

Abb. 2Ein Pattern wird zum Antipattern, wenn es im falschen Kontext genutzt wird.

Ein korrekt beschriebenes Antipattern enthält eine allgemeine Beschreibung, eine Auflistung der Faktoren, die zu den Symptomen geführt haben und wie diese zu erkennen sind, die Konsequenzen der ursprünglichen Lösung und eine überarbeitete Lösung, die beschreibt, wie die aktuellen Probleme gelöst werden können oder zumindest wie es beim nächsten Mal besser geht.

Alle Muster haben Konsequenzen. In manchen Situationen ist es eine gute Idee, ein bestimmtes Muster zu verwenden, und in anderen wird dasselbe Muster zu einem Antipattern. Es ist wichtig, die kontextabhängigen Auswirkungen zu verstehen, wenn Sie ein Muster verwenden wollen. Dies hilft Ihnen, das Gesamtbild zu verstehen, einschließlich der Nebeneffekte der Antipattern-Lösung. Wie ein Pattern ist auch ein Antipattern keine abstrakte Theorie, die jemand erfunden hat, sondern besteht aus einer Reihe von Ursachen und Wirkungen, die in häufig wiederkehrenden schlechten Lösungen erkannt werden können.

Sie sollten dieses Buch lesen, um zu lernen, Antipatterns in Retrospektiven zu erkennen, wenn (oder vielleicht sogar bevor) sie auftreten. Mein Ziel beim Schreiben von Antipatterns in Retrospektiven ist es, Ihnen zu helfen, die gleichen Fehler zu vermeiden, die ich so oft gemacht habe.

Wenn Sie in der Moderation von Retrospektiven erfahren sind, werden Sie vielleicht feststellen, dass Sie viele dieser Muster bereits kennen und wissen, wie mit ihnen umgegangen werden kann. Der zusätzliche Nutzen dieses Buches besteht darin, dass Sie nun über ein Vokabular verfügen, um mit anderen darüber zu sprechen, was Ihnen die Kommunikation erleichtern wird. Wenn Sie die Antipatterns mit Ihren Kolleg*innen teilen, können ihre einprägsamen Namen dazu beitragen, Sie darauf aufmerksam zu machen, wenn Sie oder Ihr Team zum Beispiel in »Das Glücksrad« oder in »Die oberste Direktive ignorieren« abrutschen.

Schließlich können Sie dieses Buch auch aus Schadenfreude lesen, denn wie einer der Autoren des ursprünglichen Antipattern-Buches AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis[Brown et al. 1998] bei einer Präsentation anlässlich der Veröffentlichung sagte: »[Das eigene] Glück ist gut, aber das Unglück anderer ist besser.«

Wie dieses Buch zu lesen ist

Der Oktopus

Sie fragen sich vielleicht, was ein Oktopus mit Retrospektiven zu tun hat. Die kurze Antwort lautet: nichts. Aber das ist nur die kurze Antwort.

Meine Faszination für Kraken begann, als ich von ihrer Intelligenz erfuhr. Sie können Tricks lernen, indem sie beobachten, wie andere Kraken für das Erlernen von Tricks belohnt werden, ohne selbst eine Belohnung zu erhalten. Sie können aus einem Aquarium heraus oder auch durch ein winziges Rohr ins Meer kriechen. Sie können aus einem Aquarium klettern, sich hinunter bis zum Boden bewegen, diesen überqueren, auf einen anderen Tisch klettern, in ein anderes Aquarium kriechen, dort alle Fische fressen und dann in ihr eigenes Aquarium zurückkehren, als wäre nichts geschehen.

Am meisten erstaunt mich, dass 60 Prozent des Gehirns eines Oktopus in seinen acht Beinen stecken, die in acht einzelne kleine Tiere unterteilt sind, von denen jedes seinen eigenen Willen hat und doch alle als Ganzes mit dem Rest des Oktopus in einer Synergie leben, die im Tierreich einzigartig ist. Ich sehe ein Team mit einer moderierenden Person bei einer Retrospektive als Krake: Das Team und die moderierende Person arbeiten zusammen auf ein gemeinsames Ziel hin und sind doch alle Individuen mit ihren jeweiligen Schwerpunkten und Stärken.

Zu jedem Antipattern gibt es eine Illustration mit einem Oktopus, die die Essenz des Antimusters symbolisiert. Bei dem Antipattern »Die Ursuppe« arbeitet das Team beispielsweise zusammen, um ein Gewicht zu heben, das immer noch zu schwer ist, denn das Problem, das die Teammitglieder zu lösen versuchen, liegt in der »Ursuppe« von Dingen, die sie nicht ändern können, sondern akzeptieren müssen. Bei »Die oberste Direktive ignorieren« beginnt das Team, einer Person die Schuld zu geben, anstatt zu versuchen, die Fehler im System zu finden. In »Entmutigte Moderator*innen« nehmen die Teammitglieder die moderierende Person nicht ernst, weil sie Aktivitäten ausprobiert, die sie lächerlich finden.

Die Darstellungsart der Antipatterns in diesem Buch

In Anlehnung an die Darstellungsart der Antipatterns, die im Buch AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis[Brown et al. 1998] zu finden ist, habe ich mich für eine spezifische Form entschieden, um die Lesart der Antipatterns zu erleichtern. Wie Sie sehen werden, passt diese Darstellungsart zu einigen Antipatterns besser als zu anderen. Zum Beispiel sind die Symptome manchmal offensichtlich und manchmal sind sie subtil, und es lohnt sich, sie im Detail zu beschreiben. Der Kürze halber habe ich den Abschnitt über die Einflüsse weggelassen, die normalerweise in einem Patterns zu finden sind. In meiner Darstellungsart habe ich die Einflüsse in den Kontext und zugehörige Kontextbeschreibungen eingefügt. Einflüsse können z. B. Eile, Bestreben, gehört zu werden, oder zu wenige Menschen sein.

Name: Die Namen von Patterns sind wichtig, denn sie ermöglichen es Ihnen, Ihr Vokabular über Retrospektiven zu erweitern und sich mit anderen effizient über diese Patterns auszutauschen. Das Interessante am Benennen ist, dass der Name eine große Menge von Konzepten, Prozessen und Bedingungen auf prägnante Weise umfassen kann, die die Informationen so organisiert, dass das Gehirn schnell auf alle zugehörigen Elemente zugreifen kann, die mit diesem Namen verbunden sind.

Kontext: Dieses Buch ist als Lernreise aus der Perspektive einer Retrospektiven-Moderatorin aus einem dänischen Unternehmen geschrieben. Die Geschichte und die Menschen werden später vorgestellt, aber für den Moment reicht es aus, zu wissen, dass jedes Antipattern eine Beschreibung des Kontexts enthält, in dem wir das Antipattern in unserer Geschichte finden.

Metakontext: Dieser Abschnitt beschreibt die Umgebung, in der Sie sich befinden, wenn dieses Antipattern auftritt, die Umstände, die zu diesem Problem geführt haben könnten, und den Drang, die Antipattern-Lösung zu wählen. Dies ist eine allgemeinere Art, die Situation zu beschreiben, in der Sie versucht sein könnten, die Antipattern-Lösung zu implementieren.

Antipattern-Lösung: In diesem Abschnitt wird der gewählte Weg auf der Grundlage des beschriebenen Problems erläutert. Das Antipattern sah zu dem Zeitpunkt wie eine Lösung aus, die auf der Ausbildung, auf früheren Erfahrungen, Zeitmangel, fehlendem Mut oder einfach Befehlen von oben beruhte. Es hätte die richtige Lösung sein können, wären da nicht die negativen Folgen in diesem Zusammenhang gewesen. Wenn Sie sich darüber im Klaren sind, dass Sie in diese Situation geraten können, wenn Sie sich für eine Antipattern-Lösung entscheiden, vermeiden Sie vielleicht einige der zahlreichen Fehler, die ich gemacht habe. Die Antipattern-Lösung ist nicht zu verwechseln mit der Refactoring-Lösung.

Konsequenzen: Alle Lösungen und Entscheidungen haben Konsequenzen. Im originären Buch über Design Patterns [Gamma et al. 1995] wurden sie als positive und negative Folgen aufgeführt, und je nach Kontext können die einen die anderen überwiegen. Bei Antipatterns geht es darum, dass eine Lösung in einem anderen Kontext gut passen könnte, aber in diesem Kontext sind die negativen Folgen viel größer als die Vorteile. Ich sage oft, dass diese Auflistung von Konsequenzen den Unterschied zwischen Patterns und bloßen Methoden oder Anleitungen ausmacht, die in anderen Büchern zu finden sind.

Symptome: Symptome sind die Indikatoren, an denen Sie erkennen können, dass ein bestimmtes Antipattern in der Retrospektive auftritt. Zu den Symptomen gehören Kommentare, die Sie entweder außerhalb oder während der Retrospektive hören, Verhaltensweisen, die Sie beobachten, Stimmungen, die Sie wahrnehmen, usw.

Refactoring-Lösung: Die überarbeitete Lösung schlägt vor, wie die aktuelle Situation so verbessert werden kann, dass Sie und Ihr Team mehr Vorteile als negative Folgen haben. Bei einigen Antipatterns werden Sie erfahren, dass es nicht möglich ist, die Refactoring-Lösung zu implementieren, wenn die Situation bereits eingetreten ist. Was Sie aus einem solchen Antipattern gewinnen, ist lediglich ein Bewusstsein dafür, wie Sie es beim nächsten Mal vermeiden können.

Online-Aspekt: Bei einigen der überarbeiteten Lösungen gibt es Unterschiede in der Art und Weise, wie Sie die Herausforderungen in Online- und Offline-Umgebungen bewältigen können. Eine wachsende Anzahl der Retrospektiven, die ich moderiere, findet online statt, sodass ich auch die daraus entstandenen Erfahrungen teile.

Persönliche Anekdote: In diesem Abschnitt erzähle ich von meinen eigenen Erfahrungen bei der Entdeckung der Antipatterns. Manchmal fand ich einen Weg, sie zu restrukturieren, während sie auftraten, und manchmal waren sie eine Lektion, die ich für das nächste Mal gelernt habe.

Die Antipattern-Kategorien

Strukturelle Antipatterns (Teil 1 des Buches)

Strukturelle Antipatterns beschreiben Probleme mit der Struktur der Retrospektive, z. B. wie die Aktivitäten ausgewählt werden, wie der Kommunikationsfluss moderiert wird und wo eine Änderung der Agenda das Problem entweder in der aktuellen Retrospektive oder in der nächsten Retrospektive lösen könnte. Dies sind die strukturellen Antipatterns:

Das Glücksrad (Wheel of Fortune) … wenn das Team in der Retrospektive voreilige Schlüsse zieht, indem es Symptome statt Probleme löst, und die moderierende Person die Teammitglieder dazu bringt, sich Zeit zu nehmen für die Ursachensuche hinter den Symptomen.

Die oberste Direktive ignorieren (Prime Directive Ignorance) … wenn die Teammitglieder die oberste Direktive ignorieren – »Unabhängig davon, was wir entdecken werden, verstehen und glauben wir aufrichtig, dass in der gegebenen Situation, mit dem verfügbaren Wissen, den Ressourcen und ihren individuellen Fähigkeiten, jede Person ihr Bestes getan hat« [Kerth 2001] –, weil sie es lächerlich finden, und die moderierende Person sie daran erinnert, wie wichtig diese Denkweise für eine erfolgreiche Retrospektive ist.

Die Ursuppe (In the Soup) … wenn die Teammitglieder Dinge diskutieren, die sie nicht ändern können, und die Person, die moderiert, ihnen hilft, ihre Energie auf das zu konzentrieren, was sie ändern können, und zu akzeptieren, was sie nicht ändern können.

Die Zeit überziehen (Overtime) … wenn das Team bei der Retrospektive abschweift und über eine Entwicklung spricht, die für das Team als Ganzes nicht die wichtigste ist, und die moderierende Person dem Team hilft, sich wieder auf das Wesentliche zu konzentrieren.

Smalltalk (Small Talk) … wenn die Teammitglieder Zeit mit Smalltalk in kleinen Gruppen verbringen, anstatt sich auf den Austausch und das Lernen zu konzentrieren, und die Person, die moderiert, die Aktivitäten ändert, damit sie wieder als Team zusammenarbeiten.

Erschwerende Demokratie (Unfruitful Democracy) … wenn zur Frustration der Minderheit im Team demokratisch entschieden wird, was zu diskutieren und zu tun ist, und die moderierende Person andere Wege der Entscheidungsfindung definiert, die dann alle zufriedenstellt.

Nichts zu besprechen (Nothing to Talk About) … wenn das Team glaubt, so gut geworden zu sein, dass es keine Retrospektiven mehr braucht, und die moderierende Person dem Team zeigt, wie es lernen kann, sich weiter zu verbessern.

Politische Abstimmung (Political Vote) … wenn die Teammitglieder bis zum letzten Moment mit der Abstimmung warten, um das System zu manipulieren, und die moderierende Person einen Weg findet, das Abstimmungssystem fairer zu gestalten.

Operative Antipatterns (Teil 2 des Buches)

Operative Antipatterns