Kurze Backlogs, verpasste Termine, niedrige Moral und Misserfolge können darauf hinweisen, dass Ihr agiler Prozess mehr als nur ein paar kleine Änderungen benötigt. [...]
Nennen Sie Ihren agilen Entwicklungsprozess „fragil“, „hybrid waterfall“ oder „fake agile“? Ist Ihr agiler Backlog eher eine Warteschlange von Anfragen oder eine Aufgabentafel? Genauer gesagt, zeigen Ihre agilen Entwicklungsteams eines dieser 15 Anzeichen dafür, dass Sie agil falsch vorgehen?
Vielleicht ist Ihr agiler Entwicklungsprozess gar nicht so schlecht, und Ihre Teams sprinten, veröffentlichen und stellen die Kunden zufrieden. Vielleicht haben Ihre Teams agile Methoden entwickelt, das Release-Management formalisiert, agile Schätzverfahren eingeführt und Standards für das Schreiben von Stories entwickelt. Hoffentlich haben sie sich mit Operations-Teams zusammengetan und ihre agilen Tools sind mit Versionskontrolle, CI/CD-Pipelines (Continuous Integration/Continuous Delivery) und Observability-Plattformen integrierbar.
Die Chancen stehen gut, dass die Teams in Ihrem Unternehmen irgendwo zwischen diesen beiden Extremen liegen. Obwohl viele agile Unternehmen einen kontinuierlichen Prozess zur Reifung und Verbesserung agiler Praktiken durchlaufen, muss sich der Entwicklungsprozess zuweilen ändern. Einige Unternehmen verwenden agile KPIs (Key Performance Indicators) und Devops-Metriken, um den Fortschritt zu bestätigen und zu signalisieren, wenn Änderungen erforderlich sind. Manche Organisationen haben jedoch keine formellen Metriken und verlassen sich auf Menschen und Prozesse, um anzuzeigen, ob und wo Anpassungen erforderlich sind.
Hier sind fünf Indikatoren dafür, dass sich der agile Entwicklungsprozess ändern muss und meine empfohlenen Anpassungen.
Es gibt einen kleinen Backlog und unzureichende Planung
Agile Teams finden recht schnell heraus, dass es für den Product Owner, den Scrum Master und das Team schwierig ist, effizient zu arbeiten, wenn der Backlog mit jeder Idee, Anfrage oder jedem technischen Problem belastet wird. Wenn Teams in ihren agilen Tools einen großen Backlog pflegen, sollten sie Etiketten oder Tags verwenden, um die kurzfristigen von den längerfristigen Prioritäten zu filtern.
Eine noch größere Herausforderung ist es, wenn Teams die Just-in-Time-Planung übernehmen und User Stories in den letzten Tagen vor dem Sprint-Start priorisieren, schreiben, überprüfen und schätzen. Es ist viel schwieriger, unter Zeitdruck ein gemeinsames Verständnis der Anforderungen zu entwickeln. Es ist weniger wahrscheinlich, dass Teams Architektur, Betrieb, technische Standards und andere Best Practices berücksichtigen, wenn nicht genügend Zeit für die Planung zur Verfügung steht. Noch schlimmer ist, dass es schwierig ist, nachgelagerte Geschäftsprozesse wie Schulungen und Änderungsmanagement zu berücksichtigen, wenn die Geschäftsbeteiligten die Zielvorgaben oder die mittelfristige Roadmap nicht kennen.
Es gibt mehrere Best Practices für die Planung von Backlogs, darunter die kontinuierliche agile Planung, die Programmimplementierungsplanung und andere vierteljährliche Planungspraktiken. Diese Praktiken helfen mehreren agilen Teams beim Brainstorming von Epics, beim Aufschlüsseln von Features, beim Bestätigen von Abhängigkeiten und beim Priorisieren des Schreibens von User Stories.
Sprints und Releases bleiben hinter den Verpflichtungen zurück
Nachdem ich „5 Wege, wie agile Teams Sprint Commitments einhalten“ verfasst hatte, hörte ich von ein paar Leuten auf Twitter, dass Commitments tot seien und mehr Teams von Scrum auf Kanban umsteigen.
Es gibt Zeiten, in denen ich Scrum empfehle und andere Fälle, in denen Kanban Vorteile hat, aber ich bin überzeugter Befürworter von agilen Entwicklungsteams, die sich zu der Arbeit, die sie annehmen, verpflichten. Das Commitment signalisiert den Product Ownern und Stakeholdern, dass es ein gemeinsames Verständnis darüber gibt, wer, warum und was benötigt wird, und es verlangt von agilen Teams, einen Implementierungsplan zu erstellen.
Commitments stellen eine Vorhersage dar, und die Erwartung, dass Teams die Ziele durchgängig erfüllen oder übertreffen, ist nicht realistisch. Wenn agile Entwicklungsteams sich verpflichten, User Stories zu realisieren, geschieht dies oft angesichts mehrerer Unbekannter in Bezug auf die Implementierung, Teamabhängigkeiten und Technologieannahmen.
Wenn agile Teams ihre Zusagen immer wieder verfehlen, ist es vielleicht an der Zeit, über Änderungen und Verbesserungen nachzudenken. Das Commitment zu weniger Stories mag wie eine einfache Antwort aussehen, ist es aber nicht, wenn die Abstimmung auf die Erfüllung von Anforderungen innerhalb eines Sprints oder der Dauer eines Releases das Problem ist.
Die besten selbstorganisierenden Teams erkennen Versäumnisse bei der Erfüllung von Erwartungen, nutzen Retrospektiven, um die Ursachen zu diagnostizieren, und verpflichten sich zu Verbesserungen.
Sprints enden ohne gut organisierte Demos
Die Agenda des Sprint-Review-Meetings besteht darin, dem Product Owner und den Stakeholdern fertige User Stories vorzuführen und frühes Feedback zu sammeln. Sprint-Reviews sollten gut besucht sein und die Teams sollten eine Menge zu präsentieren haben.
Die besten agilen Teams, mit denen ich das Privileg hatte zu arbeiten, behandeln Sprint-Reviews wie Theater. Sie besprechen, wie sie die Story vorführen, wer sie leiten soll, wann sie stattfinden sollen und welche Arten von Feedback erfasst werden sollen. Ein Master of Ceremonies stellt sicher, dass die Sprint-Reviews planmäßig ablaufen, das Feedback erfasst wird und langwierige Diskussionen geparkt werden, um sie im Nachhinein nachzubereiten.
Unterdurchschnittliche Reviews können auf mehrere Probleme hinweisen:
- Stories werden nicht aus der Perspektive des Benutzers geschrieben, was die Demo schwieriger macht.
- Entwickler sind besorgt darüber, eine Benutzererfahrung zu zeigen, die noch in Arbeit ist.
- Teams arbeiten bis in die letzten Stunden vor dem Review und sind nicht darauf vorbereitet, eine gute Show abzuziehen.
- Product Owner setzen unrealistische Erwartungen an die Stakeholder und lassen ihre Teams während der Demo im Regen stehen.
- Stakeholder sehen keinen Wert in der Teilnahme, weil sie in der Vergangenheit schlecht gearbeitet haben, oder sie haben das Gefühl, dass niemand auf ihr Feedback hört.
- Sprint-Reviews sollten Zeiten sein, um den Fortschritt eines Teams zu feiern. Schwache oder nicht beachtete Leistungen können zu Problemen mit der Team-Moral führen.
Zunehmende Fehler werden in der Produktion gefunden
Viele agile Entwicklungsteams automatisieren das Testen, konfigurieren CI/CD-Pipelines und stellen Infrastruktur als Code bereit, um die Zuverlässigkeit der Releases zu verbessern und Änderungen in der Produktion häufiger bereitzustellen. Die fortschrittlicheren Unternehmen verwenden Shift-Link-Testing-Strategien und ausgereifte Devops, um die Sicherheit frühzeitig in den Entwicklungsprozess einzubeziehen.
Die vorherrschende Weisheit ist, dass häufige Deployments zu größerer Benutzerzufriedenheit und weniger Problemen mit technischen Abhängigkeiten führen. Im Bericht „2020 State of Devops“ geben 45 Prozent der Unternehmen mit hohem Entwicklungsstand an, dass die Deployment-Frequenz nach Bedarf erfolgt, und 38 Prozent haben eine Vorlaufzeit von weniger als einem Tag für Änderungen. Konservativere, operativ reifere und Governance-fokussierte Unternehmen haben niedrigere Prozentsätze.
Häufige Deployments sind sinnvoll, bis sie nicht mehr sinnvoll sind. Ein klarer Indikator dafür, dass agile Entwicklungsteams zu häufig deployen, ist, wenn eine wachsende Anzahl von Fehlern in der Produktion gefunden wird.
Produktionsdefekte können sich auf die Geschäftsleistung auswirken und sind höchst problematisch, wenn Unternehmen einen Ruf für die Bereitstellung fehlerhafter Software entwickeln. Es ist auch eine Herausforderung, wenn Entwicklungsteams auf größere Produktionsvorfälle reagieren, Notfall-Break-Fix-Releases planen oder die Behebung von Fehlern gegenüber anderen Prioritäten zurückstellen müssen.
Teams, die zunehmende Fehler in der Produktion feststellen, sollten die Ursachen diskutieren und Lösungen finden. In vielen Fällen sind die frühere Planung von Backlogs, die Verbesserung von Anforderungen, die Investition in Testautomatisierung, die Erhöhung der Vielfalt von Testdaten oder die Instrumentierung von kontinuierlichen Tests alles Schritte, die helfen können, Produktionsfehler zu reduzieren.
Agile Teams oder ihre Stakeholder sind unzufrieden
Der wichtigste Faktor für die Erwägung von Änderungen ist, wenn das agile Team oder seine Stakeholder unzufrieden sind.
Das Verpassen eines Sprints oder sogar eines Releases sollte kein Grund zur Beunruhigung sein, aber die Führungskräfte sollten Ansätze definieren, um das Feedback formell zu erfassen. Einzelgespräche sind hilfreich, aber größere Unternehmen sollten Umfragen zur Kundenzufriedenheit und zu den agilen Teams in Betracht ziehen.
Achten Sie auf Teams, die Blockaden aufgrund von Problemen melden, die außerhalb ihrer Kontrolle liegen. Wenn es zu viele Abhängigkeiten zwischen agilen Teams gibt oder wenn Menschen, Fähigkeiten, Technologie oder Anbieter ihre Fähigkeit zur Ausführung behindern, dann werden anhaltende Probleme wahrscheinlich die Zufriedenheit des Teams beeinträchtigen.
Unzufriedene Stakeholder sind ebenso ein Grund zur Sorge. Unzufriedenheit kann von zu hohen Erwartungen, schlechter Lieferqualität oder einfach von den Arbeitsrealitäten außerhalb ihrer Zusammenarbeit mit agilen Teams herrühren. Nach meiner Erfahrung korrelieren glückliche agile Teams mit der Zufriedenheit der Stakeholder. Wenn Menschen frustriert sind, ist es an der Zeit, zuzuhören und entsprechende Änderungen zu priorisieren.
Eine Best Practice ist, dass agile Teams inkrementelle Anpassungen an ihrem Prozess, ihren Prinzipien, ihrer Zusammenarbeit und ihren Standards anstreben und priorisieren. Agile Unternehmen, die kleinere Änderungen anstreben, können härtere Pivots vermeiden. Ist es nicht genau das, worum es bei agilen Methoden geht?
*Isaac Sacolick ist der Verfasser des Amazon-Bestsellers Driving Digital: The Leader’s Guide to Business Transformation through Technology, der viele Praktiken wie agile Planung, Devops und Data Science behandelt, die für erfolgreiche digitale Transformationsprogramme entscheidend sind. Sacolick ist ein anerkannter Top-Social-CIO, Influencer für digitale Transformation und mitwirkender Redakteur bei CIO.com und Social, Agile, and Transformation.
Be the first to comment