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

Inhalt:

  1. Kein Review
  2. Roadshow – Kein Feedback sammeln
  3. Ticket Accounting
  4. Product-Owner Ego Review
  5. Abnahmeveranstaltung vom Product-Owner
  6. Der unnahbare Product-Owner
  7. PowerPointismus 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?

  • 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.
  • Durch das Abhalten des Reviews und den Aufzeigen des Entwicklungsstands können außerdem gegebenenfalls Informationen gesammelt werden die dann wiederum im Planning und in der Retrospektive verwendet werden können um zu Lernen und die Planung anzupassen.

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 einige kleiner Features im Sprint dennoch 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 potentieller 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:

  • Das Team präsentiert der reihe nach umgesetzte Features des Sprints, diskutiert jedoch nicht mit den Stakeholdern und sammelt 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.
  • Sammelt das Team kein Feedback so kann das Produkt sehr schnell in eine falsche Richtung laufen oder sehr schlechte Usability aufweisen.
  • Das Vertrauen in die Kompetenz des Teams kann auch schwinden bzw. die Beziehung zwischen Product-Owner, Team und Stakeholder in Mitleidenschaft gezogen werden.

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 ein mal 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 neben dem Review Feedbackgespräche mit Key-Usern und Stakeholdern 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.
  • Es wird jedes Ticket technisch im Detail besprochen aber wenig auf die Stakeholder eingegangen. Somit werden die neuen Features nicht aus User-Perspektive wiedergegeben und nicht auf den geschaffenen Nutzen eingegangen, sondern lediglich Ticket um Ticket geschlossen.

Warum ist das schlecht?

  • User und Stakeholder wollen 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:

  • Jedes relevante Feature sollte den Usern und Stakeholdern so präsentiert werden, dass ganz klar der neue Nutzen hervor geht.
  • Das Team sollte erklären welches Problem identifiziert und welche Hintergedanken 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 der Sammlung 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 Leistung, er lässt das Team gar nicht zu Wort kommen oder das Team ist nicht einmal dabei bei der Präsentation.
  • Bei der Präsentation der neuen Features verwendet der PO meist die Worte „Ich“, „meine“, „mein“ und selten die Worte „wir“, „unser“, „Team“

Warum ist das schlecht?

  • Positioniert sich der Product-Owner zu stark als Treiber der Tickets und Urheber dieser Ideen und Umsetzungen lässt dies auf zahlreiche Probleme in der Teamdynamik und dem Verständnis des Product-Owners für seine Arbeit und die agile Vorgehensweise schließen.
  • 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, oder kann einen Konflikt zwischen dem Team und dem Product-Owner auslösen.

Verbesserungen:

  • Es empfiehlt sich, dass nicht nur der Product-Owner sonder viel mehr das Team die einzelnen neuen Features vorstellt und der Product-Owner zum Beispiel vorab die User-Story und den 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 achten und gegebenenfalls bei Inkonsistenzen oder Problemen dies bei der Retrospektive ansprechen.

5 Abnahmeveranstaltung vom Product-Owner

Beschreibung des Antipatterns:

  • Der PO 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 verkaufbar.
  • Weil sich die User und Stakeholder langweilen, nehmen diese nur ungern am Review teil. Sie sehen schnell keinen Mehrwert mehr hinter dem Review und bleiben fern. Dadurch verschlechter sich die Kommunikation der Stakeholder mit dem gesamten Team und die Beziehung und das Vertrauen 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 betrachtet werden. Dies kann wiederum zu Misstrauen und Skepsis führen.

Verbesserungen:

  • Noch vor dem Eigentlichen Review sollten Team und Product-Owner 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 zwischenzeitlich bei Unsicherheiten auch schon während der Umsetzung Rücksprachen mit dem Product-Owner trifft 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, sonder 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 kann nochmal dazu verwendet werden den Stakeholdern den Outcome des Sprint nahe zu legen. Dazu sollte das Team als geschlossene Einheit mit dem Product-Owner die Ergebnisse Userzentriert präsentieren.
  • Es kann natürlich auch sein dass erst beim Review gewisse Unsicherheiten diskutiert werden müssen, solche Erkenntnisse sollte das Team begrüßen, denn das ist ein wesentlicher Teil des Lernprozesses in Scrum. Dabei ist jedoch auch wieder wichtig das 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 nur aufgrund einer Meinung eines einzelnen gebaut werden.
  • Es ist aber ein schmaler Weg 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 und Product-Owner müssen auch wirklich oft nein sagen, um den Fokus der Produkt-Entwicklung bei zu halten. Steve Jobs hat mal gesagt, das Produktmanagement nicht hart ist weil man zu gewissen Sachen ja sagen muss sonder 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 oder eine Lösung zu finden.

7 PowerPointismus 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 Screenshot um Screenshot 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 die selbe Information und Emotion wie die 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 den Stakeholdern und Usern näher zu bringen.
  • Es kann auch gerne eine Live-Demo mit den Stakeholder direkt gemacht werden, die dann selbst die neuen Features erkunden und direkt ausprobieren.

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: