Der Begriff »Agile Organisationsentwicklung« mag vielleicht nicht der (nicht mehr ganz so) neue heiße Scheiß sein, aber ich höre ihn immer häufiger in unterschiedlichsten Zusammenhängen und mit unterschiedlichsten Definitionen. In meinem Verständnis folgt OE jedoch immer dem Agilen Prinzip, oder bin ich auf einem völlig falschen Dampfer?
Bei dieser Diskussion möchte ich ein wenig früher einsteigen und zunächst die Grenze zwischen Change und Organisationsentwicklung ziehen. Vereinfacht ausgedrückt ist ein Change immer ein Big Bang. Zu einem bestimmten Stichtag wird ein Hebel umgelegt, und eine größere Veränderung tritt in Kraft, wovon im allgemeinen sehr viele Personen betroffen sind. Eine ganze Abteilung wird umgestellt, Teamschnitte ändern sich, Managementebenen verschieben sich, Zuordnungen und Zuständigkeiten ändern sich.
Ein Change ist immer projekthaft. Er wird vorbereitet, man erstellt einen Plan, arbeitet auf einen Stichtag hin, dann wird der Hebel umgelegt, und danach fegt man die Scherben zusammen und tut so, als wenn nichts gewesen wäre.
Ein Change kann auch mit Agilen Methoden durchgeführt werden. Man stellt ein Team zusammen, dass dieses Projekt iterativ durchführt. Es bleibt jedoch dabei, dass es sich um ein großes Projekt mit einem (hoffentlich definierten) Ziel handelt. Dieses Projekt wird gestartet und irgendwann abgeschlossen.
Organisationsentwicklung hingegen ist ein fortlaufender Prozess, der viele kleine Projekte miteinander vereinen sollte. OE ist daher nie abgeschlossen. Jedes Unternehmen befindet sich bewusst oder unbewusst in einem endlosen Entwicklungsprozess, allein schon deswegen, weil man sich geänderten Rahmenbedingungen ab und zu anpassen muss. Man ändert Workflows und Prozesse, weil man merkt, dass die Dinge so nicht mehr richtig funktionieren, weil jemand einen guten Vorschlag gemacht hat, oder weil der Gesetzgeber plötzlich Dinge anders haben möchte. Die Gründe sind vielfältig. All das betrifft sowohl die internen Organisationsprozesse (z.B. Richtung HR / Personal) als auch die Arbeit an Projekten und Produkten.
Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen
Diese Dinge laufen irgendwie unter dem Oberbegriff »Organisationsentwicklung«. Dabei handelt es sich meistens um voneinander isolierte kleine Maßnahmen. In Abteilung X wird ein Prozess geändert, in Abteilung Y ändert sich die Struktur, indem ein Team aufgeteilt wird und Zuständigkeiten angepasst werden.
Nennen wir dies einmal den Standardzustand einer gewöhnlichen Organisationsentwicklung.
Sollte aber nicht alles, was wir tun, in irgendeiner Form dem Regelkreis Plan – Do – Check – Act unterworfen sein? Sollte damit nicht auch jede Maßnahme, die wir hier finden, in irgendeiner Form einem Review unterzogen werden? Haben wir unser Ziel erreicht? Müssen wir nachjustieren? Müssen wir auf die Bremse treten? Und im Idealfall folgt auf die eine Maßnahme die nächste.
Die Methode ist im Moment noch vollkommen egal. Hier geht es zunächst nur um das Prinzip des Kontinuierlichen Lernens aus Erfahrung – mit anderen Worten: um das Agile Prinzip. Ich habe noch nicht alle Maßnahmen zusammengefasst und miteinander koordiniert. Ich habe keine explizite Agile Methode definiert. Ich habe mich lediglich im Unternehmen darauf verständigt, dass Organisationsentwicklung – so fragmentiert sie auch sein mag – dem Regelkreis folgt.
Ich behaupte, dass es immer eine gute Idee ist, verändernde Maßnahmen einem Review zu unterziehen, daraus zu lernen und das so Gelernte für die nächste Maßnahme zu verwenden. Damit sollte OE immer dem Agilen Prinzip folgen. Ich glaube auch nicht, dass mir da jemand ernsthaft widersprechen wird. Wir können die Dinge gern anders benennen, aber im Kern sind wir wahrscheinlich einer Meinung.
Denken wir weiter, kommen wir wahrscheinlich schnell zu dem Punkt, dass so gut wie jede Maßnahme an einem Ende des Unternehmens irgendeine Auswirkung an einem beliebigen anderen Ende unseres lächerlich komplexen Unternehmenskonstrukts haben wird. Das ist nicht ganz so wie die Sache mit dem Schmetterling und dem Wirbelsturm, aber doch irgendwie ähnlich, nur mit dem Unterschied, dass wir zumindest einen Teil dieser Auswirkungen mit einiger Gewissheit vorhersagen können. Wir sprechen schließlich über endliche Ressourcen, die an einer Stelle fehlen, wenn sie an einer anderen gebunden sind. Wir sprechen über sichtbare Abhängigkeiten und bekannte Verbindungen.
Macht es dann nicht Sinn, Organisationsentwicklung aus der Vogelperspektive zu betrachten, um auf diese Abhängigkeiten angemessen reagieren zu können? Wahrscheinlich muss nicht jeder Kleinscheiß auf dieser maximal skalierten Ebene durchgekaut werden, aber wenn abzusehen ist, dass eine Maßnahme über einen gut abgegrenzten Bereich hinausreicht, weil sich die Zusammenarbeit zwischen Abteilungen ändert, weil viele Personen oder Rollen betroffen sind, ist es durchaus eine gute Idee, diese Vogelperspektive einzunehmen. Zum einen, weil eine relativ kleine Änderung in einem Bereich große Auswirkungen in einem anderen Bereich haben kann. Wenn Aufwand und Nutzen in keinem vernünftigen Verhältnis zueinander stehen, müssen wir natürlich eine andere Lösung finden.
Ich sollte auch darauf achten, dass ich nicht an zu vielen Stellen gleichzeitig Änderungen vornehme, die sich über weite Bereiche ziehen. Zum einen gibt das unnötig viel Stress ins System, zum anderen sind die Auswirkungen dann nur extrem schwer abzusehen.
Sobald ich also über eine skalierte Ebene der Organisationsentwicklung spreche, bin ich auch bei der Koordination der Maßnahmen und damit ganz schnell bei einer Priorisierung.
Ich denke, Ihr merkt jetzt, wohin der Hase läuft.
Eine skalierte Ebene bedeutet eine Rolle oder ein ganzes Team. Priorisierung, Koordination, Review und Lernen aus Erfahrung schreien nach Agilen Methoden. Wir sind hier bei dem, was ich unter »Agiler Organisationsentwicklung« verstehe, nämlich ganz bewusst Agile Methoden für eine koordinierte Organisationsentwicklung einzusetzen.
Rolle oder Team kann ein Fulltime-Job sein. Das hängt natürlich vom Unternehmen, der Komplexität, der Anzahl der Maßnahmen und nicht zuletzt davon ab, wie viel Energie ich überhaupt investieren will. Wichtig ist lediglich, dass die handelnden Personen ausrechend viel Zeit für diese Aufgabe haben. Alles in aller Eile zwischen Tür und Angel zu machen, führt nur selten zum Erfolg, aber das ist keine neue Erkenntnis.
Bei der Wahl der Methoden haben wir alle Freiheiten. Ein reines Scrum-Vorgehen funktioniert jedoch selten. Wir würden ein festes Team für die Umsetzung brauchen, das tatsächliche Doing ist aber oft sehr verteilt und liegt in den Fachabteilungen. Auf der skalierten Ebene ist mehr Koordination als tatsächliches Tun angesiedelt, was nicht bedeutet, dass nicht auch ein DevOps-ähnliches Modell möglich wäre, in dem einzelne Mitglieder des »Zentralkomitees« temporär in einzelne Abteilungen gingen.
Ihr seht also, dass die Etablierung der skalierten Ebene der OE – also die Agile Organisationsentwicklung – keinesfalls trivial ist. Sie muss immer individuell erarbeitet werden, und der Weg dahin ist lang. Bitte glaubt niemandem, dass es ein Standardrezept gäbe, dass man einfach anwenden könnte. Wir sprechen nicht über ein einzelnes Team, wir sprechen über Euer gesamtes Unternehmen, also über eine sehr komplexe Sache.
Wenn wir ein solches Standardrezept anwenden wollten, würde das nur bedeuten, viele Dinge umzubiegen, bevor wir überhaut starten könnten. Für mich steht das im Widerspruch zu »Beginne dort, wo du dich gerade befindest«.
Ein weiterer Vorteil der Agilen Organisationsentwicklung, wenn ich sie so verstehe, wie oben beschrieben, ist die Verstetigung. Wir haben Rollen geschaffen, vielleicht ein ganzes Team, dessen Aufgabe es ist, die Weiterentwicklung unserer Organisation voranzutreiben. Damit verabschieden wir uns von anlassgetriebenen punktuellen Maßnahmen. Wir fangen an, das Große ganze zu sehen, die Querverbindungen zu sehen, weiter zu blicken. Aus dieser Sichtweise folgen automatisch immer wieder neue Impulse für Veränderung. Allein dieser Aspekt wäre Grund genug, über eine skalierte Ebene der Organisationsentwicklung – und damit über eine Agile Organisationsentwicklung – nachzudenken.
Beim ganzen Prozess der Etablierung dieser skalierten Ebene der Organisationsentwicklung kann es helfen, jemanden dabei zu haben, der sowas schon mal gemacht hat.
Kernaussage: Organisationsentwicklung folgt immer dem Agilen Prinzip von Plan – Do – Check – Act. Unter dem Begriff »Agile Organisationsentwicklung« versteht man eher die skalierte Ebene mit Anwendung Agiler Methoden im Rahmen der OE.
Folgt mir auf twitter, um keine neuen Beiträge zu verpassen.
