Scrum – verstehen und erfolgreich einsetzen. Henning Wolf

im Unternehmen (siehe [NonakaTakeuchi1995]). Wie in Abbildung 1–7 dargestellt, benötigt das Geschäftssystem Stabilität. Die Kund:innen möchten Verlässlichkeit. Das Unternehmen wird hier seine Effizienz optimieren, um die Leistung dem Kunden oder der Kundin schneller oder preisgünstiger anbieten zu können oder um einfach nur die eigenen Gewinne zu optimieren. Im Innovationssystem ist Stabilität und Effizienzoptimierung allerdings schädlich; Reinertsen spricht von toxischen Ideen (siehe [Reinertsen2014]). Innovation findet nur dann statt, wenn Instabilität zugelassen und gefördert wird. Das Ziel ist, das Lernen zu maximieren.

       Abb. 1–7Geschäftssystem vs. Innovationssystem

      Nonaka und Takeuchi raten übrigens dazu, Geschäfts- und Innovationssystem durch Rotation der Mitarbeitenden miteinander zu verkoppeln. Das für die Softwareentwicklung durchzudeklinieren, ist sehr lehrreich, würde allerdings den Rahmen dieses Buches sprengen. Nähere Informationen zu dem Thema finden sich in [HoffmannRoock2018]. Dort wird auch die Frage thematisiert, ob die Grundannahmen von Nonaka und Takeuchi zur hierarchischen Organisation des Geschäftssystems in der heutigen Zeit überhaupt noch zutreffen.

      Häufig wird das Stacey Landscape Diagram (siehe [Stacey1996]) verwendet, um die Anwendungsbereiche von Scrum zu veranschaulichen. (Ralph Stacey hat sich inzwischen von dem Diagramm distanziert, weil es oft missverstanden wurde; trotzdem ist es unserer Erfahrung nach gut geeignet, um über die Einsatzbereiche von Scrum nachzudenken.) Das Diagramm zeigt auf der x-Achse die Sicherheit der Technologie und auf der y-Achse die Klarheit der Anforderungen (siehe Abb. 1–8). Sichere Technologien werden vom Team gut verstanden und sicher beherrscht. Mit sehr unsicherer Technologie liegen wenige Erfahrungen vor. Die Technologie verhält sich scheinbar jeden Tag anders, und Dokumentation ist nicht vorhanden oder stimmt nicht mit dem tatsächlichen Verhalten überein. Anforderungen sind dann klar, wenn man sie vorher vollständig detailliert aufschreiben kann und sich bei der Systemlieferung herausstellt, dass auch genau diese Funktionen benötigt werden. Unklare Anforderungen lassen sich entweder gar nicht detailliert aufschreiben, oder es stellt sich bei der Systemlieferung heraus, dass etwas anderes benötigt wird.

       Abb. 1–8Stacey Landscape Diagram

      In diesem Diagramm unterscheidet Stacey vier Bereiche: Ist die Technologie sehr sicher und sind die Anforderungen sehr klar, haben wir ein einfaches Projekt vor uns. Im Grunde muss man hier nicht viel nachdenken, man kann »einfach machen«. Best Practices finden hier ihre Anwendung. Wird die Technologie unsicherer oder werden die Anforderungen unklarer, wird das Projekt kompliziert. Man muss analysieren und planen. Bezüglich der Technologien muss man vielleicht verschiedene Optionen gegeneinander abwägen, Prototypen erstellen, Wissen aufbauen oder externe Expert:innen hinzuziehen. Bei den Anforderungen müssen in Konflikt stehende Anforderungen bereinigt werden, und man muss entscheiden, was im Projekt umgesetzt wird und was nicht. Außerdem müssen die Details von Anforderungen geklärt werden, weil sie sich nicht von selbst ergeben. Der Bau einer Brücke fällt in der Regel in den komplizierten Bereich, die Entwicklung einer Software zur internen Zeiterfassung eventuell auch. Das sequenzielle Vorgehen nach dem Wasserfallmodell (auch ingenieurmäßiges Vorgehen) ist für solche komplizierten Projekte geeignet.

      Werden die Anforderungen noch unklarer oder wird die Technologie noch unsicherer, haben wir es mit komplexen Projekten zu tun. Im Gegensatz zu komplizierten Projekten ist bei komplexen Projekten der Ursache-Wirkungs-Zusammenhang immer erst hinterher sicher analysierbar (man spricht von retrospektiver Kohärenz). Die Wettervorherhersage ist ein Beispiel für ein komplexes Problem. Wir können mit viel Aufwand das Wetter zwei bis drei Tage in die Zukunft vorhersagen, aber nicht zwei Wochen. Wenn allerdings ein bestimmtes Wetterphänomen aufgetreten ist (z.B. ein Orkan), kann ein Meteorologe relativ einfach herausfinden, wie es dazu kam. Das Verhalten der Börse ist ein anderes Beispiel oder Fußball. In komplexen Domänen funktioniert das Wasserfallmodell nicht, weil sein langfristiger Planungsansatz darauf basiert, Ursache-Wirkungs-Beziehungen vorherzusagen. Wir brauchen einen Ansatz wie Scrum, der nur kurzfristig plant, dann analysiert, wo man steht, und dann den nächsten Schritt plant.

      Wandern wir im Diagramm noch weiter nach rechts oben, kommen wir in den chaotischen Bereich. Hier lassen sich Ursache-Wirkungs-Beziehungen auch hinterher nicht analysieren. Ein Beispiel dafür ist die Ziehung der Lottozahlen. Man kann die Ziehungen der letzten Jahrzehnte analysieren und kann doch keine Muster erkennen. Daher hilft ein Ansatz wie Scrum hier auch nicht weiter, weil es nichts zu lernen gibt. Man kann im Grunde irgendetwas tun und hoffen, dass der erhoffte Erfolg eintritt. Wenn er nicht eintritt, probiert man was anderes oder das Gleiche noch einmal (beim Lotto spielt es am Ende auch keine Rolle, ob man jede Woche dieselben oder immer andere Zahlen tippt). Entwicklungsprojekte in diesem Bereich sollte man logischerweise mit äußerster Vorsicht genießen. Glücklicherweise kann man häufig Projekte aus dem chaotischen Bereich herausbewegen, indem man auf Technologien setzt, die man einigermaßen beherrscht, und sich mehr Klarheit über die Anforderungen verschafft, z.B. durch Lean User Research und Lean Startup (siehe [Gothelf2012], [Ries2011], [Maurya2012]).

      Unabhängig von Modellen ist bei der Frage nach der Eignung die Änderungsbereitschaft relevant. Wenn das Wasserfallmodell in einem Unternehmen gut funktioniert, gibt es keinen Leidensdruck, und der schmerzhafte Wandel hin zu Scrum wird vermutlich nicht gelingen. Ken Schwaber bringt es auf den Punkt: »If waterfall suits current needs, continue using it« (siehe [James2006]).

       1.4Herausforderung: Denkweise (Mindset)

      In den Anfangszeiten der agilen Entwicklung gab es ein vorherrschendes Gefühl bei denen, die Scrum und XP einsetzten: »Ich habe den besten Job der Welt!« Und auch die Kund:innen der Teams äußerten sich ähnlich: »Wir haben das beste Team der Welt!« Im Laufe der Jahre ist diese Begeisterung deutlich zurückgegangen und einer Ernüchterung gewichen. Unserer Meinung nach hat diese emotionale Ernüchterung mit einem zu starken Fokus auf die Mechanik zu tun, der die hinter Scrum stehende Denkweise nur allzu oft geopfert wurde. Immerhin erreichen Unternehmen auch dann Vorteile, wenn sie nur die Scrum-Mechanik anwenden. Manche waren vor dem Einsatz von Scrum sogar so schlecht aufgestellt, dass ihnen schon eine schlechte Anwendung der Mechanik nennenswerte Vorteile bringt. Sie sind aber noch Welten von dem entfernt, was man erreichen kann, wenn man neben der Mechanik auch die Scrum-Denkweise im Unternehmen verankert:

       Wir interessieren uns dafür, was Wert für die Kundin oder den Kunden schafft.

       Wir optimieren unsere Arbeitsweise kontinuierlich weiter, um besseren Wert für Kund:innen zu schaffen.

       Wir suchen ständig nach neuen Inspirationen, um unsere Arbeitsweise weiter zu verbessern.

       Wir experimentieren ständig mit neuen Ideen.

       Wir sind offen für neue Erkenntnisse, auch dann, wenn sie unangenehm sind.

       Fehlschläge sind für uns nicht einfach nur ein notwendiges Übel, sondern großartige Chancen, etwas zu lernen.

       Wir dezentralisieren Verantwortung und Macht und bauen Politik im Unternehmen ab.

      Dieser Wandel im Denken geht nicht auf die Schnelle, sondern braucht Jahre – wie jeder andere Kulturwandel im Unternehmen auch. Scrum und Agilität sind also nicht einfach nur »Hypes«, die man mal eben schnell mitmachen kann. Richtig verwendet, leiten sie einen tiefgreifenden kulturellen Wandel ein.³

       1.5Das Kapitel in Stichpunkten