Skalierung
Skalierung ist die Königsdisziplin in der Agilität, an der die meisten Firmen scheitern.
Nachdem wir uns nun ein bisschen mit Agilität auf dem Teamlevel vertraut gemacht haben, geht es nun auch darum mal zu schauen, wie dies denn mit Skalierung aussieht. Also vielleicht auf organisatorischer Ebene. Denn wie gut ist Dein Scrum, wenn zwei Teams miteinander am selben Produkt arbeiten?
Diese Folge auf YouTube: https://youtu.be/eXpaHuW5mpw
Das Thema Skalierung
Ich glaube für jede, die in der Agilen Welt auf der methodischen Seite arbeitet, kommt irgendwann das Thema Skalierung. Spätestens, wenn das eigene Team gut läuft und dies auf andere übertragen werden soll. Das wäre sogar ein toller Fall. Viel eher passiert es meist, dass Agilität für eine Abteilung vorgeschrieben wird und wir quasi bei Null anfangen zu skalieren. Der wahrscheinlichste Fall ist sicherlich, dass plötzlich zwei Teams oder mehr gemeinsam an demselben Produkt arbeiten und irgendwie Schnittstellen untereinander benötigen.
Hypothesen
Wie schon angedeutet, erkenne ich hauptsächlich zwei Stilrichtungen. Top Down, ein Chef befielt Agilität und damit direkt für den ganzen Bereich und Bottom Up, die Agilen Teams werden immer mehr und dürfen in der Zusammenarbeit koordiniert werden. Ein Mix aus beidem hat sich dabei schon als gut herausgestellt. Im Zweifel würden wir an der Znip Academy immer bevorzugen, dass erst die Teams gute Agilität leben, bevor skaliert wird.
Agil soll gar nicht skalieren?
Interessant ist vielleicht die Beobachtung, dass Agilität, zumindest zu Zeiten des Agilen Manifests für Softwareentwicklung, gar nicht skaliert werden sollte. Bzw. die Frameworks waren dafür gar nicht ausgelegt und auch im Scrum Guide oder in KanBan findet sich quasi nichts dazu. Erst die letzten Jahre wurde dieses Thema stark gehyped, da große Unternehmen, die nun Agil arbeiten, dies entsprechend in den Griff bekommen wollen.
Agilität war also ursprünglich für kleine schnelle Einsatzteams von weniger als 10 Personen gedacht. Skalierung ist nun genau das Gegenteil davon, oder vielleicht auch nicht? Das macht das macht Skalierung natürlich herausfordernd.
Nicht mit Skalierung anfangen
Von daher, liebe Leserin, fang nicht direkt mit Skalierung im Agilen Umfeld an. Sammle erst einmal Erfahrungen auf dem Teamlevel. Ohne Erfahrung und nur mit Theorie lässt sich Skalierung auch nicht erfolgreich umsetzen. Deshalb setzen wir beispielsweise in unserem Flexibilitätstraining auf mehr Wissen aus der Praxis. Hast Du ein Team bereits erfolgreich aufgebaut? Dann fein, go for it! 🙂
Hast Du Consultants im Unternehmen, die nur theoretisch gelernt haben, wie es funktionieren sollte? Wie sollen diese auf vielleicht unerwartete Probleme eingehen können, wenn etwas passiert, was so nicht im Buch steht? Erfahrung ist hier der entscheidende Faktor.
Skalierende Agile Frameworks
Skalierende Agile Frameworks sind Scrum@Scale, Scrum of Scrums, MIA, OKR, SAFe, LeSS, Flight Levels, Nexus, Spotify.
Diese sind natürlich nicht gleichrangig und haben alle ihre unterschiedlichen Vor- und Nachteile.
Produkte skalieren?
Janina Kappelhoff und Henry Schneider sind sich uneins ob es quasi von den Urvätern (ja ich brauche nicht gendern) der Agilität überhaupt skalierte Implementierungen gibt.
Also es gibt kein gemeinsam entwickeltes Modell. Dies stützt auch unsere These, dass es keine Blaupausen in der Agilität gibt und gerade in skalierten Umfeldern viel speziellerer Lösungen braucht. Es gibt von einigen der Erfinder trotzdem gute Vorschläge für Skalierungsmodelle und ich möchte unterstellen, dass die Werte und Prinzipien auch auf skalierte Umfelder Anwendung finden.
Janina vertritt die Meinung, und diese scheint valide, dass das Agile Manifest für Softwareentwicklung nicht für Organisationseinheiten geschrieben wurde und damit dort wahrscheinlich nicht funktioniert.
Abstimmung
Was nun häufig der erste Impuls bei der Skalierung ist: Termine zur Abstimmung der Teams untereinander einstellen. Ähnlich wie Steuerkreise. Das macht die Kalender voll und kann durchaus die richtige Lösung sein. Wir schlagen vor sich hier etwas mehr Zeit zu nehmen und zu schauen, wie die Information am sinnvollsten transportiert werden kann. #MeTime
Maximum?
Wie groß kann eine agile skalierte Einheit maximal sein? Hier gibt es sehr unterschiedliche Meinungen. SAFe und Huge LeSS sprechen beispielsweise von 500 Menschen und mehr. Gore-tex splittet seine Einheiten ab 200 Menschen in zwei auf. Ähnlich wie Zellteilung.
Das Buch „Das Erdmännchen-Prinzip“ von John Kotter gibt hierzu interessante Gedanken. Beispielsweise, dass Agilie Organisation vielleicht nur bis 35 oder 65 Personen gut funktionieren und es dann einen Mix aus Wasserfall und Agil braucht.
Janina leitet sogar die These ab, dass auf Organisationebene dadurch gar keine Agilität gibt. Interessante These!
Wie denn nun?
Wir sind jetzt nun an dem Punkt, egal wo es her kommt, dass wir als Team Facilitator oder Agile Master gefragt werden, wie denn nun die Skalierung funktionieren soll.
Hier dürfen wir uns die wesentlichen Fragen zum Unternehmen erst einmal stellen. Denn es lohnt sich am ehesten daran zu skalieren.
Womit verdient Dein Unternehmen Geld?
Wie sieht der Wertstrom aus?
Was ist das Produkt, welches alle eint?
Warum soll es überhaupt Agil sein?
Wo sind bekannte Bottlenecks?
Allein die Antworten auf diese Fragen werden schon krass viel für Dein Unternehmen klären und sicherlich auch ändern.
Vor allem Aktiengesellschaften tendieren dazu nur Rendite oder Profit als Ziel zu haben. Dies deckt sich vielleicht nicht mit dem, warum nun eine Organisationseinheit agilisert wird. Könntest Du das Skalierungsmodell an der Rendite ausrichten?
Wenn wir das nicht wissen, dann möchte ich von Skalierung abraten.
Genauso möchte ich davon abraten zu skalieren, bevor die Teams agil unterwegs sind. Denn alles was wir nun skalieren potenziert sich ins Unternehmen. Sitzen die Prinzipien also nicht sauber, so haben wir das in schlimmer im Skalierungssystem und dort wird es noch komplexer.
Zeithorizont
All das bedeutet auch, dass eine Skalierung mehrere Jahre in Anspruch nehmen kann. Dies ergibt sich auch unserer 6 Iterationen Logik. Nehmen wir an, wir haben ein OKR-Framework mit 3 Monatszyklen, dann bräuchte es 18 Monate bis das Framework halbwegs gut im Unternehmen funktioniert.
Gute Agile Coaches wissen so etwas und begleiten die Einführung und reagieren dynamisch auf Probleme, statt nur stur einen theoretischen Plan umzusetzen.
Es geht also nicht nur um eine stumpfe Einführung, sondern um die Erfahrung für die Menschen im System und das entsprechende Handwerkszeug. Deshalb sagen wir auch, dass die begleitenden Coaches auch Praxiserfahrung benötigen. Erfahrung die wir an der Znip Academy lehren und mitbringen.
TopDown
Es ist mitunter gut, wenn die Agile Organisationsentwicklung Managementunterstützung hat. Wichtiger ist dabei gleichzeitig, dass es auf dem Team Level genug Agile Master gibt, die wissen was sie tun und entsprechen auch gegenhalten können. Es ist also nicht damit getan, dass ein Berater ein Framework aussucht. Das ist sogar der ganz leichte Teil daran.
Management Attention sorgt dafür auf der anderen Seite eher für Ablenkung und PR-Veranstaltungen als für eine richtige Transformation. Dies ist vor allem hinderlich, da die Arbeit am Anfang nicht schneller, sondern eher langsamer geht. Denn wir dürfen erst einmal Lernen anders zu Denken und zu Arbeiten.
Automatisierung
In den letzten Folgen (beispielsweise über CI/CD) haben wir schon erwähnt, wie wichtig Automatisierung ist. Dies ist bei Skalierung noch einmal wichtiger und skaliert, wie bereits erwähnt auch sehr gut mit. Wenn es also eine gute Automatisierung gibt, dann befeuert sie die Skalierung noch einmal extra und umgekehrt.
Du weißt nicht was automatisiert werden soll? Wie läuft das Reporting in Deinem Unternehmen?
Abhängigkeiten
Der Hauptjob ist zu Beginn wahrscheinlich die Abhängigkeiten der Teams untereinander aufzulösen. Das ist nicht damit getan die Teams einfach cross-functional aufzustellen. Wirklich schauen wo die Teams ihre Schnittstellen miteinander haben. Ein gutes Indiz ist die Waiting Spalte.
Das ist übrigens auch etwas, was nicht funktioniert, wenn Hypothese 1 zutrifft. Also nur „von oben“ umstrukturiert wird.
Znipcast-Hack
Kleiner Hack, falls Du unsere Folgen teilen möchtest: Du kannst znipcast.de/<Folgennummer> verwenden. Also diese Folge ist znipcast.de/137
So brauchst Du nicht immer den kompletten Folgennamen beim Teilen als URL verwenden.
Get shit done,
Gefällt dir die Podcastfolge? Dann empfiehl sie gerne anderen weiter, z.B. indem du die Folge in deiner Story teilst. Wenn du magst verlinke @znip_academy_agile und wir teilen deinen Like mit unseren Hörern.
Du möchtest dich von uns in der Tiefe in eurem Veränderungsprozess begleiten lassen, eure größten Komplexitätsnester auflösen und die besten Teamtipps bekommen? Dann buch uns 😉
In der Podcastfolge erwähnte Folgen zur Vertiefung:
Connecte dich gerne hier mit uns:
