Jürgen Hoffmann - 30 Minuten Scrum

Die Mitarbeiter geben ihr neu gelerntes Wissen innerhalb des Unternehmens gerne weiter – wenn das Management Kontaktmöglichkeiten schafft. Erfahrungen werden auch institutionalisiert. Wobei man da vorsichtig sein muss: Unter sich plötzlich ändernden Bedingungen können Lehren der Vergangenheit hinderlich sein. Es braucht einen Wechsel von Lernen und Abgewöhnen von Vertrautem, um in sich schnell wandelnden Märkten zu bestehen.

1993 formte Jeff Sutherland das erste Scrum Team bei der Easel Corporation. 1995 präsentierte Ken Schwaber die Erfahrungen mit Scrum in der Softwareentwicklung auf der OOPSLA-Konferenz. In den Jahren seitdem ist Scrum von der Agile Community weiterentwickelt worden. Unzählige Beiträge von Anwendern und viele Konferenzen haben geholfen, Scrum zu verbessern und auf der ganzen Welt bekannt zu machen.

Scrum ist nicht am Reißbrett entstanden. Es ist die kondensierte Erfahrung aus der Entwicklung Tausender Produkte. Sein erfolgreicher Einsatz setzt ein auf gegenseitigem Vertrauen basierendes Zusammenspiel von Management und Produktentwicklungsteams voraus .

Nicht in jeder Situation ist der Einsatz von Scrum sinnvoll. Ein Denkmodell, um sinnvolle Einsatzszenarien zu identifizieren, stammt aus frühen Versionen des Buches „Strategic Management and Organisational Dynamics“ von Ralph Stacey.

Abb. 1: Die Stacey-Matrix

Die den Denkraum aufspannenden Achsen sind die Fragen nach dem „Was“ (den Anforderungen) und dem „Wie“ (der Technologie) der zu bewältigenden Herausforderung. Im Bild erkennen wir nahe des Ursprungs beider Achsen die einfache Domäne. Hier geht es um sich wiederholende einfache Tätigkeiten, wie sie zum Beispiel in der Produktion am Fließband anfallen.

Beispiel: Als Student habe ich im Mercedes-Werk in Wörth am Rhein in der Fahrerhaus-Produktion mitgearbeitet. Alles, was ich für diesen Job – Einbau von Mittelkonsolen – wissen musste, hatten mir meine beiden Kollegen an der Fließbandstation innerhalb eines Tages beigebracht .

Wenn das zu lösende Problem etwas weiter weg vom Ursprung verortet ist, liegt es im Modell in der komplizierten Domäne. Hier ist eine Analyse einer Expertin erforderlich. Sie wird dann einen Plan entwickeln. Wenn die richtigen Mitarbeiter diesen Plan korrekt ausführen, wird er funktionieren.

Ganz anders die Situation sehr weit weg vom Ursprung: Wir wissen weder annähernd, was das Produkt können soll, noch haben wir die leiseste Idee, mit welcher Technologie eine Umsetzung gelingen kann. Vielleicht müssen wir die Technologie erst erfinden? Das ist die chaotische Domäne – manchmal auch Forschung oder Vision genannt. Bei dieser Art von Herausforderung braucht es ein paar Ansagen, um zum Beispiel auf der „Was“-Achse näher an den Ursprung zu gelangen.

Beispiel: Die Firma SpaceX wurde gegründet, um der Menschheit zu ermöglichen, den Mars zu kolonisieren. Zum Gründungsdatum im Juni 2002 war die Herausforderung in der chaotischen Domäne. Der wichtige Shift in die komplexe Domäne gelang durch den Fokus auf: „Baut erst mal eine Rakete, die starten und wieder landen kann. Über den Mars sprechen wir später.“

In der komplexen Domäne sind die Probleme lösbar durch einen Zyklus aus Experiment, einem Schritt der Überprüfung und einer anschließenden Anpassung des Experiments. Wie wir später sehen werden, realisiert Scrum einen solchen Zyklus.

Kompliziert oder komplex?

Im Scrum-Training werde ich oft nach dem genauen Unterschied zwischen „kompliziert“ und „komplex“ gefragt. Dazu ein Beispiel:

•Kompliziert:In der komplizierten Domäne kann die Expertin tatsächlich einen realistischen Plan machen. Sie fügt noch eine Liste mit zu klärenden Fragen hinzu und sobald die Mitarbeiter diese Liste abgearbeitet haben, steht der Plan fest.

•Komplex:In der komplexen Domäne hilft uns diese Analyse nur für einen sehr kleinen Schritt, weil dann auf einmal unsere Liste mit offenen Fragen um neue Fragen ergänzt wird. Im Komplexen ist es prinzipiell nicht möglich, einen Plan zu machen, der den gesamten Weg bis zur Lösung Bestand hat. Wir müssen ihn ständig neu anpassen und immer wieder neue Experimente vornehmen, die zu Beginn nicht absehbar waren. Das Ziel bewegt sich vor unseren Augen. Retrospektiv betrachtet sehen wir die Evolution der exzellenten Lösung – die man vorwärts in die Zukunft nicht planen konnte. Überall fehlten Daten und Erfahrungen, über die wir am Ende der Entwicklung verfügen.

Da Scrum den abgebildeten Zyklus aus „Experiment“, „Anpassen“ und „Überprüfen“ realisiert, ist es sinnvoll, Scrum in der komplexen Domäne einzusetzen. Hierbei ist es wichtig, zu verstehen, dass Produktentwicklung immer aus einer Mischung von einfachen, komplizierten, komplexen oder auch chaotischen Herausforderungen besteht. Wenn der Schwerpunkt im Komplexen liegt, ist der Einsatz von Scrum empfehlenswert. Und das ist der Erfahrung nach bei der Entwicklung wirklich neuer Produkte der Fall.

Dabei kann es sein, dass ein Produkt seinen Lebenszyklus in der chaotischen Domäne beginnt. Eine vage Idee – noch sehr unscharf – ist entstanden. Mit der Fokussierung auf einen Markt, eine Kundengruppe oder eine bestimmte Technologie bewegt sich das Produkt in die komplexe Domäne. Extrem beschleunigtes Lernen während der Entwicklung hilft uns, den entscheidenden Vorteil vor der Konkurrenz herauszuarbeiten.

Irgendwann ist das Produkt bei vielen Kunden im Einsatz. Es findet noch Produktpflege im geringen Umfang statt. Erfahrung und stabile Messwerte helfen jetzt, wo das Produkt in der komplizierten Domäne angekommen ist. Ein Kundenproblem kann von einem der Produktexperten analysiert und einer Kundin kann eine wasserdichte Reparaturanleitung oder ein funktionierender Workaround übermittelt werden.

In der einfachen Domäne angekommen, geht es nur noch um die Nutzung des Produktes. Einfache Schrittfür-Schritt-Anleitungen helfen, jedes mögliche Einsatzszenario in den Griff zu bekommen. Am Produkt selbst ändert sich nichts mehr.

Neben der Anforderung, dass die zu lösende Herausforderung ein Team erfordert und in der komplexen Domäne liegen sollte, gibt es keine weiteren Einschränkungen. Bekannt wurde Scrum durch die Erfolge bei Softwareprodukten.

Wenn man mit der Liste von Produkten beginnt, die Nonaka und Takeuchi damals untersucht haben, findet man eine Spiegelreflexkamera, einen Kopierer, ein PC-System, ein Auto und eine Sucherkamera. Offensichtlich kann man Scrum in der Hard- und Softwareentwicklung sinnvoll einsetzen.

Meine Kollegen und ich haben in der Vergangenheit Teams begleitet, die in vielfältigen Bereichen tätig waren: Immobilienverwaltung, Entwicklung von Unterwasserrobotern, Sicherheitssysteme, Fensterheber für Autotüren. Wir kennen Scrum Teams, die an Sitzmechaniken, an medizinischen Geräten oder an Maschinen zur Herstellung von PET-Flaschen arbeiten. Außerdem haben wir Scrum in der Hochschullehre eingesetzt und es ist eine ganze Community rund um den Einsatz in Schulen und in der Erwachsenenbildung entstanden.