Einführung: Agilität, Qualität und Organisationsentwicklung

Jan 10, 2025

—

Warum scheitern viele Projekte zur Organisationsentwicklung?

Kennen Sie das auch? Eine Umstrukturierung wird verkündet, der Mehrwert herausgestellt und die Erwartung ausgesprochen, dass nun alle willig sich den neuen Strukturen unterordnen und sich sogleich Verbesserungen einstellen werden. Und was passiert tatsächlich? Schleppende Umsetzung, unklare Zielsetzung und scheinbar unüberwindliche Hindernisse sorgen dafür, dass die so positiv beschriebene Veränderung mehr Ungemach produziert als vorhandene Probleme tatsächlich beseitigen würde. Was können Gründe dafür sein?

1) Oftmals wird bei einem Veränderungsprozess suggeriert, schon genau zu wissen, was alles geändert werden soll. Zielperspektiven von ein, zwei Jahren sind bei solchen Veränderungsprozessen nicht unüblich. Das unterschätzt, mit welcher Komplexität man es zu tun hat und, wie wenig berechenbar es ist, was wirklich in einem System passiert, wenn man ein bestimmten Stellen das Zusammenarbeitsmodell verändert. Sinnvoller ist es, nur eine grobe Zielperspektive auszugeben und über iterative Elemente sich langsam dorthin hinzubewegen, wohin man will. Immer in Bereitschaft, das Ziel neu auszurichten, wenn es neue Erkenntnisse geben sollte. Man bleibt damit flexibler.

2) Außerdem wird oftmals unterschätzt, wie beharrlich die Menschen sein können. Erfolgreiche Veränderung muss in den Köpfen der Menschen beginnen (siehe: Sozialkonstruktivismus). Dafür braucht es Mechanismen, die es ermöglicht, die eigenen Werte explizit zu machen und zu reflektieren (wie das z.B. Irritationen im Alltag ermöglichen). Ansonsten wird man keine nachhaltige Veränderung erreichen. Ohne Momente des Innehaltens wird man nicht schnell genug merken, wenn der Weg nicht mehr der richtige ist oder die Widerstände immer größer werden. Fragen nach der Qualität sowohl dessen, was man erreichen will, als auch, ob der Weg dorthin der richtige ist, können helfen, implizite Sorgen explizit zu machen und darüber sprechen zu können.

3) Größere Veränderungsvorhaben geht oftmals irgendwann die Luft aus. Erste Erfolge sind erzielt und die Menschen wollen auch wieder mal eine Form der Routine erfahren. Eine Struktur, die Inhalte volatil hält, aber das Vorgehen relativ strikt vorgibt, kann hier eine gewissen Halt geben. Reflexionspunkte, die auch erlauben, zugeben zu können, dass mal eine Pause gut wäre, sind hier ebenso hilfreich, wie Rituale der Selbstvergewisserung und das Feiern von Erfolgen.

Agiles, iteratives Vorgehen bei der Organisationsentwicklung

Kenner von agilen Methodiken werden schon gemerkt haben: einige der hier erwähnten Aspekte werden beim agilen Arbeiten sehr explizit adressiert bzw. können zumindest als Inspiration für das Bearbeiten der genannten Themen angesehen werden. Man könnte auch sagen: Scrum verbindet viele der genannten Aspekte auf sehr organische Art und Weise. Ich habe bereits an anderer Stelle die Elemente von Scrum genauer vorgestellt, In diesem Beitrag erweitere ich diese nun mit Überlegungen zur Organisationsentwicklung.

Beginnen wir damit, dass es zielführender ist, sich iterativ, also schrittweise an das Ziel heranzuarbeiten: Die gesamte Logik von Scrum ist, dass man sich in Sprints langsam an ein Ziel „heranrobbt“. Es gibt zwar eine Produktvision und ein langes Backlog von „Wünsch-Dir-Was“, aber die Entwickler:innen entscheiden mit dem Product Owner zusammen, was als nächstes angegangen wird. Es ist nicht unüblich, das sich über viele Sprints hinweg das Produkt in andere Richtungen hin entwickelt als gedacht. Dadurch, dass man am Ende jedes Sprints etwas abliefert, was auch gleich genutzt wird, können über das Feedback aus dem Review, neue Erkenntnisse dazu führen, das man sich neue Ziele überlegt. Eine große Flexibilität stellt sich ein, die für alle in Ordnung ist, weil man beständig im Gespräch bleibt und die nächsten Schritte gemeinsam entscheidet.

Auch ein weiteres Prinzip des agilen Arbeiten hilft, die richtige Zielperspektive zu entwickeln, nämlich die der Selbstorganisation. Hierbei ist die Idee, dass keiner von außen vorgibt, wie vorzugehen ist, sondern lediglich was als nächstes angegangen werden sollte. Wobei das Team sogar festlegen kann, in welchen Schritten es seine Entwicklung einteilt. Überführt man das auf ein Organisationsentwicklungsprozess, heißt das nicht nur, dass die Betroffenen zu Beteiligten gemacht werden müssen, sondern dass diese ein stückweit auch die Freiheit gegeben müssen, selbst zu entscheiden, wie sie die Veränderung angehen und umsetzen wollen. Für das traditionelles Management kann dies durchaus zur Herausforderung werden!

Moment der Reflexion über Qualitätsfragen ermöglichen

Es ist interessant, dass Scrum der Logik des PDCA-Zyklus, wie wir ihn aus dem klassischen Qualitätsmanagement kennen, mit Sprint-Planning (Plan), Umsetzung (Do), Review und Retrospektive (Check) sowie (Inspect &) Adapt (Act )folgt. Damit ist Scrum an sich vorbildlich auf Qualität und damit Reflexion ausgerichtet. Es bringt quasi sehr organisch das Sprechen über Qualität im Organisationsentwicklungsprozess. Zwei Aspekte möchte ich dabei besonders hervorheben.

So kennt Scrum zum einen die Definition of Done, die verlangt, dass wir explizit machen, woran wir erkennen wollen, dass ein Sprintergebnis zufriedenstellend ist. In einem Organisationsentwicklungsprozess wäre das, Indikatoren festzulegen, die uns helfen zu entscheiden, ob die gewünschte Veränderung auch verstanden und gelebt wird. Oftmals krankt es aber in solchen Prozessen daran, dass nicht genug Wert darauf gelegt wird, ob die Menschen auch das neue Verhalten erlernt haben. Durch diesen „Check“-Anteil wird das jedoch verhindert.

In der Retrospektive wird wiederum über das Vorgehen zu Erreichung dieses Ziels nachgedacht. Das Team sollte sich regelmäßig fragen, ob die Art und Weise, wie Veränderung implementiert wurde, auch genau den Erfolg gebracht hat, den man sich vorgestellt hat. Man lernt damit am lebenden Objekt, in diesem Fall im laufenden Veränderungsprozess. Es entsteht eine Methodenoffenheit, die der Komplexität der Aufgabe gerecht wird.

Wiederkehrende Struktur gibt Halt und erlaubt schnell, gegenzusteuern

Auch hier kann man sich vom agilen Arbeiten inspirieren lassen. Gerade Scrum ist ein gutes Beispiel des Zusammenspiels von Stabilisierung und Dynamik: während die Inhalte immer fließend gehalten werden und jederzeit alles wieder auf Prüfstand gestellt werden darf, bewegt sich das Scrum-Team mit seinen Sprint-Ritualen in einem sehr fixen Rahmen, der sich eigentlich nie ändert. Qualitätssicherungspunkte wie Review und Retrospektive sowie das Sprint-Planning bieten einen stabilen Fixpunkt in einem sich trotzdem laufend ändernden Umfeld. Treten Ermüdung oder Widerwille auf, kann dieser in den entsprechenden Formaten schnell wahrgenommen werden.

Mit den Rollen Product Owner und dem Scrum Master gibt es feste Rollen, die als Ansprechpartner und Gesicht der Veränderung stehen. Dabei sollte der Product Owner, der traditionell auf die Inhalte und das Stakeholder-Management zu achten hat, sollte im Fall eines Organisationsentwicklungsprozesses idealerweise prominent aus dem oberen Management besetzt sein. Der Scrum Master, der darauf schauen muss, dass es dem Team gut geht und die Strukturen die Veränderungsarbeit zulassen, ist hingegen besser bei HR angesiedelt oder kann auch jemand externe:r sein. Diese Aufgabe ist oftmals sehr auf ein zwischenmenschlichen Ausgleich und das Einhalten der formalen Strukturen ausgerichtet. Hier würde ich auch meine Rolle als Unterstützerin angesiedelt sehen, wenn man sich nach dieser Logik ausrichtet.

Grenzen der Analogie zu Scrum

Ehrlicherweise muss man zugleich zugeben, dass die Analogie zu Scrum auch nicht vollumfänglich in einem Organisationsentwicklungsprozess funktioniert. Das eine ist, dass das, sich die Idee, dass man ein kleines, selbstorganisiertes Team hat, das alle Aufgaben alleine erledigen kann, nicht ohne Schwierigkeiten auf andere Bereiche übertragen lässt. Softwareprogrammierung funktioniert relativ autonom, da die Entwickler quasi alles im virtuellen Raum entstehen lassen. Damit ist es gut möglich, kleine Teams, die alle Fähigkeiten in sich vereinen, zu bilden. Das gilt auch beim sog. „Scrum of Scrums“, das mehrere Scrumteams nebeneinander am selben Produkt arbeiten lässt.

Bei der Erarbeitung bzw. Einführung eines Bildungskonzept oder gar bei einer Organisationsentwicklung, schaut das ganz anders aus. Aufgrund von zu vielen Abhängigkeiten lässt sich entweder klein eigenes, selbstorganisiertes Team aufstellen oder gerade im sozialen Bereich ist es nicht immer möglich, nur kleine Zwischenergebnis auszuliefern. D.h. eine der besonderen Aufgaben ist es, bei einem größeren Entwicklungsprozess überhaupt Aufgaben zu finden, die kleinteilig genug sind, dass man z.B. eine konkretes Team mit der Umsetzung beauftragen kann. Nur dann ist Selbstorganisation auch im Sinne der Umsetzungsverantwortung möglich. Und nur dann muss die Organisation nicht als Ganzes das Arbeiten einstellen, um sich der Veränderung zu widmen.

Selbst wenn das gelingen sollte, muss las but not least im Hinterkopf behalten werden, dass Veränderung nicht nur materielle Ressourcen braucht, sondern auch emotional und energetisch hohe Ansprüche an die Belegschaft stellt. Man muss daher damit in jedem Fall rechnen, dass andere Dinge liegen bleiben und die Produktivität sinkt. Es muss also bei allen Planungen berücksichtigt und kommuniziert werden, was das Richtung Kundschaft bzw. der Klienten bedeutet.

Fazit

Trotz dieser Einschränkungen bleibe ich bei der These, dass Scrum, bzw. Elemente eines agilen Vorgehens, sehr hilfreich sein können, wenn man Veränderung in einer Organisation realisieren möchte. Das kleine, iterative Vorgehen nimmt die Menschen mit und ermöglicht ein schnelles Reagieren, wenn Dinge nicht so funktionieren, wie gedacht. Die Frage nach dem „Was“ wird durch verschiedenen Qualitätscheckpunkte mit dem „Wie“ verbunden. Der PDCA-Zyklus bietet einen stabilen Rahmen für Ergebnissicherung und Reflexivität, die Sicherheit in Zeiten des Umbruchs ermöglichen.