Software-Engineering Pattern und Antipattern: Retrospektive Antipattern (Teil 1)

Inhalt:

  1. Keine Retrospektive benötigt
  2. Retrospektiven bringen nichts
  3. Auf die nächste Retrospektive verschieben
  4. Retrospektive die entbehrliche Pufferzeit
  5. Übereilte Retrospektive
  6. Gebrochene Las Vegas Regel
  7. Das Team in der Opferrolle
  8. Action-Items sind nicht SMART
  9. Keine Verantwortlichen und keine Verbindlichkeit
  10. Kein Abschließen von Action-Items

Beschreibung des Antipatterns:

  • Das Team hält keine Retrospektive ab, weil es glaubt es würde nichts zu besprechen geben

Warum ist das Schlecht?

  • Es gibt immer etwas zu besprechen und zu verbessern, sieht das Team dies nicht, so wird vielleicht die Retrospektive falsch abgehalten.
  • Oder das Team ist zu unreflektiert und sieht wirklich nicht was gut und was schlecht gelaufen ist und was besser gemacht werden kann.

Verbesserungen:

  • Liegt die Aussage „Es gibt nichts zu besprechen“ daran, dass das Team nicht gut reflektieren kann und wirklich das eigenen Potenzial und die eigenen Fehler nicht sieht, so ist dies oft auf fehlende Erfahrungen und fehlendes Wissen zurückzuführen.
  • Einerseits liegt es dann an fehlenden Verständnis und Wissen über die Sprint Retrospektive, andererseits kann es an fehlenden Erfahrungen für professionelles Software-Engineering liegen. Oft schlägt hier der Dunning Kruger Effekt1 zu. Dieser führt dazu, dass wir uns heillos Überschätzen weil wir zu wenig Ahnung von einem Thema haben und uns nicht in der Tiefe mit dem Thema beschäftigt haben.
  • Liegt das Problem also in der fehlenden Verständnis für Scrum und die Sprint Retrospektive, so sollte der Scrum-Master zunächst das Thema dem Team näher bringen.
  • Sollte das Problem aber an der fehlenden Kompetenz und Selbsteinschätzung liegen muss zunächst der psychologische Mechanismus hinter dieser Fehleinschätzung bewusst gemacht werden. Ist dies dem Team dann klar, kann es sinnvoll sein dem Team einerseits Zeit für Aus- und Weiterbildung zu geben und andererseits einen Erfahrenen Softwareentwickler und Mentor beiseite zu stellen, der dann das Team auf technische Weise unterstützt und coacht.

Beschreibung des Antipatterns:

  • Das Team ist nicht davon überzeugt, dass Retrospektiven etwas bringen, es hält das Meeting für reinste Zeitverschwendung.

Warum ist das schlecht?

  • Gelangt das Team zu dieser Einschätzung ist dies meist ein Zeichen dafür, dass bereits viel zu lange Retrospektiven falsch oder schlecht gemacht wurden.
  • Die Sprint Retrospektive ist ein wichtiges Inspect-Meeting welches dem Team die Möglichkeit gibt aus dem vergangenen Sprint zu lernen und besser zu werden. Das Team passt sich durch die Retrospektive an veränderte Bedingungen oder neue Erkenntnisse an. Wird keine Retrospektive abgehalten, oder wird diese als nicht sinnvoll erachtet, führt dies dazu dass sich das Team nicht weiterentwickeln kann und nicht aus seinen Erfahrungen und Fehlern lernt.
  • Im schlechtesten Fall wird dann das Retrospektiven Meeting weitergeführt, um Scrum-konform zu sein, aber die Teammitglieder sitzen teilnahmslos dabei, ziehen keinen Nutzen oder machen aus der Retrospektive ein lustiges Event und sabotieren somit den Erfolg des Meetings.

Verbesserungen:

  • Zunächst einmal sollte das Problem offen vom Scrum-Master angesprochen werden. Der beste Platz dies zu tun ist die Retrospektive. (Rekursion / Deadlock)
  • Hat der Scrum-Master das Problem also erkannt, so muss die Ursache für diese Einstellung gefunden werden.
  • Nur wenn die Retrospektive einen Mehrwert für das Team und das Projekt liefert, wird sie gerne vom Team gemacht. Um dies zu erreichen, sollte der Scrum-Master das Team fragen was es sich von der Retro erwartet.
  • Der Scrum-Master muss dann versuchen die nächsten Retrospektiven-Meeting mit dem Team so zu gestalten, dass alle auf ihre Kosten kommen und ihre Erwartungshaltungen erfüllt werden.

Beschreibung des Antipatterns:

  • Das Team will keine Retrospektive machen, weil es gerade sehr viel zu tun hat und lässt für diesen Sprint die Retrospektive ausfallen, denn die nächste Retrospektive kommt sowieso nach dem nächsten Sprint somit ist es ja nicht so wichtig.

Warum ist das schlecht?

  • Fängt das Team einmal mit dieser Argumentation an, gibt es kein halten mehr.
  • Die Retrospektive kann dann immer wieder mal ausfallen und verschoben werden.
  • Dabei ist die Retrospektive eines der Kernelemente von Scrum und eine Möglichkeit für das Team dazuzulernen, die eigene Arbeit und die Teamarbeit zu verbessern.
  • Wird keine Retrospektive abgehalten können größere Probleme im Projekt entstehen und gegebenenfalls nicht verhindert werden, dies kostet dann unnötig Zeit.
  • Es kann auch sein, dass das Team nicht so effizient arbeitet und deswegen den Zeitstress in erster Linie überhaupt hat. Um das aufzudecken ist eine Retrospektive notwendig, somit sollte diese auf keinen Fall ausgelassen werden, weil sonst das Team nie aus dieser Endlosschleife ausbrechen kann.
  • Ist die Zeit aufgrund externer Faktoren eingeschränkt, sollte die Retrospektive ebenfalls gemacht werden, weil dadurch Konflikte verhindert werden und Psychohygiene betrieben werden kann. Verhindert das Team durch das Abhalten der Retrospektive nur einen einzigen Konflikt oder ein Problem eines Kollegen ist die Zeit schon wieder gewonnen.

Verbesserungen:

  • Retrospektiven-Meetings sollten immer zum selben Zeitpunkt im Sprint durchgeführt werden. Diese Regelmäßigkeit verschafft dem Team die notwendige Routine, um sich an das abhalten der Retrospektive zu gewöhnen und diese effizient abzuhalten.
  • Der Scrum-Master sollte sich auf jeden Fall dafür einsetzen die Retrospektive abzuhalten.
  • Er sollte einen fixen Serientermin planen der am Ende eines jeden Sprints automatisch abgehalten wird.
  • Es gibt im Sprints immer etwas zu verbessern oder zu diskutieren und es sollte nicht einziehen, dass diese Verbesserung auf die lange Bank geschoben wird und nicht stattfindet. Statt dessen sollte der Scrum-Master dem Team bewusst machen, welch ein Fehler es wäre hier sich die Zeit nicht zu nehmen.
  • Folgende Argumente können dem Team nähergebracht werden:
    • Wenn nur ein Fehler oder ein Konflikt in stressigen Zeit vermieden werden kann, so kann dies viel mehr Zeit sparen als das abhalten der Retrospektive kostet.
    • Gerade in stressigeren Zeiten ist oft auch das Konfliktpotential höher also ist das Abhalten der Retrospektive auf jeden Fall wichtig.

Beschreibung des Antipatterns:

  • Dieses Antipattern ist ähnlich zu dem Antipattern „Auf den nächsten Sprint verschieben“, es unterscheidet sich allerdings im Mindset der betroffenen. Während beim oberen Antipattern das Team an der Wichtigkeit der Retrospektive zweifelt, wird hier die Retrospektive als Pufferzeit verwendet.
  • Meist wird bei einem derartigen Antipattern der Sprint bis zur letzten Minute verplant um Output zu generieren.

Warum ist das schlecht?

  • Wer ein derartiges Puffermindset hat macht einiges in Scrum falsch. Ein Sprint ist kein Projekt welches bis auf die letzte Minute durchgeplant wird und die Retrospektive hat einen wertvollen Sinn. Hier liegt der Verdacht nahe dass das Team sehr Output getrieben und weniger Outcome fokussiert ist.
  • Wird keine Retrospektive gemacht so kann das Team nie etwas an diesen Fehlern ändern.
  • Weiters ist dieses Antipattern ein starkes Indiz dafür, dass das Team die grundlegenden Baustein von Scrum und vom agilen Arbeiten nicht verstanden hat, vor allem was die zwei Aspekte empirisches arbeiten und kontinuierliche Verbesserung angeht.

Verbesserungen:

  • Zunächst muss der Scrum-Master herausfinden wo dieses Mindset herkommt und wie weit Scrum und das schaffen von Outcome im Team verankert ist.
  • Das Team muss verstehen, dass Output zu generieren nicht das Ziel ist.
  • Der Scrum-Master muss beim Team ein Verständnis für die agile Vorgehensmethode und das empirische Arbeiten schaffen.
  • Es muss jedem im Team klar sein warum es eine schlechte Idee ist die Retrospektive ausfallen zu lassen.
  • So kann es auch hilfreich sein die Retrospektive ans absolute Ende des Sprints zu legen. Also nach das Review. Das ist ohnehin eine gute Idee, weil dadurch auch das Review in der Retrospektive besser inspiziert, diskutiert und verbessert werden kann.
  • Durch das wegfallen der „Pufferzeit“ kann es auch sein dass das Team die Sprintziele nicht mehr gut erreicht. Dann ist dies die perfekte Gelegenheit diese Situation zu inspizieren und herauszufinden was im Sprint schief läuft und was verbessert werden kann.

Beschreibung des Antipatterns:

  • Bei der übereilten Retrospektive nimmt sich das Team nicht genügend Zeit für eine ordentliche Reflexion um den nächsten Sprint und die Arbeit des Teams zu verbessern.
  • Entweder wird das Meeting gleich nur sehr kurz geplant, oder die Mitglieder verhalten sich sehr kurz angebunden und wollen eigentlich gar nicht mitmachen um schnell mit anderen Themen weitermachen zu können.
  • Oft wird das Meeting auch aktiv von einem oder mehreren Mitgliedern kurz gehalten indem Suggestivfragen gestellt werden wie „Es gibt nichts zu besprechen, oder?“ oder „Es ist doch alles OK, oder?“

Warum ist das schlecht?

  • Wer die Retrospektive übereilt, der kann am Ende des Tages mit sehr viel mehr Mehraufwand abgestraft werden. Nämlich genau dann, (1) wenn wichtige Dinge nicht besprochen werden, (2)das Team ineffizient arbeitet oder (3) es Konflikte im Team gibt die nicht besprochen werden.
  • Oftmals wird in der Retrospektive dieser Druck aufgebaut weil das Projekt oder die Entwicklung in einer sehr stressigen heißen Phase ist und Zeit gerade besonders Kostbar ist.
  • Doch genau dann sollte nicht bei der Retrospektive gespart werden, weil es genau diese Phasen sind in denen Fehler passieren und das Team besonders belastet ist. Durch diese Belastung kann es zu Konflikten kommen und diese kosten oft extrem viel Zeit.
  • Des Weiteren sollte immer beachtet werden, dass dieses Verhalten schnell dazu führt das die gesamte Retrospektive an Mehrwert verliert und dadurch auch immer weniger gerne von dem Teammitglieder gemacht wird.

Verbesserungen:

  • Der Scrum Master kann gerade wenn er mitbekommt dass extremer Zeitdruck auf dem Team liegt versuchen eine Atmosphäre des Ankommens und der Entschleunigung zu schaffen
  • Es sollte darauf geachtet werden, dass für die Retrospektive genügend Zeit eingeplant wird und auch wirklich jeder im Team teilnehmen kann.
  • Es kann auch helfen eine strukturierte Retrospektive durchzuführen welche immer nach dem selben Schema abgehalten wird. Dazu kann beispielsweise die DAKI Methode (Drop, Add, Keep, Improve) verwendet werden.
  • Unterstützend kann auch ein Moderator (oft der Scrum-Master) oder die Verwendung eines Tools dabei helfen das Meeting mit Mehrwert für alle abzuhalten und nichts zu überstürzen.

Beschreibung des Antipatterns:

  • Was in Las Vegas passiert, bleibt in Las Vegas- das selbe gilt für die Retro! Bei diesem Antipattern verrät ein Teammitglied sensible Informationen an jemanden Außenstehenden, wie beispielsweise einen Linienmanagern, anderen Mitarbeiter oder anderen Vorgesetzten

Warum ist das schlecht?

  • Bei der Retrospektive werden teilweise sehr persönliche und sensible Dinge besprochen, es werden beispielsweise Konflikte die im Team vorherrschen diskutiert und behoben.
  • Für diese Art von Informationen müssen sich alle Teammitglieder öffnen können und dementsprechend ein vertrauen haben dass sie sich öffnen können.
  • Besteht kein Vertrauen oder ist dieses verletzt werden keine Konflikte angesprochen und können somit nicht behoben werden. Dies kann dann wiederum zu einer verminderten Leistung des Teams führen weil Probleme und Konflikte viel Zeit und Energie brauchen.
  • Außerdem lässt es das Team unprofessionell und inkompetent erscheinen wenn Konflikte nach außen dringen. Das wiederum kann dazu führen dass Stakeholder wie beispielsweise Linienmanager ins Projekt eingreifen und somit Konflikte verstärken und die Leistung weiter minimieren. (Es kann natürlich vom Team aktiv beschlossen werden dass Linienmanager eingeschaltet werden und dies kann eine sehr effiziente Möglichkeit sein mit Konflikten umzugehen, es ist aber entscheidend, dass das Team diese Entscheidung von sich aus trifft.)

Verbesserungen:

  • Vorbeugung ist die beste Variante denn dieses Antipattern zu vermeiden ist einfacher als im Nachhinein den Brand zu löschen. Zunächst muss also sichergestellt werden, dass jeder weiß, dass nichts unkoordiniert aus der Retrospektive nach außen an Dritte dringen soll.
  • Dazu ist es am besten die allgemeinen Regeln für die Retrospektive in einem gemeinsamen Retrospektiven-Meeting zu erfassen und allgemein zugänglich zu machen. Wenn das Team es will kann es diese Symbolisch auch unterschreiben um dem ganzen mehr Bedeutung zu zu weisen.
  • Neue Teammitglieder müssen auf diese Regeln noch vor der ersten Retrospektive aufmerksam gemacht werden.
  • Sollte aus welchem Grund auch immer wirklich dazu gekommen sein dass jemand Informationen nach Außen getragen hat, so muss dies unbedingt sofort, oder spätestens bei der nächsten Retrospektive angesprochen werden und unterbunden werden.
  • Ist ein Schaden entstanden sollte der Scrum-Master als Moderator und Mediator versuchen alle beteiligten an einen Tisch zu bekommen und darüber zu reden.

Beschreibung des Antipatterns:

  • Das Team nutzt die Retrospektive nicht um etwas zu verbessern sondern nur um über die aktuelle Situation zu jammern und Ausflüchte zu finden warum andere für alles schlechte verantwortlich sind und sie nichts daran ändern können.
  • Das Team setzt sich somit bequem in die Opferrolle und ergreift die Opposition bei vielen Punkte.

Warum ist das schlecht?

  • Wird in der Retrospektive immer nur gejammert und nichts geändert so geht das Meeting am Sinn und Zweck vorbei.
  • Dadurch wird die Stimmung des gesamten Teams hinuntergezogen und die Produktivität leidet extrem unter diesem Mindset.
  • Wer sich nur in der Opferrolle sieht und andere für dieses Schicksal verantwortlich macht, wird nie etwas an der Situation ändern können.

Verbesserungen:

  • Der Scrum-Master sollte das Team verantwortlich machen und darauf achten, dass bei jeder Retrospektive klare Action-Items identifiziert werden die das Team umsetzen muss.
  • Es müssen klare Aufgaben und Verbesserungen aufgeschrieben und im Sprint verplant werden.
  • Am Besten managed und moderiert der Scrum-Master auch die Diskussion und dreht negative Gespräche ab und stellt gewisse Schwerpunkte zur Diskussion.
  • Beispielfragen: „Wie habt ihr das Planning empfunden und was können wir daran verbessern?“ „Woran ist es gelegen dass wir mit Ticket XY nicht so effizient waren und dies nicht abschließen konnten?“,…
  • Es können auch strukturiert Retrospektiven-Methoden wie die DAKI-Methode eingesetzt werden, bei denen jedes Teammitglied Positives, Negatives und Verbesserungen sucht und daraus dann 2-3 Action-Items fürs Team abgeleitet werden.
  • Positives und Negatives Feedback kann auch damit gesteuert werden, indem jedes Teammitglied nur fünf grüne und fünf rote Karten bekommt auf dem positive und negative Ereignisse des letzten Sprint aufgeschrieben werden können.

Beschreibung des Antipatterns:

  • Die vom Team gesetzten Action-Items erfüllen die SMART Regel nicht.
  • Bill Wake hat in seinem Artikel 2003 die Akronyme INVEST und SMART begründet.2
  • SMART Steht für S-Spezifisch M-Messbar, A Achievable (erreichbar) R-Relevant, T-Time-Boxed.
  • Somit befriedigen die Action-Items einen oder mehrere dieser Punkte der SMART-Regel nicht. Beispiele: Es ist nicht spezifisch genug beschrieben was zu tun ist, oder die ergebnisse sind nicht messbar oder erreichbar, oder die Aufgabe ist nicht relevant oder zeitlich nicht gesetzt und somit offen.

Warum ist das schlecht?

  • Werden keine konkreten Vorhaben in der Retrospektive vereinbart bleiben die Verbesserungen meinst unerledigt.
  • Wenn keine Verbesserungen gemacht werden ist die in die Retrospektive investierte Zeit nicht mehr so wertvoll und der Mehrwert für das Team und das Projekt schwindet.
  • Zu wenig Mehrwert wiederum kann dazu führen, dass andere Antipattern im Bezug auf die Retrospektive entstehen oder das Team die Retrospektive gleich gar nicht mehr machen möchte.
  • Werden keine Verbesserungen im Projekt gemacht, kann dies auch kritisch für den Projekterfolg werden und letzten Endes zu Mehrkosten und dem Projektabbruch führen.

Verbesserungen:

  • Das Team sollte die Action-Items zusätzlich zum Backlog führen. Einige Teams führen auch gerne die Action-Items im Backlog des Sprints oder dem Product-Backlog mit.
  • Dabei sollten die Action-Items auch einen gewissen Mindeststandard erfüllen den sich das Team vorab wie die Definition of Ready gemeinsam überlegt, schriftlich festhält und verwendet. Das Mindestmaß sollte dabei die Erfüllung der SMART-Regel sein.

Beschreibung des Antipatterns:

  • Bei diesem Antipattern werden zwar die Action-Items identifiziert, sauber erfasst und die Umsetzung geplant. Das Team committet sich sogar auf die Umsetzung. Doch die Action-Items werden dennoch nicht umgesetzt.
  • Es fühlt sich keiner für die Umsetzung direkt verantwortlich und jeder denkt ein anderes Teammitglied soll das Action-Item umsetzen.
  • Denn die Umsetzung von Action-Items aus der Retrospektive ist meist nicht so spannend wie die Implementierung neuer Features für das Produkt.

Warum ist das schlecht?

  • wurden Action-Items in den Sprint eingeplant und hat sich das Team darauf committet so wurde bereits viel Energie in die ganze Organisation des Action-Item gesteckt. Ein Investment also das sich auszahlen soll. Das Team hat entschieden dass es das Action-Item braucht, um effizienter und besser zu werden. Daher wäre eine möglichst rasche Umsetzung viel sinnvollen, weil dann die positiven Effekte früher eintreten und die Verbesserungen früher stattfinden. Setzt sie das Team nicht oder Später um finden diese Verbesserungen nicht statt und es entstehen mehr und mehr Kosten.
  • Dies wiederum verzögert das Projekt und lässt die Probleme nur größer werden.

Verbesserungen:

  • Damit sich das Investment rentiert sollten Action-Items möglichst schnell umgesetzt werden.
  • Um Missverständnisse und Spielräume für das Aufschieben der Action-Items zu minimieren empfiehlt es sich diese gleich in der Sprint-Planung einzelnen Teammitglieder zuzuweisen.
  • Diese sind dann für die Umsetzung hauptverantwortlich, müssen die Action-Items jedoch nicht im Alleingang umsetzen sonder lediglich die Umsetzung koordinieren und dafür eintreten dass diese auch wirklich umgesetzt werden.

Beschreibung des Antipatterns:

  • Das Team bespricht nicht die Umsetzung der Action-Items des vergangenen Sprint und schließt diese nicht gemeinsam in der Retrospektive ab.

Warum ist das schlecht?

  • Werden die Action-Items des vergangenen Sprints nicht gemeinsam abgeschlossen so kann es schnell passieren dass die Motivation der Umsetzung dieser langsam schwindet.
  • Es kann dann sein dass sich beim nächsten Sprint niemand mehr findet der neue Action-Items umsetzen möchte.
  • Wird die Umsetzung der Action-Items außerdem nicht besprochen und vom Team nochmal reviewed und die Ergebnisse und Effekte die die Umsetzung gebracht hat nicht reflektiert so kann es sein, dass Fehler die bei der Umsetzung entstanden sind nicht auffallen und gewünschte Effekte nicht eintreten.

Verbesserungen:

  • Zu beginne einer jeden Retrospektive sollte das Team die alten umgesetzten Action-Items auf ihre Umsetzung und die eingetretenen Effekte untersuchen.
  • Sind die erhofften positiven Effekte eingetreten?
  • Wurde die Umsetzung auch richtig gemacht?
  • Wo viel Selbstorganisation herrscht muss auch die gemeinsame gegenseitige Kontrolle gelebt werden, nur so entstehen auch Verbindlichkeiten und kann eine gewissen Qualität garantiert werden.
  • Wenn die Effekte eines Action-Items nicht spürbar sind und nicht nochmal diskutiert werden, dann ist fraglich warum die Umsetzung überhaupt zu Beginn notwendig war. Daher sollte das Team immer über die jeweiligen Effekte reflektieren und wenn nötig nachbessern.

Referenzen

1 https://www.quarks.de/gesellschaft/psychologie/warum-wir-uns-oft-selbst-ueberschaetzen/

2 https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

Create a website or blog at WordPress.com

Nach oben ↑

%d Bloggern gefällt das: