Fakt ist: Ein MVP – ein Minimum Viable Product – sollte genutzt werden, um frühzeitig funktionierende Software an den Kunden auszuliefern und somit auch so früh wie möglich im Lifecycle des entstehenden Produktes Feedback zu sammeln.
Das große Missverständnis um agile Produktentwicklung
Die wohl beste Erklärung für ein MVP habe ich in einem Blog-Beitrag des schwedischen Agile Coache Henrik Kniberg gefunden. Mittels einer sehr schönen Grafik räumt er auf mit einem großen Irrglauben rund um iterative und inkrementelle (aka agile) Produktentwicklung. 
Die obere Reihe zeigt einfach erklärt, wie man es nicht tun sollte. Im Beispiel geht es darum, dass der Kunde ein Auto bestellt hat. Die inkrementelle Entwicklung stellt nun mit jedem Sprint ein Ergebnis zur Verfügung. Natürlich wird der Kunde uns für verrückt erklären, wenn wir ihm im ersten Schritt lediglich einen Reifen zur Verfügung stellen. Auch in den nächsten Schritten mit Bereitstellung der Chassis, sowie der Karosserie werden wir den Kunden nicht glücklich machen. Weil letzten Endes keines der Sprintergebnisse in irgendeiner Form nutzbar ist.
Über den Kunden lernen durch frühes Feedback
Und genau darum geht es in der agilen Produktentwicklung: Am Ende eines jeden Sprints gibt es ein nutzbares Ergebnis, anhand dessen Nutzung durch den Kunden wir Feedback gewinnen können für die nächste Iteration. Dabei hinterfragen wir stets auch die Intention des Kunden, das Warum für das gewünschte Produkt. Das wird nun durch die untere Reihe visualisiert.
Auch wenn das im ersten Schritt gelieferte Skateboard beim Kunden sicherlich keine Freudensprünge auslösen wird, ist es ein voll nutzbares Produkt, welches das zu Grunde liegende Problem des Kunden bereits angeht: Sich von A nach B zu bewegen.
Um Handling-Probleme mit dem ersten Wurf zu beseitigen, wird ein Lenker spendiert und das Skateboard mutiert in der nächsten Iteration zum Roller. Mit einem Fahrrad in der nächsten Iteration gehen wir das Problem an, dass ggf auch weitere Strecken zurückgelegt werden können. Und dann lernen wir während der Entwicklung weitere Dinge über unseren Kunden: Ggf liebt er den Fahrtwind im Gesicht und das Bewegen an freier Luft? Vielleicht ist er mit dem Fahrrad schon rundum zufrieden. Vielleicht reichen im grundsätzlich die zwei Räder und um noch schneller und weiter voranzukommen möchte er ein Motorrad. Oder es wird am Ende doch das Auto.
All das entscheidet sich im Laufe der Nutzung des Produktes durch das erhaltene Feedback. Ein Feedback, dass wir – hätten wir das Produkt wie oben dargestellt ohne voll funktionsfähige Inkremente entwickelt – erst ganz am Schluss erhalten hätten. Durch die frühzeitige Bereitstellung eines minimal lebensfähigen (oder wie Henrik Kniberg es sagt minimal liebenswerten oder minimal testbaren) Produktes erhalten wir also wertvolles Feedback, können die weitere Entwicklung perfekt anpassen und steuern und zudem auch Kosten sparen für Dinge, die der Kunde gar nicht möchte oder benötigt.
Aus dem wahren Leben: Ein MVP bei der atrify im GS1 Data Quality Excellence Service
Bei der atrify haben wir im letzten Jahr ein MVP gemeinsam mit der GS1 Germany und der SmartDataOne erschaffen. Beim GS1 DQX Service sollen über das GDSN ausgetauschte Produkte durch einen Begutachtungsprozess z.B. mit Produktabbildungen verglichen werden, ob die gelieferten Produktdaten mit ihnen übereinstimmen, um somit nachhaltig die Datenqualität für den Handel zu erhöhen.
Der GS1 DQX Service kam mit einem fast hundertseitigen Fachkonzept, in dem alle Anforderungen an den Begutachtungsprozess und das benötigte System beschrieben waren recht “wasserfallig” daher. Von Beginn an holten wir hier den Kunden mit an Bord, um ihn nachhaltig von der agilen Umsetzung des Services zu überzeugen.
Initial haben wir aus dem Grobkonzept also alle relevanten Punkte in User Storys überführt und in Form von Post-Its an eine Wand gebracht. Die User Storys wurden dann anhand der verschiedenen Akteure im System und einer damit verbundenen User Journey geordnet. Gemeinhin bekannt ist diese Methodik als Story Mapping nach Jeff Patton.
Auf Grund der Vielzahl beteiligter Akteure und relevanter Usecases für eine grundlegende Abbildung des Prozesses haben wir es zwar nicht geschafft, bereits nach einem Sprint ein nutzbares Produkt zu haben, allerdings haben wir an der Wand die notwendigen Storys für unseren MVP definieren und eingrenzen können und hatten dann nach drei Sprints ein erstes nutzbares Produkt.
Die initial erstellte Story Map sollte uns noch für lange Zeit dienen, um gemeinsam mit dem Kunden die sinnvollsten nächsten Schritte zu besprechen und somit das Backlog zu priorisieren.
Für jeden kommenden Sprint konnten wir somit klare Ziele für dessen Outcome ableiten und neues Feedback über das jeweils umgesetzte Ergebnis erhalten.
Bestätigt wurde das Vorgehen dadurch, dass sich die Kartenlandschaft im Laufe der Zeit ständig verändert hat. Neue Karten kamen in den einzelnen Spalten hinzu, die vorab nicht vorgesehen waren, entweder weil sie in dieser Form vorab nicht bedacht waren oder weil bestimmte Funktionalitäten mit sinnvollen Features ergänzt wurden. Auf der anderen Seite verschwanden aber auch Karten von der Wand, die im Nachhinein einfach als nicht mehr sinnvoll erachtet wurden oder deren Aufwände bei der Umsetzung dann doch nicht mehr im Verhältnis ihres erbrachten Nutzens standen.
Das gesamte Vorgehen, auf diese Art und Weise hat ein hohes Level an Transparenz geschaffen und brachte zu dem auch eine Menge gutes Feedback von Seiten des Kunden. Und am Ende des Tages geht es in einer kundenzentrierten und agilen Produktentwicklung ja um genau das: einen zufriedenen Kunden durch frühe Bereitstellung eines Produktes ohne überflüssigen Schnick Schnack, dass sich auf seine Bedürftnisse und Anforderungen konzentriert.
