dot.coaching - Passt Agilität überhaupt zu uns? – Wenn Systeme (noch) nicht bereit sind
Immer wieder taucht im Beratungsalltag dieselbe Frage auf: "Passt Agilität überhaupt zu uns?" Eine Frage, die meist nicht an Methoden gerichtet ist – sondern an Haltung, Reifegrad und Veränderungsbereitschaft. In diesem Beitrag reflektieren wir, wie man sinnvoll mit dieser Frage umgeht – jenseits von Dogmen und Etiketten.
Agilität ist in aller Munde. Und je präsenter sie wird, desto öfter begegnet uns eine leise, aber zentrale Frage: Passt Agilität überhaupt zu uns? Oder was ist, wenn das Ideal nicht unserer Realität entspricht? Meist wird sie nicht laut ausgesprochen, sondern taucht zwischen den Zeilen auf: in Form von Widerstand, zögerlicher Umsetzung, festhalten an früheren Rollen, Frust über Rituale oder der Sehnsucht nach der guten alten Planungssicherheit. Der Reflex liegt nahe: mehr Schulung, klarere Regeln, sauberere Frameworks. Doch vielleicht lohnt es sich, die Frage und insbesondere die Sorgen dahinter ernst zu nehmen.
Zwischen Wunschbild und Wirklichkeit
In vielen Organisationen wurde und wird das Label Agilität vergeben, bevor irgendeine Veränderung überhaupt stattgefunden hat. Agilität ist ein kleines Projekt, vielleicht sogar ein Thema, das als Kulturinitiative vorangetrieben und wie jedes Projekt auch alsbald beendet wird. Teams werden kurzerhand als agile Teams, Scrum Team, high-performance Team, Stable Teams, stream-aligned Teams, SAFe-Team etc. bezeichnet, ein paar Zeremonien eingeführt – und fertig ist das agile Setup respktive der agile Salat. Dass diese Teams aber weiterhin in alten Strukturen, Matrixorganisationen und Projektlogiken verankert sind und klassischen Budgetprozessen resp. Milestones folgen müssen, wird ignoriert oder ausgeblendet. Wenn der erhoffte Mehrwert dann ausbleibt, lautet die Frage: Liegt es an der Agilität?
Hinzu kommt: In vielen Unternehmen wird das Budget nicht oder nie in der Form für die Linie gesprochen, wie es sinnvoll wäre, sondern projektweise. Für jedes Ding wird ein Projekt initiiert und verkannt, dass das eine die Form der Abwicklung ist und das andere die Frage der Finanzierung. So mutiert jedes Vorhaben zur offiziellen Veränderung – obwohl es faktisch nur darum geht, die Linie mit Geld zu versorgen damit technische oder organisatorische Schulden abgebaut werden können. Das Ergebnis: Es fühlt sich an, als wäre die ganze Organisation permanent im Change, dabei wird lediglich das Nötigste gepflegt. Echte Innovation bleibt auf der Strecke und insbesondere den agilen Vorhaben wird viel zu schnell die Budgetfrage gestellt.
Brauchen agile Vorhaben folglich länger?
Nicht unbedingt. Am Beispiel Scrum lässt sich das bildhaft erklären.
- Scrum in a Nutshell erkläre ich dir in zwei Stunden
- Die Scrum Master Schulung erhältst du in 2-3 Tagen
- Scrum eingeführt dauert etwa 2 Wochen.
- Um Scrum gelebt und erlebt zu haben benötigt schon 2 Monate (es braucht schon ein paar Sprints)
- Damit du den Kern von Scrum, die Prinzipien und Konzepte so richtig verinnerlicht hast, gebe ich dir 2 Jahre. Intensive Jahre voller Change, in Frage stellen der eigenen Rollen, der Methoden und Konzepte und 2 Jahre in denen du viele Fehler machen dürfen solltest, damit du lernen kannst.
Tja, und das liegt nicht wirklich daran, dass Scrum Komplex ist. Wie gesagt, die Basics hast du in 2 Stunden verstanden. Das, was Zeit braucht, sind du und ich. Wir müssen entlernen, loslassen, damit wir neu lernen können. Und das dauert seine Zeit. Je fester verankert dein früherer Arbeitsprozess war, je mehr du dich an die Kontrolle gewöhnt hast, desto länger dauert es, bis du und deine Umgebung den Umgang mit mehr Autonomie annehmen und in dem Sinne erlernen kannst.
Reifegrad statt Dogmatismus
Statt die Frage zu beantworten, ob Agilität überhaupt passt, lohnt es sich, die Organisation mit zwei Modellen zu spiegeln, um eine ersten Eindruck darüber zu gewinnen, wo wir gerade stehen:
- Variante 1) bilden die Entwicklungsstufen nach Haufe-Häusling, die uns reflektieren lassen, ob wir eher eine klassische Organisation sind und noch stark in Hierarchien und Kontrolle denken, oder bereits eine Experimentierphase gestartet hat in der einzelne Teams oder gar Bereiche agile Ansätze testen, oder ob sich bei uns schon eine Bewährungsphase zeigt in der ersten Ansätze sichtbar werden, wie wir gemeinsam lernen, vielleicht sind wir sogar schon in der Etablierungsphase und erweitern die agilen Konzepte über die ersten Teams und Abteilung hinaus bis hin zur Phase, die wir als lernende Organisation bezeichnen können in der die gesamte Organisation dank einem neuen (agilen) Mindset in einen kontinuierlichen Prozess steter, nachhaltiger Verbesserung gekommen ist.
- Variante 2) das Modell der Hero-, Prozess- und Agile-Organisation und veranschaulicht stark vereinfacht, dass es Organisationen gibt, die nur deshalb funktionieren, weil einzelne Personen sehr genau wissen wie gearbeitet wird, oder Organisationen die sehr methodisch vorgehen und fast alles über klar definierte und gesteuerte Prozesse abgewickelt wird und auch hier als dritte Alternative die Organisationen die bereits sehr agil unterwegs sind.
Beide Modelle laden nicht zur Bewertung ein, sondern zur Reflexion. Agilität ist kein Zustand, den man erreicht. Sie ist wie Gesundheit: Man merkt, wenn man sie nicht hat. Und sie hat gute und schlechte Tage. Wichtig ist nicht, ob man sie schon lebt – sondern ob man daran arbeitet, gesund zu bleiben.
Pragmatische Pfade statt Idealzustand
Viele Systeme und Organisationen sind (noch) nicht bereit für den agilen Idealzustand. Und die Frage "Was ist den der agile Idealzustand?" ist absolut berechtigt. Es gibt nicht den agilen Idealzustand, sondern jedes Unternehmen hat da seinen eigenen Weg, sein eigene Lösung. Es ist auch nicht immer so, dass wir den Fokus besonders auf das agile Mindset legen müssen und die Methoden schnell funktionieren. Ich hatte auch schon Organisationen begleiten dürfen, die aufgrund ihres starken wissenschaftlichen Hintergrunds überhaupt keine Probleme damit hatten, in kleinen Inkrementen zu denken oder gar mit Experimenten zu arbeiten. Dort war es eher so, dass ein stärkerer Fokus auf Prozesse und Prozessklarheit der richtige Hebel für eine nachhaltige Veränderung war. Es ist kein Makel, wenn eine Organisation den agilen Idealzustand noch nicht erreicht hat. Die Kunst liegt darin, stimmige Zwischenschritte zu gehen.
Wichtig: Manchmal soll es auch ganz einfach nicht sein. Manchmal funktioniert ein System schon sehr gut und die Einführung von agilen Ansätzen wäre eher dem Denkmodell "Solution looking for a Problem" geschuldet, den einem echten Bedürfnis nach Veränderung. Ich durfte auch schon Organisationen begleiten, die für mein Verständnis auch ohne irgend welche Labels schon sehr agil unterwegs waren. Kurzum, die wichtigstes Frage, wie immer, ist die nach dem Problem, dass wir lösen wollen.
Ich bin überzeugt davon, dass Change nur dann nachhaltig funktionieren kann, wenn die betroffenen Menschen den Change aktiv mit gestalten können. Dazu ist nicht immer ein grosses Change Vorhaben mit Schulungen und grossem Brimbamborium notwendig. Das kann durchaus auch ganz lean erreicht werden. Hier ein paar Beispiele aus der Praxis:
Falls du mehr zu den Hintergründen der hier beschriebenen Beispiele lesen möchtest, im Beitrag "Was tun, wenn das Ideal nicht passt?" gehe ich etwas detaillierter darauf ein.
- Kanban: Ein Scrum Team scheiterte immer wieder an der Planung der Sprints resp. dem Erreichen eines Sprintziels. Frust breitete sich aus, da das Team sich als unfähig verstanden fühlte, Scrum richtig zu praktizieren. Die Analyse der Arbeiten des Teams hat gezeigt, dass diese nicht wirklich sinnvoll in Sprints geplant werden kann und Scrum folglich der falsche Ansatz ist. Statt sofort mit komplexen Kanban-Boards, KPI's und WIP-Limits zu wirken, beginnen wir mit der Visualisierung des Workflows. Wenn das Board lebt, entstehen Fragen – und daraus ergibt sich der Wunsch nach Messung und Steuerung und die Menschen die so arbeiten verstehen automatisch, welche Konzepte und Ideen hinter den KPI's und WIP Limiten sind.
- Scrum: Ich bestehe auf fixe Sprintlängen, damit sich ein Rhythmus einprägt. Einem gemeinsamen Board, am liebsten physisch und den Zeremonien, die einen Sprint definieren. Aber ich zwinge niemanden, alle Rollen und Artefakte gleichzeitig auf. Rituale werden gelebt, wenn sie genutzt werden. Die Frage nach den cross-funktionalen Teams erfolgt aus der gemeinsamen Arbeit. Die Methoden des Schätzens, Messens und Reflektierens verändern sich über die Zeit automatisch, da das Team gemeinsam lernt. Einfach stur den Anleitungen eines Buchs zu folgen, hat noch nie wirklich nachhaltig geholfen.
- SAFe: Achtung, jetzt wird es vielleicht noch kontroverser. Nach dem Playbook von SAFe müssten ja alle zuerst in eine Schulung. Ich halte das in aller erster Linie für eine unglaublich clevere Idee, Geld zu machen und Verantwortung abzugeben. Geld, weil alle in die Schulung müssen. Easy Business. Verantwortung abgeben, weil der Kunde sofort in die Verantwortung genommen wird zu lernen. Grundsätzlich ist eine Schulung, je nach Lernformat, in den meisten Fällen nicht Lernen, sondern Wissensvermittlung. Das Lernen kommt erst über die Anwendung des neuen Wissens. Folglich beginne ich mit einem Workshop zur Visualisierung und Klärung der Abhängigkeiten der Arbeiten von mehreren Teams. Daraus ergibt sich der Wunsch nach gemeinsamer Planung und einer regelmässigeren Synchronisation. PI Planning wird dann eine logische Konsequenz.
Der entscheidende Hebel, damit ein Team in diesem Lernmodus kommen kann, liegt fast immer in der Entwicklung eines gemeinsamen Abstraktionsmodells: Welche Arten von Arbeiten haben wir? Wie priorisieren wir? Wer entscheidet worüber? Welche Artefakte helfen uns dabei? Dieses Modell ist oft die halbe Miete.
Widerstände anerkennen – nicht bekämpfen
Sobald sich agile Methoden etablieren, beginnen die angestossenen Veränderungen auch ausserhalb des Teams selbst zu wirken. Stabile Teams entwickeln Autonomie, sollen sie ja, sie sind ja schliesslich als Team für einen Teil der Wertschöpfung verantwortlich. Und genau an dieser Stelle kippt die Stimmung im Management oft: "Wie kann ich weiter als Führungskraft wirken, wenn mein Team so autonom ist?", "Braucht es mich überhaupt noch?" Die Antwort: Ja, aber anders. Manche nehmen diese Herausforderung an und entwickeln sich in Richtung Mentoring und Coaching. Andere verschärfen die Kontrolle. Beides ist menschlich. Und beides braucht Begleitung.
Auch Coaches sind nicht frei von emotionalen Reaktionen. Wenn Teams meine Rolle schneller übernehmen, als ich erwartet habe, löst das auch etwas bei mir aus - gar nicht selten einen inneren Widerstand - und ich muss mich fragen: Habe ich Zweifel, ob sie schon bereit sind – oder fällt mir das Loslassen schwer?
Reife erkennen
Es gibt ein paar Teams, die ich ca. jährlich besuche. Nicht um nochmals zu zeigen, was ich alles kann und weiss, sondern um auf Augenhöhe einen spannenden Austausch zu haben. Oft werde ich da überrascht über die Veränderungen. Eines dieser Teams hat vor kurzem das Thema Skalierung in Angriff genommen und für sich eine ganz spannenden und offensichtlich passende Lösung gefunden. Die steht in keinen Buch, funktioniert aber für dieses Team bestens. Ein gutes Zeichen für Reife ist folglich, wenn Zeremonien und Veränderungen auch dann stattfinden, wenn niemand zusieht. Wenn Teams sich gegenseitig zuhören, auch wenn sie unterschiedlich ticken. Wenn Verständnis wichtiger wird als das eigene Recht. Wenn Transparenz gelebt wird, nicht nur gezeigt. Wenn Wissen weitergegeben wird.
Prinzipien statt Werteposter
Agilität wird oft auch mit dem Thema Werte verknüpft. Das liegt auf der Hand, sind ja auch im Scrum Guide die fünf Wert von Scrum Offenheit, Mut, Respekt, Verpflichtung (Commitment) und Fokus ein zentraler Bestandteil.
Gleichwohl arbeite ich lieber mit Prinzipien als mit starren Werten. Prinzipien sind für mich Spannungsfelder wie wir sie aus dem agilen Manifest kennen: z. B. "auf Veränderung reagieren" und "einen Plan haben". Beides hat seinen Wert – doch das eine wiegt in der Praxis oft mehr als das andere. Prinzipien ermöglichen Entscheidungen mit Kontext. Starre Werte laden zu normativem Denken ein, Prinzipien zu reflektiertem Handeln.
Wenn ein Unternehmen folglich fragt: "Passt Agilität überhaupt zu uns?", liegt die Antwort nicht in Frameworks, Methoden oder Tools. Sie liegt in der Bereitschaft, sich ehrlich mit sich selbst zu beschäftigen. Mit den Widersprüchen. Den Zwischentönen. Den unausgesprochenen Fragen.
Wer in dieser Haltung unterwegs ist, muss Agilität nicht als Ziel begreifen – sondern als Weg, gemeinsam zu lernen. Schritt für Schritt.
Eventuell interessant
Verwandte Blogs

dot.tipp - Agilität im Alltag – Was tun, wenn das Ideal nicht passt?

dot.coaching - formale Argumente erkennen und richtig damit umgehen

Keine Kommentare
Teile deine Meinung