Scheitern auf Ansage – Szenen aus der agilen Transformation

In diesem Blogpost zeigen wir an verschiedenen Situationen (welche heutzutage leider noch viel zu häufig in der Realität vorkommen), warum Projekte scheitern oder eine agile Transformation fehlschlägt.
Wir merken immer häufiger, dass für eine „korrekte” (worüber sich vortrefflich streiten lässt) Umsetzung von agiler Entwicklung oder DevOps die Kultur des Managements und der Mitarbeiter entscheidend ist. Gerade in großen Unternehmen fällt das Mitnehmen und Motivieren der Mitarbeitenden eher zu knapp aus und so gibt es zwar immer wieder Initiativen zur Transformation des Unternehmens, aber diese verpuffen an der Einstellung der Belegschaft oder des Managements.

„Wir sind doch agil!”

Agil ist ein überstrapazierter Begriff geworden. In diesem Beitrag betrachten wir Agilität aus der Perspektive der Unternehmenskultur, welche durch die Mitarbeitenden gelebt werden muss. Diese Kultur muss von Vorgesetzten gelebt werden und die Transformation dahin ist mühevoll, denn es müssen alte Strukturen und Verhaltensweisen aufgebrochen werden.
Meist wird Agilität mit Scrum gleichgesetzt. Es wird angenommen, wenn Scrum praktiziert wird, ist agile Entwicklung automatisch vorprogrammiert. Nach Scrum zu arbeiten klingt dabei nach einer einfachen Aufgabe und dennoch passieren viele Fehler bei der Durchführung von Scrum in Bezug auf einge gute agile Praxis. Außerdem: Scrum muss dabei mitunter gar nicht so wichtig sein. Wichtiger ist es, Agilität in der Projektkultur zu leben.
Eine agile Kultur beinhaltet einen Fokus auf Transparenz über alle getroffenen Entscheidungen und eine Stärkung des Informationsflusses sowohl innerhalb des Teams als auch nach außen. So kann jedes Teammitglied maximal zum Erfolg des Projektes beitragen kann, indem es bei Planung, Design und Verbesserung des Projektes einbezogen wird. Agile Methoden sind Frameworks, um dies kontinuierlich und iterativ zu ermöglichen. Im Folgenden gehen wir auf häufige agile Anti-Patterns in Zusammenhang mit Scrum ein.

Das „Agile-Wasserfall“-Projekt: Häufig zu beobachten ist, dass agile Projekte ähnlich wie ein Wasserfall-Projekt am Anfang durchgeplant werden: ein Zeit- und Projektplan wird festgelegt und das Budget muss bestimmt werden. Für die einzelnen Features werden Deadlines bestimmt. Dann werden Requirements in User Stories verpackt und diese in einem großen Batch auf das Projekt losgelassen. Die User Stories sind im schlimmsten Fall von schlechter Qualität, z. B. weil sie viel zu groß geschnitten oder spezifiziert sind.
Features werden entwickelt, aber eine Validierung und ein Feedback durch die eigentlichen Endnutzer:innen findet, wenn überhaupt, viel zu spät statt. Das Projekt fällt immer weiter hinter den eigentlichen Plan zurück und scheitert letztlich an den gleichen Gründen wie frühere Wasserfall-Projekte: Der anvisierte Launch wird mehrmals verschoben und wenn dann endlich das Release da ist, fehlt die Nutzerakzeptanz. Ein Big Bang, wie er im Buche steht und ganz und gar nicht einer agilen Kultur entsprechend.

„Chef-Programmierer“ gibt die Richtung vor: Scrum wird als Vorwand genutzt, um Agilität vorzutäuschen. Das Pattern: Bspw. ein PO (z. B. ein früherer Projektleiter, nun umgeschult) gibt jedem einzelnen Teammitglied genau vor, welche Aufgaben es zu welchem Zeitpunkt zu erledigen hat. Scrum Tools und Meetings werden nur zum Micromanagement des Teams genutzt. Ein eigenständiges Arbeiten ist für das Team unmöglich. Prioritäten werden oft während des Sprints gewechselt, z. B. weil Features nicht nach maximalem Nutzen für das Produkt priorisiert werden, sondern nach politischen Aspekten (z. B. weil ein Feature für das nächste Release dem Kunden versprochen wurde). Als Konsequenz kommt es zu immer größeren Beeinflussungen des Teams durch den “Chef-Programmierer” bei eigentlich teaminternen Entscheidungen.
Scrum wurde nicht entwickelt, um Teams besser kontrollieren zu können. Es sollte klar sein, dass nicht jede:r alles wissen kann und daher eine Lösung im Team erarbeitet werden muss. Wenn alle im Team zusammenarbeiten und jeder einen guten Überblick über das Projekt und die zukünftige Entwicklung hat, kann vielleicht eine bessere Lösung gefunden werden.

Fehlender dedizierter Scrum Master: Gute Scrum Master sind teuer, aber wichtig. Es ist oft zu hören: „Dabei produzieren die doch nicht einmal Code!“ Als Schluss folgt: Dann kann doch auch einfach ein Teammitglied das Ganze übernehmen.
Es kommt dadurch häufig zu Frustration und Blockaden innerhalb des Teams, da z. B. Retrospektiven nicht oder schlecht durchgeführt werden oder kein dedizierter Mensch sich um die Beseitigung von Blockaden kümmert. Es folgt darauf eine sinkende Entwicklungsgeschwindigkeit und die vorher eingesparten Kosten sind dahin.
Hierfür gibt es nur eine Lösung: Setzt dedizierte Scrum Master ein. Sie sorgen für einen Schutz des Teams vor externer Beeinflussung, organisieren die Meetings und lösen interne Probleme. Das Team muss ungestört arbeiten können!

Zu große Teams: Teams sollten nicht zu groß sein, da sonst einige negative Effekte zu bemerken sind. Meetings ziehen sich aufgrund der Teilnehmerzahl in die Länge, Entscheidungsfindung wird aufgrund vieler zu berücksichtigender Parteien träger und es wird komplizierter, psychologische Sicherheit im Team aufrecht zu erhalten.
Der Wissenstransfer zwischen den einzelnen Teammitgliedern wird immer schwieriger. Außerdem verbringt das Team 30-50 % der Zeit des Sprints in Meetings, die Zeit für das Entwickeln wird immer knapper.
Bei großen Projekten wird für so ziemlich jede Entscheidung oder Blocker erstmal ein Meeting einberufen und am besten müssen immer alle mit dabei sein, es könnte ja jeden betreffen. Im schlimmsten Fall wird sich dadurch minutenlang angeschwiegen.
Teams sollten möglichst unabhängig miteinander agieren können und nicht zu groß sein. Es sollten ihre gemeinsamen Abhängigkeiten und Schnittstellen herausgefunden werden und sie sollten dem jeweiligen anderen Team ein „Produkt“ zur Verfügung stellen. Dies führt zu einer Entkopplung der einzelnen Teams und die Teams können wieder selbstbestimmt arbeiten. Größere Meetings zwischen den Teams sollten nur noch mit einzelnen „Abgesandten“ der jeweiligen Teams stattfinden. Hier hat sich auch das Pattern der Communities of Practice bewährt.

„Wir sind agil, wir machen doch DevOps!“

DevOps ist als Buzzword im Management angekommen. Dennoch werden fundamentale Konzepte von DevOps nicht oder nur teilweise umgesetzt. Wenn DevOps-Praktiken nicht funktionieren, ist dies auch häufig auf eine fehlende Anpassung der Gewohnheiten, Prozesse und Methoden durch Management und Mitarbeiter zurückzuführen.
Unter anderem werden Teams nicht dazu ermutigt, eine DevOps-Kultur zu leben. Stattdessen existieren weiterhin silo-artige, abgekapselte Abteilungen oder Teams mit unterschiedlichen Zuständigkeiten, Budgets und somit auch ganz eigenen politischen Zielen.
So wird z. B. fälschlicherweise DevOps nicht als Praxis, sondern als eine Abteilung innerhalb des Unternehmens etabliert. Ein DevOps-Team als Enabler innerhalb der Organisation wäre dabei keine schlechte Sache, doch stellt diese Abteilung in der Realität nicht Unterstützung für Teams, sondern ist verborgen hinter Beantragungen und langwierigen Prozessen. Das Team kommt nicht von den Zwängen der alten Plan-Build-Run-Kultur los. Um z. B. die dringend benötigte Build Pipeline zu bekommen, ist nicht etwa ein Klick innerhalb eines Tools nötig, sondern es müssen langwierige Anträge ausgefüllt und von mehreren übergeordneten Stellen abgesegnet werden, damit die Pipeline dann vom sogenannten DevOps-Team erstellt wird.
Diese Prozesse sind in Unternehmen über lange Zeit gewachsen, vielleicht aus guten Gründen. Dennoch hindern sie die Entwickler an einer effektiven Arbeit am Projekt. Das Credo muss sein: Alles und jeder im Unternehmen muss darauf hinarbeiten, dass die Entwickler effektiv und störungsfrei arbeiten können. Nur dann können sich Entwickler darauf konzentrieren, Werte für das Unternehmen zu schaffen, also z. B. das Produkt der Firma voran zu bringen. Für unser Beispiel könnte das also bedeuten, dass ein DevOps-Team eine funktionierende Self-Service-Plattform für CI/CD zur Verfügung stellt, mit der Projekte ohne großen Aufwand neue Build und Deployment Pipelines erstellen können. Sie fungieren selbst als Enabler-Team und schulen sowie supporten andere Teams, um ihre Plattform schnell in ihre Arbeit integrieren zu können.
Ein agile Kultur und eine funktionierende DevOps Praxis bilden eine starke Symbiose. So unterstützt DevOps das Entwickeln nach agilen Methoden enorm. Nur wenn Teams eigenständig und selbstbestimmt mit Ressourcen umgehen können, können sie auch schnell Features in Produktion bringen.

„Digitalisierungsprojekt XY hat höchste Prio!“

Fokus ist wichtig. Sehr oft erleben wir, dass Teams durch andere Aufgaben von ihrem eigentlichen Projekt abgehalten werden. Wie soll das wichtige Digitalisierungs-Projekt erfolgreich abgeschlossen werden, wenn Teammitglieder noch 50 % ihrer Zeit mit Firefighting für Altsysteme zubringen oder in sinnlose Meetings gezogen werden?
Ein gutes Management hält diesen Teammitgliedern den Rücken frei und propagiert die Projektziele, um alle Mitarbeitenden auf ein gemeinsames Ziel einzuschwören. Jedem Teammitglied sind die Ziele klar und Entscheidungen des Managements sind transparent. Nur dann werden die Teammitglieder effektiv und mit großer intrinsischer Motivation arbeiten.

„Ihr habt vor zwei Monaten gesagt, das braucht x Tage, nun macht mal!“

Zusätzlich geraten Teams in eine weitere Falle: Sie werden auf Zeiten und Budgets festgenagelt, die vor Monaten arbiträr festgelegt wurden, aber mit dem nun aktuellen Wissensstand absolut unhaltbar sind. Am Anfang des Projektes wurden viele technologische und architektonische Entscheidungen getroffen, die auf nun veralteten Annahmen basieren, wenn das Projekt ein oder zwei Monate läuft. Das Team versucht nun, diese Deadlines unbedingt zu halten, obwohl klar ist, dass diese nicht mehr zu halten sind: Die Motivation sinkt und der Glaube an den Erfolg geht verloren. Es sammeln sich Unmengen an Überstunden an und die technischen Schulden werden immer größer. Die Abwärtsspirale beginnt.
Wichtiger wäre es, Teams nicht an Deadlines und Budgets zu messen, die in den meisten Fällen nicht eingehalten werden können, sondern auf Basis von gelieferten Features. Einschneidende Entscheidungen sollten so spät wie möglich getroffen werden, um den Lösungsraum offen zu halten und dadurch so schnell wie möglich zu Ergebnissen zu kommen, die dann evaluiert und getestet werden können. Kleine, portionierte Entscheidungen sollten dagegen schnell getroffen werden, um schnell mittels Feedback validiert zu werden.

„Das ist doch alles Jugend forscht hier.“

Diese Aussage ist extrem und haben wir so schon öfter gehört. Sie ruft starke Verwunderung bei uns hervor. Für uns ist ein exploratives Vorgehen selbstverständlich und ein kontinuierliches Entwickeln von Hypothesen und deren Validierung durch Tests unabdingbar.
In der Realität sieht es oft so aus: Die genauen Anforderungen an das Produkt erscheinen klar. Also wird (nur ohne Lasten/Pflichtenheft) losgelegt und User Stories werden erstellt und ein Zeitplan ausgearbeitet. Beispielsweise werden dann Features aus den zu ersetzenden Altsystemen übernommen, die augenscheinlich unbedingt benötigt werden. Außerdem ist man sich einig, dass das Altsystem zwar gut war, aber nun mal durch etwas Besseres ersetzt werden muss. Man möchte von vornherein alles „richtig“ machen. Doch der Weg dahin ist oft unklar und wir stellen fest, dass die Kunden selbst nicht so genau wissen, welche Features wirklich den größten Business Value produzieren. Anstatt also bei Null anzufangen, wird meist ein kanonisches Datenmodell entwickelt (oder übernommen), die Architektur wird festgelegt und statt herauszufinden, womit in der Neuentwicklung der größte Wert geschaffen werden kann, wird ein großer Feature-Katalog abgearbeitet.
Das Gegenteil ist aber meistens der Fall und die Anforderungen sind alles andere als klar. Die Ziele werden dann meistens nicht erreicht, es entsteht ein immer größerer Verzug zu den Deadlines und die Endnutzer:innen werden nicht um Feedback gefragt. Die Motivation der Entwickler:innen bricht weg und niemand glaubt noch an den Erfolg des Projektes. Man befindet sich wieder in einer Abwärtsspirale und das Projekt wird früher oder später scheitern.
Ein exploratives Vorgehen kann dies verhindern, kommt aber nicht ohne vermeintliche Schmerzen. Denn es sieht am Anfang danach aus, als ob keine Erfolge zu verbuchen wären. Annahmen werden getroffen, es werden Features entwickelt und später wird viel wieder verworfen. Je früher jedoch Annahmen validiert oder invalidiert werden können, desto besser.
Es ist wichtig, von vornherein offen für Veränderung zu sein! Dies ist Teil einer agilen Kultur. Veränderung muss sich in der Architektur und der Implementierung der Software widerspiegeln. Es wird passieren, dass das Datenmodell sich nach jeder Iteration erneut ändert und der Code jedes mal stark refactored werden muss. Dennoch kann man durch solch ein Vorgehen die eigentlich wichtigen Features implementieren und erhält früh das nötige Feedback der Nutzer:innen. Es ist wichtig, den Erfolg des Teams nicht anhand von geschafften Deadlines zu messen, sondern anhand der getesteten und validierten Entscheidungen.

„Ja, wir wollen so schnell wie möglich produktiv gehen.“

Diese Aussage hören wir leider viel zu oft in Projekten, die meistens schon verzögert sind, z. B. aufgrund der oben bereits genannten Situationen. Das bedeutet manchmal, dass ein Projekt schon Monate oder Jahre hinter dem eigentlichen Zeitplan zurückliegt. Dennoch wurde während der Entwicklung noch nicht einmal erfolgreich auf Produktion ausgerollt.
Es muss eines deutlich gesagt werden: Wenn das Feature/Produkt nicht produktiv gegangen ist, wurde noch kein Wert geschaffen. Dennoch erleben wir es immer wieder, dass Teams weiter mit Feature Requests bombardiert werden: Der Fokus liegt nicht darauf, bestehende Features auf Produktion zu bringen und an Endnutzer:innen zu testen und Feedback einzuholen. Also wird weiter und weiter entwickelt, Geld verbrannt, und am Ende werden die Kunden vor vollendete Tatsachen gestellt. Wenn es überhaupt jemals zu einem Kontakt der Endnutzer:innen mit dem fertigen Produkt kommt.
Wenn es dann soweit ist, und es kann auf Produktion deployed werden, fehlt im Team das Wissen, welche firmenspezifische Compliance-Regeln und Prozesse eingehalten werden müssen, um überhaupt das neue „Cloud-native Digitalisierungsprojekt“ auf Produktion zu deployen. Beispielsweise werden Cloud-Teams als Enabler im Unternehmen eingesetzt (ähnlich wie zuvor beschrieben bei DevOps), um die jeweiligen großen Cloud-Anbieter innerhalb des Unternehmens einzuführen, aber später sind diese Teams entweder nicht dafür ausgelegt, andere Teams bei ihrem Weg zur Produktion zu unterstützen oder sind mit ihren Aufgaben völlig ausgelastet.
Wie schon bei dem schlecht durchgeführten DevOps mangelt es bei der fehlenden Produktionsreife wieder am Service-Gedanken gegenüber den Projekten. Weiterhin sollte es selbstverständlich für DevOps-praktizierende Teams sein, auch mehrmals täglich auf Produktion zu deployen. Nur so ist es möglich, einen kontinuierlichen Flow und Feedback zu erhalten.

TL;DR

Dieser Blogpost beleuchtete verschiedene Situationen und Szenarien, die in agilen Projekten vorkommen können und diese dann zum Scheitern verurteilen.
Fassen wir kurz zusammen:

• „Agilität“ ist oft eine leere Worthülse und zieht sich nicht durch die ganze Unternehmenskultur. Scrum wird eingeführt und mit agil gleichgesetzt. Ein kultureller Wandel findet nicht statt.
• DevOps-Praktiken sind wichtig, um agile Projekte zu ermöglichen, werden nicht richtig umgesetzt und versinken z. B. in einem Dschungel aus Anträgen und Berechtigungen.
• Teams können nicht selbstständig, unabhängig und fokussiert arbeiten.
• Kontinuierliches Lernen, Feedback und Verbessern findet nicht oder nur wenig statt.
• Es wird nur selten oder gar nicht auf Produktion deployed, Erfahrungen können nicht gesammelt werden und es kann nicht daraus gelernt werden. Es wurde dadurch auch kein Wert geschaffen.