Agile Methoden wie Scrum erlauben eine hohe Flexibilität bei der Software-Entwicklung. Dieser Artikel zeigt Lösungsstrategien für den Einsatz von Scrum in wasserfallorientierten Grossunternehmen.
Dieser Artikel zeigt Lösungsstrategien für den Einsatz von Scrum in wasserfallorientierten Grossunternehmen
Patrick Ruckstuhl ist Lead Software Architect bei Zühlke. Henrik Mitsch ist Executive Manager Product Management bei Sixt AG. Die New Yorkerin Annie Taylor wagte im Jahr 1901 das grösste Abenteuer ihres Lebens: An ihrem 63. Geburtstag stieg sie in ein gepolstertes Holzfass und stürzte sich damit die Niagarafälle hinunter. Zur grossen Überraschung ihrer Begleiter stieg sie beinahe unverletzt aus dem Fass. Allerdings erwies sich die Dame später als stark traumatisiert und warnte jeden davor, dieses Unterfangen zu wiederholen. Damit der Einsatz von Scrum in wasserfallorientierten Unternehmen nicht mit einem ähnlichen Schock endet, zeigt dieser Artikel, wie man mit agilen Methoden in einem grossen, phasenorientierten Projekt erfolgreich das Ziel erreicht.
Lessons learned
Fallbeispiel ist ein aktuelles Projekt in einem Grossunternehmen. Die Aufgabe: Ein neues IT-System aufbauen, das E-Commerce-Funktionalitäten und Multichannel-Kundeninteraktionen ermöglicht. Das System ist eng mit diversen Backend-Systemen gekoppelt, deren bestehende Kunden- und Produktdaten sowie Business-Logik verarbeitet werden müssen. Die grosse Herausforderung: Die effiziente Zuordnung der begrenzten Entwicklungskapazitäten. In diesem Rahmen lieferte das agile Vorgehen die optimale Antwort auf die Frage «Was entwickeln wir bis zum Termin XY?». Als erfolgsentscheidend erwiesen sich im Laufe des Projekts folgende Faktoren: Unterstützung: Bei der Einführung agiler Methoden entstehen Reibungsflächen. Gerade in phasenorientierten Unternehmen herrschen oft Vorurteile gegenüber agilen Methoden wie «agil ist unplanbar», «die vielen Tests verlangsamen den Entwicklungsfortschritt» oder «bei agiler Entwicklung wird nichts dokumentiert». Ein wesentlicher Faktor für den Erfolg ist daher die Unterstützung durch das Management. Die Projektsponsoren müssen das Team selbstständig arbeiten lassen und darauf vertrauen, dass eine gute Lösung zustande kommt. Ein weiterer Punkt ist, dass es starke Agile Coaches im Scrum-Team braucht. Dies ist wichtig, um sowohl Team als auch Projektumwelt an neue Vorgehensweisen heranzuführen und dabei zu unterstützten.
Requirements aufteilen: Um das Zusammenspiel von phasenorientierten Umsystemen und agiler Flexibilität zu gewährleisten, werden zwei Gefässe (Buckets) für die Requirements definiert (vgl. Grafik 1). Dabei unterscheidet man zwischen non-agilen Requirements (Bucket 1) und agilen Requirements (Bucket 2). Non-agile Requirements werden in einem dedizierten Designteam gemäss inkrementellem Vorgehen spezifiziert (z.B. die Interfaces zu Backend-Systemen). Die Ausgestaltung der agilen Requirements ist dem Product Owner, also dem Business-Verantwortlichen für das Produkt, überlassen. Er verfügt über die volle Entscheidungskompetenz. Die Aufteilung zwischen den beiden Buckets wird kontinuierlich in einem «Requirement Board» geklärt. Lesen Sie auf der nächsten Seite: Vom High-Level zu den DetailsVom High-Level zu den Details: Damit die Steuerungsgremien (Steering Boards) bereits frühzeitig Entscheidungen im High-Level-Bereich treffen können, werden Themen erst grob definiert und nach und nach immer detaillierter ausgearbeitet. In der agilen Software-Entwicklung spricht man vom «Cone of Uncertainty»: Je näher der Zieltermin kommt, desto klarer wird das Ziel definiert (vgl. Grafik 2). Ein Thema wird zunächst grob beschrieben (First Grooming). Diese Stufe findet einige Monate im Voraus statt und dient zur Roadmap-Planung. Die nächste Stufe, das Power Grooming, dient dazu, das Thema aufzubrechen und genauere Schätzungen zu erreichen. Diese sind Basis der Release-Ziele. Die letzte und detaillierteste Stufe ist das «Regular Grooming». Es findet während jedem Entwicklungsabschnitt (im Scrum-Vokabular Sprint) statt und dient der Abschätzung der Anforderung an die Software (Stories) für die unmittelbar bevorstehenden Sprints. Kommunikation im Team: Um seinen Handlungsradius zu erweitern, ist das agile Team funktions- und systemübergreifend zusammengestellt. Daneben spielt auch die Zusammenarbeit mit dem non-agilen Designteam (Bucket 1) eine zentrale Rolle. Neben der direkten Kommunikation zwischen Personen im Designteam und dem agilen Team gibt es ein wöchentliches Treffen. Dieses dient der Klärung aktueller Fragen aus dem Tagesgeschehen (z.B. unerwartetes Verhalten von Umsystemen) und solcher, die für das Design künftiger Releases relevant sind.
Frühe Tests: Die frühe Qualitätssicherung durch Tests schafft Raum für die Entwicklung zusätzlicher Funktionalität. Dadurch fällt auch weniger Aufwand durch nachträgliche Bugfixes an und die Feature-Entwicklung kann bis knapp vor dem Rollout weitergehen. Dies ist auch Grundlage für eine kontinuierliche Integration. Dokumentation: Zur angepassten Definition of Done (Endpunkt einer Entwicklung) zählt auch die Aktualisierung der unternehmensweiten Architektur-dokumentation. So bleibt das «Big Picture» stets aktuell. Daneben wird auch sehr stark mit einer automatisierten Dokumentation gearbeitet. So werden Schnittstellendokumentationen jeweils inklusive eines Beispiels zu Request/Response in einem Wiki-Format generiert und zur Verfügung gestellt. Ein weiteres Beispiel sind Annotationen im Code, die Anforderungen an Umsysteme markieren, um diese in einem späteren Release zur Umsetzung zu beauftragen. Lesen Sie auf der nächsten Seite: ScrumAnds-AnpassungenAnpassungen des Scrum-Frameworks (ScrumAnds): Im Zweiwochenrhythmus überprüfen «Reviews», ob die gesteckten Ziele eines Sprints erreicht wurden. Da diese aber zu viele Stakeholder zu viel Zeit kosten, empfiehlt es sich, zwischen kleinen Reviews (nur mit den wichtigsten Stakeholdern) und grossen Reviews (mit vielen Stakeholdern) abzuwechseln. Zum besseren Abgleich mit der Entwicklung von Umsystemen wird eine Sprint-Roadmap eingeführt, die wichtige Synchronisationspunkte festhält. Dies erlaubt eine flexible Definition des Aufgabenbereichs (Scoping) bei gleichzeitiger Berücksichtigung wesentlicher externer Ereignisse. Eine weitere Anpassung, die sich als sinnvoll erwiesen hat, ist das Bereitstellen von Aufwandskontingenten für schwer planbare Themen. So steht beispielsweise dem Umsystemdesignteam 15 Prozent der Sprint-Kapazität zur Verfügung.
Fazit: Aufwand lohnt sich
Annie Taylor hat den Wasserfall im Holzfass überstanden – agile Lösungsentwicklung in einer wasserfallorientierten Umwelt kann sogar richtig erfolgreich sein. Dazu ist allerdings die richtige Mischung von Durchsetzungsvermögen und Kompromissbereitschaft nötig. Kurze Feedbackzyklen und Anpassungsmöglichkeiten sind in einer komplexen, sich schnell verändernden Welt immens wichtig. Bei agilen Entwicklungsmodellen sind diese bereits im Systemdesign enthalten. Das ist letztendlich der Grund, weshalb sich der Aufwand, phasenorientierte und agile Vorgehensweisen miteinander zu verknüpfen, auf jeden Fall lohnt.
