Software-Engineering – agile Pattern und agile Antipattern: Review-Antipattern (Teil 3)

Inhalt:

Unfertige Features präsentieren
Technische Schulden sammeln und verschweigen

1 Unfertige Features präsentieren

Beschreibung des Antipatterns:

Ein Teammitglied wird mit einem Ticket nicht fertig und präsentiert den aktuellen Entwicklungsstand den Stakeholdern und dem Product-Owner.

Warum ist das schlecht?

Werden den Stakeholdern unfertige Features präsentiert zeugt dies nicht von der Professionalität des Teams.
Unfertige Features sind meist noch fehleranfällig und so kann es leicht passieren, dass die Software abstürzt oder Fehlermeldungen auftauchen. Das hinterlässt einen unfertigen, instabilen Eindruck bei den Stakeholdern und kann zu Misstrauen gegenüber dem Team führen.

Verbesserungen:

Es empfiehlt sich, unfertige Features nicht zu präsentieren.
Auf Anfrage von gewissen Stakeholdern ist es besser, den aktuellen Stand der Lösung mündlich zu beschreiben und einen Ausblick zu geben welche Themen noch offen sind und bis wann diese voraussichtlich gelöst sein werden.
Dieses Antipattern deutet darauf hin, dass das Team sehr outputfokussiert arbeitet und bei der Sprintplanung zu viele Features und PBIs im Sprint verplant hat.
Es empfiehlt sich daher in der Retrospektive diesen Umstand anzusprechen und nach Lösungsansätzen zu suchen, um die Planung und Abarbeitung des Sprintplans beim nächsten Sprint besser zu machen.

2 Technische Schulden sammeln und verschweigen

Beschreibung des Antipatterns:

Ein oder mehrere Teammitglieder präsentieren PBIs im Review, die die Definition of Done noch nicht erfüllen und noch technische Arbeiten und Schulden offen haben.
Es sind wichtige Tätigkeiten wie beispielsweise das Testen, das Absichern des Codes durch automatisierte Tests, das Sicherstellen von Clean-Code, Architekturanpassungen, Code-Reveiws, Pullrequest, etc. offen die einen wirklichen Done-Status verhindern.
Die präsentierten PBIs werden dann meist auf lokalen Entwicklungsmaschinen präsentiert und befinden sich nicht in einer höheren Stage wie beispielsweise der QA-Stage.

Warum ist das schlecht?

Werden PBIs den Stakeholdern präsentiert, die jedoch verdeckt oder offensichtlich noch Arbeiten offen haben, schadet das dem Ansehen des Teams und vermittelt einen Fortschritt, der jedoch noch nicht erreicht ist.
Der Product-Owner und die Stakeholder rechnen dann mit einem schnelleren Fortschritt und sind enttäuscht, sollte es doch nicht so schnell vorangehen.
Das wiederum kann das Vertrauen in das Team beschädigen und zu Konflikten bis hin zu unbequemen Konsequenzen führen.
Wenn PBIs präsentiert, aber in den nächsten Sprint mitgezogen werden müssen, dann treten spätestens beim nächsten Review dann Fragen dazu auf.
Das Teammitglied oder die Teammitglieder verletzen außerdem dadurch ganz klar die Defintion of Done, was wiederum zu Spannungen zwischen Product-Owner und Teammitgliedern führen kann.

Verbesserungen:

Der Scrum-Master sollte mit dem Team noch einmal über die Definition of Done sprechen und sowohl Product-Owner als auch Team auf denselben Wissensstand bringen. Denn oft wissen Teammitglieder die Details der DoD nicht mehr und es kommt deswegen zu diesem Problem.
Sollten Teammitglieder trotz besserem Wissen über die DoD PBIs präsentieren und damit einen Fortschritt präsentieren und „faken“, der nicht der Realität entspricht, muss der Scrum-Master gemeinsam mit dem Team dieses Thema adressieren. Oft besteht dann nämlich ein externer Druck, der auf dem Team lastet und es dazu bringt, den Fortschritt zu verfälschen. Hier muss der Scrum-Master, der Product-Owner und das Team eine gemeinsame Linie finden, wie mit einer derartigen Situation umgegangen werden soll. Dann kann beispielsweise ein klärendes Gespräch mit dem jeweiligen Stakeholder notwendig werden, der diesen Druck aufs Team ausübt.
Werden technische Schulden gemacht und die PBIs dennoch präsentiert, müssen diese ganz klar kommuniziert und gleich in Form von Folgetickets dokumentiert werden.
Diese Folgetickets müssen dann im nächsten Sprint umgesetzt werden, da ansonsten der Aufwand für weitere Änderungen explodieren kann und es zu Folgefehlern und Folgearbeiten kommen kann, die sehr kostspielig sind.
Generell ist es aber nicht empfehlenswert, technische Schulden zu machen und unfertige PBIs zu präsentieren, da es sein kann, dass die Software nach dem Review auch released wird und dann eine „unsaubere Lösung“ am Markt veröffentlicht wird.
Sollte das Team ein PBI mit offenen technischen Schulden präsentieren wollen, muss dies außerdem mit dem ganzen Team vorab abgeklärt und gemeinsam beschlossen und freigegeben werden.
Des Weiteren deutet dieses Antipattern darauf hin, dass in der Sprintplanung die technischen Schulden und Aufgaben rund um die Featureentwicklung vernachlässigt wurden und es mehr Zeit kostet, ein Feature wirklich technisch sauber abzuschließen. Diese Information sollte in der nächsten Retrospektive diskutiert und beim nächsten Sprintplanning berücksichtigt werden.