Immer mehr Firmen haben den Trend der Zeit erkannt. In der heutigen komplexen Umwelt haben alte Hierarchien ausgedient. Agil ist angesagt. Nicht (nur), weil agil trendy ist. Agil ist erfolgreicher! Matrix strukturierte Organisationen, bis vor Kurzem noch das Mass aller Dinge, erweisen sich als Innovationsträge, schwerfällig und anpassungsunfähig. Lernende Organisation? Eher nicht. Und was tut deine Organisation? Unter Umständen sogar das Richtige. Sie stellt um auf agil, und plötzlich sprechen alle von Scrum und Holacracy. Wieso dieses gut gemeinte Unterfangen in den allermeisten Fällen grandios scheitert, erklärt der folgende Beitrag auf unserem dot.blog.
Die VUCA Welt mit ihren vielen Einflussvariablen, Unsicherheiten und schnellen Veränderungen, treibt die digitale Transformation von Wirtschaft und Gesellschaft gnadenlos voran. Survival of the fittest. Heisst: Die Anpassungsfähigen überleben. Die anderen bleiben auf der Strecke. Das gilt ganz besonders auch für die Grossen. Sogenannte Innovationsprojekte, welche vor der aufkommenden Konkurrenz aus dem Start-Up-Umfeld schützen sollen und nach dem Wasserfall-Prinzip geplant und implementiert werden, scheitern. Heute, aber eigentlich war dies auch schon früher so.
Früher hat dieses Scheitern einfach nicht dazu geführt, dass ganze Firmen aus dem Wettbewerb gedrängt wurden. Das haben die meisten erkannt und stellen ganz schnell und plötzlich auf agil um. Leider scheitert diese Umstellung in der Praxis im ersten Anlauf öfters, als sie gelingt. Doch wieso eigentlich? Ist Agilität für meine Organisation, mit ihrer ganz speziellen Kultur, in ihrer ganz speziellen Branche vielleicht doch nicht das Richtige? Doch! Es ist einfach die am meisten gehörte Entschuldigung, wieso es nicht gelingt. Aber nur, weil sie am meisten gehört ist, ist sie noch lange nicht richtig.
Auf der Ebene der root causes zeigen sich in unserer Erfahrung immer wieder die gleichen Gründe, wieso die agile Transformation scheitert. Die ganz spezifische Situation der Firma ist es nicht, so viel wissen wir schon jetzt. Doch was ist es dann? Ganz einfach: Die Nebenwirkungen der Pille "Agilität" wurden weder korrekt diagnostiziert noch richtig behandelt. Gestorben ist der Patient schlussendlich an diesen.
Die gute Nachricht ist: Auch ihr kriegt das hin! Nebenwirkungen lassen sich nämlich im Fall der Agilität erfolgreich behandeln. Im Folgenden werde ich beschreiben, worauf ihr achten müsst, damit dies gelingt (... ja, müsst!).
Grob gesagt lassen sich in der Praxis zwei Scheiter-Szenarien beobachten.
Organisationen führen zuerst in einer einzelnen Abteilung oder Division agile Arbeits- und Organisationsformen ein. Oder sagen wir es einmal so: Zumindest denken sie, dass sie das tun. Gut. Herzliche Gratulation! Ein erster Schritt in eine gute Richtung. Und was machen sie dann? Dasselbe wie immer. Teilprojekte heissen neu Sprints oder Iterationen, Meetings heissen Dailys und die Projektleitung heisst Scrum Master oder Product Owner.
Und geändert hat sich was? Genau! Nichts. Das realisieren natürlich auch die am Change Beteiligten und ziehen die einzig logische Schlussfolgerung: «Also so anders und innovativ wie alle immer behaupten, ist diese Agilität also auch nicht!». In ihrem Fall richtig. Und dennoch falsch. Aber das merkt ja niemand, weil auch niemand merkt, dass gar noch nie agil gearbeitet wurde.
Organisationen führen Scrum, Kanban, DevOps, SAFe, Holacracy, Sociocracy 3.0, ... mehr oder weniger korrekt ein, bleiben aber auf der reinen Methoden-Ebene. Nach einer gewissen Anfangseuphorie zeigen sich aber auch im Szenario B erste negative Emotionen bei den Beteiligten. Diese werden anfänglich noch akzeptiert und überhört. Mit Sätzen wie "Das gehört bei einer Umstellung halt dazu." redet man sich die Situation schön. Schuld, dass es nicht gelingt, sind meistens die anderen. Die Alt-Denkenden. Hmm... die Frustration erhöht sich weiter. Bei den Alt-Denkenden genauso wie bei den (Neu-)Alt-Denkenden.
Was folgt? Eine gewisse Enttäuschung und das ernüchternde (aber falsche) Fazit: Agilität funktioniert in unserer Firma, in unserer Branche, mit unserer Kultur und unseren Leuten leider nicht. Für die Googles und Facebooks mag das ja etwas Gutes sein, aber für uns? Bei uns geht das nicht. Auch das ist mit ganz grosser Wahrscheinlichkeit (Ausnahmen gibt es immer) falsch. Es kann tatsächlich funktionieren! Da sprechen wir als dot consulting AG nicht aus der Theorie, sondern aus der eigenen, gelebten Erfahrung.
Und nun. Wie weiter? Bei Szenario A ist die Antwort einfach: Stopp, Neustart und zwar diesmal methodisch korrekt! Mit einer sehr hohen Wahrscheinlichkeit landet ihr mit diesem Vorgehen dann direkt im Szenario B. Doch das ist normal. Nicht aufgeben! Es ging schon vielen anderen so. Auch für das Szenario B gibt es eine Lösung. Genauso wie Paare, die eine gleichberechtigte Ehe führen wollen, in eine Eheberatung gehen, gehen Organisationen, Teams und Individuen, die eine agile Kultur leben wollen, in eine Organisations- oder Führungsentwicklung oder in ein 1:1 Coaching. (Falls Du das einmal austesten willst, kannst Du Dich hier anmelden).
Doch nochmals etwas detaillierter. Die nachfolgenden vier Nebenwirkungen sind die Hauptgründe, weshalb deine Organisation ziemlich sicher im Szenario B gelandet ist, und entweder immer noch dort ist oder schon frustriert den Weg zurück zu Wasserfall und Matrix angetreten hat.
Doch was wollen wir eigentlich mit einer agilen Transformation bezwecken? Vielleicht ergibt es Sinn, dies an dieser Stelle ganz kurz zu erläutern. Die kurze Antwort: Anpassungsfähigkeit, schnelle Richtungswechsel und damit erfolgreiches Überleben in einer komplexen - also unserer aktuellen - Umwelt. Die etwas längere - aber noch nicht ganz lange - Antwort:
Eine methodisch korrekt lancierte agile Transformation berücksichtigt die oben genannten Punkte situativ durch die Wahl der jeweils richtigen Methode: Scrum, um schnell zu lernen, Holocracy, weil Hierarchien nichts mehr bringen und Design Thinking, weil der Kunde mitreden sollte. Zumindest wenn wir ihr oder ihm etwas verkaufen möchten. So viel haben heute fast alle verstanden. Was sie aber vergessen: Die Einführung der richtigen Methode ist nicht dasselbe wie die richtige Einführung der richtigen Methode! Und ist eine solche Methode einmal eingeführt, zeigen sich mit Sicherheit gravierende Nebenwirkungen, nicht nur, aber vor allem im Bereich der Zusammenarbeit. Wird dies nicht berücksichtigt, wird Ihre agile Transformation grandios scheitern.
In der Welt der Agilität ist oftmals die Rede von Rollen. Doch was ist das eigentlich?
Eine Rolle ist nichts anderes als ein (sich über die Zeit veränderndes) Bündel gegenseitiger Erwartungen. Im Fall der Arbeitswelt also: Ein Rollenempfänger (Arbeitnehmender) hat Erwartungen an seinen Job. Er will seine Stärken einbringen, gemäss seinen Werten leben, Spass haben, Unsicherheit vermeiden, Gemeinschaft leben, die menschlichen Grundbedürfnisse halt. Die Rollensenderin (die Organisation) will, dass das System erhalten bleibt, überlebt. Erfolgreich überlebt. Für das organisationale Überleben wichtige Aufgaben müssen also auf eine kulturkonforme Art und Weise ausgeführt werden.
In der alten Welt waren diese Erwartungen explizit und plus/minus klar. Meistens sind oder waren sie sogar niedergeschrieben. Die hierarchisch höher gestellte Führungskraft erstellte irgendwann einmal ein Jobprofil und die Arbeitnehmenden wussten, was ihre Rechte und Pflichten sind. Sie wussten aber auch ganz genau, was sie von ihren Führungskräften erwarten und fordern konnten. Was also nicht Teil ihrer Rolle war.
In der neuen Arbeitswelt haben agile Organisationen und solche, die sich auf dem Weg dort hin befinden, (zumindest in der Theorie) flache Hierarchien. Das zentrale Missverständnis in den Köpfen fast aller: Es gibt jetzt NICHT keine Führungskräfte mehr. Es ist genau umgekehrt! Es gibt nur noch Führungskräfte! Das ist ein kleiner, aber wichtiger Unterschied. Die logische Konsequenz: Erwartungen, Rechte und Pflichten müssen immer wieder geklärt und neu verhandelt werden. Das ist anstrengend und kann zur totalen Verwirrung führen. Viel schlimmer noch: Die wenigstens realisieren dies überhaupt! Sie sind in ihrer idiosynkratischen Weltsicht gefangen und gehen implizit davon aus, dass alle alles schon richtig verstanden haben. Dass die Erwartungen also klar sind.
Erwartungen sind aber nie einfach so klar. Wie auch? Sie wurden ja auch gar nie besprochen! Rollen können im Gespräch geklärt werden. In einem ersten Schritt empfehlen wir dazu ein 1:1 Coaching oder einen Workshop. Bspw. bei dot!
Maximale Selbstverantwortung heisst: Jede/r ist eine Führungskraft und NICHT jede/r ist ein/e Arbeitnehmer/in. In agilen Organisationen ist das so. Und das ist auch gut so, aber nur weil es gut ist, ist es noch lange nicht einfach.
Jede/r ist eine Führungskraft bedeutet einerseits, dass die Organisation auch jede und jeden zu dieser Selbstverantwortung ermächtigen muss. Voll und ganz. Die beteiligten Personen müssen das wollen (das kann man diagnostisch abklären), können (d.h. fachlich und auch technisch dazu befähigt sein; falls sie noch nicht dort sind, müssen sie in on und off the job Weiterbildungen dort hin entwickelt werden) und vor allem auch dürfen. Dürfen bedeutet: Keine Kontrolle von irgendwo oben (... oben gibt es nicht mehr).
Einfluss haben, in anderen Worten wirksam sein im eigenen Handeln. Das ist das Ziel.
Und verhandeln. Teilweise auch mit Konflikten. In einer komplexen Welt können wir nur zusammen etwas erreichen. Keine einzelne Person, egal wie intelligent und erfahren, kann das für heutige Lösungen relevante Wissen im eigenen Kopf und Herzen vereinen. Zur Teilung des Wissens müssen wir zwingend miteinander reden. Oft. Täglich. Mehrmals täglich! Es ist kein Zufall, dass Scrum Teams im selben Raum arbeiten, siehe auch im Blogbeitrag Das ideale Büro für ein Scrum-Team.
Mehr miteinander reden bedeutet aber auch mehr Potential für Missverständnisse, mehr Potential für Kränkungen, mehr Potential für Konflikt. Und den Umgang mit diesen herausfordernden Situationen kann man lernen. Genau wie Programmieren auch! Mit der richtigen Feedbacktechnik bspw., welche du bei uns lernen kannst. Dadurch wirst du befähigt, positive (Lob) und negative (Kritik) Nebeneffekte des Handelns anderer auf dich in einer Art und Weise zurückzumelden, dass sie von diesen anderen auch angenommen werden kann.
Die einen denken, man hat ein anfängliches Grundvertrauen, welches man sich verspielen kann; die anderen sind zuerst skeptisch und bauen Vertrauen mit der Zeit auf (... oder werden in ihrem Misstrauen bestärkt). Ganz egal, ob du zu den einen oder den anderen gehörst: Vertrauen ist nicht einfach immer da. Wie eine Pflanze muss es gepflegt werden.
Psychologische Sicherheit ist gemäss einer Studie von Google DER wichtigste Faktor für erfolgreiche Teamarbeit. Wichtiger als WER Teil des Teams ist! Psychologische Sicherheit bedeutet: Ich muss mich schwach zeigen können, zwischenmenschliche Risiken eingehen können, ohne verurteilt zu werden. Ich muss wissen, dass ich trotz Fehlern als Mensch im Kern genüge. Ohne diese Fähigkeit wird es nie, nie, nie eine echte Fehler- und Experimentierkultur geben. Und ohne eine echte Fehler- und Experimentierkultur wird es keinen schnellen und nachhaltigen Fortschritt geben. Also keine Agilität und keine Innovation.
Wie baut man Vertrauen auf? Bspw. indem man in Vorleistung geht und sich selbst einmal von seiner schwachen Seite zeigt. Das braucht Mut. Indem man nicht verurteilt. Das braucht Selbstreflektion. Auch das kann man lernen. Die Grundidee dazu im Buch von Brené Brown und die gelebte Praxis in einem Coaching bei dot.
Wir wünschen weiterhin eine gute (agile) Reise! Schiff ahoi.
Kostenloses Einzel-Coaching für Führungskräfte der Agile Transformation für mehr Erfolg.
Keine Kommentare bis jetzt
Lass uns wissen, was du darüber denkst.