Wenn Agilität "hier" beginnt und nicht "wo anders"
Neue Projekte und organisatorische Veränderungen werden derzeit in Unternehmen gern zum Anlass genommen, agile Elemente einzuführen oder gleich eine agile Transformation auszurufen. Die Gründe für den Wunsch nach Agilität sind vielfältig: Time-to-Market verkürzen, Kundenzufriedenheit verbessern, anpassungsfähig an eine steigende Dynamik im globalen Markt werden, Mitarbeiter-Engagement steigern oder die Erwartungen und Anforderungen jüngerer Generationen besser erfüllen.
Doch auch wenn sich alle mit viel Elan in die Transformation hineinstürzen, wird es schnell zäher als erwartet. Woran liegt das eigentlich? Und wie kann man das verbessern?
Agilität einführen bedeutet Kulturänderung
Oft erleben wir Transformationsvorhaben, die wie folgt ablaufen: Das Management beschließt die Transformation und engagiert Berater, die ein Dokument ausarbeiten. Im Dokument werden alle Strukturen, Prozesse und Tools festgelegt; Produkte und Teams geschnitten; theoretische Grundlagen zusammengefasst; Werte beschrieben. Man bedient sich des agilen Werkzeugkastens, passt aber Rollen und Prozesse den gegebenen Besonderheiten des Unternehmens an. Nachdem das vollbracht ist, wird das Dokument publiziert. Flankiert von Postern, auf denen lockere Cartoons die Scrum-Rollen und agile Werte erklären, und einem Vorrat an bunten Klebezetteln wird damit den Mitarbeitern das neue agile Arbeitsmodell verkündet. Sie sind Kraft dessen "empowered", selbstorganisiert und haben alles, was sie brauchen.
Alles ist durchdacht und dokumentiert, es fehlt nur noch die Durchführung. Doch gerade die Durchführung entpuppt sich bei einer Transformation dann als lange Durststrecke. Es stellt sich dabei raus, dass es nicht ausreicht, eine Unterlage zu verstehen und neue Prozesse zu befolgen, um Dinge wie "Empowerment" umzusetzen. Denn "Empowerment" bedeutet, dass die Grenzen von Verantwortung und Vertrauen neu gezogen werden. Das ist leicht aufgeschrieben, betrifft aber tiefsitzende Gewohnheiten, zahlreiche implizite Annahmen und stille Vereinbarungen. Da diese Dinge über eine lange Zeit entstanden sind, braucht auch ihre Veränderung Zeit und einen gemeinsamen Lernprozess.
Der gemeinsame Lernprozess
Im Beispiel oben wird Agilität als etwas interpretiert, was auf Teamebene passiert. Die Teams erhalten den Auftrag, fortan "empowered" und selbstorganisiert zu sein. Aber ist es eine gute Idee, das Management hier außen vor zu lassen? Muss für "Empowerment" nicht auch jemand die dem Team aufgetragene Macht abgeben? Wenn das Management nur am Rande Gegenstand der Veränderung bleibt, bekommt "ich lasse euch die Freiheit" leicht den Anstrich "aber nur solange ihr das macht, was ich denke". Eine echte Verschiebung von Verantwortung kann man eigentlich nur gemeinsam lernen.
Der Versuch, die Transformation "upfront" zu designen hat zudem den Anspruch, alle Eventualitäten vorherzusehen und einzubeziehen. Doch selbst wenn man bestmöglich an alles gedacht hat, durchkreuzt einem die soziale Dynamik im gemeinsamen Lernprozess nahezu sicher jeden Plan. Aber das ist gar nicht schlimm: Beim gemeinsamen Lernen ist sowieso der Weg das Ziel. Das Vorgehen sollte daher so flexibel gestaltet werden, dass man Erkenntnisse sammeln und diese in das Vorhaben einfließen lassen kann.
Um nichts allzu falsch zu machen, gestaltet man sich schließlich noch mit Verweis auf die eigenen organisatorischen Besonderheiten den neuen Prozess so, dass er dem alten erkennbar ähnlich ist. Das passiert in der Regel sogar ganz von allein, ohne die explizite Absicht. Diese Präferenz von Sicherheit über Veränderung ist aber für Transformationsvorhaben nicht besonders hilfreich, ja geradezu widersinnig. Kleine Schritte mit greifbaren Ergebnissen, aber ohne Anspruch auf Perfektion, können hier Abhilfe schaffen. Nach jedem Schritt hat man die Möglichkeit zu reflektieren. Dieses "Inspect & Adapt" fördert Mut und einen konstruktiven Umgang mit Fehlern. Das mag sich ungewohnt anfühlen, ist aber für den gemeinsamen Lernprozess sinnvoller als ein starkes Sicherheitsgefühl.
Die Transformation agil denken
Warum eigentlich nicht die agile Transformation selbst als agiles Projekt betrachten? Man würde sich der gewünschten agilen Organisation in enger Zusammenarbeit iterativ und inkrementell nähern. Iterativ – das heißt schrittweise verbessernd mit der Gelegenheit, an Iterationsgrenzen gemeinsam zu reflektieren. Inkrementell – das heißt mit frühen kleinen Veränderungen, die sich nach und nach ergänzen, aber für sich genommen schon Vorteile und die Möglichkeit bieten, Erfahrungen damit zu sammeln.
Oder ist das ein Widerspruch, agil vorzugehen, wenn man noch gar nicht agil ist? "Wir können hier nicht agil werden, dazu fehlt das Mindset" ist dann die Begründung gegen die Anwendung agiler Methoden. Dieses beschworene "Mindset" stellt sich aber selten von selbst ein. Vielmehr hat man es hier mit einem Henne-Ei-Problem zu tun: Agiles Denken und agiles Handeln beeinflussen und fördert einander. Aber keines davon ist Voraussetzung für das andere. Und irgendwo muss man bei einer Transformation ja anfangen. Der Vorschlag, die agile Transformation agil zu führen, beantwortet die Frage nach diesem Ort mit "hier" statt mit "wo anders".
Das agile Transformationsteam
Um die Transformation agil zu gestalten, könnte man sich bei bewährten Mustern aus agilen Vorgehensmodellen bedienen und ein eigenes Team aufstellen, das die agile Zielorganisation als sein Produkt versteht.
Auch für die konkrete Ausgestaltung eines solchen Transformationsteams kann man auf Bewährtes aus der agilen Werkzeugkiste setzen:
- Das Team sollte cross-funktional sein. Für ein Transformationsteam bedeutet das, dass Wissen, Fähigkeiten und Entscheidungsbefugnisse abgedeckt sind, um agile Strukturen und Prozesse erarbeiten, beschließen, kommunizieren, einführen und begleiten zu können. Die genaue Zusammensetzung ist kontextabhängig, aber langjährige sowie junge Mitarbeiter, Entscheider, Prozessgestalter, Kommunikatoren und Experten für Agilität sind gute Kandidaten. Das Team sollte gut in der Organisation vernetzt sein, um die Vision der Transformation effektiv zu kommunizieren. Dazu bietet es sich an, ganz oder teilweise auf Freiwilligkeit zu setzen und auch unterschiedliche Hierarchiestufen einzubeziehen.
- Ein Product Owner sollte das Team fachlich führen. Es sollte jemand mit dem originären Bedürfnis nach der Transformation sein, der eine starke Vision vertreten und die fachlichen Anforderungen klar formulieren kann. In der Regel ist das jemand aus dem Senior-Management mit der Unterstützung des C-Levels.
- In einem Backlog sollten konkrete Transformationsmaßnahmen und ihr erwarteter Nutzen beschreiben und priorisiert werden. Im besten Fall verfasst der Product Owner das Backlog selbst, er musst es aber zumindest inhaltlich vollumfänglich vertreten können.
- Wie jedes agile Team sollte das Transformationsteam iterativ, inkrementell und transparent arbeiten. Dazu sollte es die typischen Methoden einsetzen, etwa Scrum und Kanban.
- Mitglieder des Teams benötigen, wie Produktentwicklungsteams auch, ausreichend Zeit, sich dem Thema zu widmen. Weder eine Produktentwicklung noch eine Transformation kann "nebenher" erledigt werden.
Anstatt alles auf einmal zu gestalten, kann sich das Transformationsteam in diesem Modell iterativ Ziele setzen und schon früh Ergebnisse erzielen. Es verordnet nicht in erster Linie anderen eine agile Arbeitsweise, sondern erlebt sie zunächst hautnah an sich selbst. Dadurch, dass das Team cross-funktional und cross-hierarchisch ist, durchbricht es Kommunikationsbarrieren und erhöht die Akzeptanz bei allen Betroffenen. Diese Pionierarbeit der agilen Transformation schafft zudem wertvolle Erfahrungen fürs weitere Vorgehen.
Hier kann es sich dann tatsächlich lohnen, Berater zu beauftragen. Aber eben nicht, um das Transformationsteam zu besetzen, sondern um dem Team als agiler Coach für methodischen Rat und eine externe Perspektive zur Seite zu stehen.
Bei den Werten ansetzen
Allein agile Methoden anzuwenden macht natürlich noch keine erfolgreiche Transformation aus. Für einen langfristigen Kulturwandel sollte man daher die Werte im Blick haben, die der Agilität zugrunde liegen und spannenderweise auch nach 20 Jahren noch Bestand haben [1]. Sie betonen:
- Individuen und Interaktionen mehr als Prozesse und Werkzeuge
- Ein funktionierendes Produkt mehr als umfassende Dokumentation
- Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
- Reagieren auf Veränderung mehr als das Befolgen eines Plans
Angewendet auf die Arbeit des Transformationsteams eröffnen sie eine interessante Perspektive. Sie können dem Transformationsteam als Wegweiser dienen, wenn es plant, handelt oder reflektiert.
Für Erfolgsfaktoren und Beispiele, wie eine Anwendung der Werte gelingen kann, haben wir unsere jüngeren Transformationsprojekte unter die Lupe genommen [2]. Am Anfang einer jeden Transformation aber steht noch ein weiter, wichtiger Schritt: Der erste.
