Über Agilität, Dogma und wie sie zueinander stehen

Von: Alexandre Soler-Sanandres

Der starre Agilist — von Agilität und Dogma

Ich finde, Agile ist eine wirkungsvolle Vorgehensweise. Es fällt mir leicht, einen Grund dafür zu liefern: Die agilen Ideen sprechen mich an. Nicht weil sie in Mode gekommen sind, sondern weil ich daran glaube, dass sie eine geeignete Methode darstellen, Software zu entwickeln. Ich halte sie schlicht und ergreifend für erfolgversprechend. Aber gibt es so etwas wie einen „Starre Agilist“? Oder kann Agile ein Dogma sein?
Nachdem man uns in die agile Welt reingeschubst hat, erwartet man, dass wir über Nacht fehlerfrei damit arbeiten können, ohne Performanceverlust versteht sich. Man bemerke: Die Methoden sollen wir beherrschen. Was dahinter steckt, gar die agilen Prinzipien und Ideen, werden, wenn überhaupt, kurz erwähnt und gleich wieder vergessen. Dabei sind sie genau das, was wir verstehen sollten.
Neues ist unbequem. Uns an neue Vorgehensweisen zu gewöhnen, fällt beschwerlich. Sie zu erlernen und zu akzeptieren ist noch mühevoller. Es ist kein Wunder, dass die Versprechen von Agile weit entfernt erscheinen. Wir haben erstaunlich lang klassische Methoden verwendet. Auf einmal soll alles agil sein. Wir müssen agil sein. Wer nicht agil ist, macht etwas falsch.
Dieser Weg ist nicht der Beste, um dem agilen Geist näher zu kommen, wenn wir da auch noch Abkürzungen nehmen, wird das zur Katastrophe. Da scheint es logisch zu sein, sich an das zu halten, was die Gurus meinen, das getan werden muss. Nichts ist naheliegender als sich Rat von den Profis zu holen, oder?

Was ist ein Dogma?

Manche Menschen denken, Agile ist zu einem Dogma mutiert. Bevor ich etwas darüber sage, schauen wir uns mal an, welche Bedeutung das Wort „Dogma“ hat. Hierfür schildere ich zwei Definitionen davon, die ich aus dem Netz gezogen habe:

Unter einem Dogma (altgr. δόγμα, dógma, „Meinung, Lehrsatz; Beschluss, Verordnung“) versteht man eine feststehende Definition oder eine grundlegende, normative Lehraussage, deren Wahrheitsanspruch als unumstößlich festgestellt wird.
— Wikipedia

(Besonders katholische Kirche) verbindliche, normative Glaubensaussage. (Bildungssprachlich, oft abwertend) den Anspruch der absoluten Gültigkeit, Wahrheit erhebende Aussage, Lehrmeinung.
— Duden

Ein bisschen hart ist das schon! Die Frage, die ich mir stelle, ist: Sind Agilität und agile Methoden die absolute Wahrheit, sozusagen unfehlbar? Eins sei vorab gesagt: Nein, sind sie nicht. Weder ist eine agile Vorgehensweise immer und für jedes Projekt von Vorteil, noch lösen sie alle Probleme der Softwareentwicklung. Agilität macht Probleme transparent und zeigt uns, in welchen Bereiche wir uns verbessern können.

Ist Agilität ein Dogma?

Meiner Meinung nach kann Agilität vom Prinzip her kein Dogma sein. Wenn sie jedoch so erscheint, liegt es meistens daran, dass die Menschen, die sie anwenden, strikt nach Buch vorgehen, ohne die Sinnhaftigkeit der Aktionen zur hinterfragen. Sie halten sich krampfhaft an das Regelwerk, ohne den Sinn verstanden zu haben. Sie ist also kein Dogma, sondern wird dogmatisch ausgelegt. Der Prozess wird bedeutender als das, was wir erreichen wollen. Man legt mehr Wert auf, WIE etwas vonstatten geht, anstatt sich auf das WAS zu konzentrieren. Sie sind beide wichtig, aber wenn wir aus den Augen verlieren, WAS wir erreichen wollen und einzig das befolgen, was andere Menschen, die mehr Ahnung vom Thema haben als wir selbst, sagen, dann bewegen wir uns im Bereich des Glaubens. Mit Agilität ist das nicht einmal annähernd verwandt.
Ich möchte ein Beispiel vorbringen, wie dieser Dogmatismus zu Tage tritt. Scrum ist nicht die einzige agile Methode, jedoch eine der bekanntesten. Im „Scrum Guide“ steht:

Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.
— Scrum Guide (July 2016)

Das Problem entsteht, wenn Menschen folgender Gleichung Vertrauen schenken:
Agil sein = agile Methode nutzen.
Das heißt, um agil zu sein, müssen wir agile Methoden verwenden, ergo z. B. Scrum nutzen. Nach der Scrum „Bibel“ bedeutet jedwedes Ausweichen vom Protokoll, dass man den erleuchteten Pfad verlassen hat. Logische Konsequenz: Will man agil sein, muss man Scrum nach Regelwerk praktizieren. Der Prozess wird zum Hauptdarsteller. Meiner Meinung nach ist das die falsche Lektüre der Ideen, welche sich hinter dem Gedanken verstecken. Die blinde Einhaltung eines Prozesses hat nichts mit Agilität zu tun. Wenn wir uns das agilen Manifest anschauen, werden wir folgende zwei Sätze darin entdecken:

Responding to change over following a plan
— Agile Manifesto

Individuals and interactions over processes and tools
— Agile Manifesto

So wie ich es interpretiere, bedeutet das eben das Gegenteil zu diesen dogmatischen Postulaten, indem wir blind einen Plan befolgen, bzw. die Reinheit des Prozesses über alles stellen sollen. Ich will damit nicht sagen, dass Scrum in seiner reinen Form nicht in Ordnung sei. Nein, es funktioniert gut. Nur nicht immer, für jedes Team, jedes Projekt und jede Gegebenheit. Ich plädiere dafür, zu akzeptieren, dass sich von der „Norm“ zu entfernen durchaus positiv, erstrebenswert und wirkungsvoll sein kann. Man kann agil sein, ohne notwendigerweise Scrum oder Kanban einzusetzen.
Unterschiedliche Unternehmen mit verschiedenen Strukturen müssen einfach anders an Agilität herangeführt werden. Ein Patentrezept gibt es nicht. Nutzt das, was es gibt und passt es an eure Bedürfnisse an. Genauso ist es bei Teams. Menschen sind unterschiedlich und was bei manchen funktioniert, läuft bei anderen nicht gut.
Unabhängig davon wie wir zur Agilität vorangehen möchten, muss ein Lernprozess stattfinden.

Der Lernprozess

Wir lernen im Laufe unseres Lebens eine ganze Menge, aber wie tun wir es? Angelehnt an die östliche Philosophie, redet man oft vom Shu — Ha — Ri Prinzip. Das soll der Weg sein, den jeder Mensch bestreitet, um Wissen auf lange Sicht zu erlernen. Dieses Verständnis des Lernprozesses wird von Alistair Cockburn verwendet, um zu zeigen, wie wir neue Techniken und Methoden der Softwareentwicklung lernen.
Der Prozess findet in drei verschiedenen Phasen statt, die, wie ihr euch bereits vorstellen könnt, Shu, Ha und Ri genannt werden. Alistair übersetzt sie mit den Worten: Folgen, Trennen und Fließen (following, detaching and fluent). Diese Übersetzungen aus dem Japanischen sind vielleicht nicht genau, aber für unsere Zwecke reichen sie aus.

Shu

Die erste Stufe ist Folgen. Wir konzentrieren uns auf eine der möglichen Lösungswege. Auch wenn es viele andere Wege gibt, die uns zur Lösung führen könnten, wir können sie nicht alle auf einmal lernen. Wir lernen diesen einen Weg von jemandem, der ihn bereits beherrscht. Wir wollen das Problem lösen, wir wollen etwas, das „funktioniert“, und das wir halbwegs verstehen können. Die geheimen Prinzipien, die sich dahinter verstecken, sind nicht unser Ziel. Die Lösung ist unser Ziel und, um sie zu finden, lassen wir uns leiten. Wir kopieren schlicht und ergreifend. Das ist der erste Kontakt. Wenn ich irgendwas Neues lernen will, ist mein erster Schritt zu schauen, wie die Experten das Problem lösen. Üblicherweise nehme ich Bücher zur Hand oder forsche im Internet darüber. Ich entscheide mich für EINEN Weg, eben einen, den die Meister sich ausgedacht haben, den ich begreifen kann und der verspricht, mir dabei zu helfen das Problem zu lösen. Alles andere ist gerade nicht wichtig. Ist das verkehrt? Ich denke nicht. Verkehrt wäre es, wenn ich es dabei belassen würde. Nach dem Motto gut kopiert ist die halbe Mitte, bleibt da noch Luft nach oben. Ich kenne jetzt die Theorie, aber Übung habe ich keine und das ist, was mir eben fehlt. Um wirklich zu lernen, muss ich mich damit beschäftigen, ausprobieren, versuchen, Fehler machen, aussortieren. Und immer auf den aufgezeichneten Weg bleiben. Das ist so, weil ich nicht weiß, wo ich mich wiederfinde, wenn ich den Weg verlasse. So gut bin ich nicht. Zumindest noch nicht :-)

Ha

In der zweiten Stufe trennen wir uns. Wir befreien uns der festen Hand des EINEN und wandern jenseits des Weges auf Erkundungstour. Der Grund dafür ist, dass. wenn wir genug Erfahrung mit dem Lösungsweg gesammelt haben, seine Grenzen uns immer bewusster werden. In diesem Moment beginnen wir uns damit zu beschäftigen, wie genau die Lösung funktioniert. Hier ist nicht nur wichtig, dass es funktioniert, sondern das Warum zu verstehen. Wir fangen an, das Problem mit neuen Möglichkeiten zu lösen. Wir experimentieren und passen den Lösungsweg auf die neuen Gegebenheiten an. Mit dem ganzen Verständnis, das wir bis jetzt gewonnen haben, sind wir in der Lage die Prinzipien nach und nach zu begreifen. Das erlaubt uns auch, die Lösungswege anderer Experten zu verstehen und anwenden zu können, wenn sie sich besser eignen. Wir fügen dieses Wissen unserem bereits vorhandenen Wissensschatz hinzu.

Ri

Die dritte Stufe: Fließen. In dieser Phase hat das Lernen eine andere Bedeutung. Hier ist es völlig irrelevant, ob einem bestimmten Weg gefolgt wird oder nicht. Wir treten ein und suchen uns anhand unserer Erfahrungen und Kenntnisse einen Weg zur Lösung. Ob es diesen Weg bereits gibt oder ob er von uns durchgeschlagen wurde, fällt nicht mehr ins Gewicht. Wir merken es nicht einmal. Es fließt. Für mich bedeutet Ri, dass man die abstrakte Idee begriffen hat und die Expertise besitzt, anhand dieser Idee zur Lösung voranzuschreiten, ohne sich an irgendwelche Lehren halten zu müssen.

Wie viel Dogma brauchen wir?

Bleiben wir kurz im Shu. Ist das nicht das dogmatische Erlernen einer bestimmten Methode? Nun, ja und nein. Ein bisschen Dogma sehe ich da schon durchschimmern, aber warum ist das so? Am Anfang brauchen wir Führung, wir brauchen bestimmte Regeln, die uns zur Lösung bringen. In dieser Hinsicht ist hier vielleicht Dogmatismus vorhanden, denn wir sollen den EINEN Weg ja nicht verlassen und in dieser Phase ist er ja unsere absolute Wahrheit. Aber wir sollten den Prozess als Ganzes betrachten und Shu ist eben nur der erste Schritt. Das für mich Wichtigste an dieser Anschauung ist, dass, um Meisterschaft in einem beliebigen Thema zu erlangen, viele verschiedene Sachen nötig sind. Führung und Regeln sind das eine, aber Experimentieren, Ausprobieren und eigene Wege gehen, gehört genauso dazu.
Wie lange dauert es von Shu zu Ha und was ist genügend Erfahrung? Wie lange dauert es, bis diese etwas dogmatische Phase zu Ende geht? Eine einzige Antwort gibt es dafür nicht. Meiner Meinung nach ist das vom Lernenden abhängig. Menschen brauchen unterschiedlich lang, um Theorie und Praxis des EINEN Weges auf ein hohes Niveau zu bringen und das ist in meinen Augen notwendig, um die zweite Phase zu erreichen. Das bedeutet, dass uns am Anfang des Lernens eine mehr oder weniger lange Zeit des Dogmas zu Leibe rückt. Die Kunst besteht darin, diese Zeit so kurz wie möglich zu gestalten, ohne jedoch die Ziele aus den Augen zu verlieren. Nämlich eine Lösung für unser Problem zu finden und zu erlernen.
Lange Rede, kurzer Sinn. Ein gewisses Maß an Dogma wird uns nicht erspart bleiben. Das ist eben der Impuls, der uns erlaubt mit der Technik Bekanntschaft zu machen und uns ermöglicht den Weg zu gehen. Ohne diesen ersten Kontakt können wir leider nicht die Wissenstreppe hinaufsteigen. In anderen Worten: Wir nutzen diese drei Phasen, um besser zu werden. In diesem Sinne werden wir erst kopieren, dann assimilieren und erst am Ende sind wir in der Lage eigenes zu kreieren. Voll im Sinne der agilen Bewegung, erst Inspect und später Adapt.

Schlusswort

In der Softwareentwicklung ist es schon mehr als einmal vorgekommen, dass Teams einfach gesagt bekommen: Ihr seid jetzt agil, da sind ein paar Boards und Klebezetteln und jetzt macht. Dann wird beispielsweise Scrum ausgelobt und von heute auf morgen ist irgendjemand Scrum Master, der Chef wird „logischerweise“ zum Product Owner und Tada: Das agile Team ist da.
Kann das überhaupt zum Erfolg führen? Ich halte das für schwierig. Viel zu oft kommt es vor, dass in Ermangelung besseren Wissens alle Regeln der ausgewählten Methode blindlings durchgesetzt werden, ohne da Warum zu verstehen. Das „Buch“ wird penibel befolgt, ohne jegliche Gestaltungsfreiheit. Zeit zum Lernen bleibt kaum. Das sind nicht die Voraussetzungen, die notwendig sind, um erfolgreich zu sein.
Lasst mich nur nochmal kurz erwähnen, dass Dogma am Anfang des Lernprozesses hilfreich sein kann, wenn nicht sogar notwendig ist. Aber es muss sich nur um eine Phase handeln, die wir so kurz wie nötig halten sollten. In kleinen Inkrementen zu arbeiten und sich kritisch mit dem Prozess auseinanderzusetzen, verkürzt meiner Erfahrung nach die Zeit des „Dogmas“.
Wie viel Dogma man braucht, hängt natürlich davon ab, wie viel Erfahrung im „Raum“ vorhanden ist und auch davon, wie viel Offenheit für Änderungen existiert. Nutzt das, was euch zur Verfügung steht. Lernt immer Unbekanntes. Übt, übt und übt nochmal. Passt die Regeln an die Bedürfnisse des Teams an, ohne das Ziel aus den Augen zu verlieren: Hochqualitative Software erstellen mit maximalen Kundenwert, so schnell wie es euch möglich ist.
Oder wie wir auf der SoCraTes vor einigen Jahren sagten:
Don’t be dog-matic. Be cat-matic :-)

Ihr seid ebenso verrückt nach IT, Software und Tech-Themen und habt Lust, Teil unseres Entwickler-Teams zu werden, hier geht´s zu unseren offenen Stellen: https://www.datev.de/web/de/karriere/geschaeftsbereiche/it/.

Photo by Will H McMahan on Unsplash