Als eine Gruppe von 17 Softwareentwicklern vor über 20 Jahren das “Agile Manifest” als Ergebnis eines Netzwerktreffens in Utah vorstellte, ahnte niemand, welche Strahlkraft diese Veröffentlichung haben würde. Die neue Art zu denken und zusammenzuarbeiten, hat sich in vielen Unternehmen durchgesetzt, längst auch außerhalb der IT. Grundsätzlich ist Agilität ein Ansatz, um Komplexität zu meistern, Teams schneller und beweglicher zu machen und bessere, kundenorientierte Produkte zu entwickeln.
Auch zwischen den aktuellen Herausforderungen der Organisationsentwicklung und der Frustration über die Softwareentwicklung der 90er Jahre gibt es zahlreiche Parallelen. Wie mein Kollege Matthias Pauers in seinem Plädoyer für agile Organisationsentwicklung schrieb: Wir sind davon überzeugt, dass agile Spielregeln den “Knoten” lösen können, der die Transformation in vielen Unternehmen lähmt.
Kurz zusammengefasst bietet agile Organisationsentwicklung den Vorteil, dass sich Unternehmen in kleinen Schritten an ihre Vision “herandrillen” – ähnlich wie agile Produktentwicklungsteams Software oder andere Produkte und Services entwickeln.
Mit meiner Artikelserie möchte ich Organisationsentwickler:innen und Unternehmenslenker:innen deshalb inspirieren, sich mit den agilen Prinzipien auseinanderzusetzen. Es lohnt sich, die Learnings aus zwei Jahrzehnten agiler Produktentwicklung auf die Transformation von Organisationen zu übertragen – unter anderem für mehr Flexibilität und Pragmatismus, ein größeres Commitment für Veränderungen, bessere Wertschöpfung, eine neue Fehler- und Feedbackkultur und nicht zuletzt auch für ein effektives Risikomanagement.
Agiles Prinzip #1 in der Produktentwicklung
Was bedeutet das im Originalkontext?
Das agile Konzept ist auf die Bedürfnisse der Nutzer:innen ausgerichtet, d.h. Nutzerzufriedenheit hat höchste Priorität. Indem Nutzer:innen frühzeitig und regelmäßig in den Entwicklungsprozess eingebunden und um Feedback gebeten werden, entsteht ein Produkt, das die Zielgruppe wirklich nutzen kann (Nutzbarkeit) und nutzen will (Werthaltigkeit).
Beispiel
Bei der Entwicklung einer App stellt das Team Nutzer:innen bereits in einem sehr frühen Entwicklungsstadium eine erlebbare, nutzbare Basisversion vor – es wird also nicht nur über das Produkt gesprochen oder etwas vorgeführt, sondern wirklich getestet. Diese Basisversion muss nicht perfekt sein und hat meist auch einen eingeschränkten Funktionsumfang, aber durch die echte Interaktion, also das Ausprobieren der App erhält das Entwicklungsteam wertvolle Informationen, wie sich Nutzer:innen in der App zurechtfinden, was bereits reibungslos läuft und wo es noch Schwachstellen gibt.
Beispielsweise könnte die allererste Basisversion einer Smart-Home-App das Einloggen und die Anzeige der Raumtemperatur auf dem Smartphone sein oder ein funktionierendes Registrierungsformular für die Eingabe von Name, Adresse und Bankverbindung o.ä. So lassen sich Schlussfolgerungen für die Weiterentwicklung ziehen (Nutzbarkeit). In Interviews mit den Nutzer:innen versucht das Team außerdem herauszufinden, welche Funktionen bei der Weiterentwicklung in Betracht gezogen werden sollten, damit die App für die Zielgruppe noch attraktiver wird (Werthaltigkeit).
Wie lässt sich dieses Prinzip auf die Organisationsentwicklung übertragen?
Vorweg stellt sich die Frage: Wer sind denn in der Organisationsentwicklung eigentlich die “Nutzer:innen”? Je nach Projekt kann der Fokus unterschiedlich sein, beispielsweise sind bei Transformationen im Bereich New Work die Mitarbeitenden die Nutzer:innen, bei Transformationen des Geschäftsmodells die Kund:innen oder auch externe Partner:innen wie Lieferant:innen.
Das agile Prinzip #1 bedeutet, dass sich auch Organisationen von Anfang an und kontinuierlich mit den Bedürfnissen der Betroffenen auseinandersetzen und diese zu aktiven Beteiligten der Transformation machen sollten. Im Gegensatz zur Softwareentwicklung ist die Definition von Prototypen und Teillösungen in der Organisationsentwicklung etwas herausfordernder – grundsätzlich geht es darum, statt langwieriger Planungen möglichst schnell kleinteilige, konkrete Veränderungen umzusetzen, die sofort einen Nutzen liefern. Der “Prototyp” muss nicht perfekt sein, aber er sollte auf die Vision einzahlen und sinnstiftend sein. Im Austausch mit den Stakeholder:innen wird die Idee Schritt für Schritt verbessert und ausgebaut, d.h. auf Basis von Praxistests und Feedback wird entschieden, was beibehalten, verworfen oder weiterentwickelt werden soll. Die Idee wird im Sinne einer lernenden Organisation mit den Nutzer:innen perfektioniert.
Wie lassen sich “Prototypen” für die agile Organisationsentwicklung identifizieren? Drei Beispiele aus unterschiedlichen Bereichen.
Werteklärung im Rahmen der Leitbildentwicklung: Die Unternehmensführung präsentiert der Belegschaft keinen vom Marketing druckreif ausgearbeiteten Wertekanon, sondern trägt im ersten Schritt nur einen „Werte-Quickie“ zusammen, welche Werte aus ihrer Sicht aktuell gelebt werden. Innerhalb eines definierten Zeitraums „testen“ die Mitarbeitenden, inwieweit diese gefühlten Kernwerte des Managements mit dem tatsächlichen Denken und Handeln im Alltag übereinstimmen. Wo gibt es Gemeinsamkeiten und Unterschiede in der Wahrnehmung? Welche dieser Werte werden wirklich gelebt? Welche fehlen oder welche stören sogar? Welche Werte sind mehr oder weniger wichtig?
Arbeitsplatzgestaltung für eine bessere Employee Experience: Im ersten Schritt könnte beispielsweise 1 Büro umgestaltet werden. Der Raum erhält eine „Kernausstattung“ und ein Team arbeitet hier für einige Wochen und sammelt Feedback, was aus Sicht der Pilotnutzer:innen bereits gut und alltagstauglich ist, was geändert werden sollte und was fehlt (Mobiliar, Raumaufteilung, Beleuchtung, Arbeitsmittel, Ergonomie, Technik, Eignung für verschiedene Arbeitssituationen oder die Kollaboration mit Homeoffice-Kolleg:innen usw.) Wichtig: Die Betroffenen werden nicht nur nach ihren Wünschen befragt, sondern sie prüfen und testen ein nutzbares Büro auf Alltagstauglichkeit. In mehreren Zwischenstufen entsteht nach und nach ein Büro, in dem sich das Pilotteam wohl fühlt und gut (zusammen-)arbeiten kann. Die Learnings lassen sich dann auf andere Büros ausrollen.
Maßnahmenmix für das Betriebliche Gesundheitsmanagement: Funktionieren digitale Angebote oder Präsenzangebote besser? Wünschen sich die Mitarbeitenden Bewegungs- oder Beratungsangebote? Kommen Vorträge, persönliche Coachings oder Team-Challenges besser an? Kein Unternehmen ist wie das andere und auch die Bedürfnisse und Vorlieben der Mitarbeitenden können sich ändern. Deshalb ist es sinnvoll, starre BGM-Programme durch einen agilen BGM-Ansatz abzulösen. Hier kann beispielsweise ein Gesundheitstag die Funktion des Prototyps übernehmen, indem einige ausgewählte Formate in Form kurzer Impulse zum Ausprobieren angeboten werden. Die Auswertung des Feedbacks der Teilnehmer:innen hilft bei der Planung eines kleinen Startangebots, dessen Resonanz nach einigen Monaten wiederum in die Optimierung und Erweiterung einfließt.
Typische Hürden
Die Umsetzung dieses agilen Prinzips erfordert eine starke Ausrichtung auf die Bedürfnisse der Stakeholder:innen. Diese “Nutzerzentrierung” darf kein Lippenbekenntnis sein, sondern braucht Ernsthaftigkeit und die Rückendeckung der Unternehmensführung. Bedeutet in der Praxis: Die Bedürfnisse und Erwartungen der Betroffenen müssen regelmäßig verifiziert und mit dem aktuellen Status der Transformation abgeglichen werden, beispielsweise durch einen Mix aus Umfragen, Interviews, Retrospektiven und Gesprächen. Das erfordert Kommunikationsbereitschaft, Zeit, Ressourcen, ehrliches Interesse und den Willen zur kontinuierlichen Anpassung. Nur so lässt sich sicherstellen, dass die Ergebnisse der Transformation wirklich auf die Zufriedenheit der Stakeholder:innen einzahlen.
Teamprove-Prinzip #1 der agilen Organisationsentwicklung
Weiter geht es im nächsten Artikel…
… mit dem agilen Prinzip „Änderungen willkommen heißen“: Wie bleiben Organisationen in einem dynamischen Umfeld wettbewerbsfähig? Wie gelingt die richtige Balance zwischen Stabilität und Anpassungsfähigkeit?
Beitrag teilen
