Eigentlich müsste es ein Grund zur Freude sein. Agilität ist auf dem Vormarsch. Sie zu fördern, das Wissen und Können auf eine breite Basis zu stellen und auch in die öffentliche Verwaltung zu tragen, ist schließlich eine Herzensangelegenheit des Forums Agile Verwaltung. Und doch treibt mich eine Sorge um. Dies Sorge, dass wir das „agile Pferd“ zu Schande reiten. Was ich beobachte, ist ein „bloßes Kopieren“ der Methoden, ohne den tieferen Sinn der Prinzipien, die dahinterstehen, zu ergründen, zu reflektieren. Und dies löst bei mir ein Deja-vu aus.
Vielleicht erinnert sich noch der eine oder andere – es sind immer hin gut zwei bis drei Jahrzehnte her, als Toyota mit seinem Toyota Production System (TPS) das große Vorbild – nicht nur für die Automobilindustrie – war. Alles sollte schlanker, effizienter werden. Und deshalb wurden die „Methoden“, die Toyota so erfolgreich gemacht haben, häufig unreflektiert übernommen, ohne ein vertiefendes Verständnis hinter den Prinzipien zu entwickeln. Der Erfolg stellte sich oft nicht so ein wie erhofft. Eingeweihte ahnen, etwas Entscheidendes wurde vergessen. Nicht das „Werkzeug“ war entscheidend, sondern die Art und Weise, wie das Werkzeug eingesetzt und weiterentwickelt, adaptiert wurde – basierend auf wenigen Prinzipien. Prinzipien, die sich auch in dem wiederfinden, was wir heute Agilität nennen. Denn interessanterweise ging es Toyota selbst nicht vorrangig um betriebswirtschaftliche Kostenoptimierung, sondern „handwerkliches Können“, wie ich vor Kurzem von einer Kennerin der Materie, Mari-Furukawa-Caspary[1], lernen durfte.
Der Blick auf Agilität wird – nach meiner Beobachtung – immer öfter auf Methoden und Erfolgspraktiken verkürzt, die vermeintliche Blaupausen für die Agilisierung von Organisationen liefern. Die vermeintliche Effizienz der agilen Ansätze rückt in den Fokus und dient viel zu häufig als Begründung für Agilität. Agilität und die agilen Ansätze werden zu vermeintlichen Wundermethoden, die man nur „kopieren“ muss, um Probleme moderner Organisationen in einer komplexen Welt zu lösen. Unreflektiert und ohne hinter die Prinzipien zu schauen, wird zum Beispiel Scrum (oder ein anderes agiles Rahmenwerk) eingeführt. Verbunden mit der Hoffnung, effizienter, kostengünstiger zu werden (ja, auch Verwaltung muss Kosten reduzieren, effizient sein). Natürlich immer mit Blick auf Beispiele gelungener Praxis aus anderen Organisationen, die man zu kopieren sucht. In großen Unternehmen setzt man immer häufiger auf Skalierungsrahmenwerk als Blaupausen wie SAFe[2] und Spotify-Model, um die Gesamtorganisation moderner und agiler zu machen. Meist, um sich dann zu wundern, warum es dort funktioniert hat und bei einem selbst nicht. Ein Trend, der zum Glück noch nicht in der öffentlichen Verwaltung in der Fläche angekommen ist. Aber sicher mit Sicherheit noch kommen wird.
Mit meiner Beobachtung bin ich nicht allein. Unter anderem gibt es die Diagnose „Zombie Scrum“ für Projekte, die zwar beanspruchen, Scrum zu praktizieren, aber in denen mit Blick auf die Prinzipien und Werte die gelebte Wirklichkeit erschreckend oft eine andere ist. Es steht zwar Scrum auf der Verpackung und das Regelwerk wird offenbar eingehalten, aber die Prinzipien dahinter werden kaum praktiziert. Die Autoren des Buchs Zombie Scrum Survival Guide führen diesen Zustand auf ein mangelndes Verständnis der Sinnhaftigkeit der zugrundlegenden Prinzipien und Werte hinter der vermeintlichen Methodik zurück. Die Symptome, die sie benennen, beziehen sie zwar auf Scrum geführte Projekte, sie lassen sich durchaus auf Agilität im Allgemeinen (sie finden sich zum Beispiel ähnlich als „Fehlmuster“ – Anti-Pattern – unter anderem im Kanban Maturity Model[3] wieder) übertragen:
- Die Bedürfnisse der Anspruchsgruppen sind kaum bekannt und werden nicht wirklich berücksichtigt. Kaum jemand macht sich die Mühe zu erkunden, was diese wirklich brauchen. Prozesse, Abläufe und Arbeitsweise werden nicht nach deren Bedürfnissen ausgerichtet und weiterentwickelt, sondern aus Sicht der Bedürfnisse der bürokratischen Organisation [Kleine Randnotiz: auch sie ist kein Selbstzweck, mutiert aber gerne dazu].
- Echtes iterativ-inkrementelles Arbeiten mit kurzen Feedbackzyklen findet nicht wirklich statt, so dass kaum konstruktives Feedback von den Anspruchsgruppen generiert wird und die „Wertschöpfung“ ausbleibt. Nicht die Lösung des Problems der Anspruchsgruppen steht im Fokus, sondern der „Selbstzweck“ der Organisation.
- Echte kontinuierliche Verbesserung und Weiterentwicklung der Prozesse und der Ergebnisse findet nicht oder kaum statt. Es wird auf bewährte Praxis gesetzt, statt gezielt durch Experimente neue Ansätze zu erkunden und die Organisation nach den Bedürfnissen der Beteiligten auszurichten.
- Agile Teams werden nicht zur Selbstorganisation befähigt. Dabei ist dies das ureigene Bestreben des agilen Weges, die Problemlösungsfähigkeit im Sinne der Experten innerhalb eines gegebenen Korridors und Ziels zu stärken und so die Reaktionsfähigkeit der Organisation auf sich verändernde Bedingungen zu erhöhen.
Mit einer der Grund hierfür ist, dass die Agilität mit Methodik gleichgesetzt wird und der Fokus zu sehr auf einer methodischen Sicht liegt, während die zugrunde liegenden Prinzipien bei der Umsetzung agiler Ansätze vernachlässigt werden. Eine regelmäßige reflektierte Auseinandersetzung mit dem Weshalb und mit den Grundlagen ist sehr hilfreich, dem entgegenzuwirken. Auf das Kopieren von erfolgreicher „Implementierungen“ im Sinne von Best Practice zu setzen, vernachlässigt, dass Organisationen selbst hochgradig komplex sind und trotz aller Ähnlichkeiten die entscheidenden Faktoren nicht die offenkundigen sind, die man an der Oberfläche sieht. Das sollte uns bereits durch die missglückten Adpationsversuche der Vergangenheit bewusst sein.
Methoden sind Hilfsmittel, um die darauf basierenden Prinzipien und Werte zu unterstützen, – aber nicht der Selbstzweck. Zentrale Fragen sollte daher immer sein, was wollen wir erreichen und warum wollen wir dies erreichen? Wie hilft es uns, unsere Arbeit in unserer Organisation besser zu machen und bessere Ergebnisse zu erzielen?
Wer sein Pferd nicht gut kennt und es nicht entsprechend hegt und pflegt, der reitet es zu Schande und kommt letztendlich nicht ins Ziel. Das gilt auch für die Agilität. Es liegt an uns, es nicht so weit zu kommen lassen.
[1]Mari-Furukawa-Caspary: Lean auf Gut Deutsch, Band 1, Books on Demand, 2016
[2]Ich bin kein großer Freund von SAFe als Rahmenwerk für die Skalierung von Agilität. Meines Erachtens ist unnötig kompliziert. Persönlich ziehe ich Kanban mit seinem evolutionären Ansatz vor, da es stärker darauf ausgerichtet, bestehende Strukturen zu nutzen und diese evolutionär weiterzuentwickeln.
[3] David J. Anderson/Theodora Bozheva: Kanban Maturity Model – Handbuch für Agilität, Resilienz und Neuausrichtung, dpunkt-Verlag 2021. Das Buch ist allerdings nicht für den Einstieg in die Kanban-Materie geeignet, sondern wendet sich an fortgeschrittene Anwender, die ihre Kenntnisse vertiefen wollen. Für den Einstieg in die Materie Kanban empfehle ich gerne Mike Burrows: Kanban – Verstehen, Einführen und Anwenden, dpunkt Verlag, 2015
Agile Verwaltung 