In einem der vergangenen Blogartikel (Portfolio Planning – Think Big, Act Bigger) ging ich auf das Thema Portfolio Planning ein. Eine wohlgeformte, direkt umsetzbare UserStory braucht Zeit zur Entstehung. Oft sind „Epics“ oder strategisch grobe Ziele der Initialzustand, welcher von einem Team erst einmal überwunden werden muss. Doch wie kommt man denn von einem großen neuen Produkt oder gigantischen Feature zu umsetzbaren Happen, welche VOR ALLEM auch noch iterativ Wert erbringen können?
Alistair Cockburn ist einer der Mitbegründer des Manifests für agile Softwareentwicklung. Als Maßnahme für das Thema Storyschnitt erfand er die Übung des „Elephant Carpaccio“ um Teams und Entwicklern das wertvolle Schneiden von Product Backlog Items näher zu bringen.
Was ist Elephant Carpaccio?
Der Gedanke hinter dem makabren Titel ist eben nicht, einen Elephanten (eine riesige Anforderung) in dünne, für sich wertlosse Scheiben zu schneiden, sondern stattdessen den großen Elefanten über die Zeit nach und nach zusammenzusetzen. Also statt mit einem großen Elefanten mit einem Minielefanten zu starten.
Verwirrt? Jaaa… die Metapher ist schon weit hergeholt. Einfach gesagt sollen kleine Teile der Endlösung nach und nach geliefert werden. und zwar so, dass wir immer wieder ein bisschen Mehrwert generieren können.
In der Übung von Alistair Cockburn welche in diesem Blogartikel von Henrik Kniberg wunderbar mit einer Anleitung versehen wurde (Elephant Carpaccio Facilitation Guide) geht es um eine einfache Kassensoftware. Statt die vermeintlich perfekte Software inklusive Rabatten, Steuerabzug und Co zu programmieren, lädt die praktisch orientierte Programmierungskata dazu ein neu zu denken.
Die Herausforderung: Versuche die Anforderung in 10 – 20 Slices zu teilen. Je mehr desto besser und fokussiere dich dabei darauf, dass jede einzelne Scheibe einen Mehrwert für sich darstellt. Wie schaut es zum Beispiel mit einer Kasse aus, die einen fest einprogrammierten Steuersatz hat? Diese wäre bereits in einem Land einsetzbar und könnte dort echten Kundennutzen und gleichzeitig Feedback für die Entwicklung liefern.
Und wofür jetzt das ganze?
Ein mir sehr wichtiger Punkt ist der, der agilen Amortisation:
Im linken Bild, habe ich versucht darzustellen, wie eine herkömmliche „Big Bang“-Amortisation aussehen würde. Eine lange Zeit verschlingt ein Produkt oder neues Feature Entwicklungskapazitäten ohne in dieser Zeit dem Kunden Wert noch dem Produktentwicklungsteam Revenue zu bringen. Nach einer langen Entwicklungszeit sieht dann das Produkt das Licht der Welt.
Im dargestellten (Ideal-)Fall kann es dann vom Kunden genutzt werden und wird entlohnt.
Das rechte Bild zeigt wie eine agile Amortisation aussehen würde. schon während der Entwicklung wird das Produkt genutzt. Zwar kann man es in dieser Zeit noch nicht zum Zielpreis verkaufen, dennoch sind Werte spür- und nutzbar. Durch das zurückfließende Feedback kann zudem die Entwicklung angepasst werden. Es entstehen bessere/wertvollere Produkte und die Zeit, bis eine Entwicklung vollkommen amortisiert ist reduziert sich drastisch.
Ein Weiterer mir sehr wichtiger Punkt ist, dass sich Entwickler mit den Kunden beschäftigen müssen. Das Verständnis von „Was bedeutet Wert für meinen Kunden?“ muss steigen um wertoptimierte kleine Elefanten formen und entwickeln zu können.
Erfahrungen aus der Praxis
Mein größtes Elefant Carpaccio durfte ich bisher mit 120 Teilnehmern parallel veranstalten. In unterschiedlichen Größen von Teams entstanden unterschiedlich viele und unterschiedlich wertvolle Storyschnitte.
Trotz der Einleitung sah ich in vielen Teams, dass der „technische“ Schnitt fest im Verständnis verankert war. Datenbank für Preise entwerfen, Datenbank programmieren, Backend entwerfen, Backend schreiben, Frontend entwerfen,…
Gerade diese Beispiele helfen mir im Nachgang den Gedanken des Elephant Carpaccio und die Nachteile eines herkömmlichen Schnitts zu beleuchten.
Mein bisheriges Highlight war dennoch eine Gruppe, welche mir nach dem Workshop ein Powerpoint Design Dokument zukommen lies ohne auch nur eine Zeile Code geschrieben zu haben :).
Nachwort
Das richtige Schneiden von Backlog Items ist eine Kür, welche viel Übung benötigt und einen großen Wettbewerbsvorteil darstellen kann. Oft zählt, wer als erstes am Markt ist, wer als erstes auf neue Reglungen reagieren kann und sich auf gegebene Situationen schnell einstellt.
Ute hat in einem schönen Beitrag mögliche Backlogitem Schneidepattern für euch zusammengefasst: Das Story Splitting Cheat Sheet » Emendare.
Ihr habt in eurem Team Herausforderungen mit dem Schneiden von Stories? Gebt uns Bescheid. In einem kleinen auf euer Team zugeschnittenen Workshop bringen wir euch gern die Grundlagen des Storyschnitts bei.