agil: systemisch & werteorientiert.

Lean & Minimum Viable Product

 “What gets us into trouble is not what we don't know. It's what we know for sure that just ain't so.”

Mark Twain

Seit dem großen Erfolg des Buches "lean Startup" von Eric Ries sind die Begriffe Lean und Minumum Viable Product (MVP) ein fester Begriff in der agilen Welt.

Der zentrale Ansatz von lean ist die Vermeidung von "waste" also nicht wertschöpfenden Tätigkeiten. Dies wurde ursprünglich im Produktionsbereich für nicht wertschöpfende Tätigkeiten verwendet, die reduziert werden sollten. Ries hat dieses Konzept für startups übertragen - und die größte Verschwendung (bzw. auch der häufigste Grund, warum startup scheitern) ist die Entwicklung eines Produktes, für das es keinen Markt/keine Kunden gibt.

Natürlich liegt es in der Natur von Innovationen, dass eben vorab nicht klar ist, ob das Produkt realisierbar ist und ein Erfolg beim Kunden erzielen wird. Das Konzept des Minimum Viable Products ist ein Ansatz um mit diesem Risiko umzugehen. Im Kern geht es darum, ein Produkt mit einer einfachen Grundfunktionalität schnell auf den Markt zu bringen (oder zumindest Kundenfeedback einzuhören) und zu überprüfen, wie die Kunden darauf reagieren. Dies ist sicherlich der bekannteste Einsatzbereich eines MVP. Allerdings ist das Konzept weiter gefasst. es geht nicht nur darum, ein Produkt schnell auf den Markt zu bringen, sondern allgemeiner um eine schnelle Überprüfung von Hypothesen um zu vermeiden, dass in eine falsche Richtung entwickelt wird und dadurch Ressourcen verschwendet werden. Die Kernfrage ist, wie man mit dem kleinstmöglichsten Aufwand die größten Risiken früh erruieren kann. Diese können technischer Natur sein oder eben auch die Marktakzeptanz. Dies  bedeutet aber nicht zwangsläufig, dass dieses Produkt auch eingesetzt wird. Es können z.B. Kartonprototypen sein, oder Bildschirm mockups, die einem potentiellen Kunden an die Hand gegeben werden. Dann kann z.B. durch ethongraphisches Forschung (also die Beobachtung des Kunden in seiner "normalen" Umgebung) reales Feedback gesammelt werden. Aus eigener Erfahrung kann ich sagen, dass es oft überraschend ist, wie echte Kunden (mit ganz unterschiedlichen IT skills, Hintergründen, etc) mit den Mockup eines neuen Programmes umgehen.

Genauso hilfreich ist es, kritische technische Fragen frühzeitig zu verifizieren, indem z.B. ein stark vereinfachter end-to-end Prozess implementiert wird zu verifizieren, dass kritische Komponenten realisiert werden können.

Im Kern geht es also immer um die frühzeitige Verifzierungen von Hypothesen in der Realität, um ein konsequentes de-risking.