Die folgenden Anzeichen deuten darauf hin, dass Ihre agilen Entwicklungsprozesse mehr als nur eine leichte Überarbeitung benötigen. [...]
Kommt Ihnen Ihr Softwareentwicklungsprozess eher fragil als agil vor? Handelt es sich gar um ein „Hybrides Wasserfallmodell“ oder zeigen sich „Fake Agile“-Tendenzen? Ähnelt Ihr Agile Backlog einer Request Queue oder einem Task Board? All das sind sichere Anzeichen dafür, dass Ihre Agile-Bemühungen in die falsche Richtung laufen.
Unter Umständen laufen Ihre agilen Entwicklungsprozesse auch gar nicht so schlecht: Ihre Teams arbeiten in Sprints, Releases kommen wie geplant und die Kunden sind zufrieden. Das liegt dann vor allem an der eingespielten Anwendung agiler Methoden, einem formalisierten Release Management, einem Partnerverbund von IT und OT oder auch daran, dass die Agile Tools im Einklang mit Versionskontrolle und CI/CD Pipelines stehen.
Die Wahrheit dürfte wie so oft in der Mitte liegen: Auch in Unternehmen, die danach streben, ihre agilen Methoden stetig weiter zu optimieren kann eine Veränderung der Entwicklungsprozesse nötig werden. Um das zu erkennen, setzen einige Firmen auf Agile KPIs und Devops-Metriken – andere wiederum können auf solche Metriken nicht zurückgreifen und müssen sich auf Menschen und Prozesse verlassen, wenn es darum geht, Signale für eine notwendige Veränderung zu erkennen.
Wir haben fünf Beispiele für solche Anzeichen für Sie zusammengetragen – inklusive entsprechender Handlungsempfehlungen.
Seichter Backlog, schale Planung
Wenn der Backlog mit Ideen, Requests oder technischen Problemen überfrachtet wird, gestaltet sich effizientes Arbeiten für den Product Owner, Scrum Master und das gesamte Team diffizil. Wenn sich ein ausufernder Backlog nicht vermeiden lässt, sollten dabei Labels und Tags zum Einsatz kommen, um die Priorisierung nicht aus den Augen zu verlieren.
Wenn die Teams auf Just-in-Time-Planung und -Priorisierung setzen, wird es noch herausfordernder, schließlich ist es unter Zeitdruck noch wesentlich schwieriger, ein gemeinsames Verständnis über die Anforderungen zu entwickeln. Fehlt der entsprechende Zeitrahmen, sinkt die Wahrscheinlichkeit, dass die Teams sich ausreichend mit Architektur, Operations, technischen Standards und anderen Best Practices auseinandersetzen. Schwerer wiegt allerdings, dass Trainings und Change Management nur schwer durchsetzbar sind, wenn den Business Stakeholdern weder Zielsetzungen noch eine mittelfristige Roadmap bekannt sind.
Um Backlogs richtig zu planen, stehen diverse Best Practices zur Verfügung – beispielsweise Continuous Agile Planning oder Program Implement Planning. Diese helfen agilen Teams in Sachen Brainstorming, Feature-Planung und User Stories.
Commitment in enttäuschend
Egal ob Scrum oder Kanban – entscheidend ist das Commitment eines Teams. Das signalisiert dem Product Owner und den Stakeholdern, dass ein gemeinsames Verständnis darüber herrscht, wie die Anforderungen aussehen und erfordert außerdem, dass die agilen Teams einen Implementierungsplan definieren.
Commitments repräsentieren einen Forecast – allerdings ist die Erwartungshaltung, dass Teams die vorgegebenen Ziele regelmäßig übertreffen nicht realistisch. Wenn agile Entwicklungsteams sich zu User Stories committen, beinhaltet dieses Commitment regelmäßig diverse unbekannte Variablen rund um die Implementierung, die Abhängigkeiten von anderen Teams oder technologische Mutmaßungen.
Wenn die Agile Teams jedoch regelmäßig ihre Commitments verfehlen, ist es an der Zeit, über Veränderungen nachzudenken. Die Zahl der Commitments zu reduzieren, ist dabei nur eine gangbare Lösung, wenn die Koordination von Anforderungen und deren Erfüllung innerhalb eines Sprint- beziehungsweise Release-Zyklus nicht das Problem ist.
Gute selbstorganisierende Teams erkennen es an, wenn ihre Arbeit nicht den Erwartungen entspricht, nutzen Retrospektiven, um die Ursachen für die Verfehlungen zu ergründen und streben nach Optimierung.
Sprint mit bitterem Ende
Sprint Review Meetings haben zum Ziel, dem Product Owner und den Stakeholdern abgeschlossene User Stories zu präsentieren und erstes Feedback einzuholen. Diese Meetings sollten folglich gut besucht sein und die Teams sollten in Sachen Showcases einiges in petto haben.
Gute Agile Teams lassen sich zu diesem Anlass nicht lumpen: Sie diskutieren, wie die User Story am besten präsentiert wird und welches Feedback eingeholt werden soll. Ein „Master of Ceremonies“ sorgt dabei dafür, dass alles nach Plan abläuft und Diskussionen im Anschluss nicht aus dem Ruder laufen.
Unterdurchschnittliche Sprint Review Meetings können auf verschiedene Probleme hindeuten:
- User Stories sind nicht aus Sicht der Benutzer geschrieben, was eine Demo erschwert;
- Entwickler versuchen eine User Experience abzubilden, die noch „Work in Progress“ ist;
- Teams werkeln bis kurz vor dem Review, was ihnen die Zeit raubt, sich ordentlich vorzubereiten;
- Product Owner sorgen für eine unrealistische Erwartungshaltung auf Seiten der Stakeholder und lassen ihre Teams während der Demo am ausgestreckten Arm verhungern;
- Stakeholder erkennen wegen vorheriger schwacher Performances keinen Mehrwert darin, am Meeting teilzunehmen – oder haben das Gefühl, dass niemand auf ihr Feedback Wert legt.
Sprint Reviews sollten die Fortschritte eines Teams zelebrieren. Schwache oder nicht wahrgenommene Performances können sich negativ auf die Teammoral auswirken.
Produktivdefekte
Um die Zuverlässigkeit der Releases verbessern und Änderungen in der Produktivumgebung mit höherer Frequenz umsetzen zu können, verlassen sich nicht wenige Agile Teams auf automatisiertes Testing, die Konfiguration von CI/CD Pipelines oder Infrastructure as a Code. Fortgeschrittenere Anwender bringen Shift-Left-Testing-Strategien oder DevOps zum Einsatz, um Security by Design von Anfang an im Entwicklungsprozess zu berücksichtigen.
Nach vorherrschender Meinung führen Deployments in höherer Frequenz zu höherer Benutzerzufriedenheit und weniger technischen Abhängigkeiten. Laut der Studie „2020 State of Devops“ reklamieren 45 Prozent der Entwicklungs-fokussierten Companies eine On-Demand-Deployment-Frequenz für sich, 38 Prozent führen Veränderungen in weniger als einem Tag durch.
Häufige Deployments ergeben allerdings nur solange Sinn, bis sie keinen mehr ergeben: Wenn sich die Fehler im Produktivbetrieb häufen, ist das ein klares Anzeichen dafür, dass die agilen Entwicklungsteams zu oft ausliefern. Solche Fehler können die Business Performance negativ beeinflussen – darüber hinaus erweist sich eine Reputation für fehleranfällige Software in der Regel als höchst problematisch. Eine weitere Herausforderung wird für die Entwicklungsteams aufgeworfen, wenn größere Vor- oder Notfälle im Produktivbetrieb auftreten. Auch diese müssen schließlich neben den eigentlichen Prioritäten bearbeitet werden.
Teams, denen solche Fehler auffallen, sollten sich zusammensetzen, die Ursachen im Rahmen einer Diskussion ermitteln und entsprechende Lösungen entwickeln. In vielen Fällen helfen folgende Maßnahmen bei der Vermeidung von Fehlern im Produktivbetrieb:
- Test Automation
- Mehr und variantenreichere Testdaten
- Continuous Testing
Happiness-Mängel
Wenn das Agile Team oder deren Stakeholder nicht glücklich mit dem Projekt sind, ist das das wichtigste Signal für dringenden Änderungsbedarf. Wenn ein Sprint oder gar ein Release einmal in die Hose geht, ist das nicht allzu schlimm. Allerdings sollten die Entscheider definieren, in welchem Rahmen formelles Feedback eingefordert wird. One-on-One-Dialoge können ein hilfreiches Mittel sein – größere Unternehmen sollten jedoch auch Kundenzufriedenheits- und interne Team-Umfragen in Erwägung ziehen.
Besonders sollten Sie auf Teams achten, die wegen äußerer Umstände in Verzug geraten. Gibt es zu viele Abhängigkeiten zwischen den agilen Teams oder stehen Skills, Technologien und Partner im Weg, wird sich das langfristig auf die Teamzufriedenheit auswirken.
Anlass zur Sorge geben auch unzufriedene Stakeholder. Das mag unter Umständen übertriebenen Erwartungen oder schlechter Qualität geschuldet sein. Ein Vorteil: Unzufriedene Stakeholder gehen meist mit unzufriedenen Teams einher. Wenn die Stimmung im Team also von Frustration bestimmt wird, ist es Zeit zuzuhören und entsprechende Änderungen zu veranlassen.
Best Practice: Inkrementelle Änderungen an Prozessen, Prinzipien, der Collaboration und den allgemeinen Standards. Agile Unternehmen, die auf kleinere Modifikationen setzen, vermeiden ausuferndes Gegensteuern.
*Isaac Sacolick ist Autor des Amazon-Bestsellers „Diving Digital: The Leader´s Guide to Business Transformation thourh Technology“. Er schreibt als freier Autor unter anderem für unsere US-Schwesterpublikation CIO.com.
Be the first to comment