Early Feedback – Der MVP Gedanke

Es gibt wohl kaum einen Begriff, bei dem wenn ich verschiedene Personen nach seiner Bedeutung frage ich so viele verschiedene Antworten bekomme wie beim MVP. Für die einen ist ein MVP bereits ein voll ausgebautes Stückchen Software mit einem Mehr an Funktionalität, andere sehen in ihm tatsächlich die Minimalausbaustufe eines Produkts. Für einige kann ein MVP eine Vielzahl von Bugs enthalten, für andere muss er voll produktionsfähig sein.

Es gibt wohl kaum einen Begriff, bei dem wenn ich verschiedene Personen nach seiner Bedeutung frage ich so viele verschiedene Antworten bekomme wie beim MVP. Für die einen ist ein MVP bereits ein voll ausgebautes Stückchen Software mit einem Mehr an Funktionalität, andere sehen in ihm tatsächlich die Minimalausbaustufe eines Produkts. Für einige kann ein MVP eine Vielzahl von Bugs enthalten, für andere muss er voll produktionsfähig sein.

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 Metho

zum Originalartikel