swissICT Magazine: Sie fordern immer wieder, dass man im Software-Engineering aufhören sollte, Metaphern der Fertigungsindustrie zu benutzen. Warum?
Dave Snowden: Wenn wir nur auf Fertigungsaspekte fokussieren, führt das zu einem sehr linearen Ansatz. Wir brauchen aber einen Entwicklungsansatz mit mehr Koevolution. Dabei führt man zuerst zeitgleiche Experimente bezüglich Anwenderbedürfnis und eigenen technischen Fähigkeiten durch, bevor man sich in einen voll strukturierten Scrum-Prozess begeben würde. Viele einzelne Praktiker tun dies bereits instinktiv, doch das genügt nicht.
Agilität läuft Gefahr, in dieselben Fallen zu treten wie traditionelle Entwicklungsmethoden. Lernen wir nichts aus vergangenen Fehlern?Scrum hat teilweise die linearen Modelle des «Wasserfalls» geerbt, wenn auch im schnelleren Takt vorgegangen wird. Wir müssen von linearen Modellen wegkommen. Es braucht einen Paradigmenwechsel, wenn wir mit komplexen Systemen umgehen wollen, bei denen keine klaren Treiber erkennbar sind. Denn dort existieren nur begrenzt wiederholbare Ursache/Wirkung-Verbindungen.
Sie haben das Cynefin Sensemaking Framework geschaffen. Was ist das und welchen Nutzen hat es im Software-Entwicklungs-Umfeld?Es hilft uns, verschiedene Arten von Systemen zu verstehen und entsprechend wirksame Problemlösungstechniken zu wählen. Das Prinzip der begrenzten Anwendbarkeit ist essentiell. Cynefin sagt nicht, dass alle Problemdomänen komplex sind, sondern dass gewisse Dinge geordnet und andere komplex sind. Wir müssen die richtige Herangehensweise für jede Domäne wählen.
Sie sagen, dass Cynefin oft falsch angewendet wird. Warum?Ein Problem ist, dass man darin nur eine 2-dimensionale Matrix mit fünf Domänen sieht, ohne zu merken, dass Unordnung und Chaos nur Übergangszustände sind. Ausserdem vergessen viele, dass die Hauptidee von Cynefin darin besteht, sich zwischen den Domänen zu bewegen. So kann man beispielsweise die Rahmenbedingungen lockern, um ein kompliziertes System komplex werden zu lassen, und dadurch neue Möglichkeiten zu erkunden. Ebenso kann man ein komplexes System durch engeres Fassen der Grenzen «nur» kompliziert werden lassen, um die neu entdeckten Möglichkeiten zu verwerten.
Sie vertreten den Aufbau einer «save-to-fail»-Umgebung im Gegensatz zu einer Umgebung die «failsafe» ist. Können Sie kurz den Unterschied erklären?Den Unterschied sieht man schon in den Worten! Wenn die Situation komplex ist, dann sollte man parallele Experimente fahren, die auch fehlschlagen dürfen. Man kann das System nur verstehen, wenn man damit interagiert. Diese Experimente sollte man als Portfolio betrachten: Einige sollten zum Beispiel ein hohes Risiko bergen, mit hohem Gewinn, andere sollten indirekt sein (sich nur mit angrenzenden Problemen befassen).
Das Gespräch führte Jiri Lundak, Mitglied der swissICT-Fachgruppe Lean, Agile & Scrum sowie Senior Software Engineer bei REDpill GmbH
