Woher weiß ich vorab, ob sich ein Feature, ein Produkt oder ein Projekt lohnt?
Die kurze Antwort ist: Man kann es nicht wissen. Aber es ist möglich mehr oder weniger gute Schätzungen aufzustellen, je nachdem wie sehr sich die eigenen Annahmen decken mit der Realität. Die Praxis in der Softwareentwicklung zeigt: in der Regel liegen Entscheider nicht selten weit daneben. 97% aller Großprojekte, die nach dem Wasserfallprinzip (Analyse vor der Umsetzung) arbeiten, scheitern oder überschreiten das Budget, den Zeitrahmen oder die Anforderungen. Wenn also weder Analyse noch Intuition hilft – was dann?
Learning by doing
Die grundlegende Idee von Scrum und des evidenzbasierten Managements beruht auf der empirischen Methode: Inspizieren und Adaptieren. Es erinnert ein bisschen an das Prinzip des „learning by doing“. In einem komplexen System kann Wert nicht ausreichend vorab bestimmt werden. Anstatt also viele Ressourcen in eine Analyse und Konzeptionsphase zu investieren, stellt man sinnvolle Hypothesen und Annahmen auf und verifiziert diese möglichst schnell durch Releases. Aus den gewonnenen Erkenntnissen werden neue Hypothesen gebildet und umgesetzt – dadurch erreicht man möglichst schnell eine Wertmaximierung. Wir sagen gern: „Wer beim Schachspielen zweimal pro Runde zieht, schlägt selbst einen Schachweltmeister.“
Laut der Lean Startup-Community passiert es nicht allzu selten, dass die ursprüngliche Idee komplett verworfen wird und durch das bessere Verständnis des Marktes wesentlich effizientere Ideen umgesetzt werden können. Die Ursprünge dieses wissenschaftlichen Ansatzes liegen vor allem im Lean Manufacturing, das in den 30er Jahren von Toyota weiterentwickelt wurde, basierend auf dem Ansatz des wissenschaftlichen Managements von Frederick Taylor und Henry Ford. Eric Ries hat in seinem Buch „Lean Startup“ die Ansätze des Lean Manufacturing mit denen der modernen Softwareentwicklung zusammengeführt und den „Bauen, Messen und Lernen-Ansatz“ als Kernkonzept der Produktentwicklung hervorgehoben. Mit dieser Macher-Mentalität werden Projekte erfolgreicher umgesetzt.
Umgehen mit Unsicherheiten
Wir leben mittlerweile in einer komplexen Welt, in der unterschiedliche Faktoren auf den Erfolg eines Projektes oder Produkts einwirken. Seit dem Ende des Kalten Krieges wird dafür häufig das Akronym “VUCA” verwendet. Es steht für Volatilität, Ungewissheit, Komplexität und Ambiguität. In der Softwareentwicklung ist die Weitsicht meist gering. Was passiert als Nächstes? Auf welches Ereignis, welche Gesetzesänderung, welche Veränderung am Markt, welche neue Technologie muss ich als Nächstes reagieren? Es ist wie ein Nebel der im Tal liegt. Um zu sehen was im Tal ist, muss man hineingehen.
Man kann sich diese Unsicherheit auch vorstellen, wie den Cone of Uncertainty aus der Meteorologie. Aufgrund der komplexen meteorologischen Wechselwirkungen ist ein exakter Verlauf eines Wirbelsturms gegenwärtig nicht berechenbar. Es können für den Weg des Wirbelsturms Wahrscheinlichkeiten berechnet werden, die mit einem längeren Zeithorizont mit zunehmender Unsicherheit behaftet sind.
Umlaufbestand = Durchsatz * Durchlaufzeit (im Durchschnitt)
Nachdem wir möglichst schnell unsere Hypothesen validieren wollen, arbeiten wir an möglichst wenig Elementen gleichzeitig. Zudem hat sich gezeigt, dass Parallelität häufig zu versteckter verschwendeter Zeit führt. „Ich komme erst am Abend wirklich zum Arbeiten“ – ein Satz den man öfter hört. Ein typisches Zeichen für zu wenig Fokus, ausgelöst durch Parallelität oder zu vielen Verantwortungsbereichen.
Fazit
Sowohl durch Lean Startup als auch evidenzbasiertes Management zeigt sich, dass in einer komplexen Welt schneller Wert geschöpft werden kann, wenn man schneller lernt. Oft können innerhalb weniger Wochen mit einem geringen Budget Annahmen durch erste Releases validiert und dadurch Projektrisiken minimiert werden. Die Wertschöpfungskurve steigt in der Produktentwicklung stärker als gegenüber traditionellen Ansätzen wie dem Wasserfallprinzip.