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

Inhalt:

  1. Der Abwesende PO
  2. Scope-Creep-PBIs
  3. Unflexible Akzeptanzkriterien
  4. PBI Abnahmeverzögerung
  5. Missbrauch von Sprintabbrüchen
  6. Fehlende Bereitschaft zum Sprintabbruch

Sprint – Antipattern

Beschreibung des Antipattern

  • Das Team hat Fragen die nur der Product-Owner beantworten kann, dieser hat aber sehr wenig Zeit und ist meist nicht oder nur schwer zu erreichen.
  • Meist ist dieser abwesende Product-Owner auch nicht regelmäßig bei Scrum-Meetings dabei. Gerade Refinement-Meetings und Plannings sind jedoch essentiell für das erfolgreiche Durchführen von Scrum.

Warum ist das schlecht?

  • Meist werden PBIs nicht bis ins letzte Detail hinein spezifiziert, weil dies die Agilität des Projekts nehmen würden und der Aufwand somit zu sehr upfront gemacht werden würde. Daher bleiben oft Details und Fragen offen, die dann agil „on-the-fly“ geklärt werden müssen.
  • Kann das Team jedoch die notwendigen Entscheidungen oder Antworten nicht durch den PO zeitgerecht bekommen, so muss sich das Team etwas überlegen. Meist wird dann kurzfristig ein anderes PBI im Sprint angefangen, oder es wird ein zusätzliches PBI in den Sprint gezogen.
  • Das sind jedoch beides Verhaltensweisen die nicht erwünscht sind und ebenfalls negative Konsequenzen haben, weil dies meist zu Multitasking führt und somit die Fehlerrate steigert und die Effizienz mindert.
  • Werden die benötigten Entscheidungen nicht getroffen kann dies zu einem erhöhten Risiko für das Projekt, das Produkt und das Sprintziel führen.

Verbesserungen:

  • Da die Abwesenheit des Product-Owners zu negativen Konsequenzen wie Multitasking, Effizienzverlust führt und das Sprintziel gefährdet ist es notwendig, dass der Product-Owner sich seiner Aufgabe bewusst wird und sich explizit Zeit nimmt
  • Der Product-Owner sollte wenn es geht möglichst gut und einfach erreichbar für das Team sein.
  • Es kann hilfreich sein wenn sich das Team mit dem Product-Owner Zeiten ausmacht, zu denen sie den Product-Owner gut erreichen können.
  • Es kann auch ein Teamkalender geteilt werden in dem jedes Teammitglied inklusive Product-Owner und Scrum-Master ihre Anwesenheitszeiten eintragen.
  • Sollte der Product-Owner seine Rolle falsch verstanden haben muss der Scrum-Master mit ihm über seine Rolle sprechen.
  • Es sollten auf jeden Fall regelmäßige Refinement-Meetings eingeplant und abgehalten werden um die Groben vorarbeiten gemeinsam mit dem Product-Owner zu machen.

Beschreibung des Antipattern

  • Dieses Anti-pattern bedeutet, dass sich die PBIs die im Sprint-Planning geplant wurden und bereits im Sprint in der Umsetzung befinden oder noch umgesetzt wurden verwändern, und der Umfang der PBIs erweitert wird.
  • Meist ist für diesen Scope-Creep ein Product-Owner dafür verantwortlich. Es kann jedoch auch sein dass ein Stakeholder druck aufs Team ausübt und den Umfang des PBIs erweitern möchte.
  • Meist werden dazu aussagen gemacht wie: „Diese Kleinigkeit kannst du doch jetzt auch gleich dazuprogrammieren, dann ist das in einem Aufwischen gleich erledigt.“

Warum ist das schlecht?

  • dieser Scope-Creep führt dazu, dass sich die geplante Zeit von PBIs massiv erhöht und sich dadurch der Plan des Sprints verändert.
  • Es wird mehr Zeit für die Scope-Creep Items benötigt, Zeit die an einer anderen Stelle im Sprint fehlt. Dadurch können ggf. wichtige anderer PBIs nicht fertig gestellt werden.
  • Im schlimmsten Fall kann das Sprint-Ziel nicht eingehalten werden.

Verbesserungen:

  • Zunächst muss klar sein werden Scope-Creep verursacht. Sind die Verursacher Stakeholder wie beispielsweise disziplinär Vorgesetzte, so kann das Team den Ball an den Product-Owner spielen.
  • Der Product-Owner muss im Falle Scope-Creeps durch einen Stakeholders diesen über die Arbeitsweise aufklären und entscheiden wie er mit den Änderungswünschen des Stakeholders umgehen soll.
  • Ist der Verursacher des Scope-Creeps der Product-Owner selbst, so muss der Scrum-Master mit diesem reden. Entweder wird das Thema in der nächsten Retrospektive angesprochen, oder es wird sofort ein klärendes Gespräch zwischen PO, Scrum-Master und Team organisiert.
  • In vielen Fällen von Scope-Creep steckt Unwissenheit und eine Art von Ungeduld vom Verursacher. Unwissenheit kann durch eine Schulung des Verursachers in agile Methoden und Scrum abgeholfen werden. Ungeduld bedarf eines klärenden Coaching-Gesprächs.
  • Ab und zu muss das Team sich aber überlegen, ob sich das schlagen der Schlacht lohnt. Es gibt Situationen, bei denen ist ein leichtes abändern der Anforderungen eines PBIs durchaus nachvollziehbar, und strategisch sinnvoll. In jeden Fall soll das Team und der Product-Owner hinterfragen, warum diese Abänderung in den Augen des Verursachers notwendig ist.
  • Wichtig zu erwähnen ist auch, dass ab dem Zeitpunkt an dem das PBI im Sprint verplant wurde nicht mehr der PO ausschließlich für das PBI verantwortlich ist, sondern das Team mit verantwortlich ist, und dementsprechend auch mit bestimmen kann.

Beschreibung des Antipattern:

  • Es kommt immer wieder mal vor, dass sich während des laufenden Sprints neue Gegebenheiten ergeben und das Team neue Erkenntnisse gewinnt.
  • Dabei kann es vorkommen dass bei einigen PBIs die Akzeptanzkriterien nicht mehr passen und die im PBI beschriebenen Aufgaben nicht mehr sinnvoll sind.
  • In diesem Fall sollte das Team die Möglichkeiten haben Akzeptanzkriterien des PBIs neu zu verhandeln. Es kommt aber immer wieder mal vor dass der Product-Owner dies nicht zulassen will.

Warum ist das schlecht?

  • Nicht veränderbare PBIs und Akzeptanzkriterien bringen das Team in eine ungute Situation. Es ist nicht sinnvoll das PBI wie ursprünglich geplant umzusetzen.
  • Beharrt der Product-Owner dennoch auf die Umsetzung so ist dies ein starkes Zeichen eines Output getriebenen Product-Owners
  • Output getriebene Teams sind stark dafür anfällig Ressourcen zu verschwenden und Produkte zu produzieren die der User nicht oder nur teilweise braucht.
  • Das blinde befolgen von Vorgaben ohne Rücksicht auf den Outcome, verletzt außerdem alle agilen Prinzipen und den Kern für was Scrum steht.

Verbesserungen:

  • Der Product-Owner sollte flexibel sein, wenn es um Abänderungen der PBIs geht.
  • Sind die Änderungen nicht zu stark so sollten sie zugelassen werden.
  • Es können beispielsweise PBIs auch aufgeteilt werden in die abgeänderte Variante und zusätzliche teile die es noch zu lösen gilt.
  • Sollte es jedoch zu oft vorkommen, dass PBIs und Akzeptanzkriterien angepasst werden müssen, so sollten Refinement-Meetings eingeführt oder besser gemacht werden.
  • Wenn sich zentrale PBIs des Sprints ändern und damit das Sprintziel sich verschiebt so muss der Sprint gegebenenfalls abgebrochen werden – auch wenn dies nur in den aller seltensten fällen vorkommen sollte.
  • In jeden Fall ist auf die Planung und Verfeinerung der zukünftigen PBIs zu achten.

Beschreibung des Antipattern:

  • Der Product-Owner nimmt sich während des Sprints nicht Zeit bereits fertiggestellte PBIs abzunehmen oder verweigert die Abnahme mit Hinweis auf das Sprint-Review.

Warum ist das schlecht?

  • Obwohl es Refinement-Meetings und Akzeptanzkriterien gibt kann es dennoch vorkommen dass das Team das PBI falsch verstanden hat.
  • Gibt der Product-Owner zu einem bereits fertigen PBI kein Feedback so kann es sein dass zu Sprintende das böse Erwachen kommt und einige Teile des PBIs vom Team falsch verstanden wurden.
  • Durch das fehlende Feedback werden PBIs vom Team als fertig gesehen. Diese PBIs haben jedoch noch unerledigte Aufgaben. Wird dieser Umstand erste zu Sprintende entdeckt entstehen erheblich mehr Aufwände als wenn gleich während des Sprint das Feedback erfolgt wäre.
  • Sind zu viele PBIs nur halb fertig und werden diese erst zu Sprintende kontrolliert, so scheitert der Sprint höchst wahrscheinlich.
  • Wird das Feedback also erst zu Sprintende gegeben werden die PBIs zurückgewiesen und müssen im nächsten Sprint verbessert werden. Die erhöht die Cycle-time der neuen Features auf mindestens 2 Sprints.
  • Es kann somit auch erst viel später „echtes“ Feedback vom Markt und den Usern eingeholt werden.

Verbesserungen:

  • Der Product-Owner sollte immer so bald als möglich die fertigen PBIs überprüfen und Feedback dazu geben.
  • Je früher das PBI abgenommen werden kann umso besser ist es für das Team. Das Team weiß dann dass es bei dieser Aufgabe keine weiteren Arbeiten mehr zu erledigen hat.
  • Sollte es noch unerledigte Aufgaben geben oder es zuvor Missverständnisse gegeben haben, so können diese mit relativ geringem Aufwand eingebaut oder verbessert werden.
  • Das frühe Feedback spart Zeit und Kosten und ermöglicht einen erfolgreichen Sprintabschluss.

Beschreibung des Antipattern:

  • Der Product-Owner bricht den Sprint ohne vorherige Absprache mit dem Team und ohne erklärbare objektive Gründe ab.
  • Meist steckt hinter diesem Verhalten ein schwehlender Konflikt oder eine schwierige Zusammenarbeit zwischen dem Team und dem Product-Owner

Warum ist das schlecht?

  • Ein Abbrechen des Sprints ohne ersichtliche Gründe für das Team führt zu Verwunderung und gegebenenfalls zu einer Verschlechterung der Beziehung zwischen Product-Owner und dem Team
  • Zu viele Sprintabbrüche lassen das gesamte Team einschließlich des Product-Owners schlecht aussehen.

Verbesserungen:

  • Da es bei solch unvorbereiteten und nicht objektiv nachvollziehbaren Sprintabbrüchen meist um ein Kommunikations- und Beziehungsproblem geht, muss in diesem Fall der Scrum-Master als Coach einspringen
  • Das gesamte Scrum-Team (inkl. Product-Owner) sollte sich in einer Retrospective überlegen wie es den gemeinsamen Umgang pflegen mag.
  • Es ist prinzipiell richtig dass ausschließlich der Product-Owner das Privileg hat den Sprint abzubrechen. Jedoch sollte dieser das nicht ohne vorherige absprache mit dem Team machen.
  • Generell ist es eine schlechte Kommunikationsstrategie das Team vor vollendete Tatsachen zu stellen.
  • Bezieht der Product-Owner das Team mit ein kann dieses gegebenenfalls gemeinsam mit dem Product-Owner Mittel und Wege finden das Sprintziel noch zu erreichen oder Abzuändern.

Beschreibung des Antipattern

  • Der Product-Owner oder das Team ist nicht bereit eine Sprint abzubrechen, obwohl es bereits bekannt ist dass das Sprintziel nicht mehr erreicht werden kann/soll.
  • Es kann sein dass der Product-Owner sich denkt dass der Sprint bereits so weit fortgeschritten ist dass ein Abbruch jetzt auch nicht mehr wichtig ist.
  • Oder dass der Product-Owner das Wissen über das bereits obsolet gewordene Sprintziel dem Team vorenthält.
  • Ab und zu kann es jedoch auch sein, dass der Product-Owner das Sprintziel abbricht, das Team sich jedoch denkt dass „nur mehr eine Kleinigkeit“ gemacht werden muss um das Ticket umzusetzen und es daher heimlich weiter am Ticket und am alten Sprintziel weiterarbeitet.

Warum ist das schlecht?

  • Es kommt immer wieder mal vor, dass ein Sprintziel obsolet wird und nicht mehr erreicht werden muss.
  • In diesen Fällen wäre ein weites Beharren auf dem Sprintziel und ein Weiterimplementieren an den PBIs des Sprints verschwendete Zeit.
  • Jeder Aufwand der nach dem bekannt werden des obsoleten Ziels gemacht wird ist reinste Zeitverschwendung. Eine Verschwendung wertvoller Ressourcen und Zeit die in andere Ziele besser investiert wären.

Verbesserungen:

  • Sprintabbrüche sind nicht lustig. Keiner erfährt gerne dass die Arbeit, die in den letzten Tagen gemacht wurde sinnvoll ist.
  • Umso wichtiger ist es dass der Product-Owner und das Team den Sprint möglichst frühzeitig abbrechen und sich auf neue Aufgaben fokussieren.
  • Der Product-Owner sollte möglichst sofort nach Kenntnisname des obsoleten Ziels mit dem Team ein Meeting einberufen und das Team über den Sprintabbruch informieren.
  • Der Product-Owner und der Scrum-Master sollten dabei sichergehen dass sich das gesamte Team gut informiert fühlt, versteht warum der Sprint abgebrochen werden muss und auch wirklich den Sprint abbricht.
  • Das Team bereitet dann alle noch offenen PBIs und alle PBIs an denen gerade gearbeitet wird für den Sprintabbruch vor. Die obsolet gewordenen PBIs werden sofort abgebrochen und zurückgestellt. Die noch offenen/halbfertigen PBIs werden in einen Zustand gebracht in dem sie entweder Teilweise abgeschlossen werden können oder in dem sie zumindest leicht in den nächsten Sprint übernommen werden können
  • Am besten wird der Sprintabbruch dann in einem gemeinsamen Sprint-Review und einer Retrospektive abgeschlossen.

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: