Agilität ohne Rahmenwerk

Warum braucht es ein gutes Rahmenwerk für agiles Arbeiten?

Wir haben in Projekten schon mit Scrum experimentiert und wollten nun einen nächsten Schritt machen. Dies bedeutete, dass wir von Projekt-Teams hin zu stehenden Teams gehen wollten, die gemeinsam mit agilen Praktiken zusammenarbeiten. Um diese Zusammenarbeit vor allem zwischen den Teams aber auch in Abhängigkeit zur Portfolio-Strategie zu klären, brauchten wir ein Rahmenwerk, das uns die nötige Orientierung und das nötige gemeinsame Bild gibt. Dieses Rahmenwerk sollte dann im Umfeld von rund 6-8 Teams getestet werden, um es später auch für andere Teams anwenden zu können. 

Was hat euch an den bestehenden Lösungen missfallen?

Zuvor waren wir im typischen Projektgeschäft. Dies hatte zur Folge, dass wir immer mehr Projekte starteten, als wir abgeschlossen haben. Als Konsequenz waren viele Mitarbeitende auf mehreren Projekten tätig und waren so nicht nur überlastet, sondern auch nicht so produktiv. Wir wollten im Sinne von “Project to Product” den Spiess umdrehen. Also fixe Teams, klare Priorisierung auf jeder Ebene, so dass im Pull-Prinzip jeweils jene Arbeit erledigt wird, die gerade am meisten Mehrwert bringt. 

Warum habt ihr versucht ein eigenes zu schaffen?

Im genannten Pilot mit den rund 6-8 Teams musste aufgrund diverser Veränderungen in der Organisation ohnehin die Zusammenarbeit neu gewählt werden. Als sich diese Veränderung bereits abzeichneten, haben wir als Transformationsteam ein bestehendes Framework wie SAFe vorgeschlagen. Dies hat allerdings nicht Anklang gefunden, da es nicht zur bestehenden Kultur passe. Also haben wir zusammen mit externer Unterstützung ein eigenes Rahmenwerk zur skalierter Agilität erarbeitet, das viele Elemente von SAFe aufnahm. 

Warum ist es nicht trivial ein gutes Rahmenwerk zu schaffen?

Ein gutes Rahmenwerk zeichnet für mich u.a. aus:

• Es verbessert die Zusammenarbeit gegenüber dem bisherigen System
• Es gibt hinreichend Orientierung für die verschiedenen Teams
• Es gibt genügend Flexibilität für kontinuierliche Weiterentwicklung 
• Es gibt dort gemeinsame Ankerpunkte, wo es zwingend notwendig ist
• Es wird von allen Beteiligten hinreichend akzeptiert
• Es ist genügend zugänglich, dass neue Mitarbeitende in die neue Zusammenarbeit  integriert werden können. 

Wahrscheinlich gibt es sogar noch mehr Anforderungen, die es braucht, damit solche Rahmenwerke tatsächlich passen. Dies zu erreichen ist unglaublich schwer, insbesondere wenn es nicht die Kernkompetenz eines Unternehmens ist. 

An welchen Knackpunkten seit ihr gescheitert?

Wie oben genannt, ist es unglaublich schwer, ein gutes Rahmenwerk zu schreiben. Wir haben dies zwar mit externer Unterstützung gemacht, die eine hohe Kompetenz hatten in der Agilen Zusammenarbeit. Allerdings kannten sie uns als Unternehmen noch nicht gut. 

Ein essentieller Grund, weshalb das Rahmenwerk scheiterte war deshalb, dass die Entwicklung der Rahmenwerks zunehmend politisch getrieben war und so Grundsätze der agilen Zusammenarbeit so verbogen wurden, dass sie nicht mehr funktioniert. 

Ein anderer Aspekt war, dass sich das Modell nicht skalieren und betrieben liess. Wir hätten rund 1 bis 2 FTE benötigt, die nur damit beschäftigt gewesen wäre, in den internen Dokumenten und Schulungen die Weiterentwicklungen des Modells anzupassen. Zudem war das Modell auf den aktuellen Piloten zugeschnitten und hätte komplett neu erfunden werden müssen, wenn wir mehr Teams, mehr Organisationsebenen oder zusätzliche Einheiten hätten auf agil umstellen wollen. 

Welches sind bewährte Rahmenwerke auf die du gerne zurückgreifst?

Als erstes greife ich sehr gerne auf das 5x Warum Modell zurück. Viele Organisationen wollen agil werden, wissen aber noch gar nicht wirklich, was besser werden soll. Erst wenn dieses “Why” klar ist, lässt sich auf das richtige Modell als Ausgangspunkt nehmen. Anschliessend sind es für mich die relativ verbreiteten Modelle wie SAFe, OKR, Spotify-Modell, Scrum, Scrumban, Kanban, Design Thinking, Lean Start up oder Management 3.0 auf die ich zurückgreife. Modelle wie LeSS oder Nexus eher weniger, da diese sehr spezifisch für skalierte Scrum-Teams entwickelt wurden und es dort schwierig ist, Teams zu integrieren, die eher mit Scrumban oder Kanban unterwegs sein müssten. 

Worauf muss man achten, wenn man diese gut ausgestaltet?

Ich habe sehr gute Erfahrungen mit dem “Shu Ha Ri” Ansatz gemacht. Sprich, zuerst wird ein Rahmenwerk genommen und nicht angepasst. Der Ruf nach “Es passt nicht zu unserer Kultur” mag da sehr berechtigt sein, aber es fehlt auch noch die Kompetenz, um zu wissen, was denn tatsächlich zur Kultur passt. Entsprechend dem Shu Ha Ri Ansatz wird also zuerst einmal mit den bestehenden Regeln gelernt, dann die Regeln hinterfragt und dann erst neue kreiert. So kann etwas besser verhindert werden, dass Anpassungen organisationspolitisch getrieben sind. 

Gleichzeitig sollte das Anwenden des Rahmenwerks auch so begleitet werden, dass nicht bereits von Anfang an verlangt wird, jedes Detail zu verstehen. Hier habe ich gute Erfahrungen gemacht, dass zwar ein klares Commitment zu einem Rahmenwerk ausgesprochen wird, in der Erklärung des Rahmenwerks habe ich mich dann jeweils auf die wichtigsten Elemente fokussiert, um diese zuerst einzuspielen. Anschliessend können weitere Elemente des Rahmenwerks Schritt für Schritt dazugelernt werden. So ist das Lerntempo für die Mitarbeitenden verträglich, ohne dass eine Diskussion losgetreten wird, ob das Rahmenwerk nun das richtige ist oder nicht. 

Welchen Tipp würdest du jemanden geben, der heute ein eigenes agiles Rahmenwerk selbst entwickeln will?

Der erste Tipp ist natürlich, eine bewusste Hypothese zu haben, was überhaupt verbessert werden soll. Wenn dieses “Wozu” klar ist, dann gibt es in den meisten Fällen bereits sehr gute und etablierte Rahmenwerke, die als Startpunkt ausprobiert werden können. 

Die Entwicklung eines eigenen Rahmenwerks ist eine sehr hohe Investition, dies sich nur dann auszahlt, wenn das Modell auch deutlich besser ist, als etablierte Modelle. Es darf nicht vernachlässigt werden, dass es deutlich effizienter ist, Mitarbeitende durch Standardschulungen aus dem Markt mit einem Rahmenwerk vertraut zu machen, als dies intern stetig selber betreuen und weiterentwickeln zu müssen. 

Entsprechend lohnt sich aus meiner Sicht nur dann ein eigenes Rahmenwerk, wenn schon eine vertiefte Erfahrung mit Agilität vorhanden ist und oder auch kein Interesse bzw. Notwendigkeit besteht, dies in einem grösseren Kontext zu skalieren.