Software-Engineering Pattern und Antipattern: Refinement Antipattern

Inhalt:

  1. Nicht genügend Refinement
  2. Zu viel Refinement
  3. Zu detailliertes Refinement
  4. Keine Berücksichtigung der DoR
  5. Keine Vorbereitung durch PO
  6. Nicht alle Teammitglieder nehmen Teil
  7. Kein gemeinsames Verständnis
  8. Der Erzwungene Abschluss

1. Nicht genügend Refinement

Beschreibung des Antipatterns:

  • Das Team nimmt sich nicht genügend Zeit, einzelne Backlogitems zu refinen.
  • Die Qualität der Backlogitems ist nicht ausreichend und das Team weis oft nicht, was zu tun ist bzw. was das Ziel des PBIs ist.

Warum ist das schlecht?

  • Sind die PBIs zu unspezifisch und nicht gut refined, so fällt es dem Team schwer, die Komplexität und den Umfang der Items abzuschätzen.
  • Daraus resultiert dann meist, dass unzureichend beschriebene und schlecht geschätzte PBIs im Sprint-Planning verplant werden und die Sprintziele oft nicht erreicht werden.

Verbesserungen:

  • Das Team sollte regelmäßig und ausreichend Refinement-Meetings durchführen oder sich in der Sprintplanung genügend Zeit nehmen, den Sprint zu planen.
  • Es sollten nur Tickets im Sprint verplant werden, die die Definition of Ready erfüllen und wirklich vom ganzen Team gut verstanden wurden.
  • Die Schätzung sollte nach besten Wissen und Gewissen gemacht werden, um einen möglichst guten Sprint-Plan erstellen zu können. Dabei soll nicht jedes Ticket ins letzte Detail durchgeplant werden, sondern der grobe Umriss der einzelnen Tickets jedem im Team klar sein.
  • Der Scrum-Guide empfiehlt, dass das Team bis zu 10 % seiner Zeit ins Backlog-Refinement stecken sollte, um Missverständnisse zu vermeiden und teure Nachbesserungen zu verhindern

2. Zu viel Refinement

Beschreibung des Antipatterns:

  • Das Team führt zu viele Refinements durch und spezifiziert und verfeinert viel mehr Backlogitems, als es in den nächsten zwei bis drei Sprints umsetzen kann.

Warum ist das schlecht?

  • Durch das eifrige Vorarbeiten des Teams werden Themen spezifiziert und verfeinert, die eventuell nie umgesetzt werden.
  • Agile Projekte sind wendig und passen sich schnell auf die Gegebenheiten und gesammelten Lernerfahrungen an. Dadurch werden sehr schnell Features und Themengebiete obsolet und fallen wieder aus dem Backlog raus.
  • Passiert dies mit aufwendig refineten PBIs geht die in diese investierte Arbeitsleistung verloren.

Verbesserungen:

  • Das Team sollte immer nur so viel Refinement betreiben, wie es wirklich benötigt, um die nächsten zwei bis drei Sprints solide umzusetzen.
  • Sind bereits genügend Tickets durch einen Refinementprozess gelaufen und hat das Team alle Informationen um eine solide Schätzung zu erstellen, muss nicht unbedingt das Refinementmeeting durchgedrückt werden.
  • Oft vergessen die Teams aber auch, dass das Aufräumen des Backlogs und das schließen obsolet gewordener Tickets zur Aufgabe des Backlogrefinements gehört. Sollten also keine neuen Tickets mehr sinnvoll sein, kann das Team die Zeit dennoch nutzen, um Ordnung zu schaffen.
  • Ein weiterer Tipp kann es sein, gemeinsam an der Produktvision zu arbeiten und diese voranzutreiben.

3. Zu detailliertes Refinement

Beschreibung des Antipatterns:

  • Beim Refinement der einzelnen Tickets wird viel diskutiert und zu sehr in die technische Umsetzung eingetaucht.
  • Es wird jedes Ticket bis ins letzte Detail geplant.
  • Das Team diskutiert sehr lange und verläuft sich in technischen Einzelheiten.

Warum ist das schlecht?

  • PBIs und das Refinement sind dazu da, das Warum und das Was zu klären, nicht jedoch, um das Wie also die eigentliche Umsetzung zu klären.
  • Verbringt das Team zu viel Zeit mit der technischen Detailplanung, wird viel Aufwand in Tickets gesteckt. Zeit, die sich aber gegebenenfalls nicht rentiert, weil die Tickets vielleicht nie umgesetzt werden.
  • Außerdem sollte die technische Lösung des Tickets durch das Team im Sprint erarbeitet werden, Product-Owner und Scrum Master können und sollen auf dieser technischen Ebene nicht mitreden.

Verbesserungen:

  • Sobald das Was und Warum geklärt wurde, sollte das Refinement eines Tickets abgeschlossen sein. Das Team weis dann, was warum umzusetzen ist, also was das neue Feature machen soll und warum das für den User relevant ist.
  • Sollten technische Unsicherheiten vorhanden sein, so kann das Team gemeinsam mit dem Product-Owner beschließen, hierfür einen technischen Spike anzulegen. Also einen Durchstich, um technische Risiken und Ungewissheiten aus der Welt zu schaffen.
  • Für die Schätzung des Tickets sollte die Komplexität und der Umfang des Tickets in Relation zu bereits bestehenden Tickets gesetzt werden und mit Story-Points geschätzt werden. Ein genauer technischer Plan, wie das Ticket gelöst wird, sollte nicht für eine Schätzung herangezogen werden und notwendig sein.

4. Keine Berücksichtigung der DoR

Beschreibung des Antipatterns:

  • Das Scrum-Team berücksichtigt beim Refinement die DoR nicht.
  • Es wird nicht überprüft, ob alle gemeinsam beschlossenen Regeln der DoR erfüllt sind und das PBI somit wirklich refined ist.

Warum ist das schlecht?

  • Das Team hat sich beim Erstellen der Definition of Ready mit dem Product-Owner auf ein Regelset geeinigt und somit auf Bedingungen, die jedes PBI erfüllen muss, um es in einen planbaren Zustand zu bekommen. Wird dieser Zustand nicht erreicht, so führt dies zu schwierigen Bedingungen beim Planen des Sprints und gefährdet gegebenenfalls das Sprintziel.
  • Hält sich weder der Product-Owner noch das Team an diese Regeln, ist das Ergebnis des Refinements zu ungenau und zufällig.
  • Das wiederum schadet der Qualität des Backlogs und führt zu Kommunikationsproblemen und Zeitverzögerungen in der Umsetzung.

Verbesserungen:

  • Es passiert immer wieder verschiedenen Teams, dass sie die DoR aus den Augen verlieren. Das ist nichts ungewöhnliches wenn der Arbeitsalltag mehr und mehr Routine bringt und das Refinement gut in den Arbeitsalltag integriert ist.
  • Es schadet daher also nicht immer wieder die DoR hervorzuholen und in Erinnerung zu rufen.
  • Am Besten ist die DoR auch physisch auf Papier ausgedruckt und im Büro aufgehängt, sodass jeder sie bei Gelegenheit lesen kann. Oft eignet sich dafür auch ein Platz neben der Kaffeemaschine.
  • Im Idealfall achten PO und Team bei jedem Refinement darauf, dass jedes PBIs auch wirklich alle Bedingungen der DoR erfüllt.
  • Insgesamt ist es die Verantwortung des Teams die Einhaltung der DoR bei jedem PBI einzufordern, da diese auch letzten Endes sich im Sprint auf die Inhalte der PBIs committen.
  • Der PO muss dann auch die Qualität laut DoR pro PBI liefern.
  • Der Scrum-Master sollte hier unterstützend darauf achten, dass das Team diese Änderungen auch einfordert und die DoR berücksichtigt wird.

5. Keine Vorbereitung durch PO

Beschreibung des Antipatterns:

  • Der PO ist derjenige, der das Refinementmeeting organisieren und moderieren sollte, denn er weiß, welche PBIs als nächstes am höchsten priorisiert sind und steuert die Produktentwicklung anhand der Produktstrategie.
  • Somit muss der Product-Owner das Backlog bereits vor dem Refinement grob organisieren, wichtige Informationen zusammentragen und PBIs anlegen. Ein häufiges Anitpattern ist jedoch, dass sich der Product-Owner nicht genügend Zeit vor dem Refinement nimmt und somit unvorbereitet im Meeting eintrifft.

Warum ist das schlecht?

  • Bereitet der Product-Owner sich nicht oder unzureichend auf die Refinementmeetings vor, so ziehen sich die Diskussionen in die Länge.
  • Es fließt dann viel zu viel Zeit in die Abstimmungen, die Aufwände steigen und die Motivation der Beteiligten sinkt.
  • Im schlechtesten Fall durchlaufen zu wenig PBIs das Refinement und der Sprint kann nicht solide geplant werden.
  • Außerdem kann es dadurch passieren, dass Teammitglieder nicht mehr am Refinement teilnehmen wollen und können.

Verbesserungen:

  • Es braucht viel Disziplin während des Arbeitsalltags immer wieder rechtzeitig vor dem Refinement das Backlog sauber zu halten, die Prioritäten abzugleichen und PBIs anzulegen. Hier empfiehlt es sich, einen Puffer vor den Meetings einzuplanen und das Refinementmeeting vorzubereiten.
  • Die Vorbereitungszeit alleine reicht jedoch nicht aus. Es gehört zu den Aufgaben des Product-Owners ständig am Backlog zu arbeiten und das Backlog zu pflegen.
  • Das Backlog und das Refinement kann außerdem nur dann agil sein, wenn der Product-Owner ständig die aktuelle Situation beobachtet, einschätzt und aufgrund der User-Wünsche und Marktsituation die Features tagesaktuell vorbereitet und in einem der nächsten Sprints zur Umsetzung bringt.

6. Nicht alle Teammitglieder nehmen Teil

Beschreibung des Antipatterns:

  • Teammitglieder können aufgrund von terminlichen Einschränkungen nicht am Refinement teilnehmen oder sie wollen nicht teilnehmen, weil sie das Meeting für nicht sinnvoll finden.
  • Es kann auch sein, dass Manager Teammitglieder explizit ausladen, weil sie es nicht effizient finden, dass diese beim Refinement anwesend sind.

Warum ist das schlecht?

  • Sinn des Refinementmeetings ist es, ein gemeinsames Verständnis für die Aufgaben zu bekommen und um Entwurfsentscheidungen für Features zu treffen.
  • Nehmen nicht alle Teammitglieder teil, so kann dieses Verständnis nicht geschaffen werden. Informationen sammeln sich dann nur bei den Teilnehmern des Meetings.
  • Treten dann Fragen in der Umsetzung auf, so müssen jene, die nicht am Refinement teilgenommen haben, die Teammitglieder fragen, die dabei waren.
  • Dies wiederum führt einerseits zu Stille-Post-Effekte und andererseits zu Mehraufwänden.
  • Ein Verhindern der Teilnahme bestimmter Teammitglieder führt also in den seltensten Fällen zu einer Effizienzsteigerung, sondern verursacht eher Kosten.

Verbesserungen:

  • Es ist oft schwierig, einen Termin zu finden, an denen jedes Teammitglied Zeit hat, vor allem wenn Teilzeitkräfte im Team mitarbeiten.
  • Es empfiehlt sich daher, die Refinements immer am selben Tag zur selben Urzeit durchzuführen und gegebenenfalls auf Änderungen bei den Verfügbarkeiten zu reagieren.
  • Organisator des Meetings sollte der Product-Owner sein, dieser soll aber vom Scrum-Master gegebenenfalls unterstützt werden und

7. Kein gemeinsames Verständnis

Beschreibung des Antipatterns:

  • Das Team schließt das Refinement einzelner Tickets ab, ohne ein gemeinsames Verständnis für die Aufgabe gefunden zu haben.

Warum ist das schlecht?

  • Kernaufgabe des Refinements ist es, das Ticket in einen Status zu überführen, der es dem Team erlaubt das Feature in einem der nächsten Sprints zu implementieren. Hat nicht jedes Teammitglied das volle Verständnis für die Aufgabenstellung des Tickets, so führt dies später in der Umsetzung zu Problemen.
  • Es kann sein, dass dann einzelne Teammitglieder Aufgaben falsch verstanden haben, und das Feature falsch umgesetzt wird. Das wiederum ist ein starker Kostentreiber und kostet Zeit – vor allem Time to Market.
  • Durch das fehlende gemeinsame Verständnis kann es auch sein, dass die Sprintplanung nicht richtig abläuft und dadurch Fehlplanungen entstehen und letzten Endes das Sprintziel nicht eingehalten werden kann.

Verbesserungen:

  • Oft entsteht ein derartiges Antipattern, weil einige Teammitglieder sehr eingeschüchtert und zurückhaltend und andere sehr laut und extrovertiert sind. Dadurch trauen sich Teammitglieder nicht nachzufragen.
  • Es kann auch sein, dass Teammitglieder einfach nicht motiviert sind und unterm Radar fliegen wollen.
  • In beiden Fällen sollte der Scrum-Master durch geeignete Moderationstechniken versuchen, alle Teammitglieder zu beteiligen.
  • Das Team sollte auf jeden Fall sichergehen, dass jeder im Team die Aufgabe verstanden hat.
  • Am besten präsentiert der Product-Owner dazu im Refinement jedes einzelne Ticket und erklärt, welches Feature benötigt wird und warum er glaubt, dass dieses Feature benötigt wird.
  • Im Idealfall wird auch über die Features diskutiert und dadurch noch besser ein gemeinsames Verständnis entwickelt.

8. Der Erzwungene Abschluss

Beschreibung des Antipatterns:

  • Der Product-Owner übt durch Kampfrhetorik oder andere Mittel Druck auf das Team aus und verhindert somit das ein PBI einen regulären Refinementprozess durchläuft, mit der Absicht, sich selbst Arbeit zu ersparen und Tickets schneller planbar zu haben.

Warum ist das schlecht?

  • Die Eigenschaft eines Tickets planbar zu sein kann nicht erzwungen werden.
  • Genauso wenig kann der Product-Owner ein gemeinsames Verständnis für die Aufgabe erzwingen.
  • Der Product-Owner erreicht durch ein derartiges Verhalten genau das Gegenteil.
  • Durch seine Einflussnahme werden Tickets in die Planung des Sprints aufgenommen, die dann mehr Aufwände für alle und somit mehr Kosten in der Umsetzung verursachen.

Verbesserungen:

  • Der Scrum-Master muss sich in diesem Fall hinter das Team stellen und mit dem Team gemeinsam dem Product-Owner klar machen, dass ein derartiges Verhalten nicht zielführend ist.
  • Vielleicht können Win-Win-Situationen gefunden werden, indem Tickets vor dem Refinement besser vorbereitet werden und nur jene Tickets diskutiert werden, die auch wirklich im nächsten Sprint umgesetzt werden.
  • Dadurch sparen sich alle Zeit und letzten Endes werden mit dieser Strategie auch die Features schneller fertig.

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: