Ich versuche mal ein Problem, rund um das Thema “agile Methoden” aus meiner eigenen Perspektive heraus zu beschreiben, denn ich halte es für relevant. Und das geht so: Vor kurzem bin ich auf Twitter über eine Antwort von Ron Jeffries (XP) gestoßen, bei der es um das (un)beliebte SAFe ging:
Meine erste Reaktion war: “Yeah, sehe ich ganz genauso. Im Grunde is SAFe einfach BAD.” Mit etwas Reaktionszeit ist mir dann jedoch ein Vortrag von Henrik Kniberg in den Sinn gekommen („Is SAFe EVAL?“ https://youtu.be/TolNkqyvieE), bei dem er sehr differenziert über dieses Frage reflektiert und berichtet, wie sie bei Lego „Big Room Plannings“ ausprobiert haben. Alles mit SAFe als Framework im Hinterkopf.
Ok, eigenes Weltbild mal wieder kurz erschüttert?
Nächster Gedanke: Wenn ich in einer Organisation bin und diese unbedingt Scrum „einführen“ möchte, dann bekomme ich ja auch ein ungutes Gefühl in der Bauchgegend. Welche Probleme genau sollen gelöst werden? Sieht die Organisation diese oder ist es eher ein abstraktes Konzept im Kopf Einzelner? Warum genau soll exakt Scrum die Lösung dafür sein? Nach meiner Erfahrung finden Organisationen, wenn sie denn Transparenz über tatsächlich vorhanden Probleme haben, Lösungen die sich mit viel weniger Widerstand fast von selbst umsetzen lassen und dann auch zielgerichtet die wirklich vorhandene Probleme adressieren. Dabei können agile Methoden wie Scrum (oder meinetwegen auch SAFe) natürlich eine Inspiration sein. Sie bleiben das Mittel zum Zweck.
Und was ist nun mit SAFe?
Wenn ich hier etwas weiter denke, dann könnte ich sagen: wenn agile Methoden oder Frameworks eher Lösungen enthalten, dann ist es sehr wahrscheinlich, dass die Probleme die sie adressieren, tatsächlich in mehr als einer Organisation vorhanden sind. Allerdings bieten diese Methoden dann immer wenig Unterstützung, das entsprechende Problem zu erkennen und zu verstehen. Sie propagieren eine spezifische Lösung. Gleichzeitig merken wir als Komplexitäter, bei unserer Arbeit mit verschiedenen Organisationen, immer stärker, dass spezifische Problemmuster wieder und wieder auftauchen. Das ist den Organisationen selbst nie bewusst. Für sie sind diese Probleme selten transparent. Sie sind für die Menschen in der Organisation daher fast nie besprechbar. Scrum, SAFe und Co. sind in diesem Umfeld dann auch nie die Lösung, sondern sogar eher schon Teil des Problems („“Bei uns funktioniert agile Methode XYZ irgendwie nicht. Könnt ihr da mal helfen?“). Was wir als Coaches dann unternehmen, hat ja viel damit zu tun, Probleme sichtbar und damit besprechbar zu machen. Im wahrsten Sinne des Wortes geht es oft zunächst darum, Begriffe und Sprache für die vorhanden Probleme in der Organisation zu entwickeln. Und genau dabei helfen die bekannten agilen Methoden, vorsichtig gesagt, eher nicht. Sie bieten eine vermeintliche Abkürzung die jedoch schnell in die Sackgasse führt.
Praxisbeispiel zu einer agilen Methoden
Ein Team in dem ich gerade neu eingestiegen bin, fragt mich, ob ich noch mal genau erklären kann, wie das mit dem “Planning Poker” denn nun vermeintlich “richtig” funktionieren würde. Sie hätten das schon mal ausprobiert und es kam dann immer teamintern zu unauflösbaren Diskussionen, was genau geschätzt werden soll. Auf meine Frage, welches real im Team vorhanden Problem sie denn mit dem Pokern lösen wollten, gibt es keine klare Antwort (“das haben wir mal gehört, dass man das so macht”, “Schätzungen könnten ja für die Planung hilfreich sein”).
In der nächsten Retrospektive sprechen sie das Thema an, dass fast alle Aufgaben die sie starten, kurz danach blockiert sind. Entweder gibt es im Team internen Abstimmungsbedarf zur Umsetzung oder der erste Entwickler der eine Aufgabe anschaut hat sofort inhaltlichen Klärungsbedarf und das Team wartet auf PO und Stakeholder. Ein kontinuierliches Backlog Refinement gibt es noch nicht. Das Team erkennt, dass es ein Problem ist, wenn erst sehr spät im Prozess das gesamte Team mit einbezogen wird. Als Lösung dafür bedienen sie sich aus dem Scrum Guide und probieren ein erstes Backlog Refinement als einstündiges Meeting aus. Als Methode schlage ich, zur Überraschung des des Teams, “Planning Poker” vor. Das Team nutzt dabei die Methode nur als Weg, um schnell auf die Punkte zu kommen, bei denen sie noch Fragen oder Klärungsbedarf haben. Die Schätzung selbst wird im Grunde nicht weiter verwendet und die Frage nach dem “was und wie schätzen wir” konnte so auch viel einfacher vom Team beantwortet werden.
In der folgenden Retro stellt das Team fest, dass sie über die Lösung “Planning Poker” viel besser auf die Arbeit an einer Aufgabe vorbereitet sind, alle ein grobes Bild haben worum es geht und woran die anderen gerade arbeiten. Es treten folglich weniger Nachfragen im Laufe der Arbeit an einzelnen Aufgaben auf und wenn es diese gibt, lassen sie sich meist sogar schneller beantworten, weil alle schon grob wissen, worum es geht.
In diesem Beispiel ist zu sehen, dass das Werkzeug “Planning Poker”, erst dann eine Wirkung entfalten konnte, als es auch ein reales, von allen akzeptiertes Problem gab, dass es lösen sollte. Ich kann mir natürlich vorstellen, dass es auch Fälle gibt, in denen Menschen ein Werkzeug einfach mal ausprobieren (idealerweise dann auch die Anleitung beachten) und darüber erkennen, welche Vorteile es bietet. Im Kontext von agilen Methoden scheint mir dies eher die Ausnahme zu sein.
tl;dt
Hypothese – “Lösungsorientierte agile Methoden und Frameworks wie SAFe und Scrum deuten auf generalisierbare Probleme hin. Sie tragen wenig dazu bei, die Probleme selbst besser zu verstehen. Die Problemmuster wiederholen sich in Organisationen. Diesen fehlen jedoch die fundamentalen Werkzeuge, um Probleme zu erkennen und damit überhaupt bearbeitbar zu machen. Organisationen führen dann Lösungen ein, die ohne tieferes Problemverständnis nicht nachhaltig wirken können.”
Was denkst du? Kennst du Erlebnisse aus der Praxis, die nicht zu meiner Hypothese passen? Was spricht gegen meine Überlegungen?