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

Inhalt:

Kein Work-In-Progress Limit
Cherry-Picking
Nicht aktuelle Sprint-Boards
Side-Gigs
Goldplating
Laufende Arbeitsunterbrechungen
Fehlende Unterstützung
Task-Assignments

1 Kein Work-In-Progress Limit

Beschreibung des Antipatterns:

Das Entwicklungsteam setzt kein Work-In-Progress-Limit und öffnet mehrere größere Features gleichzeitig.

Warum ist das schlecht?

Arbeitet das Team an zu vielen PBIs gleichzeitig im Sprint, besteht die Gefahr, dass am Sprintende keine oder zu wenige PBIs fertig sind oder zu viele PBIs einen halb fertigen Zustand haben. Der Outcome kann also nicht erreicht werden und das Produktrisiko steigt.
Es kommt außerdem zu Multitasking und vielen Reibungsverlusten, wenn zu viele PBIs gleichzeitig offen sind und die Entwickler zwischen den offenen PBIs hin und her wechseln, denn oft bestehen Abhängigkeiten zwischen den PBIs und den Entwicklern, die sie umsetzen.
Des Weiteren wird die Fertigstellung der Produkt-Inkremente gefährdet, wenn Tickets nur halb fertig sind und in den nächsten Sprint gezogen werden. Es wird somit nie ein Status erreicht, bei dem alle Tickets im Sprint abgeschlossen und auslieferbar sind.
Werden zu viele PBIs in den nächsten Sprint gezogen, so lässt sich automatisch auch eine Erhöhung der Cycle-Time der einzelnen PBIs feststellen. Eine erhöhte Cycle-Time ist jedoch schlecht, weil das Team länger braucht, bis es einen Mehrwert an den User liefert und Feedback vom Markt bekommt. Das Produktrisiko steigt dadurch.

Verbesserungen:

Das Team sollte ein Work-In-Progress-Limit (= WIP-Limit) setzen, welches kleiner oder gleich der Anzahl der Team-Mitglieder ist.
Die Größe dieses WIP-Limits ist abhängig von der durchschnittlichen Größe der PBIs. Das heißt, dass die Anzahl der Tickets, die im Sprint aktiv bearbeitet werden dürfen, abhängig ist von der generellen Granularität der PBIs, die das Team in seinem Backlog pflegt. Diese Größen können von Team zu Team und von Projekt zu Projekt unterschiedlich sein.
Im Normalfall und bei üblichen PBI-Größen hat sich eine deutlich kleineres WIP-Limit als praktikabel herausgestellt. Weil das Team meist gemeinsam an Tickets arbeitet und zumindest die Arbeit gegenseitig reviewen muss.
Der Scrum-Masters sollte darauf achten, dass das Team ein WIP-Limit setzt und dieses auch einhält und gegebenenfalls das Team Coachen und über die Risiken aufmerksam machen, die andernfalls entstehen.
Da das WIP-Limit nicht generell in allen Projekten gleich ist, muss das Team in den ersten Sprints aufgrund von Erfahrungswerten ein WIP-Limit setzen und in den laufenden Sprint-Reviews und Sprint-Retrospektiven dieses Monitoren und ggf. anpassen.
Auch der Product-Owner ist stark daran interessiert, ein WIP-Limit zu haben, denn dies garantiert, dass die Cycle-Time der PBIs nicht zu groß werden. Es ist für den PO und das Team besser, wenn lieber einige wenige Features im Sprint ganz umgesetzt werden, als dass viele Features halb umgesetzt sind.
Das WIP-Limit sollte allerdings auch nicht religiös gesehen werden, es kann durchaus Situationen geben, in denen das WIP-Limit überschritten werden muss. Diese Situationen sollten dann aber in der Retrospektive reflektiert werden und können somit zukünftig verhindert werden.

2 Cherry-Picking

Beschreibung des Antipatterns:

Dieses Antipattern besteht auf zwei Ebenen entweder betreiben einzelne Software-Engineers Cherry-Picking, oder es wird auf Teamebene betreiben.
So versucht beim Antipattern auf Teamebene das Umsetzungsteam den Product-Owner so zu beeinflussen, dass der Sprint nach den Bedürfnissen des Teams geplant wird.
Auf der Ebene des Software-Engineers äußert sich das Antipattern so, dass einzelne Software-Engineers sich nur jene PBIs zum Umsetzen aussuchen, die sie selbst am lustigsten und interessantesten finden, allen anderen Tickets lassen sie dem restlichen Team über.
Es wird dann akribisch an den eigenen Tickets gearbeitet, den Teamkollegen wird jedoch nicht geholfen. Der Grund für die Ablehnung dieser Hilfe ist dann meist, dass die eigene Arbeit gerade wichtiger ist.
Zugunsten neuer Feature und lustiger Implementierungstask werden auf der anderen Seite nicht so lustige Aufgaben wie das Schreiben von Testfällen, das Testen oder das Dokumentieren vernachlässigt oder hintangestellt.

Warum ist das schlecht?

Menschen lieben schnelle Belohnungen. Aus diesem Grund fühlt es sich so gut an ein Feature fertig zu bauen. Ein Sprint ist aber ein Mikroprojekt, welches alle Phasen eines herkömmlichen, großen Projekts beinhaltet. Es kann daher nicht einfach gesagt werden: „Ich mache meine lustigen Entwicklungstasks und das Testen, Dokumentieren und Releasen soll jemand anderer machen.“ Es werden sonst wichtige Aufgaben, die es auch braucht, um einen erfolgreichen Sprint-Abschluss hinzubekommen, vernachlässigt. Das Sprint-Ziel wird gefährdet.
Wenn sich nur einige wenige Teammitglieder immer das herausnehmen, was sie wollen, müssen anderer die nicht so lustigen Dinge machen. Dies gefährdet den Team-Spirit und führt zu Spannungen im Team. Konflikte können entstehen.
Sprintziele und Qualitätsziele werden ggf. nicht erreicht.
Meist lässt sich, wenn Teams diese Spannungen haben und Cherry-Picking betrieben wird, erkennen, dass das Team nicht vollständig selbst organisiert ist oder es bei der Selbstorganisation Schwierigkeiten hat.
Es herrscht auch offensichtlich kein Sinn für Shared-Ownership des Teams. Das Team muss also begreifen, dass es gemeinsam für das Sprintziel verantwortlich ist.
Oft entsteht auch innerhalb eines Sprints mit Cherry-Picking-Teammitgliedern ein Rückstau an Tickets, bei dem sich Ticket um Ticket in der Umsetzung befindet, aber nur wenige Features fertig werden. Das ist dann meist auf fehlende Reviews oder ähnliches zurückzuführen. Diese Arbeiten werden aber nicht aufgrund des Zeitdrucks nicht gemacht, sondern sind auf ein Fehlverhalten von Team-Kollegen zurückzuführen, die nicht gewillt sind, Reviews und Dokumentationen abzuschließen. Ein Work-In-Progress-Limit kann hier helfen (siehe fehlendes WIP-Limit).
Auf Teamebene ist Cherry-Picking dann zu erkennen, wenn wichtige, aber unpopuläre Features einfach nie fertig werden und von Sprint zu Sprint mitgeschoben oder nie verplant werden. Dieses Verhalten schadet natürlich dem Produkt, weil wichtige Baisfeatures nicht beim User ankommen und somit weniger Mehrwert für den User geschaffen wird. Das Produktrisiko steigt und die Cycle-Time für einige unbeliebte PBIs wächst enorm an.

Verbesserungen:

Der Scrum-Master sollte das Team beobachten und coachen, wie es die Arbeit im Team am besten koordinieren kann. Dabei sollte der Scrum-Master nicht selbst die Arbeit verteilen, sondern das Team auf das Problem aufmerksam machen und zu einer Lösung bringen.
Es muss dem gesamten Team bewusst sein, dass alle arbeiten im Sprint erledigt werden müssen und jeder im Team seinen Beitrag leisten muss.
Die Shared-Ownership des Teams und somit die Verantwortung des Teams für die gesamte Leistung im Sprint muss jedem Teammitglied bewusst sein.
Sollten Konflikte entstehen oder entstanden sein, so muss der Scrum-Master dem Team helfen, eine Lösung für diese Konflikte zu finden. Hier muss moderiert werden und versucht werden, dass jeder gehört und ernst genommen wird.
Ein guter Ort, um das Thema anzusprechen, ist die Retrospektive. Hier haben sowohl unzufriedene Team-Kollegen als auch der Scrum-Master die Gelegenheit, das negative Verhalten konstruktiv anzusprechen und Verbesserungen zu suchen.
Der Product-Owner sollte auf die Cycle-Time aller PBIs achten und hinterfragen, warum einige PBIs zwar als wichtig genug empfunden wurden, um sie im Backlog anzulegen, aber nicht wichtig genug, um sie umzusetzen. Er sollte in jenem Fall in der Sprintplanung darauf bestehen, dass diese PBIs geplant und umgesetzt werden.

3 Nicht aktuelle Sprint-Boards

Beschreibung des Antipatterns:

Das Team wartet das Sprint-Board nicht ausreichend während des Sprints, und somit befinden sich Tickets im falschen Status, zeigen die falsche verbleibende Zeit an und verfälschen das WIP-Kontingent.

Warum ist das schlecht?

Das Sprint-Board gehört voll und ganz dem Team, es dient einerseits der Selbstorganisation des Teams, ist aber andererseits „öffentlich“ den Stakeholdern sowie dem Product-Owner zugänglich. Ist das Board nicht gepflegt, schadet es also automatisch der Selbstorganisation und der Reputation des Teams.
Stakeholder und Product-Owner können verwirrt sein und letzten Endes auch das Vertrauen in das Team verlieren.
Ist kein Vertrauen mehr seitens der Stakeholder oder des Product-Owners da, so werden Gegenmaßnahmen ergreifen, um das Chaos zu managen.
Ist das Board nicht gepflegt und fallen dann beispielsweise Kollegen z.B. krankheitsbedingt aus, so muss sich das Team mühsam einarbeiten und herausfinden, was der letzte Stand war und in welchen Status sich ein PBI eigentlich befindet.
Es ist auch zu bedenken, dass moderne agile Tools wie Jira oder Microsoft Azure-DevOps auch Charts wie beispielsweise Burndown-Charts erstellen. Werden die Tickets nicht gewartet und der Restaufwand nicht täglich aktualisiert, so werden die Charts auch dementsprechend schlecht aussehen. Dies kann für noch mehr Verunsicherung bei den Stakeholdern und den Product-Owner führen.
Wichtige Kennzahlen und das Burndown-Chart sind aber essenzielle Informationsquellen, die es ermöglichen, Antipattern und Probleme zu identifizieren. Wird das Sprint-Board nicht gepflegt, so funktionieren diese Sicherheitsmechanismen nicht.
Das aktuelle Work-In-Progress Kontingent wird außerdem nicht richtig angezeigt, daher kann es zu Wartezeiten und Aufwänden in der Koordination des Teams kommen

Verbesserungen:

Das Team sollte sich zumindest einmal täglich daran machen, das Board zu aktualisieren.
Besser ist es, wenn jedes PBI im Sprint den aktuellen Stand, in dem es sich befindet, widerspiegelt.
Vor dem Stand-up sollten alle PBIs an denen ein Teammitglied arbeitet oder die abgeschlossen wurden, in den aktuellen Status gebracht werden.
Am Ende des Arbeitstages, noch vor dem Feierabend, sollte das Sprint-Board ebenfalls aktualisiert werden, um automatisierte Charts zu ermöglichen und im Krankheitsfall den aktuellen Status der Arbeit widerzuspiegeln.
Sollte der Scrum-Master über einen längeren Zeitraum wahrnehmen, dass das Team das Board nicht wartet, so muss er mit dem Team über die etwaigen Konsequenzen sprechen und das Team coachen, dies zukünftig zu machen.

4 Side-Gigs

Beschreibung des Antipatterns:

Bei einem Side-Gig arbeiten ein oder mehrere Teammitglieder an Themen, die nicht im Sprint geplant und somit auch nicht im Sprintbacklog/Sprintboard sichtbar sind.

Warum ist das schlecht?

Wenn ein oder mehrere Teammitglieder an Themen arbeiten, die das Sprintziel nicht beinhaltet, dann führt dies zu mehreren Problemen, denn einerseits können die Teammitglieder dann nicht an den eigentlich geplanten PBIs arbeiten, andererseits investieren sie Zeit in etwas, was nicht durch den Product-Owner erfasst und geplant wurde. Der Product-Owner ist aber für den Business-Value und letzten Endes für den Return on Investment des Produkts verantwortlich.
Eine weitere Frage ist, warum die Teammitglieder die scheinbar sehr wichtigen Aufgaben nicht in erster Linie mit dem Product-Owner im Sprintplanning besprochen haben. Es kann sein, dass dies ein Zeichen von schlechter Kommunikation oder Misstrauen ist, welches unbedingt gelöst gehört.
Ein weiteres Problem an Side-Gigs kann darin liegen, dass diese nicht im Stand-up besprochen, sondern eher verschleiert werden. Dies führt unweigerlich dazu, dass Ausreden und Verschleierungstaktiken verwendet werden. Werden diese aufgedeckt, kann dies zu massiven Vertrauensverlust und Konflikten führen.

Verbesserungen:

Sobald einem anderen Teammitglied, dem Product-Owner oder dem Scrum-Master der Umstand bewusst wird, dass einige Teammitglieder an anderen Themen arbeiten, muss dies im Team besprochen werden.
Zunächst gilt es zu hinterfragen, an welchen Nebenthemen gerade erarbeitet wird und welchen Zweck diese erfüllen.
Sind diese Nebenthemen wirklich wichtig, so ist zu klären, warum diese nicht mit dem gesamten Scrum-Team besprochen wurden, sondern mit der Implementierung auf eigene Faust angefangen wurde und ob diese weiter geführt werden soll oder nicht.
Wurden die Nebenthemen als eher unwichtig eingestuft, so sollten diese unverzüglich eingestellt werden. Die Side-Gig-Teammitglieder sollten wieder an PBIs arbeiten, die auf dem Sprintboard stehen und somit zum Sprintziel führen.
Sollte ein Misstrauensverhältnis zwischen einzelnen Teammitgliedern und dem Product-Owner bestehen, so sollte der Scrum-Master versuchen, hier zu coachen und das Team enger zusammenzubringen.

5 Goldplating

Beschreibung des Antipatterns:

Beim Goldplating erweitert ein Teammitglied die angestrebte Umsetzung eines Features um weitere, oftmals unnötige unerwünschte Details, ohne dies zuvor mit dem Team und den Product-Owner zu besprechen. Die geplante Funktionalität wird um ein Vielfaches übertroffen. Es wird mehr und mehr Zeit in Erweiterungen und Detaillierungen des Features gesteckt und kein Ende der Arbeiten gefunden.
Dabei wird Goldplating oft unbewusst von einem oder mehreren Teammitgliedern betrieben.
Die Umsetzung schießt also über das Ziel hinaus.

Warum ist das schlecht?

Goldplating ist schlecht, weil mehr Zeit und somit Budget für Features und Featuredetails benötigt wird, als ursprünglich angenommen.
Zudem wird der Product-Owner darüber nicht informiert oder um Erlaubnis gefragt, was dazu führt, dass gegebenenfalls die Produkt-Strategie und Kostenplanung nicht mehr funktioniert.
Durch die zu viel investierte Zeit in das eine PBI, ist automatisch auch weniger Zeit im Sprint für alle anderen PBIs vorhanden. Dies führt auch dazu, dass das Sprintziel bedroht wird und ggf. nicht eingehalten werden kann.
Nicht eingehaltene Sprintziele und fehlende Features führen auch unweigerlich zu Fragen und misstrauen der Stakeholder, das Umsetzungsteam und der Product-Owner kommen unter Druck.

Verbesserungen:

Goldplating kann am einfachsten verhindert werden, indem im Sprintplanning solide Schätzungen gemacht werden und im Team ein Bewusstsein für Minimal Viable Products (= MVPs) und die Probleme, die durch Goldplating entstehen, vorherrscht.
Des Weiteren empfiehlt es sich ein Burndown-Chart zu führen und die Remaining-Work immer im Auge zu halten. Brennt die Remaining-Work nicht konstant runter und erzählen einzelne Teammember Tag für Tag im Stand-up vom selben PBI, so ist es möglich, dass hier gerade Goldplating betrieben wird.
Liegt der Verdacht von Goldplating nahe, so sollte der Product-Owner und/oder der Scrum-Master beim Teammitglied nachfragen, was die Herausforderungen und Probleme bei der Umsetzung des PBIs sind.
Im Team sollte regelmäßig in der Sprintplanung und im Refinement betont werden, dass es nicht sinnvoll ist, ein PBI eigenmächtig zu erweitern. Stattdessen sollten die Teammitglieder Ideen und Erweiterungen als Feature-Ideen im Backlog anlegen oder ihren Product-Owner übergeben.
Es ist auch sinnvoll, dass sich Team-Mitglieder regelmäßig Feedback zur Umsetzung vom Product-Owner einholen. Die Kommunikation zwischen Product-Owner und Team muss gut funktionieren, um derartige Fehlallokationen von Ressourcen zu vermeiden.
Um die Kommunikation zu unterstützen sollte der Product-Owner und das Team nicht räumlich getrennt sein.

6 Laufende Arbeitsunterbrechungen

Beschreibung des Antipatterns:

Es passiert immer wieder, dass das Umsetzungsteam im laufenden Sprint von Stakeholdern (wie beispielsweise Vorgesetzten, Marketing, Vertrieb, Backoffice etc.) unterbrochen wird und kleinere Aufgaben abseits der eigentlichen Projektarbeit durchführen muss.
Der Scrum-Master beschützt das Team nicht ausreichend genug vor fremden Einflüssen von außen.
Meist hat der Scrum-Master zu diesen Unterbrechungen eine zu lockere Grundhaltung oder denkt sich, dass das Team sich selbst wehren kann und soll.
Es kann auch sein, dass der Scrum-Master zu weit weg vom Team und der Umsetzung ist und daher diese Unterbrechungen überhaupt nicht mitbekommt.

Warum ist das schlecht?

Wird das Team von außen unterbrochen, so führt das unmittelbar und unweigerlich zu einem Verlust von Umsetzungskapazität.
Wenn dann noch zusätzliche Arbeiten an einzelne Team-Mitglieder oder sogar das gesamte Team verteilt werden, dann wird das Sprintziel gefährdet und der ursprüngliche Plan kann nicht eingehalten werden. Es werden gegebenenfalls einige PBIs nicht umgesetzt, die für den Product-Owner und die User aber wichtig wären.
Zu diesen Verzögerungen kommen aber noch weitere Effekte hinzu. So kommt es beispielsweise durch zusätzliche Aufgaben unweigerlich zum Multitasking und damit zu weiteren Reibungsverlusten in der Umsetzungskapazität.
Das Team wird außerdem sehr stark beansprucht und unter Druck gesetzt. Denn es muss nun mehrere Ziele verfolgen und mehrere Stakeholder glücklich machen, obwohl zu wenig Zeit bleibt.
Das alles tritt dann in Kombination mit der Enttäuschung des Teams gegenüber dem Scrum-Master auf. So können zwischenmenschliche Spannungen zwischen dem Scrum-Master und dem Umsetzungsteam entstehen.

Verbesserungen:

Um hier gezielt Verbesserungen erarbeiten zu können, muss zunächst geklärt werden, warum der Scrum-Master das Team nicht beschützt. Kann er das Team nicht beschützen, weil er beispielsweise nicht in der Nähe des Teams ist, organisatorisch overruled wird oder die Unterbrechungen einfach nicht mitbekommt, oder will er nichts an dieser Situation ändern.
Wenn der Scrum-Master das Team nicht beschützen will, weil er dies nicht als seine Aufgabe sieht, so muss das Team diesen Umstand schnellstmöglich mit dem Scrum-Master bei einer Retrospektive oder einem separaten Meeting besprechen. Es gehört zu den Kernaufgaben eines Scrum-Masters, sein Team und den Scrum-Prozess vor negativen Einflüssen zu schützen.
Gegebenenfalls ist dem Scrum-Master auch nicht bewusst, dass diese Arbeitsunterbrechungen dem Team sehr viel Mühe und Kopfzerbrechen bescheren. Hier lohnt es sich, für Verständnis und Empathie zu sorgen.
Oft tritt dieses Antipattern jedoch auf, ohne dass der Scrum-Master etwas von diesen Unterbrechungen mitbekommt. Dies kann beispielsweise an einer räumlichen Trennung zwischen Team und Scrum-Master liegen. Eine Verbesserung wäre also hier die räumliche Nähe zu suchen und die Büros zusammen zu legen.
Oder der Scrum-Master ist zu distanziert und zu wenig integriert in den Umsetzungsprozess. In diesem Fall muss der Scrum-Master intensiver in Stand-up-Meetings und vor allem Retrospektiven integriert werden, den Umsetzungsprozess mehr begleiten und öfter bei einzelnen Team-Kollegen nachfragen, wie es ihnen geht.
Ein weiterer wichtiger Aspekt liegt in der Beobachtung der Remaining-Work und des Burndown-Chats. Brennt dieses nicht hinunter, kann dies daran liegen, dass Teammitglieder zu oft unterbrochen werden oder andere kleine Aufgaben erledigen müssen.
Sollte der Scrum-Master vom Linienmanagern des Teams overruled werden, so sollte dies auf jeden Fall dokumentiert werden und abgewogen werden, ob eine Diskussion Sinn macht oder nicht. Kommt diese Unterbrechung nur sehr selten und hat gute Gründe, so wird höchstwahrscheinlich die Ausnahme die Regel bestätigen und dieser Umstand vom Scrum-Master und vom Team toleriert werden. Kommt dies jedoch öfter vor und sind die Unterbrechungen vom Team nicht nachvollziehbar, so muss sich der Scrum-Master klar positionieren und Linienmanagern die Grenzen aufzeigen. Ein guter Scrum-Master kann dies jedoch mit Diplomatie und der Werbung um Verständnis sehr gut lösen.
Wichtig ist es auch, dass das Team das Gefühl hat sich auf den Scrum-Master verlassen zu können.
Werden dennoch ungeplante Aufgaben notwendig, so muss das Team dafür sorge tragen, dass am Sprint-Ende die Veränderung der Kapazität dokumentiert wird und der Product-Owner rechtzeitig darüber informiert wird, dass gegebenenfalls einige Tickets nicht fertig werden und das Sprint-Ziel in Gefahr ist. So kann sich der Product-Owner auf die neuen Gegebenheiten einstellen und gegebenenfalls seinen Plan anpassen.

7 Fehlende Unterstützung

Beschreibung des Antipatterns:

Der Scrum-Master unterstützt einzelne Teammitglieder nicht ausreichend, wenn diese Probleme bei der Umsetzung im Team oder im Projekt haben.
Ein Teammitglied hängt schon länger an einem Problem in der Umsetzung oder ein anderes Problem. Doch weder die Teamkollegen noch der Scrum-Master helfen bei der Lösung dieses Problems.
Das Teammitglied ist aber leider auch zu schüchtern oder gehemmt, um nach Hilfe zu fragen. Stattdessen wird Tag um Tag versucht, das Problem auf eigene Faust zu lösen.

Warum ist das schlecht?

Wird einem Teammitglied nicht geholfen, so gehen viel Zeit und Ressourcen verloren.
Hat ein Teammitglied ein Problem und niemand hilft ihm, so ist dies nicht nur für das einzelne Teammitglied schlecht, sondern auch für das Sprintziel, denn die Umsetzungskapazität wird dementsprechend weniger und somit bleiben gegebenenfalls PBIs auf der Strecke.
Wenn Sprintziele nicht erreicht werden, führt dies allerdings zu Problemen für den Product-Owner und lässt das gesamte Team schlecht dastehen. Dieser Grund sollte den Teammitgliedern klar gemacht werden und somit Hemmschuhe und Schüchternheit verhindern. Es macht schlichtweg keinen Sinn, nicht um Hilfe zu bitten.
Ein weiterer wichtiger Aspekt, warum es sinnvoll ist, lieber einmal mehr um Hilfe zu bitten als einmal weniger ist, dass Teammitglieder unterschiedliche Erfahrungen gesammelt haben und Erfahrungsgrade aufweisen. Das heißt, einige Aufgaben sind für die einen Teammitglieder sehr leicht zu lösen, während andere sich bedeutend schwerer dabei tun. Das Team ist aber dazu angehalten, möglichst effizient zu arbeiten.

Verbesserungen:

Zunächst muss geklärt werden, warum das Teammitglied nicht um Hilfe gefragt hat und warum es auch keinem aufgefallen ist, dass jemand im Team sichtlich Probleme hat und an einer Aufgabe hängt.
Es muss allen Teammitgliedern klar gemacht werden, dass es die gemeinsam getragene Verantwortung aller ist, effizient zu arbeiten und gemeinsam Sprintziele zu erreichen.
Es kann sein, dass das Team das Stand-up nicht richtig lebt und Probleme und Hindernisse nicht richtig besprochen werden. Der Scrum-Master sollte im Stand-up regelmäßig Teilnehmen und dem Team dabei helfen, sich besser selbst zu organisieren.
Insgesamt sollte sich das Team aber alleine gegenseitig helfen können. Ist das nicht der Fall, so ist es die Aufgabe des Scrum-Masters dafür zu sorgen Hindernisse und Probleme mit Hilfe des Teams aus der Welt zu schaffen.
Ein wichtiges Instrument um festzustellen, ob jemand bei einem Ticket hängt und ob es wo Probleme gibt, ist neben dem Stand-up auch das Burndownchart und die Remaining-Work des Sprintboards. Brennt das Burndown nicht ordentlich hinunter, so kann es sein, dass ein Teammitglied Hilfe benötigt.
Durch das Bitten um Hilfe und die angebotene Hilfeleistung ist die Lernkurve bei demjenigen, dem geholfen wird, auch sehr steil. Es wird somit Wissen ausgetauscht und im Team verteilt, was wiederum zu mehr Flexibilität und Effizienz führt.

8 Task-Assignments

Beschreibung des Antipatterns:

Der Product-Owner oder andere Stakeholder weisen dem Team die Arbeitspakete zu und verhindern somit die Selbstorganisation des Teams.

Warum ist das schlecht?

Durch die Zuweisung von Arbeitspaketen lässt der Product-Owner/Stakeholder das Team nicht nach agilen Prinzipien arbeiten.
Der Kern von Scrum und agilen Methoden wird daher untergraben. Das Team übernimmt im schlechtesten Fall weder Verantwortung für die Arbeit noch für die Effektivität.
Die vom Product-Owner/Stakeholder gesetzten Deadlines sind zumeist auch unrealistisch oder nicht gut durchdacht. Was dazu führt, dass diese nicht eingehalten werden können. Dies wiederum führt zu Konflikten mit enttäuschten Stakeholdern.
Das ganze Dilemma fügt sich dann meist zu einer plangetriebenen Entwicklung zusammen. Diese Vorgehensweise führt dann meist zu einer schlechten Qualität des Produkts, weil das Team Deadlines einhalten muss. Das wiederum führt zu einem gestiegenen Produktrisiko.
Das Umsetzungsteam wird unter starken Druck gesetzt und gleichzeitig demotiviert, was im schlimmsten Fall dazu führt, dass Konflikte entstehen und Mitarbeiter kündigen.

Verbesserungen:

In diesem Fall sollten die Grundregeln der agilen Umsetzung und von Scrum wiederholt und diskutiert werden. Will das Team wirklich agil nach Scrum arbeiten oder nicht.
Wenn sich das Team dafür entscheidet, so sollte es sich auch dafür einsetzen und den Product-Owner/Stakeholder darüber aufklären, wie agile Teamarbeit funktioniert.
Der Scrum-Master, sollte er vorhanden sein, muss sich dafür einsetzen, dass dieses Mikromanagement nicht stattfindet, sondern stattdessen ein System nach Scrum aufbauen, das von alleine läuft.
Sollte der Scrum-Master vorhanden sein, so ist es seine Verantwortung, Scrum in der Organisation zu etablieren und alle beteiligten über die Rollen und deren Nutzen aufzuklären.
Es ist die Aufgabe des Scrum-Masters das Team vor direkten eingriffen durch den Product-Owner oder durch Stakeholder zu schützen.
Der Scrum-Master sollte mit dem Team vor allem über Selbstorganisation, Shared-Ownership und Commitment sprechen und agile Werte schulen.