agile = fragile? Wie wir aufkeimende Agilität erhalten können

In diesem Beitrag werde ich: 

  • Verhalten von Mitarbeiter*innen und Führungskräften aufzeigen, welches aufkeimende Agilität schon während der ersten Phase des Experimentierens verhindert .
  • Wege darstellen um dieses Verhalten zu umgehen.
  • Einige konkrete Maßnahmen dazu beschreiben.
Was ist Agilität überhaupt? 

Ich möchte hier der Einfachheit halber eine einfache und in meinen Augen stimmige Sicht auf Agilität nutzen. Unter Agilität verstehe ich in diesem Kontext die Fähigkeit schnell und selbstbestimmt auf Veränderungen im Umfeld zu reagieren und sich anzupassen. Diese Sicht lässt sich so sowohl auf ein Individuum (bspw. innerhalb eines Veränderungsprozesses) als auch auf Teams und Organisationen anwenden. 

Was kann aufkeimende Agilität torpedieren?

Zu allererst: Ich glaube nicht, dass Agilität ganz von alleine aufkeimt. Es braucht einen Impuls oder einen Umstand der dazu führt, dass Teams oder einzelne Mitarbeiter*innen anfangen zu experimentieren. Dieses kann eine Intervention der Führungskraft sein, ein Impuls von außen oder etwas Ähnliches das den Organismus in Bewegung bringt. Auch das Ausscheiden einer Führungskraft und ein vorübergehendes Vakuum an der Stelle kann dazu führen, dass Teams (gezwungener maßen) starten selbstbestimmt zu arbeiten.  

Ist das der Fall und ein Team fängt an mit Agilität und Selbstbestimmtheit zu experimentieren, sich beispielsweise Verantwortung im Team aufzuteilen und Entscheidungen selber zu treffen, so handelt es sich gerade anfänglich um ein sehr fragiles Konstrukt. Schon kleinste Interventionen können dazu führen, dass aus Selbstbestimmtheit eine Schockstarre entsteht die zur Handlungsunfähigkeit führt. Diese Interventionen können sowohl von innen, von den Teammitgliedern selbst, als auch von außen, beispielsweise von Kolleg*innen oder Führungskräften kommen.  

Herrscht zum Beispiel wenig Commitment im Team darüber mit Agilität und Selbstbestimmten Arbeiten zu experimentieren und paart sich dieses noch mit einer weniger offenen (oder gar nicht existenten) Feedbackkultur im Team, so resultiert dieses in fehlender Verlässlichkeit. Absprachen im Team werden nicht eingehalten, selbstgesteckte Ziele nicht erreicht und die Ergebnisse des Teams sind allenfalls mittelmäßig. 

Gleiches gilt für die Prioritäten im Team: Verfolgen einzelne Teammitglieder andere Prioritäten als die vereinbarten Prioritäten des Teams agieren sie als Einzelgänger*innen die vorrangig die eigenen Ziele verfolgen. Auch hier ist das Resultat im Ergebnis des Teams zu spüren. 

Auch Führungskräfte können aufkeimende Agilität und Selbstbestimmtheit bewusst oder unbewusst torpedieren. Fehlt zum Beispiel der klar gesteckte Rahmen, in dem das Team selbstbestimmt arbeiten und handeln kann oder wird wiederholt innerhalb des vermeintlich gesteckten Rahmens interveniert (z.B. durch das Überstimmen von Teamentscheidungen) so wirkt das sehr schnell demotivierend für die Teammitglieder.  

Gleiches gilt, wenn z.B. eine Rolle oder Funktion die früher bei der Führungskraft lag nun durch das Team übernommen wird. Erwartet die Führungskraft, dass die Funktion genauso ausgeübt wird, wie sie es früher gemacht hat (das Wie) und beschränkt sich nicht darauf qualitativ das gleiche Ergebnis zu erwarten (das Was), so kann auch dieses demotivierend wirken. 

Zu guter Letzt ist für mich aber das schlimmste Verhalten, welches aufkeimende Agilität mit an Sicherheit grenzender Wahrscheinlichkeit torpediert oder sogar verhindert, wenn Agilität von Führungskräften (oder auch von Kolleg*innen) belächelt wird, frei nach dem Motto: “Das ist was für euch, nicht für uns, wir müssen hier unseren Job machen.” 

Wie kann damit umgegangen werden? 

Eine gewisse Sicherheit kann dem experimentierenden Team gegeben werden, wenn ein gemeinsamer Rahmen zusammen mit der Führungskraft definiert wird. Das heißt, dass sowohl der Aufgabenbereich definiert sein sollte, in dem selbstbestimmt gehandelt wird, als auch die Art und Weise wie Entscheidungen getroffen werden sollen. Gute Erfahrungen mache ich hier derzeit beispielsweise mit einem Experiment-Steckbrief, der die folgenden Aspekte beschreibt: 

  • Ausgangssituation / Kontext (Warum braucht es das Experiment und in welchem Umfeld findet es statt?) 
  • Hypothese (Was glauben wir braucht es, damit es besser wird?) 
  • Beschreibung des Experiments (Was machen wir im Experiment und wie lange?) 
  • Erfolgsmessung (Woran sehen wir, dass es besser geworden ist?) 

Neben dem Experiment-Steckbrief lassen sich die Entscheidungsmechanismen sehr gut mit dem Delegation Poker aus den Management 3.0 Praktiken vereinbaren und dokumentieren. Dieses stellt für mich eine geeignete Methode dar, um unklare Entscheidungsbefugnisse zwischen einem Team und einer Führungskraft zu klären und zu dokumentieren. Das sehe ich als fortlaufenden, beiderseitigen Prozess an. 

Durch den gemeinsam vereinbarten Experiment-Steckbrief in Verbindung mit dem Delegation Board sollte ein klarer Rahmen gegeben sein, in dem experimentiert werden kann. Dennoch kann es weiterhin Einzelne im Team geben, die sich nicht auf das Experiment einlassen möchten. In diesem Fall würde ich den “Widerstand” als Geschenk betrachten und mit der Person im Einzelnen herausarbeiten, was sie braucht um sich auf das Vorgehen einzulassen. Diese genannten Aspekte helfen in der Regel dabei das Experiment robuster zu machen. Ist auch dieses nicht machbar, so würde ich die Vereinbarung treffen, dass die Person nicht am Experiment teilnehmen muss, es aber akzeptiert, dass die anderen es tun und diesem auch nicht entgegenwirkt. Spätestens bei der Auswertung der Learnings, so sollte die Vereinbarung sein, sollte die Person dann teilnehmen und die Ergebnisse betrachten. 

Ein derartiges Vorgehen hat außerdem einen weiteren Aspekt, welcher helfen kann das Agilität nicht torpediert wird: Es entsteht ein Vorbild im Führungskreis. Lässt eine Führungskraft dieses Vorgehen zu und vertraut dem Team, so kann diese Führungskraft später auch als Vorbild für andere dienen und die gewonnen Erfahrungen teilen. Das schafft wiederum Sicherheit im Führungskreis und erzeugt ggf. sogar Interesse ein ähnliches Vorgehen mit anderen Teams zu wiederholen. 

Sobald mehrere Teams in der Organisation derartig experimentieren ist es wichtig diese Teams miteinander zu vernetzen. Durch ein Netzwerk von gleichgesinnten willigen Menschen die sich austauschen und voneinander lernen wird eine Sicherheit geschaffen, welche notwendig ist um das fragile Gebilde des Experimentierens zu schützen. 

Mein aktuelles “Projekt” in diesem Kontext

Ich begleite derzeit ein Team dabei sich neu zu definieren da zwei Teams miteinander fusionieren und gleichzeitig die Führungskraft das Unternehmen verlassen hat (welches aber nicht im Zusammenhang stand 😊 ). Hier bediene ich mich bei den Ansätzen der Soziokratie 3.0 die mir im gleichnamigen Buch von Jeff Cumps und im Soziokratie Praxisleitfaden nähergebracht wurden. 

In einem gemeinsamen Workshop werden wir zu allererst einen Treiber für die Veränderung definieren, ich nenne das auch gerne “einen Strang, an dem wir gemeinsam ziehen können”. Hier fließen neben den Meinungen des Teams auch die Perspektiven der aktuellen Bereichsleitung sowie externe Perspektiven aus meinem Netzwerk mit ein.   

Das Prinzip der Teilautonomie hilft mir dabei, den Rahmen abzustecken, denn unter Teilautonomie verstehen wir einen klar umrissenen Teilbereich (= Domäne) welcher an eine Rolle oder ein Team delegiert werden kann. Die übergeordnete Verantwortung bleibt hier bei dem/der Delegator*in, die Verantwortung innerhalb der Domäne liegt so aber in dem Team oder der Rolle. So wird nicht nur Verantwortung, sondern auch Entscheidungskompetenz delegiert. Die Aufgaben des/der Delegator*in ist dabei sowohl die erforderlichen Ressourcen bereitzustellen als auch zu erläutern welchen Bedarf die Organisation hat, aus der die Domäne entstanden ist. Zusätzlich wird die Kernaufgabe definiert als auch Einschränkungen der Autonomie innerhalb der Domäne (beispielsweise durch Abhängigkeiten, Entscheidungseinflüsse durch die Delegator*in, vorgegebene Reportings, etc.) 

Diese Definitionen werden wir, sobald wir sie vereinbart haben, auf einem Canvas visualisieren und für uns sichtbar machen, so dass wir im Teamprozess regelmäßig reflektieren können, ob wir noch auf dem Weg sind, aber auch um nachschärfen zu können, sollten wir neue Erkenntnisse gewinnen. 

Ziel ist es den Prozess maximal transparent für alle Beteiligten zu gestalten und die Möglichkeit regelmäßig nachschärfen und adaptieren zu können, sollten wir zu neuen Erkenntnissen kommen oder sich das Umfeld verändern. Denn das ist es, wie oben beschrieben, was Agilität ausmacht. 

Weitere Maßnahmen die dabei helfen könnten aufkeimende Agilität zu erhalten
  • Schonungslos offenes Feedback im Veränderungsprozess etablieren 
  • Prinzipien statt Regeln definieren 
  • Fuck-Up Sessions, Fehler sind erlaubt und erwünscht 
  • Regelmäßige (neutral geführte) Retros 
  • Teamziele belohnen 
  • Verantwortung an Rollen delegieren statt an Personen 
  • Entscheidungen gemeinsam treffen (-> Konsent) 
  • Experimente offiziell machen 
  • Fokus erlauben / keine Doppelrolle außerhalb des agilen Teams