Inhaltsverzeichnis
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?
Agile Transformation Herausforderungen: Handwerkliche Fehler
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.
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.
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.
Aber um ein Spiel mit genau diesen wenigen Mitteln erfolgreich zu gestalten, braucht es doch einiges mehr. 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.
Die häufigsten handwerklichen Fehler in agilen Transformationen
- Missachtung der Sprint Accuracy
- Scrum Master als Facilitator
- Custom agile Frameworks
- Nichtgebrauch agiler Techniken
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.
Die ganze Organisation wird dadurch nicht gerade prognosefähig und muss wieder auf alte Statusreports zurückgreifen, um überhaupt etwas Überblick über die Lieferfähigkeit zu gewinnen. Ganz schlecht.
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.
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.
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.
Das wären z.B.:
- Valuestream Mapping und das Bilden vertikalen Wertschöpfungseinheiten
- WSJF (weighted shortes job first) Priorisierung
- Design Thinking, Customer Journeys
- Agile Funding Prozesse (from Project to Product)
- Systematisches dezentralisieren von Entscheidungen
- Agile Contracting für die Zusammenarbeit mit Zulieferern
- Echtes Release on Demand inkl. der Schaffung einer BizDevOps(Sec)-Kultur
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.
P.S. Unsere Priorität ist es, das PI Planning Backlog übersichtlich und intuitiv zu halten – so kann deins mit scagile aussehen.
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:
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.
Fazit
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.
Was hat die Neuregelung des AÜG mit Scrum zu tun? Ich meine viel und möchte auf die neuen Herausforderungen, die sich daraus für die Planung von SCRUM Projekten in vielen Unternehmen ergeben in diesem Artikel eingehen.
Scrum vs. Wasserfall – Für alle Scrum Fans die schlechte Nachricht zuerst: Scrum ist nur ein Kompromiss. Die gute Nachricht, dies ist die einzige schlechte Nachricht..
Der Erfolg von agilen Projekten hängt mit der Kommunikation zusammen! Leonardo DiCaprio in seiner Rolle in ‚Inception‘ ist heute Ihr Scrum Coach und verdeutlicht, wie in Scrum erfolgreich kommuniziert werden kann. Klingt abenteuerlich? Ist es auch 🙂 Lesen Sie weiter…
