Software-Engineering – agile Pattern und agile Antipattern: Agile Antipattern

Inhalt

Schlechte Meeting- und Kommunikationskultur
Scrummerfall
Waterscrum
Implicit Team-Leadership
Gruppendenken
Gruppen-Quarantäne
Agile-Hype Scrum
Das Monster-Release
Der Bugfixing-Sprint
Visionslosigkeits-Scrum
The Bigger the Better Pattern
Zombie Bugs
Fehlende Definition of Ready
Fehlende Definition of Done

Agile Antipattern

1. Schlechte Meetings- und Kommunikationskultur

Beschreibung des Antipatterns:

Im Unternehmen werden Meetings nicht vorbereitet.
Die Agenda von Meetings ist oft nicht bekannt und die Teilnehmer werden scheinbar wahllos ausgesucht.
Es werden sehr oft Elefantenrunden mit sehr vielen Mitarbeiterinnen aus verschiedenen Unternehmensbereichen veranstaltet.
Das Team ist verteilt und Meetings werden daher oft über Video-Calls abgehalten.
In Online-Meetings werden oft keine Webcams benutzt, daher kann die Gestik und Mimik nicht transportiert werden.
Es wird nicht ein einzelnes universell einsetzbares Tool verwendet. Die Kommunikation läuft daher in parallelen Chats oftmals mit diversen Tools ab
Meetings werden nicht pünktlich begonnen und beendet.

Warum ist das schlecht?

Durch diese Meetings- und Kommunikationskultur entstehen viele Kosten und der Outcome aus diesen Meetings ist oft sehr schlecht.
Nehmen zu viele Mitarbeiter an einer Besprechung teil und stammen diese noch obendrein aus verschiedenen Unternehmensbereichen mit verschiedenen Aufgaben erschwert dies die Kommunikation und die Meetings ziehen sich in die Länge.
Durch die fehlende Struktur der Meetings und die zahlreichen Interessen der beteiligten verlaufen Meetings und Diskussionen oft im Sand.
Mitarbeiter empfinden die Meetings jedoch als mühsam und haben wenig Lust, daran teilzunehmen. Was wiederum die Situation zunehmend verschlechtert.
In Calls ohne Video sind Informationen und Kommunikation über Mimik, Gestik und sozialer Interaktion nur sehr eingeschränkt möglich, das führt zu Missverständnissen und schwächt den Teamzusammenhalt.

Verbesserungen:

Jeder im Team sollten dazu angehalten werden Meetings gut vorzubereiten.
Eine transparente Agenda sollte rechtzeitig vorab an die Beteiligten ausgesendet werden.
Meetings sollten bewusst klein, kurz und effizient gehalten werden
Online-Meetings sollen immer nur mit guter Internetverbindung mit ausreichender Bandbreite durchgeführt werden und dabei muss gutes Audio und Video-Equipment verwendet werden.
Bei Online-Meetings und Online-Konferenzen sollte immer die Webcam eingesetzt werden.
Bevorzugt soll im Unternehmen nur ein Tool für die gesamte Kommunikation benutzt werden.
Um eine gute Meetingkultur und Kommunikationskultur zu etablieren muss jeder mit guten Beispiel vorangehen und selbst immer auf Meetings vorbereitet sein. Im Idealfall werden die Teilnehmer rechtzeitig vor dem Meeting nochmal an das Meeting erinnert.
Meetings sollten immer mit Protokollen stichwortartig dokumentiert und Beschlüsse festgehalten werden. Nach dem Meeting wird diese Dokumentation dann an alle Beteiligten ausgesendet werden.

2. Scrummerfall

Beschreibung des Antipatterns:

Der Sprint wird wie ein kleines Wasserfallprojekt abgearbeitet, zuerst wird eine Planung bis ins letzte Detail durchgeführt, dann wird das Design erstellt, bei dem tonnenweise Diagramme gezeichnet werden und irgendwann danach wird erst mit der Implementierung, dem Testen begonnen.
Die Arbeiten laufen dabei aufgabenbezogen hinter einander ab. Features werden nicht in kleinen Häppchen umgesetzt.
Es gibt zahlreiche Spezialrollen, die immer wieder zueinander Abhängigkeiten haben und aufeinander warten müssen.
Oft wird das Ganze noch auf die Spitze getrieben, indem ein Software-Architekt zunächst das Design selbst erstellt oder zumindest Freigeben muss. Ein enger Flaschenhals entsteht.

Warum ist das schlecht?

In diesem Fall wird zu viel Aufwand in die Planung und das Design der einzelnen Aufgaben gesteckt und ein unnötiger Flaschenhals eingezogen, bei dem die ersten Entwicklungsschritte erst dann gemacht werden dürfen, wenn auch wirklich jedes Feature des Sprints geplant und designt wurde.
Das führt dazu, dass Ressourcen unnötig verschwendet werden.
Werden Freigaben für die einzelnen Phasen benötigt, verzögert das die einzelnen Umsetzungen noch mehr und macht das System ineffektiv weil immer wieder auf gewisse Freigaben gewartet werden muss.

Verbesserungen:

Planung zu Beginn ist wichtig. Aber nur so viel wie unbedingt nötig und so wenig wie möglich.
Das Umsetzungsteam organisiert sich die Arbeit selbst und entscheidet selbst, wie und wann es etwas machen möchte.
Besteht wirklich der Bedarf an einer gesonderten Architektenrolle, so sollte dies integriert im Team verfügbar sein und immer mitarbeiten.
User-Stories werden featureorientiert beschrieben, einzeln umgesetzt und abgeschlossen (nicht in Phasen, wo alle Tickets designt werden, bevor das erste implementiert werden darf).
Das Team sollte sich auf die Fertigstellung der einzelnen User-Stories konzentrieren und lieber einmal etwas mehr umsetzen und ausprobieren, als einmal etwas zu viel zu geplanten, was dann überhaupt nicht benötigt vom User wird.
Es sollten Tools zur Unterstützung von Test- und Deployment-Automatisierung verwendet werden, das macht das Erstellen und Ausliefern der Software einfach und kann somit das Feedback beschleunigen.
Das Team sollte Scrum-Metriken wie beispielsweise Cycletimes von Stories, Team Velocity und umgesetzte Storypoints tracken und interpretieren.

3. Waterscrum

Beschreibung des Antipatterns:

Bei diesem Antipattern werden Wasserfallmethoden über eine agile Umsetzung gestülpt.
Es werden Meilensteine geplant, die eingehalten werden müssen, exzessiv dokumentiert und Risikomanagement betrieben.
Scrum wird somit nur als Umsetzungsmethode verwendet und das agile Mindset unterdrückt und in einem Phase-Gate-Prozess eingesperrt.
Oftmals wird das Ganze dann noch von einem Projektmanager organisiert, der Deadlines vergibt, Arbeitsprozesse überwacht und Arbeitsergebnisse kontrolliert

Warum ist das schlecht?

Ein derartiges Setup versucht dem Team agiles Arbeiten zu ermöglichen, das Management vertraut diesem Mindset jedoch nicht und setzt zur Kontrolle und Steuerung Projektmanager ein. Dadurch wird einerseits Misstrauen gezeigt, was schlecht für die Motivation der Mitarbeiter ist, andererseits werden Systemkonflikte geschaffen, die automatisch zu Reibungen führen und ineffizient sind.
Scrum hat als Ansatz, dass Zeit und Funktionsumfang des Projekts schrittweise elaboriert wird, jeder Sprint jedoch die bestmögliche Qualität liefert. Bei Wasserfallmethoden andererseits sind Zeit und Funktionsumfang fix, was wiederum oft auf die Qualität der Arbeit drückt.

Verbesserungen:

Das Motto sollte hier „ganz oder gar nicht“ sein. Es sollte nur agil vorgegangen werden.
Das Managementteam sollten keine Meilensteine verwendet, sondern sich an den Userwünschen orientieren und einen Product-Owner/Produktmanager einstellen.
Gemeinsam mit dem Team sind dann Hypothesen aufzustellen und diese durch Experimente und Feedback der User bestätigt oder widerlegt werden. Das gesammelte Feedback muss dann zurück in die Produktentwicklung fließen.
Diese Vorgehensweise produziert schnell umgesetzte fertige Releases mit ständig anwachsendem Mehrwert für den User und macht ein übergeordnetes Risikomanagement unwichtiger.
Skeptische Stakeholder und Sponsoren müssen vom Scrum-Master und Product-Owner in das Sprint-Review eingebunden werden.
Die Arbeit des Scrum-Teams muss für sich sprechen und alle Bedenken der Stakeholder beseitigen.

4. Implicit Team-Leadership

Beschreibung des Antipatterns:

Im Team gibt es einen oder mehrere Experten, die bestimmen, wie die Umsetzung erfolgen soll.
Das restliche Team richtet sich nach diesen Expertenmeinungen aus und setzt die Stories nach deren vorgaben um.
Das Knowhow wird bei den Experten konzentriert.
Diskussionen werden gescheut, um Konflikte mit Experten zu vermeiden.
Die Umsetzung der Stories wird oft ausgebremst, weil Experten der Flaschenhals sind und diese nicht alles gleichzeitig machen/entscheiden können

Warum ist das schlecht?

Durch dieses Antipattern wird einerseits der Entwicklungsfortschritt gebremst, die Umsetzung kommt somit langsamer voran, als es eigentlich sein könnte, andererseits wird Expertenwissen aufgebaut und eine Abhängigkeit entsteht gegenüber den Meinungsmachern.
Dabei werden jene Mitarbeiter, die sich zurückhalten, aktiv klein gehalten und können nur sehr wenig bzw. langsam dazu lernen.
Durch die eingeschüchterten Mitarbeiter geht auch viel Meinungsvielfalt verloren, was ggf. zu Problemen führen kann, weil kreative, besser Alternativlösungen dabei nicht zur Sprache gebracht werden.

Verbesserungen:

Der Scrum-Master oder Agile-Coach muss bewusst in das Geschehen eingreifen, aktiv moderieren und das Team coachen.
User-Stories müssen so verteilt werden, dass das Team das Wissen verteilen und Verantwortung streuen.
Die Verantwortung für die Umsetzung muss im gesamten Team geteilt werden, jeder ist für den Erfolg oder Misserfolg des Sprints verantwortlich.
Um einen Wissenstransfer zu ermöglichen, kann das Team gemeinsam Aufgaben modellieren und planen und zu zweit oder in der Gruppe arbeiten; dazu empfiehlt sich beispielsweise Pair- oder Mobprogramming.
Der Scrum-Master/Agile-Coach soll aktiv die Sprint-Plannings moderieren, um „schwächeren“ Teammitgliedern die Möglichkeit zu bieten, etwas beizutragen.

5. Gruppendenken

Beschreibung des Antipatterns:

Bei diesem Antipattern ordnen einzelne Teammitglieder die eigenen Meinungen und Wünsche aufgrund des Gruppenzwangs an die Meinung der Gruppe unter.

Warum ist das schlecht?

Durch diesen Druck wird die Vielfalt an individuellen Erfahrungen und Kreativität gebremst.
Entscheidungen und Strategien werden monotoner, dadurch wird das Risiko, dass das Produkt in eine falsche Richtung entwickelt wird, erhöht.
Potenziell bessere Lösungen werden nicht besprochen und nicht umgesetzt.

Verbesserungen:

Am besten wirkt der Scrum-Master/Agile-Coach durch aktives Coaching und Moderation in Meetings diesen Antipattern entgegen und schaut, dass auch alternative Meinungen zu den diskutierten Themen zur Sprache gebracht werden.
Es können auch Abstimmungsmethoden wie Planningpoker oder Tools zur Anonymisierung verwendet werden. (anonymer Ideenkasten)

6. Gruppen-Quarantäne

Beschreibung des Antipatterns:

Das Team bleibt lieber unter sich, es schottet sich ab und ist nicht an Austausch mit anderen interessiert.
Ein Austausch mit anderen Ideen ist uninteressant oder wird als Bedrohung gesehen.
Dieses Verhalten besteht meist aufgrund von organisatorischen Altlasten und Silodenken, welches oft in großen Konzernen, die noch nach alten Manieren geführt werden, zu finden sind.
Das Team hat auch keine gute Informationsbeschaffungskultur und tut sich schwer, externe Informationen zu organisieren und diese im Team zu verbreiten.

Warum ist das schlecht?

Austausch mit anderen Fachabteilungen und Experten kann oft das eigene Team und das Projekt richtungsweisend verändern. Probleme können oft schneller und eleganter gelöst werden, wenn das Team auch Experten von außen ins Boot holt. Wird diese Möglichkeit verweigert, so kocht das Team sehr sein eigenes Süppchen.
Die einfachsten Lösungen werden dann oft nicht gefunden und die Entwicklung kann eine falsche Richtung einschlagen.

Verbesserungen:

Der Scrum-Master sollte das Team ermutigen, sich auch externe Hilfe zu organisieren.
Gerade in großen veralteten Organisationsstrukturen kann es sehr hilfreich sein, Expertenwissen anderer Abteilungen abzugreifen und ins Projekt einfließen zu lassen.
Externes Knowhow kann am besten punktuell bei konkreten Fragestellungen eingeholt werden. Dazu sollten diese Fragen aber auch gut vorbereitet werden.
Neue Teammitglieder sollten ins Team gut integriert werden.
Ein guter Tipp sind auch lockere Events, die den Wissensaustausch erleichtern wie beispielsweise Stammtische und Tech-Events.
Externes Knowhow muss aber nicht unbedingt durch Personen direkt eingebracht werden, sondern kann auch durch textuelle Quellen gesammelt werden. Dazu kann das Team einen eigenen Chat zum Teilen interessanter Blogartikeln im Team verwenden.
Das Team kann sich gegenseitig ermutigen Fachbücher zu lesen und sich gegenseitig gute Fachbücher empfehlen bzw. ausleihen.

7. Agile-Hype Scrum

Beschreibung des Antipatterns:

Scrum und die agile Arbeitsweise werden nur als Hype-Themen gesehen. Das Unternehmen setzt jetzt aber auch auf agile Methoden, um ebenfalls „cool“ zu sein und gut bei den Bewerbern und Mitarbeitern anzukommen. Der Nutzen und das Mindset werden jedoch nicht gesehen oder nicht verstanden.
Im Grunde lehnt das Unternehmen und vor allem die Führung des Unternehmens agile Methoden ab oder hat die agile Arbeitsweise nicht verstanden. Es besteht in deren Augen auch kein bedarf da bisher auch alles funktioniert hat.
Es herrscht kein agiles Mindset im Unternehmen vor. Die Führung muss dem Unternehmen aber einen agilen Anstrich verpassen, um neue Mitarbeiter zu finden.

Warum ist das schlecht?

Besteht wirklich seitens der Führung kein Interesse, das Unternehmen in einem agilen Transformationsprozess zu führen, sondern wird nur ein agiler Anstrich durchgeführt, fällt dies den Mitarbeitern sofort auf. Diese Scheinveränderung wird als sehr unangenehm wahrgenommen und führt im schlimmsten Fall dazu, dass bestehende Mitarbeiter frustriert und verärgert das Unternehmen verlassen.
Es entstehen auch automatisch Spannungen innerhalb der Organisationsstrukturen, weil die agile Arbeitsweise Freiheiten verspricht, die dann seitens des Managements nicht eingehalten werden.
Bewerber werden auch in kürzester Zeit schon im Gespräch stutzig. Falls nicht, fällt der Schwindel dann spätestens in den ersten Monaten im neuen Job auf.

Verbesserungen:

Gerade Scrum-Master sind die ersten, die in derartigen Situationen oft als Erstes eingestellt werden. Der Scrum-Master muss agile Bekehrungsarbeit leisten und auf allen Ebenen im Unternehmen dafür sorgen, dass agile Prinzipien, das agile Mindset und Scrum richtig verstanden werden.
Er muss die Vorteile der agilen Arbeitsweise und von Scrum immer wieder betonen, bis sie sich im Unternehmen und im Mindset der Agierenden manifestieren.

8. Das Monster-Release

Beschreibung des Antipatterns:

Es wird zwar agil entwickelt und fleißig Sprint für Sprint ein Release-Candidate erzeugt, dieser wird aber nie veröffentlicht und gelangt somit nie zum User.
Die Release Candidates werden auch keinen Key-Usern präsentiert und somit wird auch kein Feedback gesammelt.
Oft hört man Aussagen wie: Es werden noch Feature „zusammengesammelt“ für das „minimale Release“.
Als Ausrede, um seltener Releases erstellen zu müssen, wird oft ein zu hoher Aufwand für die Erstellung dieser Releases verwendet.

Warum ist das schlecht?

Feedback ist eines der Kernelemente agiler Methoden. Agile Produktentwicklung basiert darauf, dass Hypothesen zum Produkt und zu Nutzerbedürfnissen gemacht werden und diese Hypothesen dann schnellstmöglich durch User bestätigt oder falsifiziert werden.
Wird kein Nutzerfeedback eingesammelt, kann somit kein Wissen in die Entwicklung zurückfließen. Es wird daher eher das entwickelt, was sich der Product-Owner denkt, nicht das, was der User wirklich benötigt. Dies resultiert in sehr hohen Entwicklungskosten und in Produkten, die keinen Product-Market-Fit finden. Daraus kann dann ein erheblicher wirtschaftlicher Schaden entstehen.

Verbesserungen:

Um den Aufwand für das Erstellen eines Releases zu minimieren, sollte das Team nach hoher Toolunterstützung streben, um möglichst vollautomatisch Buildes erstellen zu können und Deployments durchzuführen.
Da vor jedem Release erhebliche Aufwände beim Testen anfallen, empfiehlt sich die Verwendung von Testautomatisierung. Dadurch können Testaufwände minimiert und eine hohe Qualität der Software sichergestellt werden.
Da das Einholen von Userfeedback immer schwierig und langwierig ist, lohnt sich die Entwicklung von Staging-Konzepten und der Einsatz mehrere Stages wie Dev-Stages, QA-Stages und Prod-Stages.
Der Product-Owner und Scrum-Master müssen gemeinsam mit dem Team in eine Routine finden, in der regelmäßig Releases nach jedem Sprint produziert werden und in die QA-Stage deployed werden. Dann kann das Team und vor allem der Product-Owner Feedback von Testuser einholen und dieses Wissen wieder in die Entwicklung zurückfließen lassen.

9. Der Bugfixing-Sprint

Beschreibung des Antipatterns:

Das Team schiebt immer Bugs vor sich her, denn die Entwicklung von Features ist scheinbar wichtiger.
Es wird auch nicht wirklich getestet, deswegen sammeln sich so viele Bugs an, dass sie gesammelt in einen Sprint abgearbeitet werden müssen.

Warum ist das schlecht?

Dieses Antipattern ist deswegen besonders schlecht, weil sich im Laufe der Zeit die Probleme mehr und mehr ansammeln. Der Bug-Sprint ist dabei nicht die „Krankheit“, sondern nur das „Symptom“. Der eigentliche Auslöser für dieses Antipattern ist die Einstellung des Teams gegenüber dem Testen und der Qualität der Software. Durch das dauerhafte vernachlässigen von Codequalität und Produktqualität durch das spärliche Testen und das „ignorieren“ bestehender Bugs entsteht ein Teufelskreislauf. Dieser kostet viel Energie und Zeit und verursacht dadurch enorme Kosten. Des Weiteren wird es zunehmend schwerer, diesen Kreislauf zu durchbrechen, für eine gute Codebasis zu sorgen, Unit-Tests und Integrationstests nachträglich einzubauen und die Testautomatisierung nachzuziehen.
Ein weiterer Nachteil ist, dass Bugs sehr schwer zu schätzen sind und dadurch der Bug-Sprint nicht gut geplant werden kann.
Große Architekturänderungen oder Nachbesserungen sind ebenso schwer einzuschätzen, was wiederum die Planbarkeit verschlechtert.
Ist das Team erst einmal bei den Stakeholdern unter Beobachtung und wird dann der Refactoring- und Bug-Sprintplan auch nicht eingehalten, führt dies zu einen weiteren schweren Vertrauensverlust.
Außerdem sollte ein Team laufend neuen Mehrwert liefern, dies ist in einer Bugfixingphase wie dieser leider nicht möglich, was ebenfalls Missgunst bei den Stakeholdern hervorrufen kann.

Verbesserungen:

Um gar nicht erst in eine derartige Situation zu gelangen, sollten Bugs immer und ständig ausgebessert werden, sobald sie gefunden werden.
Damit dies gut möglich ist, sollte in jedem Sprint etwas Zeit für Stabilisierung und Bugfixing eingeplant werden.
Das Team sollte sich immer sofort und gleich um Codequalität, Produktqualität und ums Testen bzw. das Schreiben von Tests kümmern.
Die Inkremente sollten bei jedem Sprint released werden.
Feedback sollte früh und regelmäßig eingeholt werden, da auch User des Öfteren Bugs und Fehler finden, die das Umsetzungsteam gar nicht finden kann.

10. Visionslosigkeits-Scrum

Beschreibung des Antipatterns:

Das Team setzt Features um, die nur sehr lose zusammenpassen. Ein roter Faden ist nicht erkennbar, denn es fehlt eine größere Vision.
Neue Features werden auf Biegen und Brechen integriert, egal wie gut sie zum bestehenden Produkt dazu passen

Warum ist das schlecht?

Fehlt eine Umsetzungsstrategie und werden Features in scheinbar wahlloser Reihenfolge umgesetzt, so erhöht sich das Risiko, dass das Produkt letzten Endes nicht die Wünsche der User befriedigt, zu komplex wird und somit keinen Product-Market-Fit findet.
Features, die nicht gut zum Kernprodukt passen, aber dennoch entwickelt werden, jedoch für den Nutzer keinen Mehrwert darstellen, sind die teuersten Kostentreiber. Denn es fallen Aufwände für Entwicklung, Wartung und Betrieb an, doch der Mehrwert ist für den User nicht vorhanden.

Verbesserungen:

Die Vision und die Product-Roadmap müssen expliziter gemacht werden und transparent dem Team präsentiert werden.
Features müssen abgestimmt sein und in der richtigen Reihenfolge mit der richtigen Priorität abgearbeitet werden.

11. The Bigger the Better Pattern

Beschreibung des Antipatterns:

Dies ist ein häufig auftauchendes agiles Antipattern erfolgreicher Produkte, das Team arbeitet Sprint für Sprint immer weiter am Produkt.
Das bereits gut aufgebaute Produkt wird ständig erweitert, neue Features kommen hinzu.
Bestehende Features werden laufend erweitert und noch komplexer und mächtiger gemacht.
Der Kernnutzen des Produkts und die Anzahl der verwendeten Features ändern sich aber kaum und die neuen Erweiterungen kommen nicht beim User an.

Warum ist das schlecht?

Der Kern von Produktmanagement liegt darin, den Product-Market-Fit zu finden und zu behalten. Dabei kann dieser sich im Laufe der Zeit ändern, weil die Konkurrenz aufholt oder sich Bedürfnisse der User ändern. Dem gegenüber steht aber dieses Antipattern. Wenn der Product-Market-Fit bereits erreicht ist und sich im Umfeld nichts ändert, macht es keinen Sinn das Produkt mehr und mehr zu verfeinern und komplexer zu machen, denn dadurch kann der User verwirrt werden und somit auch der Product-Market-Fit verloren gehen.
Wenn dies passiert und das Team mehr und mehr Features umsetzt, wird dies sehr schnell zum Teufelskreis und es wird viel Aufwand in ein Produkt investiert, jedoch keine Lösung gefunden. Denn die Lösung wäre, Features zu vereinfachen und anzureichern. Im schlimmsten Fall wird das Produkt so komplex, dass kein User es mehr verwenden will.

Verbesserungen:

Der Product-Owner sollten sich an die grundlegenden Konzepte der Produktvision halten und gemeinsam mit dem Team die Kernfeatures möglichst simplifiziert umsetzen und durch Experimente und Userfeedback jene Bereiche identifizieren, die verfeinert werden müssen.
Feedback von den Usern muss regelmäßig nach jedem Sprint eingeholt und evaluiert werden.
Bevor neue Features umgesetzt werden, sollten Key-User mithilfe von Papierprototypen befragt werden und somit der eigentliche Nutzen für die User evaluiert werden. Stellt sich ein Feature als nicht so notwendig heraus, muss dieses nicht unbedingt umgesetzt werden.
Es empfiehlt sich, automatische Metriken zur Verwendung von einzelnen Features zu erfassen und diese regelmäßig auszuwerten. Features, die nicht oft aufgerufen werden, brauchen nicht erweitert werden.

12. Zombie Bugs

Beschreibung des Antipatterns:

Das Produkt wird stiefmütterlich behandelt und Bugs werden nicht mehr behoben. Somit häufen sich Bugs und die Userzufriedenheit sinkt.
Meist liegt dies daran, dass das Umsetzungsteam nach der ersten Entwicklungsphase stark reduziert wurde und einzelne Teammitglieder auf andere Projekte verplant wurden. Für die Wartung ist schlicht nicht so viel Zeit vorgesehen und somit können Bugs nicht so schnell bearbeitet werden.
Das Team hat oft auch keine Lust mehr am „alten“ Projekt zu arbeiten und Fehler auszubessern, weil es bereits spannendere neue Projekte gibt und die Zeit für das alte Projekt ohnehin knapp bemessen ist.

Warum ist das schlecht?

Wurde das Produkt erst einmal soweit entwickelt, dass es marktreif ist und aktiv von Usern eingesetzt wird, wäre es eine große Verschwendung, es jetzt verkommen zu lassen.
User reagieren sehr empfindlich darauf, wenn Bugs nicht schnellstmöglich beseitigt werden. Wenn sie sich vom Produkt abwenden und Negativwerbung machen, kann dies zu einem großen wirtschaftlichen Schaden führen.

Verbesserungen:

In dieser Situation empfiehlt es sich, Bugtrackingtools zu verwenden und Metriken wie Cycletimes der Bugtickets zu beachten.
Den Usern muss es möglichst einfach gemacht werden, Bugs einzumelden und im Idealfall den Bearbeitungsstatus einzusehen.
Es muss ein einsatzfähiges Team geben, mit ausreichend Kapazitäten, um regelmäßig Wartungsarbeiten durchzuführen und Bugs zu fixen.
Im Team muss das Bewusstsein geschaffen werden, dass Bugfixing auch zum Software-Engineering dazu gehört und genauso wichtig ist wie neue Projekte zu implementieren.
Um die Last gleichmäßig im Team zu verteilen, kann eine rotierende Zuweisungsmethode gewählt werden, bei der den einzelnen Teammitgliedern der reihe nach Bugtickets bekommen.
Der Scrum-Master und das Management sollten auch den Sinn des Teams für die gemeinsame Ownership des Codes und somit auch der Bugs stärken.

13. Fehlende Definition of Ready

Beschreibung des Antipatterns:

Das Umsetzungsteam und der Product-Owner haben keine Definition of Ready (=DoR) etabliert und diskutieren oft aneinander vorbei, was die Spezifikation und Planbarkeit von PBIs angeht.

Warum ist das schlecht?

Gibt es keine Definition of Ready (=DoR) können zahlreiche Probleme auftreten.
Die Definition of Ready ist ein Regelwerk oder ein Vertrag zwischen Team und PO wie ein Product-Backlog-Item (=PBI) aussehen soll, um es richtig verstehen und umsetzen zu können.
Ein mögliches Problem: Der Product-Owner sagt, er habe das Backlog-Item bereits beschrieben und das Team solle es umsetzen, dem Team fehlen aber noch Informationen und es versteht das PBI nicht.
Es könnte auch sein, dass das Scrum-Team unterschiedlich ausspezifizierte PBIs (Product-Backlog-Items) in den Sprint aufnimmt. Die Definition eines ausspezifizierten PBIs für den Product-Owner kann aber eine andere sein als die für das Team und somit haben Team und PO unterschiedliche Erwartungshaltungen an das Product-Backlog-Item. Das führt immer wieder zu Missverständnissen. Diese Missverständnisse treten im schlimmsten Fall erst dann zutage, wenn das PBI bereits umgesetzt wurde, nur leider nicht so, wie es sich der PO vorgestellt hat.
Oder Sprintziele werden nie eingehalten, weil das Team PBIs zu implementieren beginnt, bei der Implementierung aber Fragen auftreten und das Team dementsprechend sehr oft Rücksprache zum PO halten muss. Ist dieser nicht erreichbar, so muss das Team ein anderes PBI anfangen. Es kommt zu Multitasking und dies führt zu Fehler, verbrannten Budget und resultiert in nicht eingehaltenen Sprintzielen.

Verbesserungen:

Eine Definition of Ready sollte gemeinsam mit PO und Umsetzungsteam erstellt werden.
In der Definition of Ready sollten sich alle Regeln wiederfinden, die durchgeführt werden müssen, um das PBI in einen Ready-Status zu bringen und somit das PBI im Sprint verplanen zu können.
Sind ausreichend Informationen über ein PBI gesammelt und wurde das PBI in einem Refinement-Meeting vom gesamten Team verstanden, so kann es in den Ready-Status gesetzt werden.
Der Ready-Status heißt, dass das PBI alle Regeln der DoR erfüllt und im Sprint verplant und umgesetzt werden kann.
Ins Sprint-Planning und somit auch in die Umsetzung dürfen nur PBIs gelangen, die die DoR erfüllen.

14. Fehlende Definition of Done

Beschreibung des Antipatterns:

Ein Scrum-Team hat keine Definition of Done (=DoD) und hat nicht mit dem PO über den Level von „Fertig“ gesprochen, oder schlimmer noch, einzelne Team-Mitglieder haben unterschiedliche Auffassungen davon, wann etwas „fertig“ ist.
Beispielsweise kann „fertig“ für den einen heißen, dass ein Feature implementiert ist, aber noch getestet werden muss, für den anderen heißt es, dass das Feature bereits auf der Dev-Stage ist und für den PO heißt fertig, dass ein Feature in der Produktivumgebung ist und von Testusern getestet wird.

Warum ist das schlecht?

Die fehlende gemeinsame Meinung von „fertig“ und vor allem was alles getan werden muss, damit etwas „fertig“ ist, führt zu Missverständnissen und Konflikten im Team und mit dem Product-Owner.
Zusatzaufwände für Kommunikation und erneutes Aufrollen bereits abgeschlossener Tickets häufen sich an und lassen die Entwicklungskosten steigen.
Konflikte schaden dem Projektfroschritt und verursachen ebenfalls Kosten.
Durch fälschlicherweise frühzeitig an die Stakeholder kommunizierte Erfolge sinkt das Vertrauen in das gesamte Umsetzungsteam inklusive Scrum-Master und Product-Owner.

Verbesserungen:

Das Team muss gemeinsam mit dem Product-Owner klären, was es heißt ein Feature ist „fertig“.
Des Weiteren fließt in die DoD viel technischer Input.
Meist gibt es von der Software-Engineering Organisation des Unternehmens ein Minimalset an Regeln, die die DoD umfassen muss. Hier werden dann Regeln erfasst ,die beispielsweise dann festlegen, dass jede Änderung und jedes neue Feature ein Code-Review durchlaufen muss oder dass neue Features erst dann als abgeschlossen gelten, wenn sie im Master-Branch des Git-Repositories gemerged wurden.
Die DoD des Umsetzungsteams und des POs erweitern dann diese Minimalregeln und das gesamte Scrum-Team einigt sich auf die Einhaltung dieser Regeln, die dann quasi einen Vertrag darstellen.
Ins Sprint-Review dürfen nur PBIs bzw. Features, die die DoD erfüllen.