Software-Engineering – agile Pattern und agile 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 dazu verleitet, dass nicht alle Teammitglieder am Review teilnehmen. Als Begründung für das Fernbleiben wird oft eine bessere Effizienz verwendet. Das Team meint, es ist effizienter und zeitsparend, wenn nur einige wenige vom Review „aufgehalten“ sind. Denn Softwareentwickler wollen schließlich ohnehin lieber programmieren.
  • Dies ist aber meist ein Zeichen, dass das Review falsch gemacht wird und daher zu wenig Nutzen 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 diese wichtige Informationen.
  • Diese Informationen müssen dann nach dem Review mühsam weiterkommuniziert 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 dastehen.
  • Ihre Performance wird von den Stakeholdern als schlechter empfunden. Dieser Eindruck kann zu Problemen in der Beziehung zwischen Teammitgliedern und den Stakeholdern führen.
  • Zusätzlich lässt dieses Antipattern auch das gesamte Team schlechter aussehen, wenn einige Teammitglieder ohne jegliche 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 mitzubekommen, sich an Diskussionen beteiligen zu können und Lernerfahrungen machen zu können.
  • Das Team hat eine Shared-Ownership über das 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ückhalten dieses Thema ansprechen und dafür sorgen, dass alle ihr bestes geben und sich nach bestem 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 umzusetzen und 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 der folgenden Probleme ein.
  • Stakeholder glauben dann, dass 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 aus Fehlern gelernt und in Zukunft das Vorgehen 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 unfertige 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, Features abzunehmen und Releases freizugeben.
  • So werden bei „erfolgreichen“ Sprints, also jenen, die für die Stakeholder erfolgreich aussehen, formelle Abnahmen gemacht und beispielsweise Freigaben für Releases erteilt.
  • 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 zur Zufriedenheit der Stakeholder umgesetzt wurden.
  • Dieses Antipattern ist direkt verlinkt mit anderen Antipattern die agile und plangetriebene Vorgehensmodelle verschmelzen, wie beispielsweise dem Scrummerfall oder dem Waterscrum.

Warum ist das schlecht?

  • Wird von den Stakeholdern so vorgegangen, so macht das Team kein Scrum und geht auch nicht wirklich agil vor.
  • Ein derartiges Antipattern 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 so 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 (ein weiteres Antipattern, sie Beschreibung Proxy-Product-Owner)

Verbesserungen:

  • Hier muss das Team und der Scrum-Master das gesamte Set-up wie Scrum aufgebaut ist, neu ausrichten.
  • Es muss ein ordentlicher Scrum-Prozess modelliert 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 kann das Release vom Product-Owner veranlasst werden. Eine Zustimmung von Stakeholdern soll und darf hier nicht mehr notwendige sein.

4 Fehlende Stakeholder im Review

Beschreibung des Antipatterns:

  • Dieses Antipattern zeichnet sich dadurch aus, dass am Review keine Stakeholder und Key-User teilnehmen oder die Stakeholder nur sehr sporadisch teilnehmen, wenn sie gerade Zeit haben.

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 Informations- und Feedbackquelle, sollten aber andererseits „mit ins Boot geholt werden“ und vom Team auf den neuesten Stand der Umsetzung gebracht werden.
  • Der Hauptzweck von Reviews ist einerseits das Sammeln von Feedback der Stakeholder und andererseits das Schaffen einer Vertrauensbasis. Die Stakeholder sollen durch die Review-Meetings die Möglichkeit haben, Feedback einzumelden, gleichzeitig aber auch über den Projektfortschritt begeistert werden. Wird kein Feedback gesammelt, kann sich das Produkt in eine falsche Richtung entwickeln. Teure Rückbauten oder Korrekturen können entstehen.
  • Für die Vertrauensbasis ist ein Fehlen wichtiger Stakeholder wie Sponsoren, Manager etc. ebenfalls schlecht. Einerseits kann das Vertrauen der Stakeholder in die Kompetenzen des Teams leiden, andererseits kann das Team auch dem Management und den Stakeholdern misstrauen. Dies führt zu Konflikten und kann Mitarbeiterfluktuation und hohe Kosten verursachen.
  • Daher lässt ein Fernbleiben wichtiger Stakeholder darauf schließen, dass das Projekt außerdem zu schlecht „vermarktet“ wurde oder einen zu geringen Stellenwert in der Organisation hat. Es ist jedoch entscheidend, dass es den Entscheidern bewusst ist, dass das Projekt und Produkt wichtig ist. Fehlt die Unterstützung vom Management und Key- Stakeholdern, kann es schneller zu organisatorischen und wirtschaftlichen Problemen für das Projekt kommen – das Projektrisiko steigt.
  • Es kann auch sein, dass das Reviewmeeting zu wenig Mehrwert für die Stakeholder liefert. Dies kann dann oft mit anderen Anitpattern wie dem Roadshow-Antipattern zusammenhängen und.

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 wiederum muss dafür eintreten, 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 User 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 sich, durch die Teilnahme Externer am Meeting, 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 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, und ein gemischtes Review mit internen und externen Stakeholdern als unangenehm wahrgenommen wird. 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 zu unangenehm erweisen, kann das Review auch aufgeteilt werden, so haben interne und externe Bedürfnisse platz. Oder es werden zusätzlich zum Review auch Feedbackgespräche mit echten Usern durchgeführt.
  • Sollten extra Feedbackgespräche durchgeführt werden, so sollte das Team aber an diesen Gesprächen ebenfalls teilnehmen, denn dadurch können die Informationen des Feedbacks auch wirklich ohne Kommunikationsbarrieren weitergegeben werden.

6 Wechselnde Stakeholder

Beschreibung des Antipatterns:

  • Bei diesem Antipattern gehen regelmäßig wichtige Stakeholder wie Sponsoren, Manager, oder Key-User verloren oder wechseln sich mit anderen Kollegen ab. Dies hat negative Folgen für das Projekt und die Produktentwicklung.

Warum ist das schlecht?

  • 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.
  • Gibt es zu viel Fluktuation bei den Stakeholdern, muss das Team immer wieder dieselben 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 Onboarding neuer Stakeholder zu beschleunigen, können Einführungsdokumente und Videos abseits des Reviews gemacht werden.
  • Dabei kann auf vorhandene Dokumentation zurückgegriffen werden, die ohnehin für den User gemacht werden muss. Denn 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. Es lässt sich auch beobachten, dass diese Stakeholder dann oft auch zu spät zum Review kommen. Dieses Antipattern erkennt man oft auch daher, weil es mit anderen, hier beschriebenen Antipattern kombiniert auftaucht.

Warum ist das schlecht?

  • Stakeholder sind die Hauptquelle für Feedback und Ideen zu bestehenden und neuen Features.
  • Sie sind oft auch schwer und teuer zu organisieren, deswegen sollten sie effektiv und effizient eingesetzt werden und dementsprechend sollte auch das Review gut organisiert und moderiert 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.
  • Ein Fernbleiben wichtiger Stakeholder kann dann auch verstärkt zu Konflikten führen bzw. die Entstehung von Konflikten begünstigen.

Verbesserungen:

  • Stakeholder sollten beim Review in die Verantwortung genommen und gefordert werden.
  • Es können beim Review auch gerne richtige Diskussionen entstehen. Damit dies passiert, sollte der Product-Owner oder das Team die Diskussion anstoßen, aktiv nachfragen und Stakeholder auch direkt ansprechen.
  • Das Review kann auch aufgelockert werden, indem Stakeholder die Software mal selbst ausprobieren und somit gleich selbst spüren und testen können, wie sich das eine oder andere Feature verhält. Das schafft Insights und liefert eine wichtige Grundlage für die nächsten 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 einzelne Features präsentieren.
  • Stakeholder können von Stand zu Stand ziehen und sich die unterschiedlichsten Features zeigen lassen und mit dem Standbetreiber darüber diskutieren.

Mehr agile Antipattern und Scrum Antipattern lesen Sie im Buch „100+ agile Antipattern“

100+ agile Antipattern – Ein Rezept, um jedes agile Projekt zum Scheitern zu bringen (oder zu retten) ab € 9,99 auf Amazon kaufen (affiliate-Link)

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: