Wann machen agile Frameworks Sinn?
Nach dem großen Hype auf agile Frameworks in den Jahren 2010-2020 kehrt langsam etwas Ernüchterung und auch die Erkenntnis ein, dass agiles Vorgehen nach einem bestimmten Framework wie Scrum, SAFe® oder Less® in gewissen Unternehmenskontexten Sinn macht, in anderen aber nicht. Bzw. reift die Erkenntnis, dass jede Organisation ein eignes Organisationsdesign braucht, das den spezifischen Besonderheiten der Produktentwicklung, Dienstleistung oder Arbeitsroutine Rechnung trägt.
Noch immer wird gerne das Cynefin Framework zur Betrachtung einer Ausgangssituation verwendet um zu entscheiden, ob agiles Vorgehen Sinn macht oder nicht. Dabei ist entscheidend zu betrachten in wie weit Ziele und Anforderungen klar sind oder der Weg bzw. Umgang damit:
Einordnung von Herausforderungen
Vereinfacht kann gesagt werden:
- In einfachen Herausforderungen mit klarem Ziel und einem überschauben Weg macht es keinen Sinn agile Frameworks zu verwenden. Ich kann das Problem erkennen, kategorisieren in einen Handlungsweg und reagieren. Beispiel: Ich möchte ein Spiegelei braten.
- Bei komplizierten Herausforderungen lohnt es sichAnforderungen näher zu analysieren und einen Experten zu Rate zu ziehen. Beispielhaft kann hier das Kochen eines speziellen Gerichts sein, das besondere Zutaten oder besondere Kochtechniken erfordert.
- Der größte Bereich wird in diesem Modell den komplexen Herausforderungen gewidmet, die uns in Zeiten von VUCA und BANI öfter begegnen. Hier macht iteratives Vorgehen Sinn, denn die Anforderungen stehen oft nicht zu 100% fest, der Weg zur Lösung ist unvorhersehbar. Vorgehen in kurzen Abschnitten mit stetiger Reflexion und Anpassung ist hier das beste Vorgehen. Gleichzeitig kann ich in agilen Settings die Weisheit der Vielen nutzen um mich Stück für Stück zur Lösung vorzuarbeiten.
- In chaotischen Situationen bleibt oft keine Zeit für iteratives Vorgehen, denn es muss unmittelbar reagiert werden. Auch hier kann try & error helfen, doch der Raum für Experimente ist wesentlich kleiner. Im Firefighting Modus geht es darum schnelle Lösungen zu finden, die funktionieren.
Habe ich dieses Modell im Hinterkopf kann ich zum einen als Consultant beraten, welches Vorgehen in diesem Fall Sinn macht. Als Agiler Coach sollte ich aber auch die wichtige WHY-Frage stellen, wie z.B.: „Warum soll ab sofort mit Scrum* gearbeitet werden?“ „Was versprechen Sie sich davon?“
*setze beliebig anderes agiles Framework ein
Die WHY-Frage zu Beginn stellen
Die Antwort auf diese Fragen geben mehr über die Motivation und die Ziele der Initiatoren der Veränderung preis. Hier hilft es mir, dass ich nicht zertifiziert auf ein einzelnes Framework bin, sondern anhand der Ausgangssituation einen guten Überblick geben kann, welches Framework geeignet wäre. Das passiert meistens nicht in Form von Beratung, sondern in einem gemeinsamen Workshop, in dem die Ausgangsituation betrachtet und Ziele/Wünsche/Erwartungen formuliert werden.
Schon hier lässt sich sagen, dass die zunehmend agile Skepsis in den Organisationen gut tut. Das sage ich auch obwohl – oder gerade weil – ich Agile Coach bin. Zu viel verbrannt wurde die Agilität in den letzten 10 Jahren, zu viele Transformationen frameworkbasiert gedacht und umgesetzt. Ich habe im letzten Jahr zwei Teams im Nicht-IT Kontext als Agile Coach betreut, die sich einem organisationalen SAFe® Prozess einfügen mussten, dabei hat die Projektarbeit nur ca. 60% ihrer Arbeit ausgemacht, die anderen 40% waren Tagesgeschäft. Dieses Tagesgeschäft jeden Sprint neu zu planen bzw. immer weiter mit zuziehen erzeugt Frustration und Sinnleere.
Wenn es zur Management getriebenen „Agilisierung“ in Organisationen kommt in Form von „Wir machen das jetzt mal alle agil!“, dann wird dieser Transformationsprozess oft von viel Leid und Unverständnis bei den Beteiligten bis hin zur Resignation begleitet. Martin Permantier, der Autor des „Modells der sechs Haltungen“ schreibt in seinem neuen Buch „Haltung erweitern“ zu diesem Phänomen:
Im Glauben, es handle sich um eine Methode, werden Mitarbeitende in postkonventionellen Denkweisen geschult. Das Korsett der Organisation […] bleibt unangetastet. […]
Was vor allem fehlt, ist eine positive Referenzerfahrung von Agilität, eine Erfahrung, die dem Team eine Vision der gewünschten Zukunft vermittelt, an der sie gemeinsam arbeiten. Die Herzen können sich nicht verbinden, wenn das Ziel diffus ist oder von einem Gefühl des Mangels getrieben wird. In diesem Raum der Ungewissheit entstehen haltungsspezifisch gefilterte Versionen dessen, was diese angestrebte Agilität nun sein soll, mit entsprechenden Widerständen und typischen Vorbehalten.
Agil, hybrid, klassisch… oder doch was eigenes?
Neben Agile, ja oder nein, gibt es auch die Möglichkeit hybride Modelle zu fahren oder agile Frameworks nur in produktionsrelevanten Bereichen bzw. im Projektmanagement einer Organisation einzusetzen. Dabei ist die Betrachtung von Organisationsbereichs-spezifischen Zielen und aktuellen Herausforderungen viel eindeutiger. Ein 100% passendes Prozess- oder gar Organisationsmodell gibt es nämlich selten.
Deshalb rate ich Organsiationen oder Teams zunächst klein zu beginnen und erstmal einzelne agile Praktiken und Werkzeuge auszuprobieren:
- Das kann eine zweiwöchentliche Retro sein, um das stetige Reflektieren und Verbessern der Zusammenarbeit zu lernen.
- Das kann das Arbeiten in monatlichen Iterationen sein um besser zu planen und überblickbare Teilergebnisse „zu liefern“
- Das kann die Nutzung eines KANBAN-Boards sein um die anstehende Arbeit sichtbarer und Hindernisse für alle transparenter zu machen.
Fazit
Manchmal ist ein agiles Framework wie Scrum oder skaliertes Scrum für den Arbeitskontext einfach zu mächtig und zu komplex. Die besten Erfahrungen und positiven Verbesserungen erzielen agile Frameworks nach meiner Erfahrung für Projektarbeit oder im Rahmen der Produktion. Ich habe vier wichtige Marker gefunden, die neben der oberen Einordnung in Komplexitätsgrade darauf hinweisen können, ob Scrum (hier als Beispiel) als agiles Rahmenwerk das richtige Modell darstellt:
- Die Organisation sollte sich in irgendeiner Art und Weise bereits in einem Transformationsprozess befinden, bzw. mit der veränderten Kultur befasst haben, die mit agilem Arbeiten einher geht und unter anderem eine neue Art der Führung und Entscheidungsräume erfordert (siehe Ebene Haltung und Werte im oberen Bild).
- Für den Einsatz von Scrum sollte ein Team von mindestens 3 und maximal 10 Personen vorhanden sein, in mancher Literatur ist auch von maximal 7 Menschen die Rede (ja, es kommen auch Menschen auf die Idee Scrum Einzelpersonen- oder 2er-Teams zu verordnen). Ist das Team größer, sollte über eine Teilung nachgedacht werden.
- Die Entwicklung von Produkten oder Konzepten sollte einen Kundenfokus ermöglichen. Scrum ohne Kunde bzw. Zielgruppe ist nett, aber sinnlos. Das wertvollste an dem Framework stellt für mich der immerwährende Fokus auf den Kunden und die damit verbundene Wertschöpfung dar. Der Blick auf den Kunden bzw. die Zielgruppe unterstützt die stetige Überprüfung und Anpassung von Sprint zu Sprint.
- Für skalierte Scrum-Frameworks wie Less oder SAFe, sollte es bereits erste Vorerfahrungen mit dem kleinen Bruder Scrum geben. Gleichzeitig sollten die Strukturen der Organisation so komplex sein, dass aus der Zusammenarbeit und Synchronisation zwischen Teams oder Abteilungen (und neben allen damit verbundenen Nachteilen) mehr sichtbare Vorteile entstehen.
Nur weil es nicht immer gleich Scrum sein muss, bin ich dennoch ein großer Fan der Agilität. Agil vorzugehen hängt wie oben beschrieben vom Blickwinkel auf die Herausforderung ab. Wobei zu beobachten ist, dass immer mehr Bereiche in unserer Wirtschafts- und Lebenswelt als komplex eingeordnet werden können und einfache Prozesse nach und nach automatisiert bzw. von Künstlicher Intelligenz bewältigt werden.
In Zeiten stetiger Veränderung und Nicht-Planbarkeit (Corona hat uns das alle gelehrt), ist agiles Vorgehen – nach agilen Werten und Prinzipien, aber nicht zwingend an ein Framework gebunden – aus meiner Perspektive unerlässlich um zukunftsfähig zu sein. Die Frage im Titel dieses Blogartikels sollte richtig formuliert also eigentlich nicht „When agile?“ lauten, sondern „When not agile?“
