Agilität liefert leider nicht, was sie verspricht. Produkte, die im Gegensatz zum Wasserfall den Kunden gefallen und dem Unternehmen viel Geld einbringen. Haben wir mit der agilen Entwicklung etwas falsch gemacht? Ja und nein. Viele Unternehmen betrachten Agilität nur als einen Teil der Produktentwicklung und haben sich damit nicht sehr weit vom klassischen Wasserfall entfernt. Sie konzentrieren sich sehr stark auf die „Delivery“, also darauf, wie das Produkt entwickelt und an den Kunden ausgeliefert wird. Das ist schon ein großer Fortschritt gegenüber dem Wasserfall, denn durch die verkürzten Zyklen und DevOps können neue Funktionalitäten und Bugfixes viel schneller in kleinen Iterationen an den Kunden gebracht werden.
Allerdings lernen die Teams erst durch die Auslieferung der Funktionalität an die Kunden. Product Owner und Stakeholder denken sich Ideen aus, werfen User Stories ins Backlog und das Team setzt sie um. Manchmal trifft man den Nagel auf den Kopf und die Kunden mögen das Produkt/Feature. Und manchmal ist das gelieferte Inkrement nur ein Schuss ins Blaue. Inspect & Adapt funktioniert auch so, ist aber teuer, da die gesamte Delivery Pipeline durchlaufen wird. Außerdem enttäuscht man Kunden und verliert möglicherweise Marktanteile. Im Grunde tappt man im Dunkeln. Man hat nur perfektioniert, „wie wir entwickeln“.
Und wenn ein Teil der Agilität „Product Delivery“ ist, dann ist der komplementäre Teil der agilen Entwicklung „Product Discovery“: Was entwickeln wir und warum? Und hier endet in den meisten Unternehmen die Agilität. „Was“ entwickelt wird, entscheiden Stakeholder, Product Owner und interne Experten. Warum wir es entwickeln und welche Kundenbedürfnisse damit wirklich befriedigt werden, ist meist eine Frage der Phantasie.
Product Discovery bringt Licht ins Dunkel des Backlogs. Bessere Ideen entstehen auf Basis echter Daten und schlechte Ideen landen im Papierkorb. Dafür muss man sich warm anziehen und das Gebäude verlassen, in dem man sich so gemütlich User Stories ausgedacht hat. Man muss mit den Kunden sprechen, die Probleme verstehen, die sie lösen wollen.
Was passiert in der Product Discovery und wer macht es? Es ist wichtig, dass die UX-Rolle im Team besetzt ist, denn Discovery bedient sich aus dem UX-Repertoire: User Research, Prototyping, Design Thinking etc. Es ist aber keine Aufgabe nur für Designer: Product Discovery ist Teamwork und involviert alle Teammitglieder (Product Owner als Teil des Teams). Natürlich müssen Entwickler auch User Stories umsetzen und nicht nur „discovern“, jemand mit technischem Wissen sollte jedoch die Product Discovery unterstützen.
Product Discovery ist nach dem Double-Diamond-Modell aufgebaut. Im ersten Diamanten geht es darum, den Kunden, den Kontext und das Problem zu verstehen. In Phase 1 (Exploration) wird das breite Problemfeld durch Nutzerforschung, Kunden- und Stakeholderinterviews, Datenanalyse erforscht. In Phase 2 wird das Feld eingegrenzt und ein Kernproblem formuliert. In Phase 3 werden verschiedene Lösungsideen generiert und in Phase 4 durch Prototypen und Experimente validiert. Obwohl der Prozess in Phasen unterteilt ist, handelt es sich nicht um einen Wasserfall: Es ist jederzeit möglich, zu einer früheren Phase zurückzukehren und Anpassungen vorzunehmen.
Wie die Product Delivery, die kontinuierlich stattfindet, ist auch die Product Discovery ein kontinuierlicher Prozess. Man spricht daher auch von Continuous Discovery. In jedem Sprint ist der Product Owner zusammen mit den Designern und Entwicklern im Gespräch mit den Kunden, um neue Ideen zu generieren und durch Experimente zu testen. So wird sichergestellt, dass keine Ideen umgesetzt werden, die nicht am Markt validiert wurden. Dadurch wird das Risiko von Fehlentwicklungen reduziert und Zeit und Geld gespart.