Software-Engineering Pattern und Antipattern: Agile Antipattern

Inhalt

  1. Schlechte Meeting- und Kommunikationskultur
  2. Scrummerfall
  3. Waterscrum
  4. Implicit Team-Leadership
  5. Gruppendenken
  6. Gruppen-Quarantäne
  7. Agile-Hype Scrum
  8. Das Monster-Release
  9. Der Bugfixing-Sprint
  10. Visionslosigkeits-Scrum
  11. The Bigger the Better Pattern
  12. Zombie Bugs
  13. Fehlende Definition of Ready
  14. Fehlende Definition of Done

Agile Antipattern

  • Meetings werden nicht vorbereitet
  • Das Team ist verteilt und Meetings/Kommunikation werden daher oft über Chats/Calls abgehalten
  • Die Kommunikation läuft in parallelen Chats oftmals mit diversen Tools ab
  • 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:

  • Nutzung von gutem Audio und Video-Equipment
  • Meetings und Konferenzen nur mit Webcam
  • Bevorzugt nur ein Tool und einen Channel für die gesamte Kommunikation nutzen
  • Bevorstehende Termine planen (Meeting-Kultur schaffen/stärken)
  • Selbst immer auf Meetings vorbereiten, mit gutem Beispiel vorangehen und Teilnehmer rechtzeitig vor dem Meeting erinnern.
  • Meetings mit Protokollen stichwortartig dokumentieren und Beschlüsse festhalten
  • Der Sprint wird wie ein kleines Wasserfallprojekt abgearbeitet, zuerst die Planung bis ins letzte Detail, dann das Erstellen des Designs es werden Diagramme erstellt, etc. dann erst die Implementierung das Testen und das Releasen.
  • Arbeiten laufen hautsächlich sequenziell ab und nicht parallel in kleinen Häppchen

Verbesserungen:

  • Planung zu Beginn ist wichtig. Aber nur so viel wie unbedingt nötig und so wenig wie möglich.
  • Das Umsetzungs-Team organisiert sich die Arbeit Wie und Wann es etwas macht selbst.
  • User-Stories werden einzeln abgeschlossen (kein zusammenwarten) aber parallel umgesetzt (nicht eines nach dem anderen).
  • Das Team sollte sich auf die Fertigstellung der einzelnen User-Stories konzentrieren.
  • Verwende Tools zur Unterstützung von Test- und Deployment-Automatisierung
  • Tracking von Scrum-Metriken wie Cycletimes von Stories
  • Wasserfallmethoden werden über eine agile Umsetzung gestülpt
  • Es werden Meilensteine geplant, die eingehalten werden müssen und 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.

Verbesserungen:

  • keine Meilensteine verwenden, sondern an den Userwünschen orientieren
  • Schnelle wirklich fertige Releases mit ständig anwachsendem Mehrwert für den User machen ein Risikomanagement sinnlos.
  • Bindet skeptische Stakeholder und Sponsoren in das Sprint-Review ein
  • Im Team gibt es einen oder mehrere Experten, die beeinflussen und 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 das Bottleneck sind und diese nicht alles gleichzeitig machen/entscheiden können

Verbesserungen:

  • Commitment und Entscheidungen des gesamten Teams auf die Umsetzung
  • Scrum-Master oder Agile-Coach, coached das Team, dass es User-Stories so verteilt, dass diese das Wissen verteilen und Verantwortung streuen.
  • gemeinsames agiles Modelling zu zweit oder in der Gruppe
  • Einsätzen und verwenden von Pair- oder Mobprogramming
  • Aktive Moderation von Plannings durch Scrum-Master/Agile-Coach um „schwächeren“ -Teammitgliedern die Möglichkeit zu bieten etwas beizutragen
  • eigene Meinungen und Wünsche werden aufgrund des Gruppenzwangs an die Meinung der Gruppe angepasst.
  • Dadurch wird die Vielfalt an individuellen Erfahrungen und Kreativität gebremst

Verbesserungen:

  • Aktive Moderation von Scrum-Master/Agile-Coach in Meetings
  • Nutzen von Abstimmungsmethoden wie Planningpoker oder Tools zur Anonymisierung
  • 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

Verbesserungen:

  • Externes Knowhow punktuell bei Fragesellungen ins Team holen
  • Neue Teammember ins Team holen
  • Wissensaustausch durch Stammtische und Tech-Events
  • Teilen interessanter Blogartikeln im Team
  • Scrum und die agile Arbeitsweise werden nur als Hype-Themen gesehen, Unternehmen machen jetzt mit, um auch „cool“ zu sein und gut bei den Bewerbern und Mitarbeitern anzukommen. Der Nutzen und das Mindset werden jedoch nicht gesehen und verstanden.
  • Im Grunde lehnt das Unternehmen und vor allem die Führung des Unternehmens agile Methoden und Scrum ab.

Verbesserungen:

  • 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.
  • Es wird zwar agil entwickelt und brav Sprint für Sprint ein Release-Candidate erzeugt, dieser wird aber nie veröffentlicht und gelangt somit nie zum User.
  • Es werden noch „Features zusammengesammelt“ für das „minimal Release“
  • Nutzerfeedback wird dementsprechend nicht eingesammelt und kann somit nicht in die Entwicklung zurückfließen. Es wird daher eher das Entwickelt was der Product-Owner denkt, nicht das was der User benötigt.

Verbesserungen:

  • Toolunterstützung, um automatische Buildes und Deployments durchführen zu können.
  • Verwenden von Testautomatisierung zur Sicherstellung hoher Qualität der einzelnen Releases
  • Einsatz von Staging-Konzepten Dev-Stages, QA-Stages und Prod-Stages.
  • Regelmäßiges Releasen und einholen von Feedback der Testuser
  • Bugs werden immer vor sich hergeschoben, denn die Entwicklung von Features ist wichtiger.
  • Es wird auch nicht wirklich getestet, deswegen sammeln sich so viele Bugs an, dass sie gesammelt in einen Sprint abgearbeitet werden.
  • Bugs sind aber schwer zu schätzen und daher kann der Sprint nicht gut geplant werden.

Verbesserungen:

  • Bugs sollten immer und ständig sobald sie gefunden werden ausgebessert werden.
  • In jedem Sprint sollte etwas Zeit für Stabilisierung und Bugfixing eingeplant werden.
  • Das Team sollte sich immer sofort und gleich um Codequalität, und Produktqualität und Testen kümmern
  • Die Inkremente sollten bei jedem Sprint released werden.
  • Feedback sollte früh und regelmäßig eingeholt werden
  • Es werden nur Features umgesetzt die lose zusammenpassen aber eine größere Vision fehlt.
  • Neue Features werden auf Biegen und Brechen integriert egal wie gut sie zum bestehenden Produkt dazu passen

Verbesserungen:

  • Die Vision 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 und mit der richtigen Priorität abgehandelt werden.
  • Das bereits gut aufgebaute Produkt wird ständig erweitert, neue Features kommen hinzu
  • Bestehende Features werden laufend erweitert und noch besser 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.

Verbesserungen:

  • Halten Sie sich an die grundlegenden Konzepte und Visionen des Produkts
  • Holen sie sich regelmäßig Feedback von Usern ein
  • Prüfen sie bei Befragungen von Key-Usern mit Papierprototypen ob neue Features gut ankommen und gebraucht sind.
  • erfassen sie automatische Metriken zur Verwendung von einzelnen Features und werten sie diese regelmäßig aus. Features, die nicht oft aufgerufen werden, brauchen nicht erweitert werden.
  • Das Produkt wird stiefmütterlich behandelt und Bugs werden nicht mehr behoben. somit häufen sich Bugs an und die Userzufriedenheit sinkt

Verbesserungen:

  • Verwendung von Bugtracking-Tools
  • ermöglichen einer Einfachen Art und Weise wie User Bugs melden können
  • Schaffung von Kapazitäten im Team zum Bugfixen
  • Schaffung von einem Bewusstsein, dass Bugfixing auch zum Software-Engineering dazu gehört
  • Rotierende Verteilung im Team von Bugfixing
  • Sinn für gemeinsame Ownership des Codes und somit auch der Bugs.
  • 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.
  • Ein weiteres Problem könnte sein: Das Scrum-Team nimmt unterschiedlich ausspezifizierte PBIs (Product-Backlog-Items) in den Sprint auf. Die Definition eines Ausspezifizierten PBIs für den Product-Owner ist eine andere 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 zu Tage, wenn das PBI bereits umgesetzt wurde, nur leider nicht so, wie es sich der PO vorgestellt hat.
  • Oder es äußert sich so: Sprintziele werden nie eingehalten, weil das Team PBIs beginnt zu implementieren; 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 nicht eingehaltenen Sprint-Zielen.

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.
  • 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, das PBI erfüllt alle Regeln der DoR und kann im Sprint verplant und umgesetzt werden.
  • Ins Sprint-Planning und somit auch in die Umsetzung dürfen nur PBIs gelangen die die DoR erfüllen.
  • 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.
  • Beispielswiese kann „fertig“ für den einen heißen, ein Feature ist Implementiert aber muss noch getestet werden, für den anderen heißt es das Feature ist bereits auf der Dev-Stage, und für den PO heißt fertig ein Feature ist in Produktivumgebung und wird von Testusern getestet.
  • 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

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 solche Dinge geregelt wie, dass jede Änderung und jedes neue Feature ein Code-Review haben musste; 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 diese Regeln, die dann Quasi einen Vertrag darstellen.
  • Ins Review dürfen nur PBIs bzw. Features, die die DoD erfüllen.

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: