Wie läuft die Implementierung eines Features normalerweise ab? Stakeholder oder Product Owner kommen auf eine Idee, haben eine Vision und arbeiten diese aus. Sie denken sich vielleicht sogar einen Business Case aus, der oft auf fragwürdigen Daten basiert, nur um „grün“ zu sein. Und wenn sie das Feature ohne Business Case in die Entwicklung geben können, dann wurde keine Zeit investiert, um zu evaluieren, ob das Feature einen Mehrwert für den Kunden bringt. Dann landet das Feature in Form von User Stories auf dem Backlog und wird iterativ entwickelt. Es gibt sogar Reviews des Fortschritts, bei denen der Anforderer dabei ist.
Welche Gefahren birgt dieses Vorgehen? Von der Idee bis zur Veröffentlichung des Features gibt es keinen Moment, in dem das Feature mit den Kunden des Produkts validiert wird. Erst wenn es fertig ist oder in einer ersten Version (fälschlicherweise als „MVP“ bezeichnet) erscheint, kann das Team den Nutzen des Features validieren. Zu diesem Zeitpunkt ist es meiner Meinung nach bereits viel zu spät: Wenn das Feature sein Ziel verfehlt, wurde unter Umständen viel Geld unnötig verbrannt. Entweder kommt das Feature bei den Kunden gar nicht an oder es muss mühsam angepasst werden.
Um das Risiko des Scheiterns eines Features zu minimieren, sollte bereits die Idee mit den Kunden validiert werden. Hier kommt das „echte“ MVP ins Spiel: Das Team soll Wege finden die Idee zu validieren, ohne die tatsächliche Entwicklung. Es kann eine Attrappe sein, eine Anmutung, ein anderer Weg um zum ähnlichen Ergebnis zu kommen. Man kann sich eine Lösung ausdenken und dann solange abspecken, bis sie nicht mehr funktioniert, um ihren Wert mit dem Kunden zu testen. Mehr zu dem MVP stellte ich dem Artikel Ein MVP ist oft kein MVP dar.
Systematische Vorgehensweise
Agile Teams sprechen gerne von „Continuous Delivery“. In der Praxis bedeutet dies, dass Software häufig und schnell gebaut, getestet und bereitgestellt wird. Auf diese Weise können kleine Änderungen von den Benutzern getestet werden. Das Team kann so die korrekte Implementierung schnell validieren.
Ähnlich wie bei der Entwicklung kann auch die Entwurfsphase in einen kontinuierlichen Modus überführt werden: Continuous Design. Jedes Feature beginnt mit der Designphase, die sich mit dem Problem und der Lösung beschäftigt. Es ist wichtig zu verstehen, dass alle Annahmen Hypothesen sind, die mit echten Kunden validiert werden müssen. Je früher im Prozess die Validierung der einzelnen Hypothesen stattfindet, desto schneller können falsche Annahmen aussortiert oder korrigiert werden. Man vermeidet damit viel Verschwendung in den weiteren Schritten, da diese nicht auf falschen Annahmen aufbauen würden. Ohne Systematisierung ist der Erfolg einer Idee oder eines Features Zufall.
Auf Continuous Design werde ich in einem anderen Blogpost näher eingehen. Wichtig für die agile Produktpipeline ist, dass die Entwicklung mit einem Satz validierter grober Anforderungen beginnt. Wenn sich das Team mit dem Problem beschäftigt, greift es auf User Research zurück (z.B. Personas und Jobs-To-Be-Done), also auf echte Kunden-Insights. Es werden Hypothesen aufgestellt, die auch mit potenziellen Kunden validiert werden. Wenn das Problem verstanden scheint, wird eine Lösungshypothese entwickelt und validiert: Hier kommt das MVP ins Spiel. Erst wenn aus dem Design hervorgeht, dass das Problem existiert und das Team eine Lösung liefern kann, die von den Kunden akzeptiert wird, beginnt die Entwicklung. Da die Entwicklung agil ist, setzt das Team das Feature in kleinen Losgrößen um und testet es mit repräsentativen Nutzern.
Wenn das Feature fertig ist und den Kunden live zur Verfügung gestellt wird, evaluiert das Team anhand verschiedener Metriken, ob das Feature auch den erwarteten Kundennutzen bringt (Fokus auf Outcome). Hat sich die Lösungshypothese als richtig erwiesen oder nicht? Die Erkenntnisse fließen in die nächste Iteration der Produktpipeline ein.
Testgetriebenes Design
Ähnlich der testgetriebenen Entwicklung, bei der zuerst getestet und dann implementiert wird, kann in der Agilen Produktpipeline auch das Design eines Features testgetrieben erfolgen. Noch bevor die Lösung implementiert wird, überlegt sich das Team, wie der Mehrwert des Features evaluiert werden kann. Das Team muss messen, ob das Feature zum gewünschten Kundennutzen geführt hat und einen positiven ROI aufweist. Dies ist das Produktpipeline-Feedback, das agiles Nachsteuern auf Basis des Outcomes und nicht des Outputs ermöglicht.
