mabuco ...bloggt - 03/2023

How NOT to do agile! Praktische Lösungen für häufige Probleme

28. März 2023 | Martin Stingelin

Wir erleben immer wieder, wie agile Projekte in Schieflage geraten. Liegt dies an den agilen Methoden oder an den Menschen?
Richtig, es ist der menschliche Faktor. Gerade agile Methoden stellen hohe Anforderungen an die Professionalität aller Beteiligten, verfügen aber auch über die notwendigen Mittel, um solche Schieflagen zu verhindern, diese Mittel müssen aber konsequent genutzt werden.

Nehmen wir das agile Manifest als Ausgangsbasis (siehe auch http://agilemanifesto.org)

Individuals and Interactions over processes and tools – Individuen und Interaktionen stehen über Prozessen und Werkzeugen

Problem - Fehlen echter Kommunikation und Interaktion:
Einwegkommunikation mit der Kommentierungsfunktion in den eingesetzten Werkzeugen, führt zu unübersichtlichen Tickets in denen wichtige Informationen versteckt sind und zu Aussagen wie «Ich habe das schon vor 2 Monaten im Ticket dokumentiert».

Lösung:

Echte Kommunikation nutzen. Unklare Punkte von Angesicht zu Angesicht klären (Stand-ups, Planning-Meetings, Refinements, Reviews, virtuelle Meetings, Telefonate) und die essenziellen Fakten und Entscheide am richtigen Ort im Ticket festhalten.

Working software over comprehensive documentation –

funktionierende Software steht über umfassender Dokumentation

(Das ist keine Entschuldigung keine oder schlechte Dokumentation zu liefern).

Problem - Zu viel, nicht zielführende Dokumentation/Information:
Es gibt agile Projekte, in welchen mehr Dokumentationen, Informationen in Wikis, Ticketing-Tools und sonstigen Ablagen verstreut vorhanden sind, als für eine gute Systemdokumentation überhaupt nötig wären.

Lösung:

  • Einfache verständliche Vorgaben, was wo und wie dokumentiert werden soll.
  • Ausformulierte, verständliche Anforderungen, zum Beispiel auf Basis der Sophist-Schablone (https://www.sophist.de).
  • User Stories um klarzumachen, wer was wozu braucht.
  • Eindeutige messbare und durch Tests belegbare Akzeptanzkriterien.

Problem - Missverständnisse werden zu spät erkannt:
In Reviews oder bei Tests durch den Kunden zeigt sich, dass zu Beginn der Entwicklung noch zu viel unklar war und dies in der Entwicklung mit Annahmen kompensiert wurde.

Lösung:

  • Unklarheiten mit dem PO (Product Owner) im Planning besprechen.
  • Nutzen einer DoR (Definition of Ready) um sicherzustellen, dass alle für die Entwicklung notwendigen Informationen vorhanden sind. 
  • Refinements durchführen, um offene Punkte und Verständnisfragen zu klären.

Problem – Lehren aus Fehlern werden nicht gezogen, respektive führen nicht zu geändertem Verhalten:
Menschen machen Fehler, das ist kein Problem, wenn es nicht immer wieder die gleichen Fehler sind und aus den Fehlern etwas gelernt wird. «Fail fast, learn faster». Häufig wird aber die notwendige Zeit für das Fixen von Fehlern (Bugs) im nächsten Sprint nicht vorgesehen.

Lösung:

  • DoD (Definition of Done) nutzen und den sich ändernden Bedürfnissen anpassen. Der Check gegen die Akzeptanzkriterien dürfte zwar selbstverständlich sein, gehört aber bestimmt in die DoD.
  • Timeboxing einsetzen, um Zeit für Arbeiten zu berücksichtigen, die sich nicht oder nur sehr schwer schätzen lassen, wie zum Beispiel die notwendige Zeit für das Bugfixing der Lieferung aus dem vorangehenden Sprint.

Customer collaboration over contract negotiation –
Zusammenarbeit mit dem Kunden steht über Vertragsverhandlungen.

(Dies bedeutet nicht, dass Verträge nicht wichtig sind, aber Verträge sind kein Garant für eine funktionierende Zusammenarbeit.)

Problem – Kunde nimmt seine Verantwortung nicht wahr:
Gerade bei Entwicklungsarbeiten auf Basis einer WTO-Ausschreibung eines Werks, ist es nicht damit getan, alles minutiös in Verträgen festzuhalten. Basis für die Zusammenarbeit mit dem Entwicklungsteam und die Zielerreichung ist primär das Backlog.

Lösung:

Der PO (Product Owner) muss sicher stellen, dass das Backlog die essenziellen Aspekte von Ausschreibung und Angebot reflektiert. Für gewollte Abweichungen gegenüber dem ursprünglichen Umfang braucht es ein klar definiertes und gelebtes Changemanagement. Changes müssen als solche im Backlog ersichtlich sein. Auch hier ist der PO in der Verantwortung.

Responding to change over following a plan –

Reagieren auf Veränderungen steht über Befolgen eines Plans

Problem – Micromanagement durch Kunde / PO während Sprint:
Fortlaufende Richtungsänderungen, Anforderungsänderungen und Re-Priorisierungen durch Stakeholder, respektive PO im Verlauf von Sprints.

Lösung:

Sprints brauchen Stabilität hinsichtlich Dauer, Umfang und verfügbarer Kapazität damit das Team seine Commitments einhalten kann. Es ist unter anderem eine der Aufgaben des SCRUM-Masters, solche Destabilisierungen zu verhindern. Richtungsänderungen und grössere Re-Priorisierungen sollten in Sprint-Plannings einfliessen.

Problem – Instabile Teams:
Die verfügbare Kapazität des Teams schwankt dauernd, weil Teammitglieder auch in anderen Projekten oder dem Support tätig sind, respektive laufend für andere Arbeiten abgezogen werden. So kann kein eingespieltes Team entstehen. Das Team wird keine Commitments abgeben, oder schlimmer, die abgegebenen Commitments nicht einhalten.

Lösung:

Lassen sich grössere Schwankungen nicht vermeiden, so empfiehlt es sich das Sprint-Commitment in zwei Bereiche aufzuteilen (massgebend für den Sprinterfolg sind dabei nur die Committed-Items):

  • Committed-Items, die das Team mit grosser Sicherheit umsetzen kann. Der Umfang dieser Items sollte mit der minimal sichergestellten Kapazität umgesetzt werden können.
  • Candidates oder Candidate-Items, solche die das Team umsetzen will, sofern die Kapazität im Sprint dafür ausreicht.  

Problem – Festhalten an dokumentierten Prozessen, Arbeitsteilungen und Strukturen, die sich nicht bewährt haben:
Wenn es bisher nicht funktioniert hat, weshalb soll es nun ab morgen funktionieren? Change bedeutet auch geänderte Bedürfnisse in der Zusammenarbeit zu erkennen und zu adressieren.

Lösung:

Retros sind der Ort, an welchem die Art und Weise der Zusammenarbeit kritisch hinterfragt werden soll. Was nicht funktioniert über Bord werfen und nach besseren Lösungen suchen, Bewährtes behalten.

Problem – Wahl der falschen agilen Methode:
Es gibt diverse agile Methoden, nicht jede ist für jeden Kontext geeignet. Die Wahl der falschen Methode und das «sture» Festhalten an der ursprünglichen Entscheidung führt häufig zu Misserfolg, Frust bei den Beteiligten und - zu Unrecht – zu einem schlechten Image von agilen Methoden.

Lösung:

  • Stärken und Limitierungen der agilen Methoden, sowie den Kontext, in welchem die Methode eingesetzt werden soll, bereits beim Setup berücksichtigen.
  • Mut, gegebenenfalls die eingesetzte Methode zu wechseln.

Zusammen agil unterwegs? Möchten Sie mehr zum Thema wissen? Wir helfen Ihnen gerne weiter, kontaktieren Sie uns!

Wir fühlen den Puls der Zeit, Sie auch?

Ihr mabuco Team

Zurück zur Übersicht