Die Einführung agiler Arbeitsmethoden ist eine riesige Aufgabe – es ist wie eine Veränderung der Kultur, wie Dinge erledigt werden.
Schlüsselpositionen wie Scrum Master und Product Owner brauchen Fähigkeiten und Erfahrung, um diesen Wandel anzuführen. Aber hier ist das Problem: Viele sind sich nicht bewusst, wie schwierig diese Veränderung sein kann, und unterschätzen sie daher erheblich.
Was sind also die häufigsten Herausforderungen und Fehler bei der agilen Transformation? Und welche Strategien können wir anwenden, um diese Umstellung effektiv zu bewältigen?
Produktentwicklung ist meist keine Wissenschaft, sondern es kommt auf gutes Handwerk an. Gleiches gilt für eine agile Transformation innerhalb produktentwickelnder Organisationen.
Und das ist hier in keinster Weise despektierlich gemeint, sondern ganz im Gegenteil.
Agile Transformation ist hands-on working und erfordert eine Reihe von Fähigkeiten aber auch Erfahrung der Protagonisten, allen voran Scrum Mastern, Product Ownern und agile Coaches.
In den vorhergehenden Artikeln dieser Reihe haben wir gesehen, dass eine agile Transformation nichts weniger ist als ein umfassender Kulturwandel, also viel mehr als nur eine leichte Umorganisation von Rollen, Events und Prozessen. Und selbst diese wären in einer Organisation nicht so leicht zu bewerkstelligen.
Kurz, eine agile Transformation ist eine äußerst komplexe Angelegenheit.
Organisationen tendieren leider oft dazu diese enorme Komplexität und den Impact auf die Unternehmenskultur zu unterschätzen.
Dies führt leider oft dazu, dass mit der agilen Transformation Akteure beauftragt werden, die für diese Rollen nicht hinreichend vorbereitet sind.
Das mag neben der häufigen Unterschätzung der Komplexität sicher auch an der Nichtverfügbarkeit von sehr qualifizierten Ressourcen liegen.
Zum Teil ist es aber auch ein hausgemachtes Problem, der agilen Industrie, die mit ihren Ausbildungsmodellen „Scrum Master in 3 Tagen“, oder „SAFe SPC in 5 Tagen“, den Organisationen suggerieren, man könne innerhalb weniger Tage und nach dem Lesen eines Buches und dem Bestehen eines Examens Experte auf diesem Gebiet werden und eine Organisation durch die Untiefen eines komplexen Kulturwandelprozesses führen.
Machen wir uns nichts vor, die agile Industrie hat hier ein Geschäftsmodell aufgebaut und ein Kurs „Scrum Master in 6 Monaten mit anschließendem zweijährigen Praktikum“ verkauft sich nicht gut und möchte auch niemand investieren. Obgleich eine schiefgelaufene agile Transformation um ein vielfaches teurer wird.
Da es sich hier eh um keine geschützten Berufsbezeichnungen handelt, kann sich faktisch jeder „agile Coach“ nennen.
Und da für diese Rollen aktuell sehr viel Geld bezahlt wird, machen das auch viele.
Ich möchte hier niemanden zu nahetreten, aber ich würde bei agilen Rollen eher den Vergleich zu Ärzten ziehen wollen, die nach ihrer Ausbildung noch einige Jahre – ich glaube es sind 5 – einen Facharzt machen müssen bevor sie sich niederlassen dürfen. Ich bin mir sicher, dies würde agilen Transformationen und den Organisationen, die sie durchführen auch sehr guttun.
Agile-by–the-book funktioniert in den meisten Fällen nun mal nicht, auch dann nicht (oder gerade), wenn das Buch nicht besonders dick ist, was zumindest bei Scrum der Fall ist.
Ich vergleiche daher agile Methoden gerne mit einem Schachspiel, um das zu verdeutlichen:
Man kann einem zehnjährigen die Schachregeln gut in ca. drei Stunden beibringen. Er wäre dann in der Lage, jeden Zug korrekt – sprich regelkonform – auszuführen. Weltmeister wird er damit aber nicht.
Natürlich ist die korrekte Ausführung der Züge eine Grundvoraussetzung, um überhaupt Schach zu spielen und diese erlernt sich recht schnell, denn es gibt nur wenige Figuren und jede hat ein klares Zugmuster.
Dabei ist die Komplexität einer agilen Transformation durchaus vergleichbar mit der eines Schachspiels.
Es gibt in vielen Situationen jeweils eine Reihe von Handlungsalternativen und es braucht oft erfahrene Coaches, den Impact jeder dieser Alternativen in der näheren Zukunft abschätzen zu können und den Zusammenhang innerhalb des Gesamt-Konstruktes der Organisation zu überblicken.
Das erfordert gleichermaßen Wissen und Erfahrung und die Fähigkeit, beides miteinander zu verknüpfen. Falsche Entscheidungen können mit hoher Geschwindigkeit einen großen negativen Impact erzeugen, also sehr schnell, ziemlich teuer werden.
Hier ein paar Beispiele für handwerkliche Fehler im Umgang mit der agilen Maschine:
Fehler 1 – Missachtung der Sprint Accuracy:
Agile Methodik führt ein anderes Zeitmodell ein:
Während im klassischen Projektmanagement, die Länge der Phasen sich nach den Inhalten richten, ist im agilen Kontext alles Timeboxed.
Im typischen Wasserfall ist die Spezifikationsphase abgeschlossen, wenn die Spec fertig ist, die Implementierungsphase ist abgeschlossen, wenn alles, was in der Spec steht, umgesetzt ist, etc.
In der agilen Welt hingegen erhält alles eine inhaltsunabhängige Timebox, Sprints erhalten eine Timebox, z.B. 2 Wochen, Daily’s 15 Min, Planning 1h, etc.
Damit gewinnt das KPI Sprint-Accuracy eine enorme Bedeutung, denn Teams sollen lernen, die Inhalte entsprechend der Timebox zu planen, sonst macht das Ganze überhaupt keinen Sinn.
Auf dieses KPI wird aber in sehr vielen Teams gar nicht referiert, Scrum Master arbeiten sehr oft mit ihren Teams gar nicht explizit daran, die Sprint Accuracy auf über 90% zu bringen.
Fehler 2 – Scrum Master als Facilitator:
Scrum Master sehen sich sehr oft als agile-Facilitator, also als Organisatoren und Moderatoren von agilen Events.
Dabei sollten sie eigentlich als Team-Coach das agile Mindset des Teams entwickeln, dafür eine Strategie entwerfen und die Teams unter Einsatz agiler Techniken und best practices trainieren.
Ich vergleiche das immer mit einem Trainer eines Fussballvereins, der sein Team nur zu den Spielen begleitet, aber nicht wirklich mit dem Team eine Strategie entwickelt und mit dem Team intensiv daran arbeitet, dass diese Strategie auf dem Platz in jedem Spiel (Sprint) auch von jedem umgesetzt wird.
Oft sieht man das in den Daily-Scrums, wo Scrum Master jeden einzeln nach seinem Beitrag fragt – wie in der Schule der Lehrer die Schüler nach ihren Hausaufgaben fragt.
Dabei zerfällt das Team wieder in ihre Einzelbestandteile und das Daily-Scrum wird zum Statusmeeting degradiert.
Fehler 3 – Custom agile Frameworks:
Organisationen adaptieren agile Frameworks nur soweit, wie es ihnen gefällt, aber nicht unbedingt soweit, wie es notwendig wäre. Das typische agile-Framework-cherry-picking.
Oft entwerfen sie dann ihr eigenes Framework, und reden sich das damit schön, dass die Frameworks nicht vollständig zu ihnen passen, weil ihr Unternehmen dann doch sehr speziell ist.
In Wahrheit scheuen sie aber eine agile Transformation in letzter Konsequenz und wollen sich eine Hintertür offenhalten, d.h. sie nehmen sich einige agile Praktiken, die sie ganz nett finden und die ihnen nicht wehtun und lassen oft die weg, die ein echtes agiles Mindset fördern würde, wo aber auch das Management komplett mitziehen müsste.
Manchmal ist es auch umgekehrt, dass das Management genau das will, aber es in den Abteilungen gar nicht durchgesetzt bekommt.
So oder so, ich habe z.B. in all den großen Organisationen (eCommerce, Transport, Banken, Versicherungen, Energie, Manufacturing, Automotiv) in denen ich als agile Coach tätig war, noch keine gesehen, die mit SAFe nicht hätten arbeiten können, jede hatte aber anfangs irgendwelche Ausreden, es nicht tun zu müssen.
Fehler 4 – Nichtgebrauch agiler Techniken:
Neben den agilen Frameworks gibt es sehr viele agile Techniken, welche die agile Transformation unterstützen und welche für das große Ziel „Business Agility“ in die Organisation zu bringen, nahezu unablässig sind.
Ich habe gleichzeitig aber nicht viele Organisationen und auch nicht viele agile Coaches gesehen, die davon konsequent Gebrauch gemacht haben, bzw. das in die täglichen Abläufe der Organisationen integriert haben.
Die meisten Organisationen bleiben dann doch bei dem kleinen Besteck, bestehend aus ein paar Rollen, Artefakten und Events und feiern sich schon, wenn sie Jira dazu bekommen haben, ein PI-Planning zu unterstützen und mit den Teams ein paar Healthchecks einigermaßen regelmäßig durchzuführen.
Um solche Fehler zu vermeiden bzw. den agile Trasformation Challenges zu begegnen, braucht es eine gute agile Transformation Strategie
Diese versteht eine agile Transformation nicht als einen natürlichen Evolutionsprozess, sondern als eine bewusste, strategische Entscheidung für einen top-down initiierten und gesteuerten Kulturwandelprozess.
Das klingt leider wenig romantisch und etwas hart und nüchtern, aber genauso sollte man die Sache angehen und der Realität ins Auge blicken.
Die Roadmap für die Entwicklung und Umsetzung einer solchen agile Transformation Strategie könnte ungefähr folgendermaßen aussehen. SAFe hat beispielsweise eine solche Roadmap veröffentlicht, die durchaus Sinn macht und adaptiert werden könnte. Hier eine etwas vereinfachte Form als weiteres Beispiel bzw. aus einer etwas anderen Perspektive. Ziel unseres Vorschlages ist, die in dieser Artikelreihe behandelten Agile-Transformation-Fails zu vermeiden oder positiver ausgedrückt, die agile Transformation Challenges von vornherein zu adressieren:
Beantworten Sie die Frage, welcher Teil Ihrer Organisation transformiert werden soll und warum und welcher Teil „lean“ und traditionell hierarchisch bleibt. Zur Erinnerung, agil werden sollten insbesondere die Einheiten, die direkt Business Value produzieren, also Wertschöpfung betreiben. Das sind wesentlich alle Bereiche, die direkt mit Produktentwicklung zu tun haben. HR, Verwaltung, strategisches Management muss das nicht notwendigerweise. Aber sie sind natürlich auch involviert und müssen in ihren Prozessen darauf Rücksicht nehmen (z.B. agile Funding, agile HR, etc.). (siehe SAFe Dual Operation System)
Machen Sie ein Value-Stream Mapping. Value Streams sind die Folge von Aktivitäten, die letztlich Business Value zu Ihren Kunden bringt. Machen Sie das für Operational Value Streams (Business) und Development Value Streams (die Systeme, die sie brauchen, um das Business zu machen). So lernen sie Ihre Organisation aus der Perspektive der Wertschöpfung neu oder besser kennen und sie führen gleich die Perspektive der Wertschöpfung in Ihre grundlegende Betrachtungsweise ein. Darnach wird es leichter zu argumentieren, was es braucht, um bessere Wertschöpfung zu betreiben.
Setzen Sie sich für die agile Transformation klare Ziele, die sie auch mit KPIs belegen. OKRs sind beispielsweise recht beliebt geworden und sie sind kein Widerspruch zu einer agilen Transformation, sondern können durchaus hilfreich sein. Sie sollten nur nicht dazu führen, dass die Teams eine doppelte Agenda haben, OKRs und die Features/Epics, die sie entwickeln sollen. Klare Ziele dienen dazu, den Bezugsrahmen für alle transparent zu halten, sie sollen nicht Druck erzeugen, sondern Orientierung geben. Und vergessen Sie nicht, dass agile Transformationen eine große Investition sind. Stellen Sie ausreichend Mittel und Ressourcen bereit.
Bereiten Sie dann die Menschen in Ihrer Organisation auf die Transformation vor. Zuerst brauchen Sie agile Leader, SAFe nennt das ein LACE Team. Vergessen Sie nicht, eine agile Transformation ist top-down, Sie brauchen also Leute, die das initiieren und vorantreiben. Diese müssen extrem gut ausgebildet sein. Anschließend sollten alle Menschen in Ihrer Organisation, die von der Transformation betroffen sind, gut vorbereitet werden. Achten Sie dabei darauf, dass sie den Menschen nicht das Gefühl geben, dass die Transformation nötig ist, weil sie vorher irgendwas nicht gut gemacht haben. Die Leute haben bisher einen hervorragenden Job gemacht, sie sind bereit, das nächste Level zu erreichen und noch mehr zum Erfolg des Unternehmens beitragen.
Starten sie die Transformation zügig und zunächst in ausgewählten Bereichen. Setzen Sie dabei entsprechend Ihrer agile Transformation Strategie gezielt agile Techniken ein. Nicht einfach nur Scrum oder Kanban, sondern auch Techniken wie Design Thinking, Agile Funding, WSJF-Priorisierung, PI-Planning, CI/CD für eine BizDevOps Kultur bis hin zu Release on Demand, etc. Sie müssen es nicht groß machen, aber möglichst vollständig. Sie müssen dabei einige Dinge einfach mal ausprobieren. Bleiben Sie hartnäckig, nicht alles wird sofort gut gelingen, vieles braucht einfach etwas Zeit zur Gewöhnung. Wenn Sie abnehmen wollen und Ihren Ernährungsplan umstellen, brauchen Sie auch mindestens 6 Wochen, damit Ihr Körper sich daran gewöhnt. Für einzelne agile Praktiken sollten Sie sich mindestens die gleiche Zeit geben, eher noch etwas mehr.
Lernen Sie in dieser Phase aus Erfolgen. D.h. machen sie kleine und einfache Schritte. Sie müssen den Menschen Erfolgserlebnisse verschaffen. Feiern Sie die Erfolge ausgiebig. Nur so entsteht nach und nach ein agiles Mindset. Lassen Sie sich von Misserfolgen nicht entmutigen, aber reden Sie sie auch nicht schön. Ändern Sie vielleicht einfach mal die Strategie, um in noch kleineren Schritten wieder Erfolge zu feiern. Eine agile Transformation ist Detailarbeit.
Agile Transformationen sind sehr komplexe und langwierige Angelegenheiten, weit mehr als bloß das Umorganisieren einer Matrixorganisation in end-to-end Feature Teams.
Es braucht sehr viel Wissen und Erfahrung, um agile Methodik in eine Organisation einzuführen.
Organisationen unterschätzen häufig die Komplexität und auch den Schwierigkeitsgrad einer solchen Transformation.
Oft werden aufgrund dessen die Akteure nicht optimal auf ihre Rollen vorbereitet und das führt zu handwerklichen Fehlern, die eine agile Transformation irgendwo auf der Oberfläche einer Organisation einfriert, aber keine nachhaltige Tiefenwirkung im Sinne eines echten Kulturwandels entfaltet.
Oft wird auch viel zu viel herumtheoretisiert und das handwerkliche Niveau der Transformation, also die Qualität, mit der Akteure in der Organisation hands-on wirken ist zu oft zu niedrig.
Bitte nicht falsch verstehen, Fehler passieren überall. Aber wenn flächendeckend zu wenig Expertise vorhanden ist, zu viele Akteure die Techniken agiler Praxis gar nicht kennen oder nicht wissen mit ihnen umzugehen, dann hat es eine agile Transformation sehr schwer die Wirkung zu erzielen, die sich eine Organisation erhofft.
Am besten Sie erstellen eine agile Transformation Strategie zusammen mit Experten und adressieren dort klar und transparent alle Punkte, die Ihnen wichtig- und für eine erfolgreiche Transformation notwendig sind.
Mit dem WSJF Excel Template wird die agile Projektpriorisierung so einfach wie nie! Lernen Sie hier wie es funktioniert und laden Sie sich das kostenlose Template herunter.
Mit der WSJF Methode werden PI Plannings zum Kinderspiel und effektiver als je zuvor. Hier geht’s zum kostenlosen Step-by-Step Guide und WSJF Excel Template
Was ist der Unterschied zwischen einer vertikalen und horizontalen Organisation und wie bildet man eine vertikale Organisationsstruktur? Roadmap für agile Transformation + Case Study
Für Scaled Agile Organisationen kann es frustriererend sein, wenn Projektmanagement Tools ihre Prozesse nicht unterstützen.
Daher haben wir scagile als eine App entwickelt, die aktiv agile Best-Practices fördert und mit der ein Value Flow über die gesamte Organisation hinweg etabliert wird.
