Es ist der Trend, einen "Agilen Wasserfallprozess" zu erzeugen und diesen dann Scrum zu nennen. Was es nicht ist. Sorry for that!
Was sind die Merkmale eines "Agilen Wasserfallprozesses"?
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!
"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:
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.
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.
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 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:
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.
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"!
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!!
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!
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?