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

Inhalt:

Kein Review
Roadshow – Kein Feedback sammeln
Ticket Accounting
Product-Owner Ego Review
Abnahmeveranstaltung vom Product-Owner
Der unnahbare Product-Owner
Präsentationismus oder das ungesehene Produkt

1 Kein Review

Beschreibung des Antipatterns:

Es wird kein Sprint-Review abgehalten.
Der Product-Owner und die Stakeholder können sich selbst das Release ansehen, wenn es denn eines gibt, denn oft wird auch kein Release gemacht, weil der Sprint eher so ein Richtwert ist und die Releases spontan zu anderen Zeiten gemacht werden.

Warum ist das schlecht?

Gibt es keine Reviews, können Stakeholder und Keyuser kein Feedback zur Umsetzung geben. Die Entwicklung läuft ggf. in eine falsche Richtung und dies führt zu einem gestiegenen Produktrisiko.
Oftmals wird auch deswegen kein Review gemacht, weil das Team zu plangetrieben vorgeht und gar kein Feedback von Stakeholdern und Keyusern haben will/ braucht. Denn der Plan für die nächsten Sprints ist ohnehin bereits fixiert und wird nicht verändert. Das zeugt von einem anderen Antipattern, dem Waterscrum.
Reviews sollen immer gemacht werden, egal ob das Team das Sprintziel erreicht hat oder nicht. Denn nur durch die Transparenz des Reviews können Stakeholder und Product-Owner vertrauen in das Team setzen. Wird das Review nicht oder nur unregelmäßig gemacht, verlieren Stakeholder das vertrauen ins Team. Es kann sein, dass Konflikte entstehen oder Stakeholder Entscheidungen über den Köpfen des Teams hinweg treffen.
Durch das Fehlen des Reviews und kann außerdem nicht der aktuelle Entwicklungsstand aufgezeigt werden. Daher können keine Informationen gesammelt werden, die im Planning und in der Retrospektive wichtig wären. Somit wird das Lernen und Planen erschwert.

Verbesserungen:

Sprint-Reviews sollen immer gemacht werden.
Wurde das Sprint-Ziel nicht erreicht, ist es sinnvoll, den aktuellen Umsetzungsstand der Tickets zu präsentieren.
Oft sind dennoch einige kleiner Features im Sprint umgesetzt worden, diese können dann auch präsentiert und sogar released werden.
Reviews, bei denen das Team wenige Tickets abgeschlossen hat, sollten der Transparenz halber auf jeden Fall dennoch gemacht werden. In diesen Fällen kann es ratsam sein, die Retrospektive und Analyse der Probleme einschließlich der Suche potenzieller Lösungen vorab zu machen und damit auch gleich die Stakeholder zu versorgen. Das zeugt von Professionalität des Umsetzungsteams aus den gemachten Fehlern zu lernen.

2 Roadshow – Kein Feedback sammeln

Beschreibung des Antipatterns:

Die Teammitglieder präsentiert nacheinander die umgesetzten Features des Sprints, diskutieren diese jedoch nicht mit den Stakeholdern und sammeln auch kein Feedback.

Warum ist das schlecht?

Das Ziel des Reviews ist es, einerseits Transparenz zu schaffen, was gerade wie umgesetzt wurde und dadurch auch eine Vertrauensbasis der Stakeholder in das Team herzustellen, andererseits ist es aber auch die Gelegenheit, Feedback von den Kernstakeholdern und Key-Usern einzusammeln und über das Produkt zu diskutieren.
Somit sollte das Feedback dazu führen, dass das Produkt besser die Bedürfnisse der User und Stakeholder erfüllt. Wird kein Feedback eingeholt, kann es passieren, dass die Entwicklung in eine falsche Richtung läuft und Probleme löst oder Features anbietet, die der User nicht braucht. Das Produktrisiko steigt also. Werden Features implementiert, die keiner braucht, entstehen außerdem unnötig Kosten.
Sammelt das Team kein Feedback, so kann das Produkt auch sehr schnell eine schlechte Usability aufweisen.
Als weitere negative Konsequenz kann auch das Vertrauen in die Kompetenz des Teams schwinden oder die Beziehung zwischen Product-Owner, Team und Stakeholder in verschlechtert sich.

Verbesserungen:

Das Team inklusive des Product-Owners sollte nie eine „Wir wissen schon was ihr wollen sollt.“-Einstellung aufweisen. Niemand weis genau, was die User wollen, nicht einmal die User selbst. Und es gibt außerdem zahlreiche Aspekte einer Software, die keine Richtung und kein Falsch haben. Deswegen sollen Reviews dazu genutzt werden, um über das Produkt und die neuen Features zu diskutieren.
Am besten wird das Review-Meeting interaktiv gestaltet. Das Team kann beispielsweise Stakeholdern oder Key-Usern neue Features direkt ausprobieren lassen und somit auch gleich Feedback sammeln und herausfinden, ob die Software intuitiv aufgebaut ist.
Alternativ können auch noch Feedbackgespräche mit Key-Usern und Stakeholdern neben dem eigentlichen Review vereinbart werden.

3 Ticket Accounting

Beschreibung des Antipatterns:

Das Team nutzt das Review nicht, um Feedback einzuholen, sondern um die Tickets zu warten und abzuschließen und das Backlog zu pflegen.
Die Teammitglieder besprechen jedes Ticket sehr technisch bis ins letzte Detail, gehen aber wenig auf die Bedürfnisse der Stakeholder ein. Das heißt, dass das Team auch nicht auf den neu geschaffenen Nutzen der Features eingeht und auch nicht die neuen Features aus der User-Perspektive präsentiert. Stattdessen wird lediglich Ticket um Ticket diskutiert und geschlossen. Falls ein Ticket nicht ganz fertig wurde, legt das Team auch neue Tickets im Backlog an.

Warum ist das schlecht?

User und Stakeholder wollen genau wissen, warum ein Feature wichtig ist und welchen Nutzen es bringt. Geht das Team bei der Präsentation nicht darauf ein, verstehen die Stakeholder und User gegebenenfalls nicht den Mehrwert des Features.
Durch dieses fehlende Verständnis kann die Beziehung zwischen Stakeholdern und Team leiden. Es kann passieren, dass die Sinnhaftigkeit einzelner Features hinterfragt wird. Daraus entstehen dann Diskussionen und das schädigt das Vertrauen der Stakeholder in das Team.

Verbesserungen:

Bei einem Review wird der geschaffene Mehrwert und Nutzen präsentiert nicht die Details der einzelnen Features. Jedes relevante Feature sollte daher den Usern und Stakeholdern so präsentiert werden, dass ganz klar der neue Nutzen hervorgeht.
Das Team sollte erklären, welches Problem identifiziert und welche Annahmen und Entscheidungen gemacht wurden und dann erklären, wie das neue Feature diese adressiert und löst.
Es kann hilfreich sein, zunächst die User-Story zu präsentieren, da hier ja bereits das Warum definiert wird.
Technische Details und das Schließen der Tickets sollte Nebensache beim Review sein. Der Fokus liegt auf dem Präsentieren des geschaffenen Mehrwerts und dem Sammeln von Feedback.
Die Teilnehmer sollten nie gelangweilt sein, das Team soll sich auf den Outcome fokussieren und nicht auf den Output. Somit können auch kleinere oder zu technische Tickets weggelassen werden.

4 Product-Owner Ego Review

Beschreibung des Antipatterns:

Der Product-Owner präsentiert die umgesetzten Features als seine eigene Leistung, er lässt das Team gar nicht zu Wort kommen oder würdigt die Leistung der Teammitglieder nicht.
Oft ist das Team auch nicht einmal bei der Präsentation dabei.
Bei der Präsentation der neuen Features verwendet der PO meist die Worte „Ich“, „meine“, „mein“ und selten die Worte „wir“, „unser“ und „Team“.

Warum ist das schlecht?

Positioniert sich der Product-Owner zu stark als Treiber der Umsetzung und Urheber dieser Ideen, lässt dies auf zahlreiche Probleme in der Teamdynamik und der Zusammenarbeit zwischen Product-Owner und Team erkennen.
Es ist naheliegend, dass der Product-Owner ein falsches Verständnis für seine Arbeit und die agile Vorgehensweise hat.
Agile Teamarbeit bedeutet, dass jeder im Team gleichgestellt ist, aber seine Rolle zu erfüllen hat. Der Product-Owner alleine setzt keine Tickets und User Stories um. Vielmehr sind alle Errungenschaften eine Teamleistung.
Präsentiert der Product-Owner das Sprint-Ergebnis dermaßen egozentrisch, deutet das auf eine gestörte Beziehung mit dem Team hin und kann einen Konflikt zwischen dem Team und dem Product-Owner auslösen.
Im schlimmsten Fall führt dieses Antipattern also dazu, dass Konflikte eskalieren, Kosten entstehen oder sogar Teammitglieder kündigen und das Projekt abgebrochen wird.

Verbesserungen:

Generell sollte das Team über den Sinn und Zweck des Reviews sprechen und sich gemeinsam überlegen, wie es die Reviews gestalten möchte. Aus diesen Überlegungen sollte das Team dann Verhaltensregeln ableiten und diese auch leben.
Es empfiehlt sich, dass nicht nur der Product-Owner sondern viel das ganze Team die einzelnen neuen Features vorstellt und der Product-Owner zum Beispiel vorab die User-Story und den erwarteten Mehrwert den Stakeholdern und Key-Usern präsentiert.
Der Scrum-Master und das Team sollten auf jeden Fall auf die Präsentation und die Rhetorik der vortragenden Teammitglieder achten und gegebenenfalls bei Inkonsistenzen oder Problemen dies bei der Retrospektive ansprechen.
Sollten sich Teammitglieder übervorteilt vorkommen, so müssen sie ihre Meinung bei der nächsten Retrospektive kundtun und gemeinsam mit dem restlichen Scrum-Team Regeln für das nächste Sprint-Review etablieren

5 Abnahmeveranstaltung vom Product-Owner

Beschreibung des Antipatterns:

Der Product-Owner nutzt das Review, um die Arbeit des Teams abzunehmen und zu akzeptieren.
Die Bedürfnisse der Stakeholder werden nicht berücksichtigt und es wird auch kein Feedback eingeholt.
Durch die langen Abnahmen und die damit verbundenen Diskussionen liegt der Fokus nicht bei den Stakeholdern und Usern, sondern beim Product-Owner.

Warum ist das schlecht?

Durch den fehlenden Fokus auf die Bedürfnisse der Stakeholder wird kein Feedback eingeholt, dadurch kann das Produkt nicht verbessert werden und im schlimmsten Fall wird das Produkt schlecht verwendbar und ist nicht wirtschaftlich vermarktbar.
Weil sich die User und Stakeholder langweilen, nehmen diese nur ungern am Review teil. Sie sehen am Review schnell keinen Mehrwert mehr und bleiben dem Meeting fern. Dadurch verschlechter sich die Kommunikation der Stakeholder mit dem gesamten Team. Die Beziehung mit und das Vertrauen in das Team leidet.
Führt das Team und der Product-Owner viele Diskussionen über die Entstehung, den Fertigstellungsgrad oder die Abnahme einzelner Tickets, so kann das von den Stakeholdern als unprofessionell erachtet werden. Dies kann wiederum zu Misstrauen dem Team gegenüber führen. Die Stakeholder bekommen Zweifel an der Kompetenz des Teams.

Verbesserungen:

Das Team und der Product-Owner sollten noch vor dem eigentlichen Review versuchen, die Arbeiten zu diskutieren und gemeinsam abzuschließen. Am besten sammelt das Team das Feedback des Product-Owners während des Sprints. Dazu ist es natürlich notwendig, dass der Product-Owner immer für das Team erreichbar ist.
Noch besser ist es, wenn das Team bei Unsicherheiten schon während der Umsetzung im Sprint Rücksprachen mit dem Product-Owner hält und diese aus dem Weg schafft, sodass die Abnahme bzw. das Fertigstellen nach Definition of Done eine reine Formalität wird.
Der Product-Owner nimmt die Tickets nicht ab, sondern prüft mit dem Team gemeinsam, ob das Ticket die Defintion of Done erfüllt und ob es keine Missverständnisse mit der User-Story und den Akzeptanz-Kriterien gegeben hat.
Das eigentliche Review soll dazu verwendet werden, den Stakeholdern den Outcome des Sprints nahe zu legen. Dazu sollte das Team als geschlossene Einheit mit dem Product-Owner die Ergebnisse userzentriert präsentieren und Feedback einholen.
Es kann natürlich auch sein, dass gewisse Unsicherheiten erst beim Review sichtbar werden und diskutiert werden müssen. Solche Erkenntnisse sollte das Team begrüßen, denn das ist ein wesentlicher Teil des Lernprozesses in Scrum. Dabei ist es jedoch auch wieder wichtig, dass das Team geschlossen agiert.

6 Der unnahbare Product-Owner

Beschreibung des Antipatterns:

Der Product-Owner akzeptiert kein Feedback von den Stakeholdern oder dem Umsetzungsteam während des Reviews.
Er sieht das Review als reine Demonstration, wenn dann doch Feedback kommt, nimmt der Product-Owner dieses nicht ernst oder nickt es nur ab, ohne es dann umzusetzen.

Warum ist das schlecht?

Wenn der Product-Owner kein Feedback annimmt, so fällt das über kurz oder lange als sehr unangenehm auf.
Das wiederum bringt Missgunst und Misstrauen.
Das Produkt sollte niemals aufgrund der Meinung eines Einzelnen gebaut werden.
Es ist aber ein schmaler Grat der beschritten werden muss, denn es muss auch gleichzeitig der Fokus bewahrt werden und auch Nein gesagt werden können.

Verbesserungen:

Keiner weiß genau, was in das Produkt muss und was nicht. Daher müssen Product-Owner auch wirklich oft Nein sagen, um den Fokus der Produkt-Entwicklung beizuhalten. Steve Jobs hat einmal gesagt, das Produktmanagement nicht deswegen hart ist, weil man Entscheidungen treffen muss und zu gewissen Sachen Ja sagen muss, sondern weil es schwierig ist zu den vielen anderen guten Ideen Nein sagen zu müssen.
Im Idealfall sollte der Product-Owner transparent arbeiten und ehrlich sein. Wenn er ein Feature, eine Änderung oder ein Feedback nicht gut findet, so sollte er es offen sagen und begründen, warum dies so ist. Das schafft vertrauen und lässt ihn kompetent wirken.
Der Scrum-Master sollte, wenn er auf ein derartiges Verhalten des Product-Owners aufmerksam wird, mit diesem das Gespräch suchen und versuchen, eine Verhaltensänderung zu bewirken oder eine Lösung zu finden.

7 Präsentationismus oder das ungesehene Produkt

Beschreibung des Antipatterns:

Das Team oder der Product-Owner bereiten für jedes Review eine statische Präsentation mit einem Präsentationstool vor, in dem sie einen Screenshot nach dem anderen präsentieren.
Das eigentliche Produkt wird jedoch nicht oder nur sehr kurz gezeigt.

Warum ist das schlecht?

Sehen die Stakeholder das Produkt nicht oder nur sehr kurz, können sie das eigentliche Look and Feel des Produkts gar nicht wahrnehmen. Eine Präsentation transportiert nie dieselbe Information und Emotion wie die (Live-)Demonstration des eigentlichen Produkts.
Präsentationen sind auch nicht so glaubwürdig und werden meist als langweilig erachtet

Verbesserungen:

Im Idealfall sollte das Team immer die Software und die neuesten Features live präsentieren.
Der Fokus sollte darauf liegen, den Mehrwert zu präsentieren und die Funktionalität und Arbeitsweise der Software den Stakeholdern und Usern näher zu bringen.
Es kann auch gerne eine Live-Demo mit den Stakeholdern direkt gemacht werden. Dabei können die Stakeholder selbst die neuen Features erkunden und direkt ausprobieren.