dot.research - Ist der Agile Wasserfall Scrum?
Es ist der Trend, einen "Agilen Wasserfallprozess" zu erzeugen und diesen dann Scrum zu nennen. Was es nicht ist. Sorry for that!
Der Trend "Agiler Wasserfallprozess"
Was sind die Merkmale eines "Agilen Wasserfallprozesses"?
- In einem ersten Schritt findet jemand heraus, was grundlegend gebaut werden soll: Gekonnt nutzt man dazu Methoden wie Design Thinking, Story Map oder Impact Map. In diesem Moment arbeitet der Product Owner oft mit Business Ownern, Business Analysten, System Architekten oder Product Managern zusammen.
- In einem weiteren Schritt findet jemand heraus, wie Nutzer mit der Anwendung grundlegend interagieren sollen: Die bisher gewonnenen Informationen aus I. kombiniert man in User Stories, verlinkt auf Beschreibungen in Wikis, auf den Clickable Prototyp und den Design Guide. In diesem Moment arbeitet der Product Owner oft mit Business Ownern, Business Analysten, UI/UX Spezialisten und Frontend Engineers zusammen. Oft sehr erfahrene Fachkräfte.
Und nun kommt das iterative Vorgehen zum Zug: In Iterationen, den sogenannten "Sprints", werden vermeintliche "Produkt Inkremente" entwickelt, d.h.: - Der Product Owner zerlegt entsprechend den Kompetenzen des Entwicklungsteams vorhandene User Stories in kleinere User Stories (Dekomposition), sodass eine reibungslose Entwicklung durch einzelne Teammitglieder möglich ist. Unterstützt wird der Product Owner dabei oft durch die erfahrensten Mitglieder des Entwicklungsteam.
- Der Product Owner stellt die so vorbereiteten Anforderungen - die User Stories - dem Entwicklungsteam vor. Mitglieder des Entwicklungsteams erfragen beim Product Owner Details, sodass diese das "What?" verstehen. Die erfahrenen Mitglieder des Entwicklungsteam unterstützen den Product Owner dabei, sie kennen aus III. bereits die "magischen" Details.
- Das Entwicklungsteam startet nun mit der Umsetzung: User Story um User Story, der Fortschritt innerhalb eines Sprints wird anhand einem Kanban transparent gemacht. Erfahrene Teams nutzen die Möglichkeit des Burn-up Charts, um frühzeitig Prognosen hinsichtlich eines möglichen Liefertermins abgeben zu können.
- Um den Arbeitsfortschritt überblicken zu können, kommt das Team nach jeder Iteration zu einem Review-Meeting zusammen und betrachtet, was bisher erreicht wurde. Im Idealfall stösst ein Stakeholder dazu, erfahrene Product Owner laden gerne auch jemanden vom Top-Management des eigenen Unternehmens ein.
Und ab da wird der nächste Sprint eingeleitet: Dieser startet bei Punkt III. - Um die Qualitätssicherung sicherstellen zu können, dehnen einige Organisationen ihr Vorgehen weiter aus, indem sie Tester das Produkt testen lassen. In diesem Moment arbeitet der Product Owner mit dem Testmanager und seinem Team zusammen, welches die Übersicht über die Testdaten und -systeme hat, diese gekonnt konfigurieren kann und so Einblicke in die Qualität liefern kann.
Wie unterscheidet sich also der "Agile Wasserfall" vom bekannten "Wasserfall"?
Einen "Iterativen Wasserfall": Diese Abbildung zeigt eine erste Phase, die der Analyse gewidmet ist.
Eine zweite Phase (möglicherweise leicht überlappend mit der ersten) ist dem User Experience Design gewidmet. Anschliessend wird die Phase der Kodierung in Iterationen (Sprints) gewidmet - Agile! Abschliessend kommen das Testing und die Auslieferung zum Zug. Voilà: Der Agile Wasserfall steht!
Was ist damit problematisch?
"It depends...": Man könnte argumentieren, dass ein agiles Vorgehen nach Scrum nicht in jedem Fall oder bei jeder Marktsituation notwendig ist. Und vielleicht ist der "Agile Wasserfall" gerade in deiner Situation das Richtige. Vielleicht auch der erste Schritt hin zu einem agilen Unternehmen und Teil der Agilen Transformation. Da stimme ich gar zu. Also: Schwierig zu beantworten.
"But...": Ist dein Unternehmen Teil der VUCA-Welt - der Digitalen Revolution ausgesetzt! - und das zu entwickelnde Produkt extrem den Einflüssen von VUCA ausgesetzt, dann kann man die Chancen, welche sich aus einem Agilen Vorgehen ergeben, auch nutzen:
- Frühzeitig mit einem minimal überlebensfähigen Produkt an den Markt zu gehen, um Einsichten von echten Nutzern erlangen zu können;
- Marktbedürfnisse aufnehmen und darauf reagieren zu können;
- Kosten über die Zeit verteilen zu können;
- und im Idealfall gar Ertragsquellen erschliessen zu können, welche die Finanzierung der Weiterentwicklung ermöglichen
Im Idealfall werden in einem agilen Prozess alle Arten von Arbeiten zur gleichen Zeit abgeschlossen:
Das Team beendet die Analyse des Problems genau zu jenem Zeitpunkt, zu welchem es die Lösung des Problems entwickelt, was der Fall ist, wenn das Team die Programmierung und das Testen dieser Lösung abgeschlossen hat.
Alle vier dieser Disziplinen (und weitere, hier nicht erwähnte) werden alle genau zur gleichen Zeit beendet. Und somit wird ein echter Wert erzeugt. Ein echtes Produkt, das über die Zeit entlang den Marktbedürfnissen wächst. Das nennt sich "Value Driven Development". Die Kernidee von Scrum.
Value Driven Development
Um "Value Driven Development" zu erreichen, sind Anforderungen dann zu erheben, wann sie umgesetzt werden, basierend auf den aktuellsten Erkenntnissen des Marktes. Anforderungen werden nicht in Teile wie UI/UX, Frontend oder Backend aufgeteilt (Punkte I. und II.), sondern kombiniert und kombiniert umgesetzt, sodass ein Ganzes entstehen kann und nicht viele Teile eines Ganzen.
Schmackhafte Kuchenstücke dank Value Driven Development
Isst du auch gerne Schwarzwälder Kirschtorte?
Genau! Ein Stück Schwarzwälder Kirschtorte macht mir Appetit - dafür würde ich Geld ausgeben!
Was aber, wenn du Tortenteig, Schlagsahne und rote Kirschen herstellst und diese als Einzelnes anbietest?
Hm. Dafür möchte man lieber nichts bezahlen, denn Kuchen ist besser als Tortenteig.
(Torten-)Stück um Stück wächst das Produkt inkremental, erzeugt bereits frühzeitig einen Wert. Vielleicht noch ein kleiner, für bloss einen Gast. Dieser gibt Auskunft darüber, wie ihm das Tortenstück schmeckt. Und zack, können wir unser Produkt verbessern. Basierend auf den Erträgen "Umsatz" (wir verkaufen das Tortenstück) und "Feedback".
User Story als Einladungskarte zu Kaffee & Kuchen
User Stories heissen so, weil eine Story etwas ist, das man sich erzählt und über das man spricht. Eine User Story ist die Einladung zu einem Gespräch zwischen Nutzer und Entwickler und keine Spezifikation (Punkte I. und II.). Der Product Owner stellt diese dem Team zur Verfügung - er druckt quasi die Einladungskarten, um gemeinsam bei einem Kaffee den Kuchen zu geniessen.
Ron Jeffries schlägt vor, die "Formel der 3 Cs" zu nutzen:
- Card: Mit Card ist einerseits gemeint, dass eine Story eine physische und im wahrsten Sinne (be-)greifbare Repräsentation in Form eines Post-Its oder einer Karteikarte haben soll.
- Conversation: Anderseits folgt aus dem begrenzten Platz auf einem solchen Zettel auch notwendigerweise eine gewisse Kürze und damit Unvollständigkeit. Diese Karte ist also nur der Anfang eines Gesprächs.
- Confirmation: Wenn durch das Gespräch das gemeinsame Verständnis erzielt wurde, lässt sich dieses gut formal in Form von Akzeptanzkriterien festhalten. BTW: Akzeptanzkriterien, welche dann die Grundlage für ein testgetriebenes Vorgehen bilden können.
Eine User Story unterteilt nicht eine (Markt-)Anforderung auf Basis der Wissensverteilung in einem Team auf Teammitglieder. Wird dies so gemacht (Punkt III.), stellt sich die Frage nach der "Wertmaximierung für das Produkt" (dem Tortenstück) - BTW die essenzielle Aufgabe des Product Owners.
Wir empfehlen, die Dekomposition dem Team zu überlassen. Und zwar nachdem der Sprint startete! Das Entwicklungsteam kann so selbstorganisiert die Arbeit aufteilen, bleibt jedoch gemeinsam verpflichtet (commited), alles für die Erreichung des Sprint-Goals zu unternehmen.
Refinement und Planning fortlaufend und gemeinsam
Die Dekomposition von Anforderungen in kleinere Einheiten (Tortenstücke!) und das Entwickeln des gemeinsamen Verständnis zum "Weshalb?" und "Was?" des Produkts sowie Gespräche über "Wie?" man das Produkt realisieren will, müssen fortlaufend und gemeinsam, auch während eines Sprints, im gesamten Team stattfinden (Punkt IV.), sodass das Wissen dazu im gesamten Team wächst.
So entsteht ein gemeinsames Interesse am Produkt, werden Wissensinseln verhindert, die Realisation kann auf verschiedene Teammitglieder abstützen und Engpässe werden vermieden. Erfahrungen Einzelner aus ähnlichen Vorhaben können in die Entwicklung einfliessen, womit ein besseres Produkt entsteht. "1 + 1 = 3"!
Produkt Inkremente sind das Ziel
Um Rückmeldungen vom Markt und Nutzern erheben zu können, ist ein frühzeitige Lancierung des Produktes zwingend: Bloss so ist die Verwertung von Rückmeldungen möglich. Bloss so ist ein agiles Vorgehen möglich. Die agilen Säulen "Transparency, Inspection and Adaption" kommen sonst nicht zum Tragen. Und selbstverständlich wollen wir durch Qualität am Markt glänzen! Dazu ist eine Qualitätssicherung zwingend! Muss also integraler Bestandteil eines jeden Sprints sein. Ist doch so - korrekt?
Wenn ihr jedoch grundlegende Probleme mit der Auslieferung nach jedem Sprint habt, seien diese technischer oder politischer Natur, stoppt. Überprüft, wie ihr Arbeiten zur Verbesserung der Auslieferungs-Leistung anpacken könnt. Verbessert eure CI/CD Umgebung z. B. so, dass automatisiertes Testen innerhalb des Sprints möglich wird. Prüft z. B. ob Test Driven Development ein Ansatz ist, welchen ihr im Team verfolgen wollt.
Erschafft eine Wertschöpfungskette, welche euch die Auslieferung von qualitativ hochstehenden Produkt Inkrementen erlaubt, um so Rückmeldungen zum Produkt vom Markt generieren zu können. Wer weiss, vielleicht erschliesst ihr euch durch diese Wertschöpfungskette gar eine Ertragsquelle, welche euch die Finanzierung zukünftiger Produktfeatures erlaubt? Wie cool wäre das denn?! Wäre das gar Lean? Lean Startup?! Wow - jetzt läufts mit der Agilität!!
Fazit
Design Thinking, Story Mapping, Impact Mapping, User Stories, Planning, Sprint, Daily, Review und Retrospektive machen sicherlich einen Unterschied. Und sind wichtige Teile agilen Vorgehens. Die Essenz von agilem Vorgehen wird jedoch nicht durch agile Methoden und Prozesse erreicht, wenn diese falsch angewendet werden. Man erinnert sich vielleicht noch vage: "Scrum is: Lightweight, simple to understand and difficult to master". Sorry!
Bemerkungen
Es ist ein wenig naiv anzunehmen, dass ein Team ein kombiniertes Vorgehen (Tortenstück, Value Driven Development, CI/CD) immer perfekt erreichen kann. Zu Beginn kann es vielleicht bloss einige Male erreicht werden. Aber es kann das Ziel bleiben, auf das ein Team hinarbeiten kann. Hoffentlich nutzt das Team das Mittel der Retrospektive und verbessert ihre Arbeitsweise so stetig.
Ein Team sollte immer daran arbeiten, einzelne Phasen wie Analyse, Design usw., so weit wie möglich überlappen zu lassen. Im Idealfall sind alle Phasen in einem Sprint vertreten und fokussieren dieselben Anforderungen. Rückmeldungen von Nutzern und Erkenntnisse zum Markt sind kurzfristig umzusetzen. Das Vorausdenken sollte so spät wie möglich und so wenig wie möglich erfolgen. Anforderungen sollten so klein geschnitten sein, sodass diese innerhalb einer Iteration abgeschlossen werden können.
Wenn ihr User Stories als Miniatur-Spezifikationsdokumente behandelt, stoppt. Wenn User Stories auf ellenlange Beschreibungen im Wiki verweisen und die Übersicht verloren geht, stoppt. Beginnt stattdessen, über jede einzelne User Story als ein Versprechen nachzudenken und bei Bedarf ein Gespräch zu führen. Teilt auf - aber nie entlang den technischen Grenzen wie UI/UX, API, Backend o.Ä. Geniesst stattdessen feine Tortenstücke! En Guete!
Siehst du Vorteile im "Agilen Wasserfallprozess" im Vergleich zu Scrum? Ist das problematisch? Oder Evolution? Vielleicht auch eine Zwischenstation innerhalb der Agilen Transformation? Da Continuous Integration, Deployment und Delivery noch nicht fit sind? Was sind deine Beobachtungen und Erfahrungen?
Eventuell interessant
Verwandte Blogs
Kommentare (2)