Manchmal sehnt man sich als Produktmanager in die guten alten Zeiten des Wasserfalls zurück. Die Welt war da noch einfach und übersichtlich. Der Produktmanager saß am Schreibtisch, dokumentierte seinen Plan in einem PRD, übergab es an die Entwickler und machte sich dann daran, das nächste PRD zu verfassen. Zwischendurch wurde man nur ab und zu von Zwischenfragen belästigt, und man freute sich, wenn das Projekt dann nach 3 Jahren (mehr oder weniger) abgeschlossen war.
Heute kommt man hinter der Entwicklung des agilen Produktmanagements kaum noch nach. Konnte man sich bis vor einiger Zeit noch mit Scrum ausreichend agil fühlen und den Wasserfall besserwissend belächeln, schein heute kein Projekt mehr ein vernünftiges zu sein, wenn es nicht nach Lean Startup umgesetzt wird.
Diese Entwicklung ist auf der einen Seite extrem spannend, denn hier sind in den letzten Jahren grundlegende Prinzipien einer ganzen Industrie verändert worden, und die Reise ist noch lange nicht zu Ende. In der Praxis können diese Veränderungen und Trends auf der anderen Seite allerdings rasch zur Verwirrung führen. Gefährlich wird es immer dann, wenn die agilen Ansätze nur halb verstanden und entsprechend nach Moden wahllos gewechselt werden. Richtig aber ist, dass es nicht DEN agilen Entwicklungsansatz gibt. In einem Unternehmen gibt es ganz unterschiedliche Aufgaben, die auch unterschiedlich angegangen werden sollten. Nachfolgend stellen wir ein einfaches Schema zur Einteilung von Projekten vor, das bei der Wahl „der Agilität“ helfen soll.
Nach Cynefin von David Snowden lassen sich auch in der Produktentwicklung u.a. komplizierte und komplexe Umfelder unterscheiden. Kompliziert ist ein Umfeld dann, wenn die Ursache/Wirkungsbeziehung von vornherein klar ist. Komplexe Umfelder zeichnen sich hingegen dadurch aus, dass die Ursache/Wirkungsbeziehung nicht vorhersehbar ist und allenfalls nachträglich analysiert werden kann. Während man also in einem komplizierten Umfeld a priori eine Aussage darüber treffen kann, was eine Änderung von A für Auswirkungen auf B hat, ist dies in komplexen Umfeldern nicht möglich. In komplexen Umfeldern bleibt einem deshalb nichts anderes übrig, als sich anhand von Heuristiken dem gewünschten Zustand von B zu nähern. Im Zweifel sind dabei gleich eine Vielzahl von Variablen A systematisch möglichst schnell zu verändern und ex post in ihrer Wirkung auf die Zielgröße B zu bewerten. Genau das ist der Kern aller agilen Ansätze: Effektives Lernen durch schnelles Feedback.
Startups bilden eine extremere Form des komplexen Umfeldes. Hier ist nicht nur die Ursache/Wirkungsbeziehung zwischen Gestaltungsvariablen unklar, sondern auch die zugrundeliegende Idee und Vision sind unsicher. Es ist also nicht nur unklar, ob die Lösung richtig ist, sondern auch, ob man das richtige Problem in der Vision erfasst hat. Entsprechend müssen neben dem agilen Build/Measure/Learn Zyklus zum Testen einzelner Maßnahmen auch die Idee und Vision validiert werden, was den Kern des Lean Startup Ansatzes bildet:
Im Unterschied zu einem Startup muss ein erfolgreiches Unternehmen mit einem skalierenden Geschäftsmodell die Vision und Idee nicht mehr hinterfragen, der Grad der Komplexität sinkt. Zur Optimierung des Produkts, das auf der validierten Vision/Idee aufbaut, reicht nun agiles Lernen auf Basis des Build/Measure/Learn Zyklusses:
Zu beachten ist dabei allerdings, dass der Weg des agilen Lernens nicht unendlich weitergegangen werden kann, da das Geschäftsmodell zwar kontinuierlich optimiert wird, gleichzeitig wirkliche Innovationen aber nicht möglich sind. Jedes Unternehmen muss deshalb kontinuierlich (zumindest sehr regelmäßig) bewusst den Weg in ein hoch komplexes (oder sogar chaotisches) Umfeld suchen, um Innovation zu ermöglichen, die dann zurück in ein komplexes Umfeld überführt werden müssen, um sie skalieren zu können. Mit anderen Worten: Jedes Unternehmen muss regelmäßig Startups generieren.
Mit der Verbreitung von agilen Entwicklungsansätzen und Lean Startup ist aber vielfach in den Hintergrund gerückt, dass es in jedem Unternehmen auch einige Dinge zu entwickeln gibt, die „nur“ kompliziert sind. Hier ist vollkommen eindeutig, was mit B passiert, wenn A geändert wird. Beispielsweise ist klar, welche Trackingparameter ich messen kann, wenn ich eine bestimmte Trackingtechnologie einbaue. Hier begrenzt sich die Unsicherheit auf technische Fragestellungen, so dass nicht verlässlich abschätzbar ist, welcher Aufwand im Einzelnen hinter den Tasks steckt. Um dieser Unsicherheit zu begegnen, reicht aber eine einfache agile Planung in einem linearen Modell aus, um Aufwand und Nutzen in einem vernünftigen Verhältnis stehen zu lassen:
Erfolgreiche Unternehmen sind also gleichzeitig mit komplizierten, komplexen und hoch komplexen / chaotischen Umfeldern konfrontiert und sollten bewusst zwischen den verschiedenen agilen Ansätzen unterscheiden.
Foto von adam fletcher auf flickr unter CC Lizenz