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

Inhalt:

  1. Immer die selben Gesichter
  2. Faken oder Cheaten
  3. Review Sprint-Gate
  4. Fehlende Stakeholder im Review
  5. Fehlende Kunden im Review
  6. Wechselnde Stakeholder
  7. Passive Stakeholder im Review

1 Immer die selben Gesichter

Beschreibung des Antipatterns:

  • Beim Sprint-Review sind nicht alle Teammitglieder anwesend. Einige fehlen immer oder sind nur sporadisch anwesend.
  • In Präsentationen oder Diskussionen halten sich einige Teammitglieder immer zurück und beteiligen sich kaum.
  • Oft sind Scrum-Teams auch verleitet dazu, dass nicht alle Teammitglieder am Review teilnehmen. Als Begründung dafür wird oft Effizienz verwendet. Das Team meint es ist effizienter, wenn nur einige wenige vom Review aufgehalten sind. Und Softwareentwickler wollen schließlich ohnehin lieber Programmieren. Dies ist aber meist ein Zeichen dass das Review falsch gemacht wird und daher zu wenig Nutzten stiftet.

Warum ist das schlecht?

  • Das Review ist ein ideales Meeting um Insights, Feedback und Ideen zu bekommen und vor allem um zu lernen.
  • Fehlen einige Teammitglieder verpassen dies wichtige Informationen.
  • Diese Informationen müssen dann nach dem Review mühsam weiter kommuniziert werden, was wiederum zu Informationsverlusten und Mehraufwänden führt.
  • Beteiligen sich einige Mitglieder des Teams nicht stark genug oder sogar gar nicht, so lässt sie dies schnell in einem falschen Licht stehen.
  • Ihre Performance wird von den Stakeholder als schlechter empfunden und dies kann zu Problemen in der Beziehung mit den Stakeholdern führen.
  • Es lässt auch das gesamte Team schlechter aussehen wenn einige Teammitglieder ohne jeglicher Beteiligung am Review Teilnehmen.

Verbesserungen:

  • Das Review sollte von allen Teammitgliedern gleichermaßen mit leben befüllt werden.
  • Jedes Teammitglied muss verpflichtend beim Review teilnehmen, um somit auch notwendige Informationen und Feedback zu bekommen, sich an Diskussionen beteiligen zu können und Lernerfahrungen machen zu können.
  • Das Team hat eine Shared-Ownership über da Produkt und das Sprintziel und muss somit auch gemeinsam das Review durchführen.
  • Die Mitarbeit am Review kann zwar nicht erzwungen werden, der Scrum-Master sollte aber, wenn er bemerkt, dass einige Teammitglieder sich zurück halten dieses Thema ansprechen und dafür sorgen, dass alle ihr bestes geben und sich nach besten Maße beteiligen.

2 Faken oder Cheaten

Beschreibung des Antipatterns:

  • Das Umsetzungsteam schummelt bei den Ergebnissen die es präsentiert.
  • Es werden Features so hingebogen dass sie gerade noch herzeigbar sind, obwohl wichtige Funktionalität nicht vorhanden ist, oder massiv an der Qualität gespart wurde.
  • Die Tickets die präsentiert werden erfüllen nur teilweise oder gar nicht die Definition of Done.
  • Oft hat das Team bei der Umsetzung massive technische Schulden angehäuft um noch das eine oder andere Feature präsentieren zu können.

Warum ist das schlecht?

  • Werden Features als fertig präsentiert, sind es aber nicht, so kauft sich das Team viele folgende Probleme ein.
  • Stakeholder glauben dann das der Produktfortschritt weiter ist, als er in Wirklichkeit ist. Die zusätzliche Arbeit muss aber noch gemacht werden da die Software in einen halb fertigen Zustand nicht veröffentlicht werden kann. So kann ein Teufelskreis entstehen in dem mehr und mehr Arbeit angestaut wird, die dann heimlich wieder im Nachhinein gemacht werden muss.
  • Fliegt zu einem späteren Zeitpunkt dann der Schwindel auf, so fällt das Team in Misskredit. Die Glaubwürdigkeit ist dann dahin und die Stakeholder und der Product-Owner werden gezwungen mehr und mehr zu hinterfragen.
  • Agile Methoden und Scrum basieren aber auf einem Vertrauensverhältnis. Bröckelt dieses Vertrauen, dann kann nicht mehr agil vorgegangen werden. Es werden mehr Arbeiten vorgeplant, kontrolliert und gesteuert.

Verbesserungen:

  • Tickets die die Definition of Done nicht erfüllen, dürfen nicht im Review präsentiert werden.
  • Nicht fertiggestellte Tickets sollten diskutiert werden. Nur so kann gelernt und adaptiert werden.
  • Das Team sollte den Stakeholdern und dem Product-Owner gegenüber immer ehrlich sein und den aktuellen Umsetzungsstand wiedergeben.
  • Es kann durchaus auch von Zeit zu Zeit sinnvoll sein den Stakeholdern, Usern und Product-Owner nicht fertige Features zu präsentieren. Nämlich dann wenn frühzeitig Feedback gesammelt werden soll. Das ist vor allem bei umstrittenen Features und neuartigen Features interessant.

3 Review Sprint-Gate

Beschreibung des Antipatterns:

  • Das Sprint Review wird von den Stakeholdern dazu verwendet Abnahmen durchzuführen und Freigaben zu machen.
  • So werden bei „erfolgreichen“ Sprints, also jenen die für die Stakeholder erfolgreich aussehen formelle Abnahmen gemacht und beispielsweise Freigaben für Releases vorgenommen.
  • Das Team darf nur dann Releases durchführen wenn diese formal von den Stakeholdern freigegeben wurden. Es darf auch nur dann an neuen Themen weiterarbeiten wenn alle Tickets so umgesetzt wurden wie es den Stakeholdern passt.
  • Dieses Antipattern ist direkt verlinkt mit anderen Antipattern die agile und plangetriebene Vorgehensmodelle verschmelzen, wie beispielsweise den Scrummerfall oder den Waterscrum.

Warum ist das schlecht?

  • Wird so vorgegangen, so macht das Team kein Scrum und geht auch nicht wirklich agil vor.
  • Ein derartiges Vorgehen untergräbt alles wofür Scrum und agile Vorgehensmodelle stehen.
  • Das Team kann nicht autonom arbeiten, darf scheinbar auch keine eigenen Entscheidungen treffen und ist voll und ganz abhängig von Linienmanagern oder anderen wichtigen Stakeholdern.
  • Diese Situation ist deswegen auch noch doppelt schlecht weil die Stakeholder hier immer zischen den beiden verschiedenen Ansätzen hin und her wechseln können. Ist etwas kompliziert oder nicht so einfach zu lösen, hört das Entwicklungsteam schnell den Vorwurf „warum es nicht agil arbeitet“. Werden Vorschläge gemacht die den Stakeholdern nicht passen können diese die Ideen einfach ausschlagen und ihre Macht ausspielen.
  • Für den Product-Owner ist diese Situation auch sehr unangenehm weil er immer zwischen den Fronten steht und eigentlich nur als Product-Owner Proxy agiert (weiters Antipattern, sie Beschreibung Proxy Product Owner)

Verbesserungen:

  • Hier muss das Team und der Scrum-Master das gesamte Setup wie Scrum aufgebaut ist neu ausrichten.
  • Es muss ein ordentlicher Scrum-Prozess gemacht werden, bei dem Sprintziele im Planning formuliert und geplant werden und das Team im Sprint autonom auf diese hinarbeiten kann. Sind diese dann im Review erreicht, so können diese vom Product-Owner released werden. Eine Zustimmung von Stakeholdern soll und darf hier nicht mehr notwendige sein.

4 Fehlende Stakeholder im Review

Beschreibung des Antipatterns:

  • Es nehmen am Review keine Stakeholder und Key-User teil, oder die Stakeholder nehmen nur sehr sporadisch teil wenn gerade Zeit ist.

Warum ist das schlecht?

  • Stakeholder bestehen aus Key Usern, Managern und Sponsoren/Geldgebern des Projekts, und allen anderen möglichen beteiligten. Sie dienen einerseits als wichtige Informationsquelle, sollten aber andererseits „ins Boot geholt werden“ und vom Team auf den neuesten Stand der Umsetzung gebracht werden.
  • Reviews sind dazu da Feedback von den Stakeholdern zu sammeln. Sind keine Stakeholder da so kann auch nichts gelernt und verbessert werden.
  • Eine fehlen wichtiger Stakeholder wie Sponsoren, Manager etc. lässt darauf schließen, dass das Projekt zu schlecht „vermarktet“ wurde. Es ist entscheidend, dass es den Entscheidern bewusst ist, dass das Projekt und Produkt wichtig ist. Da es sonst zu Problemen für das Projekt und das Produkt kommen kann die organisatorischer Natur sind.
  • Es kann auch sein, dass das Event des Reviews auch einfach zu wenig Mehrwert für die Stakeholder liefert. Dies kann dann oft mit anderen Anitpattern wie dem Roadshow-Antipattern zusammenhängen.

Verbesserungen:

  • Zunächst muss festgestellt werden ob alle Stakeholder auch wirklich zum Review eingeladen werden, oder ob ein anderes Antipattern hinter diesem Symptom steckt.
  • Es muss eruiert werden ob die Stakeholder dem Projekt keine Bedeutung zumessen oder ob sie keinen oder zu wenig Sinn in der Teilnahme am Review sehen.
  • Der Scrum-Master und der Product-Owner sind in dieser Situation auf jeden Fall gefragt. Der Scrum-Master muss dafür sorgen dass das Review effizient abläuft und auch alle beteiligten einen Mehrwert darin erkennen. Der Product-Owner muss dafür sorgen dass wichtige Entscheider vom Review wissen, daran teilnehmen können und auch die Wichtigkeit im Projekt und Produkt erkennen.

5 Fehlende Kunden im Review

Beschreibung des Antipatterns:

  • Das Team und der Product-Owner laden zum Review immer nur den selben kleinen Internen Personenkreis ein, externe Stakeholder und Unser werden nicht zum Review geladen.
  • Oft ist es für den Product-Owner oder das Scrum-Team organisatorisch zu kompliziert User und externe in das Meeting einzuladen, oder es fehlt auch die Motivation weil durch die Teilnahme Externer am Meeting sich die Dynamik der Diskussion und Präsentation ändert und dies oftmals als anstrengen wahrgenommen wird.

Warum ist das schlecht?

  • Nehmen keine User am Review teil, so wird immer nur die interne Sicht auf das Produkt repräsentiert. Die externe Sicht fehlt, und das wertvollste Feedback, nämlich das von den echten Usern kann nicht gesammelt werden.
  • Ein Unausgewogenes Feedback mit Schwerpunkt auf interne Bedürfnisse führt dazu, dass sich das Produkt in eine falsche nach innen gewandte Richtung entwickelt. Das geht zu lasten der Usability und der User-Experience

Verbesserungen:

  • Es ist durchaus nachvollziehbar dass gewisse Diskussionen intern besser funktionieren, als wenn das Review mit internen und externen Stakeholdern gemischt ist. Nichts desto trotz sollte das Feedback durch User wichtig genommen werden und einen Platz haben. Es empfiehlt sich also das Review mit gemischten Stakeholdern (sowohl internen als auch externen) durchzuführen.
  • Sollte das nicht möglich sein oder sich als unangenehm erweisen, kann das Review auch aufgeteilt werden. Oder es werden zusätzlich zum Review auch Feedbackgespräche mit echten Usern durchgeführt.
  • Sollten extra Feedbackgesprächen durchgeführt werden, so sollte aber das Team an diesen Gesprächen ebenfalls teilnehmen, um auch wirklich ohne Kommunikationsbarrieren die Information weiter zu geben.

6 Wechselnde Stakeholder

Beschreibung des Antipatterns:

  • Starke Fluktuation ist nicht nur im Scrum-Team ein Problem, auch wenn sie bei den Stakeholdern auftritt, kann es zu negativen Konsequenzen für die Produktentwicklung kommen.
  • Gibt es bei wichtigen Stakeholdern und Feedback-Gebern bzw. Sponsoren der Produktentwicklung zu häufig wechsel, ist dies ein negatives Zeichen. Es muss dann in den Reviews vermehrt diskutiert werden und das zeichnet dieses Antipattern aus.
  • Mit jedem wechsel bei den Stakeholdern geht leider auch etwas tiefe im Feedback verloren, denn neue Stakeholder können nicht sofort in der gewohnten tiefe Feedback geben und müssen sich erst einarbeiten.

Warum ist das schlecht?

  • Gibt es zu viel Fluktuation bei den Stakeholdern, muss das Team immer wieder die selben dinge neu erklären und die Stakeholder mit ins Boot holen.
  • Das kostet dem Team zeit und führt oft in Reviews zu Diskussionen.
  • Im schlimmsten Fall werden gewisse Entscheidungen die bereits viel früher im Projekt entschieden wurden hinterfragt, diskutiert und umentschieden. Das ist dann ein Risiko für die gesamte Produktentwicklung.

Verbesserungen:

  • Das Team wird nicht verhindern können, dass es bei den Stakeholdern hin und wieder mal einen Wechsel geben kann. Es muss sich also Strategien überlegen wie es den Mehraufwand so gut es geht gering hält.
  • Es kann beispielsweise sehr hilfreich sein wichtige richtungsweisende Entscheidungen die durch die Stakeholder und deren Feedback ausgelöst wurden, in einen Decision-Log zu protokollieren.
  • Um das Onboading neuer Stakeholder zu beschleunigen können Einführungen und Videos abseits des Reviews gemacht werden und dabei auf vorhandene Dokumentation zurückgegriffen werden die eigens für derartige fälle Vorbereitet ist. Eine gute User-Doku und Projektdokumentation ist generell nie eine schlechte Idee solange nicht zu viel Aufwand in die Dokumentation gesteckt wird.
  • Um Risiken zu minimieren sollte das Team auf jeden Fall versuchen alle neuen Stakeholder so schnell es geht ins Boot zu holen und von der Produktidee zu begeistern, das ist die Aufgabe des Product-Owners.
  • Damit neue Stakeholder auch mit der Arbeitsweise, den Meetings und deren Ablauf vertraut sind sollte der Scrum-Master, das agile Wissen und das Scrum-Wissen der neuen Stakeholder frühzeitig abklären und gegebenenfalls coachen und educaten.

7 Passive Stakeholder im Review

Beschreibung des Antipatterns:

  • Passive Stakeholder nehmen zwar am Review teil, sind aber eher teilnahmslos und geben kaum Feedback.
  • Oft zeigt sich diese Teilnahmslosigkeit auch indem sie dem Review nicht die Bedeutung zumessen die es eigentlich bräuchte. Sie kommen oft auch zu spät oder man erkennt dieses Antipattern weil es mit anderen hier beschriebenen Antipattern auftaucht.

Warum ist das schlecht?

  • Stakeholder sind die quelle für Feedback und Ideen für neue Features.
  • Sie sind oft auch schwer und teuer zu organisieren, deswegen sollten sie effektiv und effizient eingesetzt werden.
  • Ist einem Stakeholder offensichtlich das Review zu langweilig und beteiligt sich dieser zu lange nicht an den Reviews so kann es sein dass er sich überflüssig fühlt und zum nächsten Review nicht mehr kommen wird.

Verbesserungen:

  • Stakeholder sollten beim Review in die Verantwortung genommen werden und gefordert werden.
  • Es sollten richtige Diskussionen entstehen. Damit dies passiert sollte der Product-Owner oder das Team die Diskussion anstoßen, aktiv nachfragen und Stakeholder auch gerne direkt ansprechen.
  • Das Review kann auch aufgelockert werden indem Stakeholder mal selbst die Software testen und somit gleich selbst spüren und testen können wie sich das eine oder andere Feature verhält. Das schafft insight und liefert eine wichtige Grundlage für nächste Entscheidungen.
  • Eine weitere Idee wäre es ein Review mal wie eine Art Messe zu veranstalten, bei der sich auf verschiebenden Messeständen die Teammitglieder platzieren und Stakeholder von Stand zu stand ziehen und sich die unterschiedlichsten Features zeigen lassen und darüber diskutieren können.

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: