Agilität? Haben wir probiert! Funktioniert nicht! – Teil 1

Warum das durchaus so sein kann: Ein Überblick in mehreren Teilen

Sie haben sicher schon von dieser “Agilität” oder diesem “Agile” (sic!) gehört, von dem alle reden. Vielleicht haben Sie “es” sogar schon ausprobiert. Und eventuell haben Sie auch das Gefühl, dass nach Jahren der Euphorie in letzter Zeit die Stimmen der Kritiker und Skeptiker wieder lauter werden? War also alles nur heiße Luft, einfach wieder nur eine von vielen Managementm(eth)oden, die kommen und gehen?

Ich persönlich bin davon überzeugt, dass Agilität mehr ist. Doch wo kommt dann dieser aktuelle Gegenwind her? Wieso scheitern viele Unternehmen daran, agiler zu werden?

Es gibt vielfältige Gründe, warum “Agilität” in Unternehmen nicht funktioniert oder nicht den erhofften Erfolg bringt. Und es lohnt sich, etwas genauer hinzuschauen: Liegt es daran, dass Agilität schlicht der falsche Ansatz für die jeweilige Situation und das angestrebte Ergebnis ist? Oder liegt es daran, dass Agilität durchaus der passende Ansatz wäre, jedoch die Rahmenbedingungen oder Fehler in der Umsetzung zum Scheitern führten?

Achtung: Unter Umständen kann diese Erkenntnis für Ihr Unternehmen überlebenswichtig sein!

Wenn Sie feststellen, dass Agilität für Ihr Unternehmen (aktuell) gar nicht hilfreich ist, dann können Sie das Thema guten Gewissens (erst einmal) abhaken und sich den für Sie wichtigeren Dingen zuwenden – was, nebenbei erwähnt, an sich schon ein wichtiger Aspekt von Agilität ist: Fokus, Fokus, Fokus und Themen zügig abschließen!

Sollten Sie allerdings erkennen, dass Ihr Unternehmen allem Anschein nach agiler werden muss, um am sich verändernden Markt (weiterhin) erfolgreich sein zu können, dann sollten Sie es vielleicht besser doch noch einmal angehen. Freuen Sie sich: Sie haben eine zweite Chance gewonnen! Nutzen Sie sie! Lernen Sie aus Ihrem bisherigen Scheitern, agil. Und vielleicht finden Sie in diesem Artikel auch die eine oder andere Inspiration.

Apropos – vielleicht ist es Ihnen im Titel aufgefallen: Dies ist der Beginn einer kleinen Serie, aktuell habe ich drei Artikel im Sinn. Ich möchte darin auf einige typische Missverständnisse, Probleme und Hindernisse eingehen, die ich in der Praxis erlebe, und den einen oder anderen Hinweis geben, wie Sie es besser machen können. Doch – Sie ahnen es vielleicht – es gibt nicht die eine universelle Lösung, keine “Best Practice” und kein Kochrezept für erfolgreiche Agilität! Wenn es so etwas gäbe, bräuchte es diese Artikel nicht und ich hätte als Agile Coach und Begleiter von Transformationen nicht so viel zu tun. 😉

Sie setzen auf das falsche Pferd, Teil 1: Agilität kann bei Ihnen gar nichts bringen!

Simon Sinek sprach “Start With Why!” und das gilt auch für die Frage, ob es in Ihrem Unternehmen sinnvoll ist, auf Agilität zu setzen. Warum also sollten Sie auf Agilität setzen bzw. wofür ist Agilität der passende Ansatz? Und wofür eher nicht?

Agilität im Allgemeinen und Scrum als das am weitesten verbreitete agile Framework im Speziellen, sind Ansätze zum erfolgreichen Umgang mit hoher Komplexität, mit hoher Dynamik, mit Mehrdeutigkeit, mit Unsicherheit und Ungewissheit. Manche nennen diese Situation auch “VUCA”.

Wenn sich Ihr Unternehmen also in einem hoch komplexen/dynamischen Umfeld befindet oder in absehbarer Zeit die Gefahr besteht, dass sich Ihr Marktumfeld in eine solche Richtung entwickeln könnte, dann wird Agilität zum Erfolgsfaktor und vielleicht sogar zur Voraussetzung für das Überleben am Markt!

Umgekehrt gilt: Wenn sich Ihr Unternehmen in einem stabilen Marktumfeld befindet, wenn Sie gut voraussagen können, welche Produkte erfolgreich sein werden, wenn Sie recht zuverlässig planen können und der Erfolg vor allem vom Preis abhängt, dann ist Agilität eher nicht der richtige Ansatz für Ihr Unternehmen.

Und Agilität zum Selbstzweck bzw. “weil das ja jetzt alle machen” ist meines Erachtens nicht nur zum Scheitern verurteilt, sondern pure Verschwendung und kann sogar schädlich sein: Funktionierende Abläufe werden gestört, die Produktivität sinkt und weil niemand versteht, warum diese Veränderung notwendig ist, sinkt die Motivation der Mitarbeitenden.

Noch schlimmer: Sollte sich Ihre Situation in der Zukunft ändern und Sie zur Erkenntnis kommen, dass Sie nun doch agiler werden müssen, dann werden Sie es doppelt schwer haben, gegen die Erinnerung anzukommen, dass “Agilität ja eh nicht funktioniert” hat, als Sie es damals schon einmal ausprobiert hatten.

Das Schwierige: Je größer Ihr Unternehmen, desto größer ist die Wahrscheinlichkeit, dass Sie keine eindeutige Antwort finden werden. Sie werden sich mit manchen Produkten in ruhigen Fahrwassern bewegen und langfristig planen können, mit anderen Produkten müssen Sie ständig durch Stromschnellen steuern, und manch ein bisher ruhiges Gewässer wird plötzlich durch ein Erdbeben erschüttert.

Wahrscheinlich müssen Sie wohl oder übel differenzieren: Setzen Sie dort auf agile Ansätze, wo Agilität besonders wichtig und wirkungsvoll ist! (Doch Vorsicht: Auch das birgt Gefahren! In einem der folgenden Artikel werde ich tiefer darauf eingehen.) Und bleiben Sie wachsam, die Situation kann sich jederzeit ändern!

Wie geht das? Was kann dabei helfen? Vor allem: Darüber sprechen! Regelmäßig!

Oft haben viele Mitarbeitende schon lange ein Bauchgefühl, dass langfristige Planung immer weniger funktioniert und “die Einschläge immer näher” kommen, doch man spricht nicht darüber, jedenfalls nicht mit den Entscheidern, man ändert nichts, man macht halt einfach weiter … solange, bis es vielleicht zu spät ist. Dann heißt es: “Also mir war das ja schon lange klar …!”.

Dies gilt es zu vermeiden! Und dazu braucht es Übung, unterschiedliche Perspektiven und Offenheit!

Und es gibt eine Reihe von Modellen und Denkwerkzeugen, die sich als Basis für die gemeinsame Arbeit an dieser wichtigen Fragestellung bewährt haben: Das Cynefin-Modell, die Stacey-Matrix und die PAVE-Matrix. Im Folgenden verwende ich eine Abbildung auf Basis der Stacey-Matrix zur Visualisierung.

Sie haben falsche Hoffnungen: Wenn Effizienz zur Sackgasse wird!

Wenn ich von Entscheidern in Unternehmen Sätze höre wie “Wir führen Scrum ein, um effizienter zu werden!”, dann bekomme ich regelmäßig Gänsehaut. Wobei ich verstehe, wo dieser Wunsch und diese Überzeugung herkommen. Schließlich lautet der Titel eines sehr populären Buches von Jeff Sutherland, einem der Erfinder von Scrum, “Scrum: The Art of Doing Twice the Work in Half the Time”. Das ist wahrscheinlich auch gar nicht falsch, und wer will das nicht: “doppelt soviel Arbeit in der Hälfte der Zeit” schaffen? Meines Erachtens aber führt diese Zielsetzung zunächst einmal geradewegs auf’s Glatteis.

In hoch komplexen/dynamischen Situationen, in sich immer schneller verändernden Märkten, bei immer undurchschaubareren Käuferpräferenzen, bei immer neuen Wettbewerbern mit gänzlich neuen Geschäftsmodellen und technologischen Innovationen (Stichworte: Digitalisierung und Plattformökonomie), geht es zunächst einmal darum, “das Richtige” zu tun, also erst einmal das erfolgreiche Produkt (das “Was”) zu finden! Und zwar möglichst schnell und kostengünstig! Es geht in erster Linie um Effektivität! Und erst in zweiter Linie geht es um Effizienz!

Was nützt es, wenn ein Unternehmen eine neue Smartwatch zu einem sehr günstigen Preis auf den Markt bringt, weil es die Entwicklung und Produktion hocheffizient organisiert hat, wenn inzwischen niemand mehr Smartwatches kaufen möchte? Vielleicht wurde in der Zwischenzeit herausgefunden, dass Smartwatches “strahlen” und so chronische Handgelenk-Arthrose verursachen? Oder vielleicht kam doch unerwarteterweise eine neue Edition der Google Glasses auf den Markt und “alle” wollen nun eine solche Brille haben?

Unter Komplexität und hoher Dynamik gilt: “”effectiveness eats efficiency for lunch” [Eric Wilde]

Natürlich sorgt Agilität “nebenbei” auch für Effizienz, doch das ist nicht das Thema dieses Artikels.

Tatsächlich ist es so, dass maximale Effizienz unter hoher Komplexität/Dynamik auch maximal riskant ist. Wenn maximale Effizienz bedeutet, dass alle Mitarbeitenden durchgängig wertschöpfend tätig sind, wenn alle immer unter Strom stehen, dann ist eine Organisation kaum in der Lage, auf Störungen zu reagieren. Dynamikrobuste Organisationen bewahren Puffer und Redundanzen und damit die Fähigkeit, sich an neue unvorhergesehene Situationen anzupassen.

Sie setzen auf das falsche Pferd, Teil 2: Agilität ist mehr als Scrum!

Gehen wir also davon aus, dass Ihr Unternehmen größtenteils bzw. oft unter hoher Komplexität, Dynamik, Ungewissheit agieren muss. Agilität scheint also durchaus der erfolgversprechende Ansatz zu sein. Und Ihnen ist auch klar, dass Sie unter diesen Umständen zunächst und vor allem auf Effektivität achten sollten.

Super! Also flächendeckend Scrum einführen und auf in eine rosige Zukunft?

Das kann funktionieren. Das wäre aber Zufall.

Erstens: Scrum ist ein Rahmenwerk, das noch zu füllen ist. Scrum ist sehr sehr leichtgewichtig. Der aktuelle Scrum Guide in Deutscher Übersetzung umfasst gerade einmal 20 Seiten Inhalt. Das ist eine super Basis. Aber es wäre naiv anzunehmen, dass diese 20 Seiten ausreichen, um vollumfänglich zu beschreiben, wie die unterschiedlichsten Unternehmen und Teams ihre Arbeit an Produkten organisieren. Es bleibt Ihnen nicht erspart, dieses Rahmenwerk mit spezifischen Lösungen für Ihren Kontext zu füllen.

Ein kleines Beispiel: Im Scrum Guide steht, dass das Entwicklungsteam zu Beginn des Sprints eine Prognose über die Funktionalität, die im Sprint entwickelt werden soll, erstellt. Im Scrum Guide steht nicht, wie das Entwicklungsteam diese Prognose erstellt, wie es den Umfang und die Inhalte des Sprints abschätzt. Den Begriff “Planning Poker” suchen Sie im Scrum Guide vergebens. Planning Poker ist nur eine Möglichkeit von vielen.

Und es lohnt sich, diese 20 Seiten immer mal wieder ganz genau anzuschauen, vor allem dann, wenn man sich bei der konkreten Ausgestaltung nicht sicher ist. Auch dazu ein kleines Beispiel: Ich treffe sehr häufig auf Experten, die davon überzeugt sind, dass der Product Owner die User Storys schreiben muss – und auf Nachfrage: nur der Product Owner! Das ist so nicht ganz richtig … (Einmal ganz abgesehen davon, dass auch die “User Story” nur eine von vielen Möglichkeiten ist, um Einträge im Product Backlog zu beschreiben, der Scrum Guide gibt da keine konkrete Technik vor.)

Zweitens: Scrum ist nicht automatisch immer die beste Wahl!

Auch hier kann die Stacey-Matrix als Denkwerkzeug helfen: Wenn das Ziel bzw. die Kundenbedürfnisse unklar sind oder wenn sich die dynamisch ändern Anforderungen, dann sollte ich Ansätze wählen, die vor allem darauf fokussieren, das “Was” zu validieren: Design Thinking, Lean Startup, Effectuation oder Business Model Generation wären da zu nennen.

Es wäre doch verrückt, direkt mit der Produktentwicklung zu beginnen, ohne herausgefunden zu haben, wer eigentlich die Kunden und Nutzer sind, welches Problem wir mit unserem Produkt lösen wollen bzw. ob unsere Zielgruppe dieses Problem wirklich hat und ob dieses Problem wirklich relevant für sie ist? Oder? Und doch passiert es täglich! Die meisten Innovationen scheitern daran, dass viel Zeit und Geld für die Entwicklung von Produkten verschwendet wird, die niemand nutzen, geschweige denn bezahlen werden.

Kanban ist in vieler Hinsicht ein Sonderfall! Zum Einen muss man Kanban im Lean Manufacturing und Kanban für Softwareentwicklung (und Veränderungsvorhaben) unterscheiden. Zum Anderen ist Kanban noch leichtgewichtiger und damit variabler einzusetzen als Scrum. Ein typisches Einsatzgebiet von Kanban ist die Steuerung von wenig komplexen Aufgaben in einem standardisierten Prozess. Ein anderes Einsatzszenario ergibt sich, wenn (ehemalige) Scrum Teams den Sprint-Takt durch kontinuierliche Entwicklung und Auslieferung ersetzen. Oder Kanban wird eingesetzt, um die Zusammenarbeit zwischen Teams und im Gesamtportfolio zu steuern.

Und um es noch komplizierter zu machen: All das lässt sich auch noch miteinander kombinieren! Scrum Teams können selbstverständlich auch einen Design Sprint einlegen, um in kurzer Zeit viel über Kundenbedürfnisse zu erfahren und einen ersten Prototyp für eine neue Idee zu entwickeln. Sie können jederzeit Pretotyping einsetzen, um ohne großen Aufwand Hypothesen zu validieren. Sie können situativ Effectuation-Werkzeuge nutzen und bspw. ein gemeinsames Mittelinventar aufstellen, um neue Ansätze aus eigener Kraft zu finden. Viele Scrum Teams arbeiten in planbaren Sprints an der Produktentwicklung und nutzen parallel Kanban zur Organisation von unplanbaren ad hoc-Tickets. Etc. pp.

So leid es mir tut: Es gibt leider kein “One-size-fits-all”. Jede Organisation ist einzigartig und komplex. Und da kann es keine “Best Practices” geben. Auch nicht mit Scrum. Scrum ist eine, wie ich finde, sehr sehr gute Ausgangsbasis, um Erfahrungen zu sammeln und Schritt für Schritt eine eigene Lösung zu finden. Man darf sich dabei auch gerne von anderen Organisationen inspirieren lassen. Wenn man allerdings Lösungen, die in anderen Unternehmen gut funktionieren (wie bspw. das sogenannte Spotify-Modell), einfach kopiert, darf man sich nicht wundern, wenn es in der eigenen Organisation quietscht und knarzt und schlimmeres.

Noch ein Tipp: Wann immer Sie sich unsicher sind, ob eine Methode, eine Technik, eine Änderung etc. noch “agil” ist, schauen Sie in das Agile Manifest und sprechen Sie darüber.

Ausblick

In diesem ersten Artikel ging es vor allem um die Frage, ob Agilität überhaupt der passende Ansatz ist und falls ja, welcher konkreter Ansatz auf welche Situation passen könnte. Ich hoffe, ich konnte Ihnen dazu ein paar hilfreiche Impulse mitgeben.

In den nächsten Artikeln wird es dann vor allem um typische Probleme bei der Umsetzung bzw. bei der Ausgestaltung der Einführung und Nutzung von Agilität gehen.

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Und hier finden Sie die nächsten Teile der Beitragsserie Agilität? Haben wir probiert! Funktioniert nicht!

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.