137 Skalierung

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/ verwenden. Also diese Folge ist
znipcast.de/137


So brauchst Du nicht immer den kompletten Folgennamen beim Teilen
als URL verwenden.


 


Get shit done,


Janina & Henry


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


Janinas Ultimativer OKR Guide


In der Podcastfolge erwähnte Folgen zur Vertiefung:


Scrum

Teams

OKR

Agilität

SAFe

Flight Levels

Agile Coaches

CI

CD

Waiting Spalte

cross-functional



Connecte dich gerne hier mit uns:


LinkedIn


Instagram


YouTube


Facebook


Webseite


Facebook-Gruppe


The post 137 Skalierung appeared first on Znipcast - für gute
Zusammenarbeit | Agile, Scrum, KanBan, Psychologie,
Teamentwicklung und NLP | Podcast der Znip Academy.