Alistair Cockburn hat vor Jahren den Begriff “Heart of Agile” aufgebracht. Seine Idee war es, aus dem agilen Methodenwahnsinn auszubrechen und stattdessen einfache Prinzipien aufzustellen.
Selbst einer der ersten Agilisten überhaupt – Alistair hatte nicht zuletzt jenes sagenhafte Treffen organisiert, bei dem das Agile Manifest entstand – war er erst spät zum Certified Scrum Trainer (CST) geworden. Eigentlich absurd, dass ausgerechnet Cockburn eine Prüfung zum CST machen musst. War er es doch, der 2003 die erste Agile Software Development Konferenz überhaupt organisiert hatte. Und Alistair wusste auch mehr über das agile Arbeiten als wir alle zusammen. Auf eben dieser Konferenz habe ich u.a. Ken Schwaber und Jim Highsmith zum ersten Mal getroffen und kennengelernt. Auf eben dieser Konferenz habe ich mit Stacia, die wir als Keynote Speakerin gewinnen konnten, die Nacht durchtanzt und war in Alistairs Hotelzimmer bei der After Party, bis uns die Security aus dem Zimmer warf… aber das ist eine andere Geschichte.
Alistair hatte also die Idee aus dem Methodenwahnsinn auszubrechen.
SHU HA RI
Jahre zuvor schon hatte er der agilen Community erklärt, dass es beim Erlernen von neuen Fähigkeiten, ähnlich wie beim Aikido, drei Level des Lernens gibt: Shu, Ha, Ri. Und es sei wichtig, diese zu verstehen.
Shu ist jener Level in dem der/die Auszubildende genau eine Methode perfekt erlernt.
Dann – im Ha – lernt der Lehrling viele andere Methoden kennen – wir würden ihn/sie jetzt als Gesellen:in bezeichnen. (Wobei manche Menschen tatsächlich nie aus der Shu-Phase herauskommen – das sind dann die Scrum Cargo Cult-Leute.)
Erreicht man den Level des Ri, ist man auf dem Level des/der Meisters:in, tritt aus dem Lehrbetrieb aus und gründet den eigenen Handwerksbetrieb. Da wendet man dann als Meister:in, das Gelernte, die Methoden oder auch nur einzelne Elemente – ganz nach Gutdünken – an. Auf diesem Level angekommen, speist sich das Tun aus dem umfangreichen Wissen. Meister:innen können oft gar nicht mehr sagen, wo das, was sie tun oder wie sie handeln, seinen Ursprung hat. (Viel besser erklärt es Alistair übrigens in diesem Vortrag selbst: https://www.itu.dk/om-itu/presse/nyheder/2018/video-agil-ophavsmand-besoegte-danmark
Radikal einfach
Um nun also aus dem Methodenwahnsinn ausbrechen zu können, muss man die Prinzipien dahinter verstehen. Alistair war aufgefallen, dass es sich immer um folgende 4 Punkte dreht:
- Menschen zusammen arbeiten zu lassen – collaborate
- Etwas zu liefern – deliver
- Das Gelieferte zu reflektieren – reflect
- Und anschließend sich, das Ergebnis oder den Prozess zu verbessern. – improve
In dem zuvor erwähntem Vortrag, erläutert Alistair weiter, dass man diesen – sehr simplen Ansatz – natürlich unendlich erweitern kann: es gibt zig Varianten, wie man das Zusammenarbeiten verbessern kann, es gibt hundert Möglichkeiten, wie man besser liefern kann, usw.
An diesem Punkt wird es aber auch gleichsam schwierig. Alistair setzt nämlich voraus, dass Menschen diese unendlichen Varianten kennen oder zumindest ausprobieren würden; sie also in der Lage wären von abstrakten Prinzipien, erfolgreiche Handlungen ableiten zu können.
Und genau das war und ist der Fehler, den der/die Kenner:in, der/die Meister:in leider immer wieder macht. Wir Agilist:innen sind nämlich davon ausgegangen, dass die Leute nur den Prozess (Scrum, Kanban, usw.) zu kennen brauchen, um ihren täglichen Job besser machen zu können. Sie würden dann schon das Richtige entwickeln, bessere Designs kreieren, eine emergente Architektur bauen und so weiter. Es stellte sich jedoch heraus, dass sie es nicht taten. Man konnte sie noch so oft ins Reflect führen, sie begannen dennoch nicht, anders an Aufgaben heranzugehen, oder sich andere (Lösungs-)Wege einfallen zu lassen.
Der Prozess des Managens, die neue Struktur eines Spotifiy Modells oder die Entscheidungsbefähigung durch Soziokratisches Synthetisieren bleibt dem Wesen des Problems immer äußerlich und führt daher nie zur Lösung des Problems. All diese Verfahren erklären nicht, wie man wirklich neu und anders Probleme löst.
Ja, sie befähigen dazu zu erkennen, dass anders gearbeitet werden muss, jedoch zeigen sie nicht, wie man das macht. Die agilen Frameworks sind in diesem Sinn Diagnose-Systeme und zeigen an, wo gehandelt werden muss, sie sagen aber nie, wie es geht. Genau darin liegt also auch das oftmalige Scheitern von Versuchen Scrum oder Kanban, Flight Levels oder SAFe etc. einzuführen.
Veränderung entsteht nur durchs Tun
Mir wurde also klar – es reicht nicht, ein System, ein Team oder eine Organisation in die Reflexion zu bringen und Prinzipien zu erklären. Fehlendes Know-how, fehlende Technologien oder fehlende Skills können durchs Reflektieren nicht erworben, durch das Erklären von Prinzipien nicht vermittelt werden. Veränderung – und Lernen ist genau das – entsteht nur durchs Tun, durch ständiges Ausprobieren und durch das Sammeln von neuen Erfahrungen. Erst dann sind zum Beispiel Teams in der Lage neue Wege zu gehen.
Foto: Canva/pro