Schneller, höher, weiter!
Agile Entwicklung nach Scrum macht Spaß, und agile Entwicklung nach Scrum ist erfolgreich … wenn, man wirklich Scrum macht und agil arbeitet.
Das ist nicht so einfach, und vor allem bei einer agilen Transition ist die Gefahr groß, dass man ein paar Rituale, wie ein Daily, und ein Board einführt und schon hat man Scrum oder „macht“ agil. Glaubt man.
Auch wir bei congstar hatten eine steile Lernkurve. Zu Anfang der agilen Transition als Befreiungsschlag für ein Projekt, das congstar an den Rand des Abgrundes geführt hatte, waren die Teams verteilt, arbeiteten auf Plattformbasis der jeweiligen Dienstleister, und eine Integration der Komponenten fand erst am Ende der Entwicklungssprints statt, weil der Prozess dafür manuell und nicht erprobt war. Lückenhafte Testautomatisierung provozierte hohe manuelle Testaufwände und so entstanden Sprints mit „Mikro-Wasserfällen“. Die Umstellung auf (pseudo-) agil war ein Befreiungsschlag, um die Komplexität zu beherrschen und das Projekt zu retten, aber nur ein erster Schritt.
Die Fachbereiche sahen nach einem fast zweijährigen Innovationsstau, der durch das Projekt entstanden war, voller Erwartung auf die nächsten Releases und wollten mehr. Bald schon war klar, dass die Teams die Anforderungen nicht in der gewünschten Geschwindigkeit umsetzen konnten, und er kam der verständliche Ruf nach Skalierung, nach mehr Kapazität, mehr Features, mehr Teams.
Aber wir waren nicht bereit, und Gabrielle Benefield bemerkt ein einem Tweet so treffend:
Warum sind alle so versessen darauf Scrum zu skalieren, wenn sie Schwierigkeiten haben ein einzelnes Team ans Laufen zu kriegen?
Wir konnten die Organisation davon überzeugen, dass wir vor einer Skalierung unsere Hausaufgaben machen mussten. Die Rückendeckung der Geschäftsführung war hier eine wichtige Hilfe. Wir stellten notwendige Change Requests zur Implementierung einer ordentlichen Testautomatisierung und notwendiger Infrastrukturänderungen, die auch vom ganzen Unternehmen als höchste priorisiert wurden. Wir setzten Continous Integration mit Jenkins auf und automatisieren die Deployments, sodass die einzelnen Komponenten mehrmals täglich integriert und testbar waren. Eine effiziente Testautomatisierungsplattform wurde entwickelt und die wichtigsten Regressionstests in Abstimmung mit den Product Ownern automatisiert. So gelang es uns, die „Mikro-Wasserfälle“ abzuschaffen und zu einen effizienten Scrum Prozess zu kommen.
Jetzt waren wir so weit, vertikal skalieren zu können, also durch mehr Teams auch mehr Kapazität für die schnellere Umsetzung von mehr Anforderungen bereit zu stellen.
Vertikale Skalierung durch Zellteilung
Um möglichst effizient ein neues Team aufzustellen und an unsere Arbeitsweise heranzuführen, erweiterten wir die bestehenden Teams zunächst um neue Mitarbeiter, die dann im laufenden Prozess eingearbeitet wurden und wir für mindestens ein Release mit deutlich größeren Teams arbeiteten. Da die größten Bedarfe bei der Telko-Plattform lagen, begannen wir dort.
Dies führt zu Diskussionen, da die Product Owner Geschwindigkeitsverluste durch die Einarbeitung fürchteten und auch wahrnahmen. Für die Startphase der Einarbeitung meldeten sie also Kapazität ab.
Nach der Einarbeitung fand die sogenannte Zellteilung statt, bei der Alt und Neu gemischt wurden. Dabei war es uns wichtig, dass für alle Rollen, also Entwickler, Tester, Scrum Master und Product Owner es eine Mischung aus alten Hasen und neuen Kollegen in den Teams war. Bei den Entwicklern und Testern war das leicht, da es davon immer mehr als einen im Team gab. Bei den Scrum Mastern und Product Ownern achteten wir darauf, dass zumindest einer der beiden schon länger bei congstar war.
Der Skalierungsschritt von einem auf zwei Teams war dabei erfahrungsgemäß der Schwierigste, da die Abstimmungsnotwendigkeit des Teams nach außen von 0 auf 100 stieg, und – neben dem Teamgefühl – auch ein Wir-Gefühl zwischen den Teams, die auf einem System arbeiten, entstehen musste. Beim Schritt von zwei auf drei, wurde das einfacher und nahm mit jedem weiteren Team ab.
Skalierung gibt es nicht umsonst
Um den zusätzlichen Aufwänden und Reibungsverlusten durch die Teamerweiterung Rechnung zu tragen, reduzierten wir die Umsetzungskapazität pro Team, so dass ein nicht-linearer Zuwachs entstand.
Auf dieser Abbildung sieht man die Kapazität entlang der Releases, aufgeteilt nach der der Teams, die an der Telco-Plattform und der, die an der Web-Plattform arbeiteten. Die Kapazitätszunahme von 10.1 bis 11.5 war der Prozessverbesserung geschuldet. Mit dem Release 12.1 begann die Skalierung der Telco-Teams von 2 auf 3. Man sieht deutlich die Einarbeitungsdelle.
Zudem ist auch nach der Einarbeitung, die im Release 12.4 abgeschlossen war, erkennbar, dass die Kapazität nicht linear skaliert. Hatte rechnerisch ein Team eine Kapazität von 6 Einheiten, dann kommen drei nicht auf 18, sondern nur auf 17. Die entstehenden Abstimmungs- und Kommunikationsaufwände wachsen überlinear, da z.B. bei drei Teams, die auf einer Komponente arbeiten, sich jedes mit zwei anderen abstimmen muss und nicht nur mit einem.
Dieses Vorgehen hat sich bei weiteren Skalierungen bewährt.
Ab einer gewissen Gesamtteamgröße verschwand dann die Einarbeitungsdelle, da sie auf Grund der leichteren Verteilung der Einarbeitungsaufwände auf immer mehr Teams nicht mehr spürbar war und wir gute Routinen sowohl im Auswahl- als auch Einarbeitungsprozess für neue Teammitglieder bekommen haben.