Gebt der (Framework-)Vielfalt eine Chance!
Letzte Woche war ich im Rahmen eines Netzwerktreffens mit einigen weiteren Berater:innen der Automobilindustrie im Austausch. Dabei ging es – wie so oft in der agilen Szene – auch um die Bedeutung von Frameworks und insbesondere von SAFe®.Wir stellten fest, dass sich gerade im Automobilbereich die Meinung durchsetzt, dass SAFe® de facto der Standard sei und auch bleiben werde. Mir geht es weniger darum, einzelne Frameworks zu bewerten. Meines Erachtens hat jedes einzelne seine Berechtigung und dadurch auch Vor- sowie Nachteile. Mir geht es eher um die Diskussion, ob es in dieser Sache sinnvoll ist, einen Standard auszurufen.Um es kurz zu machen: Ich finde es schade. Schade, weil wir uns dadurch die Möglichkeit nehmen, unseren Lösungsraum weiter zu öffnen. Das heißt nicht, dass ich Standards per se verurteile. In vielerlei Hinsicht sind diese sogar fördernd – vor allem, wenn es darum geht, für Kompatibilität und Integration zu sorgen. Man stelle sich vor, eine Schraube mit Gewinde wäre nicht genormt. Wir würden uns vieles verbauen.Doch in der Welt der komplexen Probleme, die kreative Prozesse benötigen, um Lösungen herbeizuführen, tut uns die Standardisierung oft mehr weh, als sie bringt. Das gleiche Arbeitsmodell wie andere Unternehmen einzuführen? Keine gute Idee, auch wenn das auf den ersten Blick Synergien hebt. So versucht man, eine Lösung zwanghaft auf den eigenen Kontext anzupassen, für den möglicherweise eine ganz andere Lösung viel besser passen würde.Bei borisgloger consulting vertreten wir den Ansatz, ein eigenes Skalierungs-Framework für den spezifischen Kontext gemeinsam mit dem Kunden zu entwickeln. Wir nennen dieses Vorgehen myScaled Agile, weil es zum Ziel hat, passfähige Ansätze für die Organisation zu entwickeln. Wir haben dabei eine Vielzahl von Lösungsbausteinen im Gepäck, Praktiken aus SAFe®, Scrum@Scale, Nexus oder auch der Soziokratie. Diese Bausteine formen wir dem Kontext entsprechend zu einem funktionierenden Ganzen. Man kann sich das dann ein wenig wie eine Maßkonfektion im Anzugladen oder in einer Schreinerei vorstellen.Ein konkretes Praxisbeispiel ist unsere Arbeit mit Webasto (siehe Case Study). Hier haben wir ein Organisations- und Zusammenarbeitsmodell entwickelt, welches Elemente aus verschiedenen Ansätzen vereint. Die Teams wurden entlang des Wertstroms und einzelner Module geschnitten. Die Linienorganisation haben wir nach Expertisen aufgestellt und damit Ansätze aus dem „Spotify-Ansatz“ verwendet. Die Synchronisation der Product Owner und Agile Master inklusive deren skalierte Rollen Chief Product Owner und Agile Coaches haben wir aus Scrum of Scrums bzw. Scrum@Scale®. Um den langen Planungszyklen in der physischen Produktentwicklung gerecht zu werden, haben wir zudem eine Art übergreifende 3-Monats-Iteration über den klassischen 2-Wochen-Iterationen etabliert, die ihren Ursprung in der QBR-Methode oder auch der PI-Planung hat. Doch auch hier haben wir im Detail weiter angepasst, da wir im Kontext von Webasto bewusst auf ein Vertreter- und Repräsentanten-System für diese übergreifende Planung gesetzt haben und diese nicht mit allen Teammitgliedern durchführen.Eines meiner diesjährigen Fokus-Themen wird sein, diese Thematik zu vertiefen und mit weiteren Expert:innen daran zu tüfteln, herauszuarbeiten, was wir von Standards lernen können, wie wir diese in der täglichen Arbeit nutzen wollen und wie wichtig „tailor-made“ für den spezifischen Kontext ist. Stay tuned!Wenn ihr Lust habt, diese Thematik mit mir tiefer zu ergründen oder selbst bei euch auszuprobieren, dann freue ich mich auf eure Rückmeldung.
