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

Inhalt

Defintion of Ready Gate
Sprintlänge an Plan anpassen
Erzwungener Plan
Sprintplanung by Lead Dev
Botschafter-Planning

Sprint Planning – Antipattern

1. Defintion of Ready Gate

Beschreibung des Antipatterns:

Das Umsetzungsteam ist sehr unflexibel in der Sprintplanung, es lässt nur jene PBIs für die Planung zu, die zuvor das Refinement durchlaufen haben und bereits die Definition of Ready erfüllen.
Alle PBIs, die die Definition of Ready nicht erfüllen, werden nicht zur Diskussion zugelassen.

Warum ist das schlecht?

Im Idealfall ist das Backlog bereits nach Priorität sortiert, jene PBIs, die die höchste Priorität aufweisen, sind bereits refined, erfüllen die Definition of Ready und sind in ausreichender Anzahl vorhanden, um den nächsten Sprint zu planen.
In der Realität kann sich aber die Strategie für die Umsetzung sehr schnell ändern und somit auch die Prioritäten im Backlog.
Ist das Team hier unflexibel, können nur PBIs verplant und umgesetzt werden, die bereits eine niedrigere Priorität oder sogar gar keinen Priorität mehr haben.
Dies führt gegebenenfalls dazu, dass Features umgesetzt werden, die niemand mehr braucht. Das verursacht massive Kosten.
Des Weiteren werden die Features, die durch das Definition of Ready Gate zurückgehalten werden, verzögert. Das heißt, dass sich für diese Tickets die Time to Market verschlechtert und erst später der Nutzen beim User ankommt. In einer schnelllebigen Produktwelt kann dies hohe Kosten verursachen.

Verbesserungen:

Insgesamt ist es wichtig, auf die Definition of Ready zu achten. Das Team sollte nicht jede spontane Idee des Product-Owners durchwinken und die DoR völlig vernachlässigen. Genauso wichtig ist es aber, agile und anpassungsfähig zu sein. Passiert dies nicht, ist das Team sehr schnell wieder in der plangetriebenen Welt.
Gibt es eine Umplanung in der Produktstrategie oder wurde aufgrund des frischen Userfeedbacks der Bedarf an einem speziellen Feature entdeckt, darf die Definition of Ready nicht im Weg stehen. In diesen Situationen ist es notwendig, abseits vom Refinementmeeting diese Tickets ins Planning mit aufzunehmen und zu verplanen.
Das Thema mit der Definition of Ready darf also nicht dogmatisch gesehen werden.
Der Scrum-Master und das Team sollten allerdings sehr wohl darauf achten, dass dieser Zustand eine Ausnahme ist und nicht zur Regel wird.
Ergeben sich relativ spontan Tickets, die das Refinement noch nicht durchlaufen haben, aber verplant werden sollen, empfiehlt es sich, sich im Planning mehr Zeit zu lassen und die Themen genauer mit dem Product-Owner durchzubesprechen.
Es ist wichtig für das gesamte Scrum-Team über dieses Thema zu sprechen und seinen eigenen Weg zu finden und von Fall zu Fall zu entscheiden, wie mit der Situation umgegangen werden soll.

2. Sprintlänge an Plan anpassen

Beschreibung des Antipatterns:

Das Scrum-Team passt die Sprintlänge an den Sprintplan bzw. einzelne Features an.
Es gibt keine einheitliche Sprintlänge, jeder Sprint ist unterschiedlich lange.
Die einzelnen Features werden nicht in kleine Einheiten zerlegt, um sie in einem standardisierten, regulären Sprint verplanen zu können, sondern es wird stattdessen die Sprintlänge des nächsten Sprints an die großen Features angepasst.

Warum ist das schlecht?

Scrum ist ein selbstoptimierendes Framework, welches sehr viele Mechanismen hat, die dem Team bei dieser Optimierung helfen.
So kann über die Retrospektive und das Review sowohl die Zielerreichung als auch die Effektivität des letzten Sprints reflektiert werden.
Um hier aber den Vergleich zu vergangenen Sprints zu ermöglichen und eine Basis für diese Reflexion zu haben, müssen die Zeiträume, in denen die Umsetzung passiert ist, standardisiert sein. Sprich: Die Sprintlängen müssen immer gleich sein.
Ist dies nicht der Fall, ist eine Optimierung und eine Vergleichbarkeit nur schwer möglich, es steigen die Kosten bzw. die Kosten bleiben auf einem hohen Niveau.
Kennzahlen wie die Time-to-Market, die Velocity oder die Kapazität schwanken und sind nicht sinnvoll einsetzbar.
Die Teilnahme an Review-Terminen ist für die Stakeholder schwieriger planbar, weil diese in unregelmäßigen Abständen stattfinden. Dies führt zu geringeren Teilnahmezahlen der Stakeholder und somit zu einer schlechteren Beziehung zwischen Stakeholdern und Team, was wiederum das Vertrauen der Stakeholder in das Team negativ beeinflussen kann.

Verbesserungen:

Das Scrum-Team sollte sich auf eine Sprintlänge einigen und diese über den Lauf des Projekts konstant halten.
Es sollte jedoch auch regelmäßig darüber reflektieren, ob die gewählte Sprintlänge auch effizient ist. Ein wechseln von beispielsweise 2 Wochensprints auf konstant 3 Wochensprints ist kein Antipattern, wenn die grundlegende Begründung für diesen Wechsel beispielsweise eine Erleichterung von Refinementmeetings, oder eine Effizienzsteigerung im Releasemanagement ist.
Ebenso wenig ist es ein Antipattern, wenn beispielsweise zu speziellen Feiertagen, z.B. am Jahresende in den Weihnachtsfeiertagen, ein irregulärer Sprint geplant wird, weil das Team teilweise auf Urlaub ist.
Da die Vergleichbarkeit gegeben sein soll und es noch zahlreiche andere Nachteile gibt, muss die Sprintlänge somit immer gleich bleiben. Passiert dies nicht und ist die Änderung nicht wie bei den oberen zwei Beispielen gut begründet, muss der Scrum-Master hier die Probleme aufzeigen und das Team coachen, dieses Antipattern zu vermeiden.
Anstatt die Sprintlänge zu verändern, muss das Team mehr aufwand ins Refinement stecken und die Tickets auf ein angemessenes Maß herunterbrechen, welches die Planbarkeit in kleinen einheitlichen Sprints ermöglicht.

3. Erzwungener Plan

Beschreibung des Antipatterns:

Der Sprintplan wird von Personen außerhalb des Umsetzungsteams beeinflusst oder erzwungen.
Zum Beispiel nehmen Vorgesetzte des Umsetzungsteams Einfluss und zwingen das Team gewissen Tickets in einer gewissen Zeit umzusetzen.
Es werden Deadlines vorgeschrieben, die das Team „halten muss“.
Es kann auch sein, dass der Product-Owner auf das Team Einfluss nimmt und das Team unter Druck setzt, mehr und mehr Tickets in den Sprint aufzunehmen.

Warum ist das schlecht?

Wird das Team von Personen, die außerhalb des Teams stehen, beeinflusst, so kann es sein, dass das Sprintziel von Anfang an nicht realistisch ist.
Das Team kann dadurch stark demotiviert werden. Das kann zu einer Situation führen, in der eine selbsterfüllende Prophezeiung eintritt und das Sprintziel somit wirklich nicht erreicht wird.
Derartige Einmischungen sind oft auch nicht konform zum Sprintziel. Das heißt, ein Vorgesetzter gibt Themen vor, die nicht unmittelbar zur Produktstrategie und somit auch nicht zum Sprintplan passen.
Im schlimmsten Fall wird dem Team zunächst im Sprintplanning ein Plan vorgegeben und am Sprintende wird dem Team dann vorgehalten, dass der Plan nicht eingehalten und die Funktionalität nicht wie versprochen geliefert wurde.
Das demotiviert das Team und kann dazu führen, dass einige Teammitglieder mit der Zeit das Handtuch werfen und sich einen neuen Job suchen.
Da die Einmischung von Außen außerdem oft sehr unkoordiniert passiert, werden routinierte Abläufe durch diese Einmischung durcheinandergebracht. Dies führt dazu, dass wertvolle Zeit und Effizienz verloren gehen und die Kosten steigen.

Verbesserungen:

In diesem Fall sollte der Scrum-Master die Situation erkennen und gemeinsam mit dem Team und den Stakeholder/Product-Owner reden.
Je nachdem, was die Beweggründe für diesen Druck von Außen sind, muss unterschiedlich damit umgegangen werden. Es empfiehlt sich daher für das Team und den Scrum-Master zunächst zu hinterfragen, warum so ein Druck oder so eine Vorgabe gemacht wird.
Aufgrund dieses Hintergrundes müssen dann gemeinsam mit dem Stakeholder/Product-Owner geeignete Gegenmaßnahmen gefunden werden.
Es empfiehlt sich dabei auch die „neuen“ Features in den Scrum-Prozess mitaufzunehmen. Neue Tickets anzulegen oder vorhandene Tickets zu refinen und einen realistischen Sprintplan zu erstellen, der diese Bedürfnisse mitberücksichtigt.
Sollte der Druck von einem Stakeholder kommen, muss der Product-Owner diesen Input auch in seine Produktstrategie und das Sprintziel miteinfließen lassen.

4. Sprintplanung by Lead Dev

Beschreibung des Antipatterns:

Ein Lead Dev oder ein erfahrener Senior übernimmt die Sprintplanung und schüchtert bewusst oder unbewusst andere Teammitglieder ein.
Er spielt die Erfahrungskarte aus und lässt Meinungen und Input von unerfahreneren Junior-Devs nicht zu.

Warum ist das schlecht?

Ein derartiges Verhalten zeigt, dass das Team nicht gleichberechtigt ist und keine Shared-Ownership im Projekt lebt.
Aufgrund eines derartigen Antipatterns können schnell Konflikte im Team entstehen. Diese schwelen dann dahin und kosten viel Zeit und Geld.
Im schlimmsten Fall kündigen einige Mitarbeiter nach kurzer Zeit, weil sie die andauernden Konflikte nicht mehr aushalten.
Ein weiterer wichtiger negativer Faktor ist, dass das Team nicht als Ganzes hinter dem Sprintplan steht und somit nicht motiviert ist, das Sprintziel umzusetzen. Sprintziele werden in weiterer Folge oft nicht erreicht.
Außerdem wird der Sprint in diesem Antipattern von erfahreneren, meist schnelleren Entwicklern geplant. Dadurch schleicht sich sehr schnell ein Fehler in die Planung ein, weil schwächere, langsamere Entwickler nicht berücksichtigt werden.

Verbesserungen:

Der Scrum-Master und der Product-Owner müssen im Sprintplanning gut aufpassen, wer die Meinungsführer sind und wie der Sprint geplant wird.
Sie müssen erkennen, ob einige Mitglieder aufgrund ihrer Kommunikationsweise oder Erfahrungen andere Teammitglieder ausstechen und falls dem so ist, gezielt moderieren und für Ausgleich sorgen.
Es ist relativ häufig der Fall, dass erfahrenere Kollegen mehr am Planning teilnehmen und mitgestalten und sich unerfahrenere Kollegen zurückhalten. Allein dieser Umstand ist noch kein Antipattern, sollte aber dennoch durch Moderationstechniken ausgeglichen werden. Denn dadurch ermöglicht man es auch den anderen Teammitgliedern sich mehr zu beteiligen und dazuzulernen.
Im Idealfall wird das Antipattern, falls es immer wieder auftritt, in der Retrospektive angesprochen und das Team darin bestärkt, sich eigene Lösungskonzepte zu überlegen. So kann beispielsweise eine Kommunikationsmethode etabliert werden, bei der jedes Teammitglied mindestens einen Kommentar abgeben muss und somit jeder mindestens einmal pro Thema zu Wort kommt.

5. Botschafter-Planning

Beschreibung des Antipatterns:

Es nimmt nicht das gesamte Team am Planning teil, sondern lediglich ein Teil vom Team.
Diese Botschafter vertreten das Team und machen das gesamte Planning.

Mögliche Ursachen:

Dieses Antipattern kann mehrere Ursachen haben.
Einerseits kann es sein, dass das Team nicht am Planning teilnehmen will, weil es das Planning für überflüssig hält.
Andererseits kann es auch sein, dass ein Manager nicht will, dass das gesamte Team im Planning teilnimmt, weil er das als Zeitverschwendung empfindet.

Warum ist das schlecht?

Nimmt nicht das gesamte Team am Planning teil, so geht viel Kommunikation an den nicht teilnehmenden Mitgliedern vorbei.
Wichtige Informationen, die für die Umsetzung wichtig sind und nicht im Ticket festgeschrieben wurden, fehle und müssen entweder nachgefragt werden oder führen zu Fehlern in der Umsetzung.
Durch den Kommunikationsbedarf, der nach dem Planning im Team entsteht, muss viel Zeit in Nachbesprechungen gesteckt werden. Da die Informationen aber nicht aus erster Hand kommen, entsteht ein Stille-Post-Effekt der hohe Kommunikationskosten verursacht und zu kostspieligen Fehlern führt.
Wird das Team von einem Stakeholder oder Manager an der Teilnahme gehindert, führt dies außerdem zu Unmut im Team. Das schadet der Motivation und kann letztendlich dazu führen, dass Teammitglieder kündigen und sich einen neuen Job suchen.

Verbesserungen:

Im Scrum-Framework nehmen immer alle Teammitglieder bei jedem Event/Meeting teil.
Sollte das Team keinen Mehrwert im Sprintplanning erkennen, so ist vermutlich das Verständnis für Scrum und die agile Vorgehensmethode noch nicht ausgereift.
In diesem Fall muss der Scrum-Master das Scrumwissen beim Team auffrischen.
Es kann auch sein, dass der Scrum-Prozess wirklich noch nicht sauber läuft und somit das Planning zu wenig Mehrwert liefert. Dann ist es die Aufgabe vom Scrum-Master diesen Umstand in der nächsten Retrospektive mit dem gesamten Scrumteam zu diskutieren und Lösungen zu finden
Sollte ein Stakeholder oder Manager von außen auf das Team einwirken, muss der Scrum-Master hier ebenfalls das Gespräch suchen und hier für Verständnis für die agile Vorgehensweise mit Scrum sorgen.