Читать книгу Scrum – verstehen und erfolgreich einsetzen - Henning Wolf - Страница 20

Scrum eignet sich für die Entwicklung, wenn nennenswerte Probleme zu lösen sind. Für repetitive Tätigkeiten (z.B. Produktion oder Erbringen eines standardisierten Service) ist Scrum nur bedingt verwendbar und häufig zumindest ineffizient. Das verwundert auch nicht weiter, wenn man sich vergegenwärtigt, dass für das operative Erbringen einer Leistung andere Dinge wichtig sind als für die Entwicklung von Produkten oder Dienstleistungen. Nonaka und Takeuchi unterscheiden dazu zwischen dem Geschäfts- und dem Innovationssystem 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]).