Agile Transformation
Kennen Sie die zwölf Prinzipien aus dem agilen Manifest? Um diese Prinzipien zu verfolgen, hat die zeit ag im Bereich der Produktentwicklung in den vergangenen Monaten eine intensive agile Transformation gestartet. Wir berichten Schritt für Schritt über unsere Erfahrungen und präsentieren erste Ergebnisse.
Das pre-agile Zeitalter
Vor der agilen Transformation war die Produktentwicklung der zeit ag mit verschiedenen Herausforderungen konfrontiert. Aufgrund fehlender Transparenz in Bezug auf den Fortschritt der Produktentwicklung verlor man zunehmend das Vertrauen von Kunden und Stakeholdern. Dies erschwerte die Kommunikation und wir wussten: Das kann so nicht weitergehen. Also wagten wir den ersten Schritt in Richtung Erfolgsfaktor Agilität.
Der Wechsel in ein agiles Vorgehensmodell ist eine Herausforderung.
Erster Schritt: IST-Analyse
Wo genau drückt der Schuh? Eine Analyse der IST-Situation zeigte uns, dass die Ursachen unterschiedlicher Natur waren. Zur Zusammenarbeit nutzten wir keine etablierte Methode und das Entwicklungsteam war nach technischen Disziplinen unterteilt. Infolgedessen waren Verantwortlichkeiten unklar und Produktverantwortungen sowie Fachanforderungen nicht vorhanden. Diese Ursachen führten zu einer eingeschränkten Planbarkeit und nicht sichtbaren Ergebnissen.
Zweiter Schitt: Transformation einläuten
Zusammen mit dem Produkt-Team initiierten wir in einem Workshop die agile Transformation. Dabei haben wir uns am Manifest für agile Softwareentwicklung orientiert. Das Manifest besagt anhand von zwölf Prinzipien, dass Individuen und Interaktionen wichtiger sind als Prozesse und Werkzeuge, eine funktionierende Software wertvoller ist als eine umfassende Dokumentation, die Zusammenarbeit mit dem Kunden im Vordergrund steht und eine schnelle Reaktion auf Veränderungen bedeutsamer ist als das Befolgen eines Plans. Darauf aufbauend formulierten wir unser Ziel:
Wir erarbeiten ein fachlich geschnittenes Backlog (Liste von Anforderungen), können einen Forecast (Prognose) für den ersten Release abgeben und reduzieren wiederkehrende technische Aufwandtreiber. So sind wir bereit, fachliche Anforderungen effizient End-to-End umzusetzen und diese kontinuierlich abnehmen zu lassen.
Dritter Schritt: Transformationsphase
Um dieses Ziel zu erreichen, wurde ein Transformationsteam zusammengestellt, bestehend aus dem PO (Product Owner), Frontend- und Backend-Entwicklern und Business Analysten, um das Produkt von einem möglichst breiten Blickwinkel aus zu betrachten. Dank der klaren Zielsetzung konnten wir die Arbeiten für die bevorstehende Transformation zusammenstellen. In einem ersten Schritt bündelten wir die notwendigen Arbeiten in folgende Kategorien: fachlich, technisch, methodisch und organisatorisch. Diese Gliederung bildete das Transformationsbacklog für den vierwöchigen Sprint 0, mit dem wir unser erstes Ziel erreichen wollten.
Vierter Schritt: Methode definieren
In der methodischen und organisatorischen Kategorie konzentrierten wir uns auf das zu etablierende Vorgehensmodell. Da mehr als zehn Entwickler an der Produktentwicklung beteiligt sind, mussten wir ein skalierbares Vorgehensmodell wählen. Dabei entschieden wir uns für «Large Scale Scrum». Dieses nachhaltige Modell erlaubt uns, auch in Zukunft mit mehreren Feature-Teams an einem Produkt zu arbeiten.
Grafik: Large-Scale Scrum
Fünfter Schritt: Backlog anlegen
In der fachlichen Kategorie erarbeiteten wir in mehreren Story-Mapping-Workshops die Anforderungen für ein «minimal verkaufbares Produkt» («Minimal Viable Product») sowie die entsprechenden User Stories, das heisst die Beschreibungen der Anforderungen aus Sicht des Anwenders. Das Entwicklungsteam schätzte die User Stories im Backlog in relativen Grössen (klein – mittel – gross). Jedes Feature-Team hat exemplarisch für klein, mittel und gross klassifizierten Stories die absoluten Schätzwerte für den «besten», «normalen» und «schlechtesten» Fall hinterlegt. Die daraus resultierende Schätztabelle unterstützte uns bei der Erarbeitung des ersten Forecasts zur Fertigstellung des definierten MVP.
Sechster Schritt: Aufwandtreiber reduzieren
Im technischen Stream wurden Aufwandtreiber wie beispielsweise nicht automatisch ausgeführte Tests oder die Verwendung von unpassenden Frameworks (Rahmenbedingungen) identifiziert. Um diese Aufwandtreiber zu reduzieren, haben wir entsprechende Architektur- und Technologieentscheide getroffen. Daraus resultierten konkrete Massnahmen wie zum Beispiel der Aufbau einer Continuous Integration / Continuous Deployment Umgebung., die mittel- und langfristig die Aufwände reduzieren sollten. Dank den Ergebnissen aus dem Sprint 0 konnte der Grundstein für die agile Produktentwicklung gelegt werden.
Start in ein neues Zeitalter
Der Wechsel in ein agiles Vorgehensmodell ist eine Herausforderung. Daher waren auch bei uns die Ergebnisse aus den ersten Sprints noch nicht ganz zufriedenstellend. Die gemeinsam definierten Sprintziele konnten nicht erreicht werden und auch die Methodik musste sich in den Teams zuerst festigen. Durch den kontinuierlichen Verbesserungsprozess identifizierten wir Stolpersteine und potenzielle Optimierungen. Dieser Prozess wird einerseits in den einzelnen Featureteams wie auch übergreifend im Produktentwicklungsteam gelebt. So werden wir in jedem Sprint sichtbar besser.
Die agile Transformation bewährt sich für uns auf allen Ebenen.
Einige Sprints später wurden die Sprintziele immer öfters erreicht. Dank der Agilität erreichten wir Transparenz bezüglich Fortschritt, bessere Planbarkeit und steigerten das Vertrauen der Stakeholder und der Mitarbeitenden in die Produktentwicklung. Durch den konsequenten Fokus auf die Fachlichkeit stellen wir nun den Anwender ins Zentrum. Die agile Transformation bewährt sich für uns auf allen Ebenen. Die Basis für die agile Produktentwicklung wurde erfolgreich gelegt. Damit sind wir für zukünftige Herausforderungen gerüstet und freuen uns auf die kommenden Sprints.
Autoren: Stefano Pellegrini, Software Engineer & Architect zeit ag, und Patrick Roos, Co-Founder adhook.io
