Kaum ein Unternehmen verzichtet heute darauf, agile Methoden auszuprobieren. Ob Vendor Management, regulierte Industrie oder eine Bank, fast überall geht es inzwischen darum, agil zu handeln oder sich agil aufzustellen. Am häufigsten setzen die Teams auf Scrum, danach folgen Kanban, DevOps sowie Lean und Design Thinking. Das zahlt sich aus. Wer sich agil neu erfindet, bekommt meist mehr raus, als er oder sie vorher reingesteckt hat. 89 Prozent der Teams, die agile Methoden nutzen, erzielen Ergebnisse, die den Aufwand rechtfertigen. Sie liefern ihre Projekte schneller ab, machen dabei weniger Fehler und gehen seltener Risiken ein, wie die Hochschule Koblenz in einer Studie mit mehr als 600 Teilnehmenden aus 20 Ländern zeigt (Komus et al., 2020). Trotz dieser guten Erfahrungen kommen Unternehmen aber nicht immer zum gleichen Ziel, obwohl sie von sich sagen, den gleichen Aufwand zu betreiben. Einige meinen, die Erfolgswahrscheinlichkeit gleiche einem Münzwurf. Wie kann das sein?
Agil handeln versus agil sein
Auch wenn es agile Methoden heißt, ist Agilität keine Methode. Es ist auch kein Werkzeug, um bessere Software zu schreiben oder ein Framework, das jeder lernen und anwenden kann, wie die Regeln eines Spiels. Vielmehr setzt sich Agilität aus verschiedenen Werten und Prinzipien zusammen, oder kurz: aus Glaubenssätzen, um besser zu entscheiden und schneller zu einem Ergebnis zu kommen. Das agile Manifest (Beck et al., 2001) nennt vier dieser Glaubenssätze, an denen sich z. B. Scrum, Kanban & Co. orientieren:
1. Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
2. Funktionsfähige Produkte sind wichtiger als umfassende Dokumentationen.
3. Zusammenarbeit mit Kunden ist wichtiger als Vertragsverhandlung.
4. Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans.
Wer diese Glaubenssätze liest, fragt sich häufig, wie er oder sie jetzt danach handeln soll, um agil zu sein. Gerade Neulinge auf diesem Gebiet wissen nicht gleich, wo sie starten sollen, und suchen deshalb zunächst nach agilen Werkzeugen, nach etwas, das sich sofort anwenden lässt und von anderen wahrgenommen wird. Simon Powers (2006) nennt das die agile Zwiebel (agile onion) in deren Kern bewährte Werkzeuge und Techniken für agiles Arbeiten stecken (vgl. Abbildung 1). Dazu gehören beispielsweise Daily Meetings, Retrospektiven und Story Points. Doch genau wie ein Hammer niemanden zum Handwerker macht, machen agile Techniken allein niemanden zum Pionier für Agilität. Wichtiger noch als die Werkzeuge, die für jeden sichtbar sind, weil sie offensichtlich etwas an der Art zu arbeiten verändern, sind die zu verinnerlichenden Werte. Sie lassen sich weniger leicht erkennen, sind es aber, die erst zu den gewünschten Ergebnissen im Unternehmen führen. Menschen verständigen sich am besten über Werte, nicht über Abläufe, denn das macht sie nahezu beliebig austauschbar – und verhindert Spitzenleistungen. Grund dafür ist einer der wichtigsten Werte im Arbeitsleben: Vertrauen zwischen Menschen. Genau das aber geht verloren, wenn Menschen nur noch in einen vorher festgelegten Ablauf vertrauen, statt sich gegenseitig Vertrauen zu schenken. Mit dem Vertrauen verlagert sich zudem auch die Verantwortung auf den Prozess, weil das Individuum nicht mehr selbst zu entscheiden braucht, was zu tun ist. Das verstößt nicht nur gegen die agilen Glaubenssätze, sondern erfüllt gleich zwei von fünf Kriterien, die Patrick Lencioni identifiziert hat, warum Teams scheitern (Lencioni, 2002). Die weiteren drei sind, neben fehlendem Vertrauen und fehlender Verantwortung, die Angst vor Konflikt, fehlende Verbindlichkeit (Commitment) und Unaufmerksamkeit gegenüber den Resultaten. Deshalb dürfen flache Hierarchien und kleine Teams, die selbst verantwortlich sind und entscheiden sollen, nicht nur Lippenbekenntnisse bleiben. Beides leitet sich unmittelbar aus dem agilen Mindset ab (vgl. Hofert, 2018, S. 20ff.). Der Personaldienstleister Hays hat festgestellt, dass agile Teams nicht nur besser entscheiden und Prioritäten richtig setzen, sondern auch die Beteiligten besser einbinden und sich viel stärker an dem orientieren, was Kund*innen sich wünschen (Hays 2015, S. 16). Aktuellere Studien kommen zu ähnlichen, wenn auch weniger detailliert aufgeschlüsselten Ergebnissen. Was sie alle gemeinsam haben: Sie beziehen sich auf Organisationen, die agile Glaubenssätze bereits verinnerlicht haben.
Ansonsten würden die Führungskräfte nicht entlastet, sondern wären damit beschäftigt, agile Werkzeuge einzuführen und ihr Team zwar mit anderen Methoden zu steuern, aber eben doch immer noch zu steuern. An genau dieser Schwelle stehen viele Unternehmen. Sie führen agile Werkzeuge ein und trainieren sich an, danach zu handeln. Doch agile Glaubenssätze tatsächlich zu verinnerlichen und dafür zu sorgen, dass sich die Teams wirklich selbst verantwortlich fühlen, sie zu ermutigen, selbst zu entscheiden, das ist für viele noch ein weiter Weg (vgl. Lasnia & Nowotny, 2018, S. 41ff. und S. 82f.). Dafür müssen sich Unternehmen in Teilen neu erfinden. Wenn man so will, geht es darum, den Sprung aus dem Kern der Zwiebel (vgl. Abbildung 1) in die äußeren Schalen zu schaffen. Dorthin, wo die agile Organisation anfängt, sich zu verselbständigen. Daran, an dem letzten Quäntchen Mut, scheitert manch agile Transformation.
Neun Irrtümer im agilen Alltag
Wie schmal der Grat zwischen gerade noch klassisch und gerade eben schon agil sein kann, sollen die folgenden Beispiele aus der Praxis zeigen. Wer regelmäßig in agilen Teams oder in Teams arbeitet, die es noch werden wollen, dürfte sich hier wiederfinden.
1. Wir sind jetzt agil. Wir machen Dailys. Darin stecken gleich zwei falsche Annahmen. Die Aussage ersetzt nur eine Methode durch eine andere. Über den Individuen stehen, anders als das agile Mindset vorschlägt, weiterhin Prozesse. Wer so spricht, befindet sich tief im Innern der agilen Zwiebel und vermutet wohl, dass sich durch die agilen Werkzeuge automatisch ein besseres Ergebnis einstellt. Daraus ergibt sich eine mögliche Gefahr: Cherry Picking, also sich aus klassischen und agilen Methoden das auszusuchen, was dem Entscheider gerade nützt. Dann fühlt es sich für die Mitarbeitenden so an, als wäre Agile nur eine zusätzliche Belastung, weil das Daily eben täglich stattfindet, statt des vormals wöchentlichen Jour Fixes. Praktisch heißt das, es geht so weiter wie bisher. Das Unternehmen gewinnt dadurch nichts, denn: «A fool with a tool is still a fool» (Ron Weinstein). Scrum, aus dessen Baukasten das Daily stammt (vgl. Abbildung 2), ist eine Heuristik. Sie bedient sich der agilen Glaubenssätze, um hochkomplexe Probleme zu lösen, die sich nur schwer beschreiben und deshalb schwer in die klassische Wasserfallplanung übersetzen lassen. Die Dailys dienen dazu, sich gegenseitig auf den aktuellen Stand zu bringen und zu besprechen, wer was als nächstes tut – sie sind nur ein kleiner Ausschnitt dessen, was in einem normalen Scrum Cycle alles passiert.
2. Wir brauchen keinen Plan. Wir sind agil. Agil sein, heißt nicht, auf einen Plan ganz zu verzichten. Wer so vorgeht, lässt seine agilen Teams nackt im Wind stehen. Zwar brauchen die Kolleg*innen keinen bis zur Abnahme getakteten Plan. Wohl aber eine Idee, Vision oder Zielvorgabe, worauf das agile Projekt hinlaufen soll. Dazu gehört auch, Pläne zu schmieden, und zwar kontinuierlich, kleinteilig und innerhalb des Teams. Von außen muss deshalb das Warum oder das Was kommen sowie Grundvertrauen darin, dass sich ein agiles Team selbst organisiert (vgl. Triest & Arend, 2019, S. 157ff.) und aufgabenbezogen Pläne fasst.
3. Ich entscheide nichts. Auch nicht der Product Owner. Viele Unternehmen trauen sich nicht oder nur zaghaft, Verantwortung an den Product Owner eines agilen Teams abzugeben. Wenn es wirklich wichtig wird, sollen immer noch Gremien entscheiden oder diejenigen, die vor einer agilen Transformation schon auf den richtigen Stühlen saßen. Das geht fast immer schief, weil sich ein Product Owner dann verhält wie jemand, der ein Projekt leitet – und so zum Spielball der Geschäftsleitung verkommt. Tatsächlich sollen Product Owner aber die einzigen sein, die ins Team kommunizieren und Anforderungen formulieren. Ihre Aufgabe ist es, Bedürfnisse innerhalb der Organisation zu erkennen und zu priorisieren. Wo das nicht passiert, sollten die Unternehmen ihre agilen Rollen klären (vgl. ebd. S. 105ff., 159ff. und Schmiedlinger, Rasche, Thonfeld & Tuchen, 2021, S. 53ff., insb. S. 60–63).
4. Wer zum Teufel hat das verbockt? Das ist eine gefährliche Frage, weil sie nach Schuldigen sucht, statt zu betonen, was das Team aus einem Fehler gelernt hat. Fehler zu machen, ist in der agilen DNA fest verankert, weil es darum geht, sich einem großen Problem in kleinen Schritten zu nähern und ständig zu schauen, was funktioniert und was nicht. Dahinter steckt ein völlig anderes Menschenbild als jenes der industriellen Revolution, die Arbeitsteilung, Planung und möglichst wenig Irritationen als ideal betrachtet (Taylorismus). Agile Teams gehen von einer systemisch-konstruktiven Haltung aus: «Jeder Mensch handelt aus seiner Sicht im jeweiligen Augenblick und Kontext sinnvoll» (Oestereich & Schröder, 2019, S. 18). Mit dem Finger auf jemanden zu zeigen, untergräbt dieses Ideal und unterminiert den freien Fluss der Ideen in Teams, weil jeder damit rechnen muss, an den Pranger gestellt zu werden.
5. Unsere Kundenberater*innen wissen am besten, was die Kund*innen wollen. Hinter dieser häufig getroffenen Fehlannahme steckt die Idee, dass Mitarbeitende und Kund*innen gleich oder zumindest äquivalent handeln und denken. Was wir gut finden, finden sie auch gut. Wer aber auf unterstellten Wünschen beginnt, ein Projekt durchzuführen, riskiert viel. Schlauer ist es, ständig zu validieren, ob das, was das eigene Unternehmen gerade entwickelt, dem entspricht, was der Markt will. Immerhin basiert das gesamte agile Mindset darauf, die Welt als ständig in Bewegung wahrzunehmen. Diese Bewegung aber können Mitarbeitende erfahrungsgemäß nicht simulieren, weil sie sich permanent mit ihrem eigenen Anschauungsobjekt – dem neuen Produkt oder dem nächsten Update – auseinandersetzen. Kund*innen dagegen beschäftigen sich damit nur genau in dem Augenblick, in dem sie ein Angebot nutzen. Darum gilt: So früh wie möglich die Zielgruppe um Rat fragen und sie dauerhaft einbinden.
6. Wir bauen den goldenen Henkel schon im MVP. Ein MVP – Minimal Viable Product – ist das am ehesten lauffähige Produkt und darum notwendigerweise nicht perfekt. «Verabschiede dich von perfekt, freunde dich an mit erledigt», schreibt Maria-Xenia Hardt (2021) über ihre Doktorarbeit, die sie teils unter erheblichem Zeitdruck erstellt hat. Das gilt beispielhaft für jedes agile Projekt. Nicht, dass man es nicht besser machen könnte, doch dafür bleibt noch Zeit, wenn es erstmal funktioniert. Zudem bestehen zwei gravierende Risiken, falls das MVP bereits einen vermarktungsfähigen Zustand (MMP) erreicht. Erstens wird häufig das Budget gekürzt, weil das Produkt angeblich fast fertig ist, und zweitens verlängern sich die Release-Zyklen, da sich niemand traut, ein unfertiges Produkt zu veröffentlichen. Reihenhäuser statt Luftschlösser bauen, führt eher zum Erfolg.
7. Straffer Zeitplan und knappe Ressourcen? Mit Scrum bekommen wir das hin! Die Wahrheit ist, dass sich Projekte mit Scrum meist aufwändiger, weniger schnell und mit höheren Kosten als mit einem vergleichbaren, klassisch als Wasserfall geplanten Projekt umsetzen lassen. Der Grund: Scrum versteht sich nicht als Liefermaschine, sondern als Heuristik um zu lernen. Wenn keine Zeit dafür besteht, Wissen aufzubauen, auszuprobieren und zu lernen, eignet sich Scrum nicht für das vorgesehene Projekt. Vielmehr baut die Entscheidung, Scrum einzusetzen, unnötigen Druck auf das Scrum-Team auf, bloß rechtzeitig fertig zu werden. Das Problem: Scrum macht inspect and adapt stark (vgl. Sutherland, 2002, S. 15–17), nicht follow suit, also stumpf dem zu folgen, was andere vorgeben – und sei es nur die Vorgabe, einfach zu machen, statt dem Sinn und Zweck agiler Methoden zu genügen und den Teams die Zeit einzuräumen, die sie brauchen, um zu lernen und sich zu verbessern. Besonders gefährlich ist dieses Vorgehen, wenn es bereits erfolgreiche Scrum-Projekte im Unternehmen gibt. Deren Sinn droht nachträglich Schaden zu nehmen.
8. Selbst mitdenken müssen, stand aber nicht in der User Story. User Stories müssen einfach geschrieben sein und nicht mit zu vielen Details überladen. Hänge das Bild im Kinderzimmer 1,50 Meter über dem Boden, 2 Meter von der rechten Wand entfernt mit einem 3cm Nagel auf und setze den Hammer im 45-Grad-Winkel an und schlage genau dreimal kräftig zu, ist keine sinnvolle User Story, wenn es darum geht, ein Bild aufzuhängen, ohne, dass es runterfällt. Im schlimmsten Fall trifft derjenige, der diese Anweisungen ausführt, die Stromleitung. Details auszuarbeiten und auftretende Schwierigkeiten zu umgehen, gehört zu den Kernaufgaben des agilen Teams. Vorab sollten alle beteiligten Personen klären, ob jeder den Kontext und das Ziel des Kunden – die User Story im wörtlichen Sinne – versteht. Das reicht. Anderenfalls gilt das berühmte Sprichwort: shit in, shit out.
9. Ich habe leider keine Zeit für die Retro. Wer die Retrospektive schwänzt, um keine Zeit für den nächsten Sprint zu verlieren, höhlt inspect and adapt (vgl. ebd.) aus und verhindert so, dass das Team lernt. Zudem bauen sich möglicherweise Spannungen auf, falls sich jemand im Team übergangen oder nicht ausreichend gewürdigt fühlt. Diesen Konflikt tragen Betroffene mit sich herum und stecken damit schlimmstenfalls alle anderen an. Weil niemand von diesen Befindlichkeiten weiß, bleibt unentdeckt, ob es sich um einen unglücklichen Einzelfall handelt oder um etwas, das andere Kolleg*innen genauso empfinden. Ein womöglich ernstes Problem bleibt unausgesprochen. Das ist Gift für die gesamte Firmenkultur. Wer skeptisch zu den Retros eingestellt ist, lässt sich häufig mit einer Scrum-Simulation überzeugen, dass sie sinnvoll sind und das Team weiterbringen.
Agilität richtig verankern
Fast alle diese Beispiele, warum Agilität im Unternehmen scheitert, lassen sich darauf zurückführen, dass viele Führungskräfte die neuen Methoden einfach verordnen. Ihnen ist nicht klar, dass sie sich für mehr als nur einen Werkzeugkasten entscheiden. Wer agile Teams fördern und deren Erfolg sicherstellen will, muss sich auf einen kulturellen Wandel einlassen, der auch Auswirkungen auf etablierte Führungskräfte hat. Dafür sollten sich Organisationen bewusst entscheiden (vgl. Schmiedlinger, Rasche, Thonfeld & Tuchen, 2021, S. 3–14). Das setzt auch voraus, zuerst das richtige Umfeld zu schaffen, damit agile Methoden florieren – agil sein zu wollen, weil das jetzt alle machen, führt dagegen nahezu sicher zu Frustrationen. Führungskräfte sollten nicht bloß imitieren was andere machen oder was in Büchern steht. «Being Agile» und «Agile Doing» unterscheiden sich stark voneinander, insbesondere darin, was erreicht werden soll – in der Beratersprache ist das der Impact. Und der findet vor allem im Kopf statt. Scrum, Kanban & Co. zielen darauf, das Lernen zu vereinfachen. Sie schaffen Räume, um sich auszutauschen und stellen Formate und Methoden vor, die das agile Mindset fördern. Sie stellen das Warum über das Wie. Darum ist agil sein auch so anstrengend, weil sich agile Teams das Warum permanent vergegenwärtigen müssen und keinen vorab gefassten Plan abarbeiten. Agilität gilt als ein Wertesystem zweiter Ordnung, das für obligatorisch und nicht optional hält, das Wozu und Wohin immer wieder von neuem auszuleuchten (Oestereich & Schröder 2019, S. 22).
Auf diese Klärung lassen sich alle agilen Methoden und Frameworks zurückführen. In seinem Aufsatz «Aufbruch in das Ungewisse» in OrganisationsEntwicklung Heft 4/2020 nennt Alexander Nicolai dies die «Logik des iterativen Innovierens», die sich innerhalb der agilen Teams abspielt und die für Unternehmen als übergeordnetes Leitbild dienen sollte, und erklärt, warum es sich dabei um einen «zeitlosen Kern» von Agilität handelt. Er beschreibt, wie aus der Not und einer simplen Webseite heraus Airbnb entstand. Die ersten drei Buchungen waren der MVP und noch nicht das fertige Produkt. Transferwise, Dropbox oder die Digitalbank N26 seien auf eine ähnliche Weise großgeworden. N26 ist auch deshalb ein gutes Beispiel, weil das Unternehmen derzeit mit der Bankenaufsicht im Clinch liegt. Im Juli 2021 hat die BaFin gegen N26 eine Geldbuße von 4,25 Mio. Euro verhängt, weil die Bank Lücken bei der Geldwäscheprävention nicht rechtzeitig geschlossen hat (BaFin, 2021). Hier prallen zwei völlig verschiedene Weltbilder aufeinander. Nicolai rät deshalb, Iterationsbarrieren abzubauen und sich eine flexible Distanz zum «operating core» zu erlauben: «Weit genug entfernt, um möglichst frei iterieren zu können, nah genug, um erfolgskritische Ressourcen hebeln zu können …» (Nicolai 2020).
Wer sich für dieses Mindset öffnet, bleibt ständig in Bewegung. Zwar gibt es auch in einer agil organisierten Arbeitswelt hin und wieder Aufgaben, die keinen Spaß machen. Eine Routine, die nicht selten zum Boreout führt, stellt sich dagegen kaum ein, weil verinnerlichte Agilität bedeutet, niemals an einem bestimmten Ziel anzukommen. Kein Unternehmen kann insofern jemals abschließen, sich agil zu transformieren. Auf den erreichten Gipfel folgt immer schon der nächste Change (vgl. Schmiedlinger, Rasche, Thonfeld & Tuchen 2021, S. 180–192). Wer agil mit Hilfe eines Transformationsteams werden möchte, sollte sich deshalb davor hüten, dieses Team später aufzulösen, sondern sich stattdessen fragen, wie es dazu beitragen kann, die agile Botschaft im Unternehmen weiterzutragen.
Sophie Hummel
Partner Senacor Technologies
Ann-Katrin Stehle
Senior Consultant Senacor Technologies, Frankfurt am Main
Literatur
• BaFin (2021). N26 Bank GmbH: BaFin setzt Geldbußen fest. https://zoe.ch/bafin
• Beck, K. et al. (2001). Agile Manifesto. www.agilemanifesto.org, zuletzt abgerufen am 6. Oktober 2021.
• Hardt, M.-X. (2021). Silicon-Valley Methoden im Studium: Verabschiede dich von «perfekt», freunde dich an mit «erledigt». Der Spiegel. https://zoe.ch/erledigt-statt-perfekt
• Hays AG (2015). Von starren Prozessen zu agilen Projekten: Unternehmen in der digitalen Transformation. https://zoe.ch/haysdigitransformation
• Hofert, S. (2018). Das agile Mindset: Mitarbeiter entwickeln, Zukunft der Arbeit gestalten. Springer-Gabler.
• Komus, A. et al. (2020). Studie Status Quo (Scaled) Agile 2019/2020. Hochschule Koblenz. www.status-quo-agile.de
• Lasnia, M. & Nowotny, V. (2018). Agile Evolution: Eine Anleitung zur agilen Transformation. BusinessVillage.
• Lencioni, P. (2002). The Five Dysfunctions of a Team: A Leadership Fable. Jossey-Bass.
• Nicolai, A. (2020). Aufbruch in das Ungewisse: Die Logik des iterativen Innovierens als zeitloser Kern agiler Innovationsmethoden. OrganisationsEntwicklung, Heft 4/2020, 46–51.
• Oestereich, B. & Schröder, C. (2019). Agile Organisationsentwicklung. Handbuch zum Aufbau anpassungsfähiger Organisationen. Vahlen.
• Powers, S. (2006). What is Agile? Adventures with Agile. https://www.adventureswithagile.com/2016/08/10/what-is-agile/
• Schmiedlinger, C., Rasche, C., Thonfeld, E. & Tuchen, K. (2021). Agile Transformation. Der Praxisguide zum Change abseits des Happy Paths. Hanser.
• Sutherland, J. (2015). Die Scrum-Revolution. Management mit der bahnbrechenden Methode der erfolgreichsten Unternehmen. Campus.
• Triest, S. & Ahrend, J. (2019). Agile Führung: Mitarbeiter und Teams erfolgreich führen und coachen. mitp Verlag.
