Der agile Pragmatismus

Gerade habe ich einen Projekt- und Teamwechsel hinter mir und wunderte mich beim Off- und Onboarding über die Rückmeldung meines alten bzw. über die Kennenlernfragen meines neuen Teams. Das alte Team lobte im Abschlussfeedback mehrfach meinen Pragmatismus, während mein neues Team als eines der ersten Dinge von mir erfahren wollte, wie streng ich als Scrum Master sei. Grund genug, um zu reflektieren, was eigentlich dieser agile Pragmatismus ist und wie ich dazu stehe.

Als jemand, der sehr gerne studiert hat und auch abseits von Seminaren gerne lernt, ist der Stempel, ein Pragmatiker zu sein, im ersten Moment fast eine Beleidigung für mich. Denn: Ich liebe Theorien. Nicht, weil ich so gerne blind Regeln folge oder versuche, Strukturen im Chaos zu finden, sondern weil ich überzeugt bin, dass Modelle uns helfen, bestimmte Aspekte der Realität zu vereinfachen und bearbeiten zu können. Ein Pragmatiker ist für mich jemand, der bedenkenlos bekannte Theorien übergeht und nur nach schnellen Erfolgen handelt. Ich dagegen will nachhaltig arbeiten.

Das heißt natürlich nicht, dass Agilität und Scrum für mich nur einen Wert in der Theorie haben. Nein. Experimente im Team zu machen hat einen pragmatischen Hands-On-Charakter. „Einfach mal machen“, um es nach einer kurzen Periode dann zu evaluieren und zu systematisieren, hat natürlich den Charakter einer wissenschaftlichen Herangehensweise, dem ich nur Positives abgewinnen kann. Und ich kann auch verstehen, dass einige Entwickelnde in der Vergangenheit schlechte Erfahrungen gemacht haben und deswegen Scrum mit Verkopftheit, Einschränkungen oder mit einer Flut von Meetings verbinden. Das muss aber gar nicht sein. Scrum kann sehr schmal, lean und effizient gehalten werden, wenn man in der Lage ist, innerhalb eines Sprints alle wichtigen Arbeitsschritte für ein kleines Inkrement zu erledigen (inkl. Exploration, Analysen, Architektur etc.).

Orientierung am echten Schmerz, statt vorauseilende Optimierung

Wenn mich mein neues Team beim Kennenlernen also fragt: „Adrian, bist du ein strenger Scrum Master, oder bist du eher pragmatisch?“ wollen sie wissen, ob sie ungefähr so weitermachen können wie bisher, oder ob ich sofort zum agilen Frühjahrsputz ansetze und direkt alles auf den Kopf stellen werde, um wie die ”Scrum Polizei” das Einhalten aller Regeln einzufordern. Und natürlich will ich keine unnötige Unruhe in Teams bringen und erst recht keine funktionierenden Prozesse umschmeißen, nur damit es besser in meine Vorstellung von Scrum passt. Es ist immer gut, mit dem zu beginnen, was bereits im Team an Prozess und Struktur da ist. Von hier aus kann man evolutionär vorgehen, mit kleinen Schritten Anpassungen verproben und entsprechend „pragmatisch“ Dinge verändern, die vorher schmerzhaft waren. Ein plötzliches Umwerfen des Bekannten ist gar nicht notwendig. Und mit Partizipation des gesamten Teams an diesen Entscheidungen und Geduld bleibt Veränderung nachhaltiger.

So halte ich vorauseilende Optimierung für einen großen Fehler. Wenn z.B. ein Team in der Regel nur 80% der Stories innerhalb der Sprints erfolgreich abarbeiten kann, dann versuche ich nicht sofort Story Points einzuführen, obwohl dies ein übliches Vorgehen wäre, um Geschwindigkeit, Kapazitäten und Teamerfolge zu messen. Stattdessen würde ich schauen, ob und wo genau der Schmerz versteckt ist. Ist es die Unzuverlässigkeit der Planung, die uns schmerzt, oder fehlender Fokus? Dann könnten wir überlegen, ob uns eine Konkretisierung des Sprintziels helfen würde? Oder ist es vielleicht sogar akzeptabel, wenn wir zwar unsere Sprintziele, aber nicht 100% der geplanten Aufgaben erreichen? Wo drückt der Schuh genau?

Während ein Pragmatiker vielleicht sofort eine schnelle Lösung parat hätte, empfehle ich hier vom Problem und nicht von der Lösung her zu denken. Im Team sollten wir zuerst überlegen, was uns aktuell stört und erst dann, wie wir es ändern können. Nicht umgekehrt. Sonst würden wir ja versuchen, für jede Lösung (Storypoints, User Stories, Refinementmeetings) das passende Problem zu konstruieren – das geht natürlich nicht, weil das Problem eigentlich in seiner konkreten Form bereits gegeben ist.

Teams, ihre Arbeitsumgebung und ihre Probleme sind immer individuell und unterschiedlich. Zwar erkennt man mit steigender Erfahrung als Scrum Master auch immer wiederkehrende Muster, das heißt jedoch nicht, dass Lösungen direkt auf der Hand liegen. Nicht jedes Vorgehen passt zu jedem Team. Und hier braucht es vom Scrum Master einen nüchternen Blick auf grundlegende Probleme, nicht auf schnelle Lösungen. Vielleicht wird dieses Vorgehen von meinen Teams auch als „pragmatisch“ wahrgenommen. Für mich ist es ein analytisches Prüfen, Falsifizieren und Anpassen einer Hypothese. Natürlich mit Auswirkungen auf die Praxis.

Agile Hardliner?

Der andere Aspekt, den mein neues Team aus mir beim Kennenlernen rauskitzeln wollte, ist, wie Scrum Guide-konform meine praktische Vorstellung von Scrum ist. Das wird ganz gerne als „dogmatisch“ betitelt. Irgendwie verwunderlich, dass die Orientierung an den groben Regeln des Scrum Guides wie religiöser Fanatismus beschrieben wird, der den Ungläubigen Angst macht.

Meine innere Haltung dazu ist, dass ich die wenigen Regeln des Scrum Guides achte und genau so mit meinem Team erfüllen will. Aber vielleicht nicht vom ersten Tag an. Wir sollten die Regeln natürlich auch verstehen und nicht nur blind befolgen. Dazu gehört, dass man manchmal den ersten Schritt gehen muss, indem man z.B. ein kleines Experiment macht.

Es ist für mich völlig okay, wenn ein Daily mal länger als die definierte Timebox von 15 Minuten dauert. Aber es wäre nicht okay, wenn es immer so wäre und so bleiben würde. Es ist für mich völlig okay, wenn wir in einem Sprint Review unseren Kunden ausnahmsweise nur eine Skizze statt funktionierender Software zeigen. Aber wir sollten im Anschluss darüber reden, wie wir den Mehrwert unserer Präsentation und unseres Produktes maximieren können. So nehme ich die Abweichungen vom Scrum Guide oder von üblichen agilen Praktiken als Anlass für Gespräche und Prozessanpassung mit dem Ziel, Stück für Stück mit unserem Prozess näher an den Scrum Guide zu rücken. Scrum ist auch nur Scrum, solange die wesentlichen Eigenschaften, die im Scrum Guide beschrieben sind, eingehalten werden.

Das mag vielleicht für einige etwas dogmatisch wirken, aber Scrum in der Theorie ist ein ausgewogenes Konstrukt. Ändert man maßgebliche Dinge, dann hat das Konsequenzen für den ganzen Prozess. Man muss also systemisch denken, wenn man daran etwas verändern wollen würde, sonst kommt es ins Ungleichgewicht und produziert vielleicht Probleme an Stellen, wo vorher keine waren. Verzichtet beispielsweise ein Team auf das Sprintreview, dann erhält es kein Feedback zum Produkt und kann auch keine begründete Neuausrichtung ihres Plans für den nächsten Sprint machen. Stattdessen würde es stumpf das Backlog von oben nach unten abarbeiten. Das nimmt aber einen wesentlichen Vorteil von Arbeit in Iterationen raus – Inspect & Adapt. Das Konstrukt Sprint verliert damit an Wert.

Ich bin bereit, die Regeln des Scrum Guides in Ausnahmefällen temporär und in Absprache mit dem ganzen Team zu biegen oder zu brechen, ohne mich davon gänzlich lösen zu wollen. Vielleicht macht mich das zum umgangssprachlichen Pragmatiker. Aber da ich mir der Risiken solcher Vergehen bewusst bin, verstehe ich mich selbst eher als Theoretiker, der im nächsten Schritt nach perfektem Scrum strebt, um das Modell wieder in sein Gleichgewicht der Ordnung zu bringen.