Was ist Agilität? – Zum x-ten Mal gestellt, zum x-ten Mal keine Antwort

Immer wieder die Frage – von Lesern, Konferenzbesuchern, innerhalb des FAV: Was ist Agilität? Unsere Webseite „Agilität in der Verwaltung – eine einführende Übersicht“ wurde schon über 4.500-mal aufgerufen.

Aber eine schlüssige Definition, gar eine endgültige Antwort – wie soll es die geben? Gerade Agilität beruht auf der Erfahrung, dass nichts endgültig und fest ist. Wie sollte also Agilität ein starres Rahmenwerk sein, wenn sie selbst die Bewegung in einer bewegten Umwelt sein will? Wir müssen immer wieder die Anstrengung machen, mir neu über den Sinn von agilen Herangehensweisen zu verständigen.

Die folgenden Überlegungen sind im Rahmen unseres FAV-Buchprojekts „Agile Verwaltung 2040“ entstanden. Es gab viele Diskussionen in unseren Literaturcafés und in Autor:innen-Teams. Die These, die ich hier vorstellen will, lautet: In der agilen Verwaltungs-Community haben sich drei verschiedene Sichten, vielleicht sogar „Strömungen“, entwickelt. Konferenzen oder auch Digitalisierungsprojekte, die sich das Label „agil“ angeheftet haben, verkörpern ganz unterschiedliche Ziele und Visionen. Dazu versuche ich hier einen ersten Überblick.

Leitsätze des FAV von 2016

Kurz nach der Gründung des Forums Agile Verwaltung formulierten seine Mitglieder Leitsätze, die die wesentlichen Prinzipien der agilen Denkweise darstellen sollten:

Das Ganze in den Blick nehmen,
cross-funktionale Teams bilden,
mit überschaubaren Änderungen und Teilergebnissen experimentieren,
die Anspruchsberechtigten einbeziehen,
sich regelmäßiges Feedback von innen und außen verschaffen
und so sein System immer angemessener machen.

Diese sechs Bausteine erscheinen mir nach wie vor überraschend aktuell. Aber nach den Erfahrungen in den vergangenen 6 ½ Jahren gibt es Unterschiede. Einige der Prinzipien haben sich verbreitet und sind weithin akzeptiert. Andere führen eher ein Schattendasein – sie spielen in den verwaltungsinternen Diskussionen kaum eine Rolle. Vielleicht, weil ihre Bedeutung nicht recht erkannt wird. Oder vielleicht im Gegenteil, weil sie aus Sicht mancher Führungskräfte so brisant sind, dass sie ihnen ausweichen.

Ich unterscheide relativ schematisch drei Sichtweisen auf Agilität. Überflüssig zu betonen, dass es zwischen diesen drei „Schubladen“ keine scharfen Trennlinien gibt, sondern Vermischungen und Überschneidungen.

Sichtweise #1: Agilität als Methodenkoffer

Hier wird der Schwerpunkt auf die Aspekte

mit überschaubaren Änderungen und Teilergebnissen experimentieren, und
sich regelmäßiges Feedback von innen und außen verschaffen

gelegt. Nach dieser Sichtweise ist Agilität ein Methodenkoffer, aus dem wir uns situativ bedienen können. Darin befinden sich Methoden wie Lean Coffee, Kanban-Boards, Reviews, Retrospektiven, Design Thinking, 1-2-4-all und noch ein paar Dutzend weitere. Die Interessent:innen an Agilität werden eingeladen, möglichst viele dieser Methoden kennenzulernen und praktisch zu erproben. Wenn in einer Verwaltung – so die Vorstellung – viele solcher Experimente stattfinden, wird mit der Zeit auch eine Vertiefung und Verbreitung agiler Denkweisen folgen.

Die Sichtweise #2: Cross-funktionale selbstorganisierte Teams

Der Methodenkoffer nach Sichtweise #1 kann individuell oder durch kleine ad-hoc-Gruppen ausprobiert werden. Das muss nicht einmal kontinuierlich geschehen. Cultural Hacks, die untereinander nicht abgestimmt sind, sollen den harten Fels verwaltungsjuristisch-neoliberaler Verwaltungsdenke höhlen.
Zu einer Kultur der Teamarbeit kommt man so nicht. Der Übergang zur agilen Teamarbeit beruht auf dem Satz

cross-funktionale Teams bilden.

Das ist tatsächlich der einzige Punkt, der Christiane Büchter und mir in der Version von 2016 auffiel: Er reicht nicht mehr aus. Wir würden ihn heute formulieren als

cross-funktionale selbstorganisierte Teams bilden.

Die Selbstorganisation der Teams ist es, die den umstürzenden Charakter von Frameworks wie Scrum oder Kanban begründet. Damit Teams ihre Produktivität und Kreativität voll ausschöpfen können, müssen sie hierarchiefrei und autonom sein. Das stellt sie in einen deutlicheren Gegensatz zum Status Quo als die Sichtweise #1.

Agile Teamarbeit ist nur möglich, wenn verschiedene Instrumente aufeinander abgestimmt und zu einer synchronisierten Vorgehensweise verzahnt werden. Sie kann nicht mehr „unter dem Radar“ durchtauchen, sondern bedarf des aktiven Commitments der umgebenden Verwaltung. Denn: cross-funktionale Teams funktionieren nur dann, wenn sie das Recht haben, Entscheidungen über Lösungen zu treffen.
Nehmen wir an, ein Team aus fünf verschiedenen Abteilungen arbeitet an einem Problem und findet eine Lösung. Und dann muss jedes Teammitglied zu seinem bzw. seiner Vorgesetzten gehen und um Mitzeichnung bitten? Wenn dann auch nur eine dieser Führungskräfte die Zustimmung verweigert, muss das Team wieder zusammentreten und quasi von vorn anfangen. Es wäre völlig unpraktikabel.

Das bedeutet aber umgekehrt, dass die vorgeschriebenen Mitzeichnungswege agile Teamarbeit verhindern. Das war der Grund, warum wir bei einem Workshop mit dem Bundesverwaltungsamt gemeinsam zum Schluss kamen: Auch die neue Version des Organisationshandbuchs der Bundesregierung kann keine agile Teamarbeit anbieten.

Agile Teamarbeit stößt auf Hierarchie- und Machtfragen. Sie ist nur möglich, wo eine Verwaltung oder zumindest einige Vorgesetzte sich freiwillig committen, dass die Mitzeichnung nur formal praktiziert wird. Dann darf sich dort Sichtweise #2 entfalten. Und stellt einen deutlichen Schritt in Richtung sinnstiftenden, befreienden Arbeitens dar. Das geht wirklich in Richtung New Work.

Sichtweise #3: Agile Frage nach dem „Was?“

Aber auch Sichtweise #2 verkörpert noch kein New Work im Sinne Frithjof Bergmanns. Sie wird weitergetrieben durch Sichtweise #3. Diese macht sich vor allem die Forderungen

Das Ganze in den Blick nehmen und
die Anspruchsberechtigten einbeziehen

zu eigen. Beide Formulierungen beziehen sich auf die Ziele von agilen Projekten.
In der freien Wirtschaft gelangt Agilität mit Sichtweise #2 an ihr maximal zu bedienendes Handlungsfeld. Definieren wir Sinn als

“Das Richtige richtig tun können und dürfen.”

dann sehen wir z.B. in Scrum: Das Thema „das Richtige tun“ (das „Was“) wird ausgeklammert und die Kompetenz des Entwicklungsteams eingegrenzt auf “es richtig tun” (das „Wie“). Das “Was” der Arbeit wird als gegeben vorausgesetzt (es gibt keine „Zielfindung“ im Scrum-Guide). Das Team hat keine Legitimation, diese Vorgabe in Frage zu stellen. In gewinnorientierten Unternehmen entscheiden die Eigentümer, was gemacht wird. Sollte ein Mitglied eines agilen Projekts auf einmal moralische Zweifel am Ziel haben – dann kann es sich aus dem Projekt verabschieden. Einen Einfluss auf das Ziel sieht Scrum für ihn nicht vor.

Die Chancen von Agilität in der öffentlichen Verwaltung

Diese Beschränkung gibt es in der Verwaltung nicht. Einrichtungen öffentlichen Rechts sind nicht dem Gebot der Gewinnerzielung unterworfen. Sie können Visionen entwickeln, die vielleicht monetär höhere Kosten als Einnahmen verursachen, aber trotzdem einen “Gewinn” für die Gesellschaft bedeuten. Dadurch wird es überhaupt erst möglich, bewusst als Gesellschaft zu handeln. Oder, mit einem Zitat von Gerhard Wohland: “Mit dem Markt kann man nicht diskutieren, mit einem Minister aber schon.” Eine selbstbewusste Verwaltung kann Potentiale entfalten, die privatwirtschaftlichen Organisationen aus systemischen Gründen gar nicht zur Verfügung stehen.

Die Selbstorganisation eines Scrum Teams wäre auch in öffentlichen Projekten nicht schrankenlos. Es wäre eingebettet in einen öffentlich erarbeiteten Auftrag, dessen Ziele es nicht eigenmächtig in Frage stellen kann. Der Unterschied zur Privatwirtschaft läge woanders. Wenn das (Verwaltungs-)Scrum Team bemerkt, dass der Projektauftrag grundlegende gesellschaftliche Ziele verletzt, hätte es nicht nur das Recht, sondern geradezu eine Verpflichtung, gegenüber dem Auftraggeber seine Bedenken deutlich zu artikulieren.

Die möglichen Wechselwirkungen des eigenen Projekts mit anderen gesellschaftlichen Zielen werden dem Team oft erst in der Phase der Umsetzung bewusst. Man arbeitet z.B. an der Umsetzung eines Mobilitätskonzepts eines Stadtteils, und auf einmal wird deutlich, dass damit vorher nicht bedachte Umweltgefahren verbunden sind. In diesem Fall würde das Scrum Team aus seiner eingeschränkten Rolle als “Umsetzer” heraustreten und aus einer anderen Rolle heraus – nämlich als Mitglieder der Gesellschaft mit Handlungsrechten im öffentlichen Raum – mit den auftraggebenden Gremien in Dialog treten.

In diesem Szenario würde aus Scrum ein Scrum++ und zum Betriebssystem gesellschaftlicher Innovation.