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

Inhalt

  1. Product-Owner nicht erwünscht
  2. Zeitschleifen Retrospektive
  3. Routine Retrospektive
  4. Anwesenheitspflicht
  5. Retrospektive nach Planning
  6. Kein passender Raum

Beschreibung des Antipatterns:

  • Der Product-Owner ist in der Retrospektive nicht erwünscht und wird dezidiert nicht eingeladen bzw. ausgeladen.
  • Das Team glaubt die Retrospektive ist ein Meeting ausschließlich für das Umsetzungsteam.

Warum ist das schlecht?

  • Der Product-Owner ist ein essentieller Bestandteil des Scrum-Teams und die Retrospektive ist ein Meeting des gesamten Scrum-Teams. Er hat wesentliche aufgaben im Scrum und steuert maßgeblich den Produkt und Projekterfolg. Aufgrund dieser Verantwortung und Schnittstellenfunktion können hier in der Zusammenarbeit viele Fehler und Konflikte entstehen und Verbesserungspotentiale entdeckt werden.
  • Nimmt der Product-Owner nicht an der Retrospektive teil oder darf nicht teilnehmen, so können diese Verbesserungen und Konflikte nicht direkt angesprochen und gemeinsam gelöst werden.
  • Das Team könnte zwar dennoch über Probleme in der Zusammenarbeit mit dem Product-Owner sprechen, sie reden dann aber über den Product-Owner und nicht mit und dies kann wiederum zu Konflikten führen.
  • Wird der Product-Owner nach der exklusiven Retrospektive auf Verbesserungen angesprochen, kann die Bereitschaft des Product-Owners niedriger sein diese umzusetzen weil er nicht die Möglichkeit hatte mit zu reden.
  • Außerdem kann es sein dass der Product-Owner Probleme oder Veränderungspotentiale beim Team entdeckt hat die er diskutieren möchte. Darf er nicht an der Retrospektive teilnehmen, so hat er keine Möglichkeit diese zu mit dem Team zu diskutieren.

Verbesserungen:

  • Der Scrum-Master sollte hier aktiv eingreifen und das Team über die zahlreichen Nachteile informieren die entstehen wenn der Product-Owner nicht bei der Retrospektive dabei ist.
  • Es kann durchaus mal Abstimmungsbedarf innerhalb des Umsetzungsteams geben, dieser sollte unabhängig zur Retrospektive durchgeführt werden. Wichtige Diskussionen und Problemlösungen und Konflikte sollten allerdings immer in der Retrospektive gemeinsam diskutiert und gelöst werden.
  • Der Scrum-Guide definiert die Retrospektive als gemeinsames Meeting des gesamten Scrum-Teams inkl. Scrum-Master und Product-Owner.
  • In einem ersten Versuch sollte diskutiert werden, warum das Team den Product-Owner nicht in der Retrospektive haben wollen. Oft liegt hinter einem derartigen Bedürfnis ein schwelender Konflikt mit dem Product-Owner. Dieser muss vom Scrum-Master angesprochen und mit dem Team und dem Product-Owner gelöst werden.

Beschreibung des Antipatterns:

  • Bei jeder Retrospektive taucht ein und das selbe Thema immer wieder auf. Die Verbesserungen werden nicht gemacht oder greifen scheinbar nicht.
  • Das Team ist schon sehr unzufrieden was diesen Punkt angeht.
  • Wird der Punkt zur Sprache gebracht werden Augen gerollt und die Teammitglieder finden es bereits überdrüssig sich mit dem Thema zu beschäftigen.

Warum ist das schlecht?

  • Taucht ein Punkt immer wieder in der Retrospektive auf deutet dies einerseits darauf hin dass es ein Thema ist welches das Team wirklich beschäftigt und stört, andererseits aber dass keine oder keine wirksamen Maßnahmen gesetzt werden.
  • Im schlimmsten Fall lässt sich das Team eine dicke haut wachsen oder kündigt eines Tages weil es das Problem nicht mehr aushält.

Verbesserungen:

  • Meist entstehen solche Themen bei Problemen die außerhalb des Kompetenzbereichs des Teams liegen. In diesen Fällen kann das Team das Problem nicht aus eigener Kraft lösen und muss um Unterstützung von Vorgesetzten oder anderen Stakeholdern bitten.
  • Der Scrum-Master sollte das Team dabei in der Kommunikation und Koordination unterstützten.
  • Liegt das Problem innerhalb des Kompetenzbereichs des Teams ist vom Scrum-Master zu hinterfragen warum das Problem nicht gelöst werden kann. Oft liegt dahinter ein schwelender Konflikt zwischen (Scrum-) Teammitgliedern. In diesem Fall muss der Konflikt offen angesprochen werden.
  • Liegt es allerdings an anderen externen Fakten wie beispielsweise einer Abhängigkeit zu einer externen Ressource, so muss ebenfalls die Lösung extern gesucht werden.
  • In seltenen Fällen wird auch die Retrospektive falsch abgehalten und das Team glaubt dass jemand anderer die Probleme des Teams lösen wird. In diesem Fall muss der Scrum-Master als Enabler dafür sorgen dass sich das Team selbst hilft. Sozusagen Hilfe zur Selbsthilfe leisten.

Beschreibung des Antipatterns:

  • Das Team empfindet die Retrospektive als Routine und sieht keinen Mehrwert in der immer wiederkehrenden Diskussion über den vergangenen Sprint.
  • Es wird immer die selbe Methodik genutzt um die selben Probleme anzusprechen, aber kaum Verbindliches beschlossen oder etwas verbessert.
  • Der Mehrwert ist für viele Teammitglieder nicht gegeben und somit nehmen sie nicht mehr oder nur sporadisch an der Retrospektive teil.

Warum ist das schlecht?

  • Wird die Retrospektive als notwendige Routine gesehen und auch wenig bis kein Mehrwert erkannt gefährdet dies den Projektfortschritt.
  • Es werden Probleme nicht angesprochen oder gelöst und Konflikte können weiter bestehen bleiben und Kosten und Reibung im Projekt verursachen.
  • Es können auch keine Verbesserungen in der Zusammenarbeit gemacht werden und das Team kann nicht wachsen.

Verbesserungen:

  • Um zu eruieren was das Team an der Retrospektive schlecht findet sollte das Team eine Meta-Retrospektive über die Retrospektive abhalten und diskutieren was schlecht läuft und was verbessert werden kann.
  • Es gibt zahlreiche Methoden und Moderationstechniken die in der Retrospektive angewendet werden können. Der Scrum-Master kann hier auch gerne mal zwischen diesen Methoden wechseln.
  • Es kann auch eine gute Idee sein die Retrospektive mal an einen anderen Ort oder zu einer anderen Uhrzeit zu machen. Beispielsweise mal an einem Freitag Nachmittag als Wochenausklang mit einem Bier.
  • Dabei sollte dennoch darauf geachtet werden dass die Retrospektive einen Mehrwert hat und fokussiert bleibt.
  • Wird immer wieder die selbe strukturierte Retrospektivenmethode verwendet kann dies schnell langweilig werden es gibt aber zahlreiche Methoden1 2 wie die Heldenreise, die Schatzinsel oder andere Methoden wie DAKI, KALM, Rennwagen, Schachtel, Story-Telling, FFF, Seestern, usw. …
  • Der Scrum-Master sollte sich auf die Retrospektiven vorbereiten und überlegen wie er mehr Leben in die Retrospektive hinein bringt, besser moderieren kann und mehr Mehrwert für das Team aus der Retrospektive raus holen kann.

Beschreibung des Antipatterns:

  • Teammitglieder wollen nicht an der Retrospektive teilnehmen, werden aber vom Management dazu gezwungen.

Warum ist das schlecht?

  • Mitglieder zur Teilnahme an der Retrospektive zu zwingen bringt niemanden etwas.
  • Es kann keine Vertrauensbasis geschaffen werden und die Retrospektive hat keinen Mehrwert.

Verbesserungen:

  • Anstatt Mitglieder zur Teilnahme an der Retrospektive zu zwingen sollte viel mehr versucht werden einen Mehrwert für alle Teammitglieder zu schaffen, sodass diese freiwillig und gerne zur Retrospektive kommen.
  • Oft liegt hinter dem nicht erscheinen ein fehlendes Verständnis was in die Retrospektive ist und wie sie funktioniert. Dies kann der Scrum-Master jedoch ganz einfach durch ein klärendes Gespräch aus der Welt schaffen.
  • Es kann auch sein dass sich einige Teammitglieder nicht trauen zur Retrospektive zu kommen, beispielsweise wenn sie offene Konflikte mit Teammitgliedern haben oder einfach zu introvertiert oder schüchtern sind. In diesen Fällen sollte dies ebenfalls vom Scrum-Master adressiert und im Vorfeld besprochen bzw. gelöst werden.
  • Eine gute Übung ist es zu beginn der Retrospektive oder im Vorfeld zu klären was die Erwartungshaltungen der einzelnen Mitglieder an die Retrospektive sind und gemeinsam Regeln zu setzten wie das Team die Retrospektive abhalten möchte.

Beschreibung des Antipatterns:

  • Das Team hält die Retrospektive erst nach dem Planning ab.
  • Action-Items die in der Retrospektive beschlossen werden füllen den bereits geplanten Sprint somit noch mehr an, oder werden erst im nächsten Sprint abgearbeitet.

Warum ist das schlecht?

  • Wenn die Retrospektive erst nach dem Planning gemacht wird haben die Action-Items im Sprint meist keinen platz mehr. Der Sprint ist geplant und das Team ist nur widerwillig bereit die Action-Items anzugehen und Verbesserungen zu machen.
  • Aus diesem Grund bleiben die Action-Items im Sprint dann meist liegen, werden sehr spät oder gar nicht gemacht, oder andere geplante Features werden nach hinten verschoben und gegebenenfalls nicht umgesetzt. Das wiederum gefährdet somit das Sprintziel und macht einen guten Sprint-Plan zu Nichte.
  • Werden die Action-Items erst in den darauffolgenden Sprint verplant so ist dies ebenfalls nicht zielführend, weil Verbesserungen oder Problemlösungen möglichst gleich durchgeführt werden sollen um möglichst frühzeitig eine positive Wirkung zu bekommen und den potenziellen Schaden möglichst gering zu halten.

Verbesserungen:

  • Die Retrospektive sollte immer vor dem Planning gemacht werden und mindestens ein Action-Items im nächsten Sprint verplant werden.
  • Die Action-Items sollten der Priorität nach abgearbeitet werden.
  • Sollten Themen aus dem Sprint-Planning ebenfalls zu diskutieren sein kann dies im Planning oder bei der nächsten Retrospektive passieren.

Beschreibung des Antipatterns

  • Die Retrospektive fühlt sich drückend an und ist eher schleppend.
  • Die Retrospektive wird immer in kühlen Besprechungsräumen abgehalten.
  • Der Raum ist nicht passend, sehr steril und drückend und lässt das Team nicht kreativ und lösungsorientiert arbeiten.

Warum ist das schlecht?

  • Der klassische Besprechungsraum ist kein idealer Ort für eine produktive Retrospektive.
  • Das Team kann aus dem gewohnten Umfeld nicht aus den gewohnten Denktmuster ausbrechen und somit nicht das volle Potenzial der Kreativität entfachen.
  • Auch Reflexionen können nicht so effizient durchgeführt werden und Konflikte nicht so konstruktiv gelöst werden, weil der neutrale Boden fehlt.

Verbesserungen:

  • Agiles arbeiten benötigt auch den passenden Raum um seine Ideen platz zu geben.
  • Nicht umsonst investieren Unternehmen viele Millionen in ihre Büroräumlichkeiten und versuchen mit Innenarchitekten den idealen Platz für kreative Lösungen zu gestalten.
  • Sollten solche Möglichkeiten dem Team nicht zur Verfügung stehen, so kann dennoch einiges gemacht werden.
  • Das einfachste was das Team gestalten kann ist die Sitzordnung im Besprechungsraum. Die Tische können auf die Seite geräumt werden und die Teammitglieder können im Kreis versuchen Lösungen zu gestalten.
  • Es kann auch leicht die Retrospektive mal draußen im freien oder in einem ruhigen Lokal durchgeführt werden. Dabei ist aber auf die notwendige Privatsphäre zu achten.
  • Mit etwas Budget können auch externe Räumlichkeiten in Seminar-Hotels oder anderen Veranstaltungsorten gebucht werden.
  • Eine weitere einfache Möglichkeit ist es die Retrospektive durch Düfte, Musik und Naschereien etwas aufzuwerten.
  • Das Ziel der Retrospektive sollte dabei aber immer bleiben effizient den vergangenen Sprint zu reflektieren und Verbesserungen und Problemlösungen zu generieren.

1https://agilescrumgroup.de/retrospektive-formen-mit-beispielen-und-ideen/

2https://retromat.org/de/?id=1

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: