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

Inhalt:

Der Abwesende PO
Scope-Creep-PBIs
Unflexible Akzeptanzkriterien
PBI Abnahmeverzögerung
Missbrauch von Sprintabbrüchen
Fehlende Bereitschaft zum Sprintabbruch

Sprint – Antipattern

Der Abwesende PO

Beschreibung des Antipatterns:

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 der Product-Owner auch nicht bei Scrum-Meetings dabei. Gerade Refinement-Meetings und Plannings sind jedoch essenziell für die erfolgreiche Durchführung von Scrum.

Warum ist das schlecht?

Meist werden PBIs nicht bis ins letzte Detail hinein spezifiziert, weil dies ein agiles Antipattern darstellen würde und somit zu viel Aufwand upfront investiert 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, 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.
Die Umsetzung verzögert sich daher, weil das Team mit mehr Wartezeiten und Kommunikationsaufwänden beschäftigt ist.

Verbesserungen:

Da die Abwesenheit des Product-Owners zu negativen Konsequenzen führt, ist es notwendig, dass sich der Product-Owner seiner Aufgabe bewusst wird und sich explizit mehr Zeit nimmt. Der Scrum-Master sollte daher mit dem Product-Owner sprechen und herausfinden, was die Ursache für ein derartiges Verhalten ist.
Liegt die Ursache dieses Verhaltens darin, dass der Product-Owner sich der Konsequenzen seiner Abwesenheit nicht bewusst ist, kann dies leicht durch ein Gespräch gelöst werden. Liegt das Problem jedoch darin, dass der Product-Owner vom Management noch vielseitig anders verplant ist und seine Aufgaben somit gar nicht wahrnehmen kann. Muss der Scurm-Master und der Product-Owner mit dem Management nach einer Lösung für dieses Problem suchen.
In jeden Fall sollte der Product-Owner aber, möglichst gut und einfach für das Team erreichbar sein.
Es kann hilfreich sein, dass sich das Team mit dem Product-Owner Zeiten ausmacht, zu denen der Product-Owner gut erreichen ist.
Ein Teamkalender kann beispielsweise geteilt werden, in dem jedes Teammitglied inklusive Product-Owner und Scrum-Master ihre An- und Abwesenheiten eintragen.
Sollte der Product-Owner seine Rolle falsch verstanden haben, muss der Scrum-Master mit ihm jedenfalls über seine Rolle sprechen und aufzeigen, dass eine Teilnahme an den Scrum-Meetings und am Sprint essenziell ist.
Denn es sollten auf jeden Fall regelmäßige Refinement-Meetings eingeplant und abgehalten werden, um die Groben vorarbeiten gemeinsam mit dem Product-Owner zu machen.

Scope-Creep-PBIs

Beschreibung des Antipatterns:

Dieses Antipattern bedeutet, dass sich die PBIs die im Sprint-Planning geplant wurden und bereits im Sprint in der Umsetzung befinden, oder noch umgesetzt werden, verändern und der Umfang der PBIs erweitert wird.
Meist ist für diesen Scope-Creep ein Product-Owner 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 dazu programmieren, dann ist das in einem Aufwischen gleich erledigt.“

Warum ist das schlecht?

Dieser Scope-Creep führt dazu, dass sich der Umsetzungsaufwand 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 fertiggestellt werden.
Im schlimmsten Fall kann das Sprint-Ziel nicht eingehalten werden.

Verbesserungen:

Zunächst muss klar sein, wer den Scope-Creep verursacht. Sind die Verursacher Stakeholder, z.B. disziplinär Vorgesetzte, so kann das Team den Ball an den Product-Owner weiterspielen.
Der Product-Owner muss in diesem Fall den Stakeholder über die agile Arbeitsweise mit Scrum 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.
Hinter vielen Fällen von Scope-Creep steckt Unwissenheit und eine Art von Ungeduld des Verursachers. Unwissenheit kann durch eine Schulung oder ein informatives Gespräch mit dem Verursacher geklärt werden. Dabei wird dem Stakeholder das agile arbeiten mit Scrum näher gebracht. Ist der Stakeholder zu ungeduldig, bedarf es eines klärenden Coaching-Gesprächs.
Ab und zu muss sich das Team aber überlegen, ob es sich lohnt, die Schlacht zu schlagen. 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 Stakeholders notwendig ist.
Wichtig zu erwähnen ist auch, dass ab dem Zeitpunkt zu 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 mitbestimmen muss.

Inflexibilität bei den Akzeptanzkriterien

Beschreibung des Antipatterns:

Es kommt immer wieder mal vor, dass sich während dem laufenden Sprint Rahmenbedingungen ändern 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 agilen Prinzipen und im Kern das, wofür 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.
Ein PBI kann beispielsweise auch in zwei zusätzliche PBIs aufgeteilt werden. Eine abgeänderte Variante, die im Sprint abgeschlossen wird, und ein neues PBI, welches die zusätzlichen Teilen, die es noch zu lösen gilt, beinhaltet.
Kommt es jedoch zu oft vor, dass PBIs und Akzeptanzkriterien angepasst werden müssen, so sollten Refinement-Meetings eingeführt oder besser abgehalten werden. Dazu muss das Thema in der Retrospektive angesprochen werden und das Team muss gemeinsam Lösungen finden und einführen.
Wenn sich zentrale PBIs des Sprints ändern und sich damit das Sprintziel 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.

PBI Abnahmeverzögerung

Beschreibung des Antipatterns:

Der Product-Owner nimmt sich während des Sprints keine Zeit, bereits fertiggestellte PBIs abzunehmen oder verweigert die Abnahme mit dem 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 Sprints 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.
Dieses Antipattern erhöht also nicht nur die Entwicklungskosten, sondern auch das Produktrisiko.

Verbesserungen:

Der Product-Owner sollte immer so bald wie 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.

Missbrauch von Sprintabbrüchen

Beschreibung des Antipatterns:

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 schwelender 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 Retrospektive ü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.

Fehlende Bereitschaft zum Sprintabbruch

Beschreibung des Antipatterns:

Der Product-Owner ist nicht bereit, einen Sprint abzubrechen, obwohl es bereits bekannt ist, dass das es keinen Sinn mehr macht, am Sprintziel festzuhalten.
Der Product-Owner denkt sich, dass der Sprint bereits so weit fortgeschritten ist und ein Abbruch jetzt auch nicht mehr wichtig ist.
Oft weiß der Product-Owner bereits, dass das Sprintziel obsolet geworden ist, kommuniziert dies aber nicht dem Team.
Ab und zu kann es auch dazu kommen, dass der Product-Owner den Sprint abbricht, das Team sich jedoch denkt, dass „nur mehr eine Kleinigkeit“ gemacht werden muss, um ein Ticket abzuschließen und es daher heimlich weiterentwickelt.

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 Bekanntwerden des obsoleten Ziels gemacht wird, ist reinste Zeitverschwendung. Eine Verschwendung wertvoller Ressourcen und Zeit, die in andere Ziele besser investiert wären.
Wird heimlich oder offen an obsoleten PBIs weitergearbeitet, wird somit viel Zeit verschenkt und es entstehen Kosten, die verhindert werden können.

Verbesserungen:

Sprintabbrüche sind nicht lustig. Keiner erfährt gerne, dass die Arbeit, die in den letzten Tagen gemacht wurde, sinnlos war.
Umso wichtiger ist es, dass der Product-Owner und das Team den Sprint möglichst frühzeitig abbricht und sich auf neue Aufgaben fokussieren.
Der Product-Owner sollte möglichst sofort nach Kenntnisnahme 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/halb fertigen PBIs werden, sofern sie noch einen Mehrwert für den User liefern, in einen Zustand gebracht, in dem sie entweder teilweise abgeschlossen werden können oder indem sie zumindest leicht in den nächsten Sprint übernommen werden können.
PBIs die halb fertig sind, aber keinen Mehrwert mehr darstellen, werden sofort und mit möglichst minimalen Aufwänden abgeschlossen.
Am besten wird der Sprintabbruch dann in einem gemeinsamen Sprint-Review und einer Retrospektive abgeschlossen.