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

Inhalt

Product-Owner nicht erwünscht
Zeitschleifen Retrospektive
Routine Retrospektive
Anwesenheitspflicht
Retrospektive nach Planning
Kein passender Raum

1. Product-Owner nicht erwünscht

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, welches ausschließlich für das Umsetzungsteam da ist.

Warum ist das schlecht?

Der Product-Owner ist ein essenzieller Bestandteil des Scrum-Teams und die Retrospektive ist ein Meeting des gesamten Scrum-Teams.
Der Product-Owner 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 Verbesserungspotenziale entdeckt werden.
Nimmt der Product-Owner nicht an der Retrospektive teil oder darf nicht teilnehmen, so können 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 ihm 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 diese umzusetzen, niedriger sein, weil er nicht die Möglichkeit hatte mitzureden.
Außerdem kann es sein, dass der Product-Owner Probleme oder Veränderungspotenziale beim Team entdeckt hat, die er diskutieren möchte. Darf er nicht an der Retrospektive teilnehmen, so hat er keine Möglichkeit, diese 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, 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 will. 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.

2. Zeitschleifen Retrospektive

Beschreibung des Antipatterns:

Bei jeder Retrospektive taucht ein und dasselbe Thema immer wieder auf. Die Verbesserungen zu diesem Thema werden aber 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.

3. Routine Retrospektive

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 dieselbe Methodik genutzt, um dieselben 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 und nicht gelöst, 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 Freitagnachmittag als Wochenausklang mit einem Bier.
Dabei sollte dennoch darauf geachtet werden, dass die Retrospektive einen Mehrwert hat und fokussiert bleibt.
Wird immer wieder dieselbe strukturierte Retrospektivenmethode verwendet, kann dies schnell langweilig werden es gibt aber zahlreiche Methoden¹ ² 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.

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

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

4. Anwesenheitspflicht

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 der Teammitglieder ein fehlendes Verständnis dafür, was die Retrospektive ist, wie sie funktioniert und was der Mehrwert ist. 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.

5. Retrospektive nach Planning

Beschreibung des Antipatterns:

Das Team hält die Retrospektive erst nach dem Planning ab.
Action-Items, die in der Retrospektive beschlossen werden, haben im geplanten Sprint keinen Platz mehr, 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 verhindert einen guten Sprint-Plan.
Werden die Action-Items erst in dem 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-Item 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.

6. Kein passender Raum

Beschreibung des Antipatterns

Der Raum, in dem die Retrospektive abgehalten wird, ist nicht passend, sehr steril, drückend und lässt das Team nicht kreativ und lösungsorientiert arbeiten.
Die Retrospektive fühlt sich daher drückend an und verläuft oft schleppend.
Die Teammitglieder beschreiben die Raumatmosphäre als kühl, trocken, steril, langweilig.

Warum ist das schlecht?

Der klassische Besprechungsraum ist kein idealer Ort für eine produktive Retrospektive.
Das Team kann nicht aus dem gewohnten Arbeitstrott und den gewohnten Denkmustern 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.
Daher ist die Konsequenz dieses Antipatterns, dass weniger Verbesserungen identifiziert und Konflikte weniger angesprochen bzw. gelöst werden. Das lässt die Entwicklungskosten und Projektrisiken steigen.

Verbesserungen:

Agiles arbeiten benötigt auch den passenden Raum, um Ideen, Kreativität und Emotionen 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.
Ganz leicht kann die Retrospektive auch mal draußen ins Freie verschoben werden oder in einem ruhigen Lokal durchgeführt werden. Dabei ist aber auch auf die notwendige Privatsphäre zu achten. Denn Konflikte und Emotionen werden ungern in der Öffentlichkeit mit fremden Zuhörern angesprochen.
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.
Der Fokus der Retrospektive sollte dabei aber immer auf Effizienzsteigerungen und Lösungsvorschlägen bleiben.
Das Team sollte den vergangenen Sprint reflektieren und Verbesserungen und Problemlösungen generieren können.

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

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