Deutungshoheit

Bild: Pexels / Tima Miroshnichenko - Lizenz

Dass Change-Projekte in deren Rahmen agile Frameworks und agile Produktentwicklung eingeführt werden nicht immer so verlaufen wie das dafür verantwortliche Management es sich wünscht ist ein erstaunlich häufig zu beobachtendes Phänomen. Die Gründe dafür sind vielfältig und reichen von der Zielsetzung bis zur Ergebniskommunikation. Ein weiterer, der häufig unterschätzt wird, ist eine bestimmte Art des Kontrollverlustes: das sich verändernde Unternehmen beitzt keine Deutungshoheit über den neuen Arbeitsmodus mehr.

Um zu verstehen warum es sich dabei um einen Ausnahmefall handelt hilft ein Blick auf den Normalfall. In ihm werden methodische Veränderungen dadurch eingeleitet, dass das von Unternehmensberatern unterstützte Management sich in ein Tagungshotel zurückzieht um dort in Ruhe neue Strukturen und Abläufe zu konzipieren. Diese werden dann nur noch verkündet, und zwar so, dass die betroffenen Mitarbeiter kaum noch widersprechen können.

Dabei ist eines wichtig: dass Widerspruch kaum möglich ist liegt meistens nicht daran, dass er nicht erlaubt wäre. Deutlich schwerer wirkt eine Informations-Asymetrie: egal ob es sich um Synergieeffekte und Sparpotentiale handelt oder um erfolgversprechende "Best Practices" und Industrie-Standards, den meisten Menschen fehlen sowohl die Erfahrungs- und Vergleichswerte um mitreden zu können als auch Zeit und Informationszugang für eigene Recherchen.

Bedingt dadurch befindet sich in diesem Szenario die Deutungshoheit über das angestrebte Vorgehen nahezu ausschliesslich auf der Seite von Management und Beratern. Nur sie haben den vollständigen Blick darauf wie der methodische Ansatz gedacht ist, er umgesetzt wird, sein Erfolg gemessen wird, etc. Verstärkt wird das oft noch dadurch, dass die Dokumentation des angestrebten Vorgehens nicht für alle zugänglich ist (wofür es sowohl gute als auch schlechte Gründe geben kann).

Im Fall agiler Transitionen ist diese Asymetrie aufgehoben. Das Manifest für agile Softwareentwicklung und die Grundlagen-Dokumente von Exteme Programming, Scrum und (IT-)Kanban stehen frei verfügbar im Internet und dank der Soft Power der agilen Bewegung findet ihre Verbreitung nicht nur durch (teure) Konferenzen und Bücher statt sondern auch durch zahllose, grösstenteils kostenlose Meetups und Online-Publikationen.

Durch diesen gleichen Informationszugang verschiebt sich die Deutungshoheit, und das in mehrfacher Hinsicht. Zum Einen kann sie nicht mehr (bewusst oder unbewusst) monopolisiert werden, wodurch in der Einführungsphase plötzlich eine Situation der Augenhöhe entsteht die für viele Organisationen höchst ungewohnt ist. Man kann es sich vorstellen - ein Sachbearbeiter oder Tester der einem Manager sagen kann ob dieser Scrum richtig verstanden hat oder nicht kann für ganz neue Dynamiken sorgen.

Zum Anderen (und das ist sogar noch weitergehend) verlagert sich die Deutungshoheit aus der Organisation heraus. Die Verfasser des agilen Manifests sind fast alle noch am Leben und sehr auskunftsfreudig, und die oben verlinkten Regelwerke der einzelnen Frameworks sind zwar minimalistisch, aber dafür ein vielen Stellen von unmissverständlicher Klarheit. Und keine Firma der Welt (egal wie gross sie ist) hat einen Einfluss auf das was darin steht.

Das hat Folgen. Natürlich kommt es in vielen Organisationen während der Change-Projekte zu Kompromissen, Missverständnissen oder halbgaren Lösungen. Aber anders als in den meisten klassischen Veränderungsvorhaben ist das jetzt für alle offensichtlich. "Wenn man agil arbeitet macht man das so" funktioniert nicht mehr als Universalbegründung wenn alle wissen dass das nicht stimmt. Und beim Scheitern alles auf die angeblich unpassende Methodik zu schieben geht auch nicht mehr.

Für viele Entscheidungsträger mag das zunächst bedrohlich klingen, man kann aber auch das Positive darin sehen. Dadurch dass die agilen Frameworks ausserhalb der eigenen Deutungshoheit liegen kann man sie als Leitstern benutzen, der alle (im Zweifel gut gemeinten) Kompromisse oder Minimalkonsense unverfälscht übersteht, so dass es immer wieder von neuem möglich ist zu refocussieren und sich erneut an ihm zu orientieren. Es kann sogar befreiend sein, keine eigene Methodik erarbeiten zu müssen.

Natürlich kollidiert ein solches Vorgehen mit vielen eingeübten Change-Routinen, die Veränderungen eher schnell beenden als durch regelmässige Refocussierungen immer wieder neu starten wollen. Genau das ist der zu Beginn genannte Verlauf den sich das verantwortliche Management häufig anders wünschen würde. Aber genau das ist eben auch - agil.