Mitch Rauth | 25.04.2013| iqnite Deutschland 2013 | Düsseldorf, Deutschland
Ausgangslage
congstar wurde Mitte 2007 als Tochterfirma der Telekom Deutschland gegründet, um als Zweitmarke neue Kundenkreise in Deutschland zu adressieren. Damit das Unternehmen schnell auf dem Markt war, richtete man auf einem bestehenden System aus dem Festnetzbereich einen entsprechenden Mandanten ein, um die Kunden technisch verwalten zu können. Das klappte hervorragend und lief sehr stabil und verlässlich, brachte aber den Nachteil mit sich, dass die dahinter liegenden Governance Prozesse auch sehr stabil und verlässlich waren und so gar nicht zu einem StartUp passten. Jede Produktänderung oder Anpassung der Website dauerte viele Monate bis zu mehr als einem Jahr.
Dies erlaubte nicht die Entwicklung der Marke mit der notwendigen Geschwindigkeit, sodass die Geschäftsführung sich Mitte 2008 dazu entschied, den gesamten Software Stack im laufenden Betrieb auszutauschen und zu einer passenderen Infrastruktur zu wechseln. Da es in der kleinen Firma congstar keine eigene IT-Organisation gab, wurde ein Generalunternehmer mit der Umsetzung des Projektes beauftragt. Dieser setzte das Projekt klassisch auf, entwarf eine kleinere und modularere Systemlandschaft und plante die notwendige Migration. Der Betrieb auf der bisherigen Plattform wurde zum 01.07.2010 gekündigt.
Es kam, wie es kommen mußte, und Ende 2009 war das Projekt in einer essentiellen Krise. Die Plattformkomponenten standen bereit, es gab einen Projektplan, der aber nichts mehr mit der Realität zu tun hatte, es war unklar, was fertig entwickelt, was fertig getestet war, und congstar stand vor dem Rande des Abgrundes.
Die agile Transition … Scrum but!
Die Ruhe der Weihnachtsferien nutzte das congstar Management, um mehrere Veränderungen auf den Weg zu bringen. Dem Generalunternehmer wurde gekündigt, eine eigene IT aufgebaut und, um der Komplexität und dem Chaos Herr zu werden, die Arbeitsweise von Wasserfall auf ein iteratives, agiles Vorgehen umgestellt.
Einer unserer Partner, der für einen Teil der Systemlandschaft verantwortlich war, arbeitete bereits mit Scrum und beriet uns. Wir holten uns externe agile Coaches ins Haus, stellten alles auf Scrum um, und gründeten drei Teams. Die Geschäftsprozesse wurden in ein Backlog gebracht und priorisiert, und Anfang 2010 nahm die neue Organisation die Arbeit auf.
Die Ausgangslage erlaubte nicht, Scrum nach dem Lehrbuch einzuführen, sondern zwang uns zu Scrum but!
- Wir hatten drei Entwicklungsteams, die über mehrere Standorte und zwei Länder verteilt waren.
- Die Qualitätssicherung basierte auf einem Testfallkatalog mit mehr als 1500 Testfällen und war rein manuell.
- Da jedes Team nach Scrum arbeitete, es aber keine permanente Integration der Softwareartefakte gab, folgte noch ein Verbundtest, der durch ein eigenes Testteam durchgeführt wurde.
Unsere drei Teams arbeiteten also parallel an den Sprintinhalten, nach zwei Sprints übergaben sie die Artefakte an die Integration, und es folgte ein vierwöchiger Qualitätsairbag in Form eines Verbundtests. Nach zwei Monaten war die Software dann releasefertig:
Das hatte nur sehr beschränkt mit Scrum zu tun. De facto arbeiteten wir in Mikrowasserfällen.
Dennoch gelang es uns durch dieses Vorgehen die Software zu stabilisieren, die Migration durchzuführen und kurz vor der Abschaltung des Altsystems live und produktiv zu sein. congstar war gerettet, obwohl es noch eine Menge an Nacharbeiten gab, sei es Fehler zu bereinigen, aber auch noch niedrig priorisierte Geschäftsprozesse fertig zu bauen.
Für die Anforderer endete damit ein achtzehnmonatiger Innovationsstau, und es gab eine lange Liste von Änderungswünschen, die wir nun auf der neuen Plattform umsetzen konnten. Alle zwie Monate ein Release zu haben war eine deutliche Verbesserung gegenüber dem Zustand mit dem Altsystem, aber natürlich wollten die Fachbereiche schnell mehr und mehr Erweiterungen und Umsetzungen und riefen nach Skalierung.
Einfach ein weiteres Team hinzuzufügen verbot sich, da der Aufwand durch die Integration im Quality Airbar überlinear stieg, und die Kosten nicht vertretbar waren.
Dadurch, dass mit jeder Iteration immer mehr Code entstand, der manuell getestet werden mußte, wurden die Testphasen immer länger, und die Entwicklungskapazität und der Durchsatz der Teams sanken. De facto sank die Effizienz, und dieser Ansatz war nicht skalierbar.
Bei einen neuen Produktlaunch im Frühjahr 2011 kam es dann zur Krise, da die notwendigen Änderungen dazu groß und komplex waren und nur so eben fertig wurden. Selbst im Quality Airbag mußte noch weiter entwickelt werden.
Die späten Änderungen konnten nicht mehr ausreichend getestet werden, und das Produkt brauchte 34 Hotfixes nach Launch, um einigermaßen produktionsfähig zu sein.
Die Firma, und insbesondere die Fachbereiche, stellte daher die Frage, ob denn Scrum als Entwicklungsmethode für die congstar überhaupt brauchbar sei, oder man nicht besser wieder planbarere Ansätze verfolgen sollte.
Wenn Scrum, dann bitte richtig!
Wir zeigten auf, dass die aktuelle Situation eine Folge der agilen Transition war, und wir diese nicht wirklich abgeschlossen hatten. Das agile Arbeiten und Scrum funktionieren sehr gut, aber eben auch nur dann, wenn wir auch wirklich agil entwickeln und Scrum richtig gemacht wird.
Den vollen Benefit von Scrum könnten wir nur heben, wenn wir
- täglich die Software integrieren und den Verbundtest in die Sprints bringen.
- die Tests schnell und automatisiert durchführen.
- nach jedem Sprint potentiable shippable Software haben.
Wir machten den Anforderen klar, dass dazu Arbeiten notwendig sind und reservierten Entwicklungskapazitäten, um die technischen Grundlagen zu schaffen.
Für die kontinuierliche Integration der Softwarekomponenten installierten wir eine Build Pipeline mit Jenkins.
Testautomatisierung ist die Basis jeder agilen Entwicklung
Und wir bauten ein Testautomatisierungsframework aus Open Source Komponenten und Eigenentwicklung
Dieses hatte zum Ziel modular, erweiterbar, multi-release-fähig, multi-user-fähig und vor allem wartbar zu sein.
Als diese Voraussetzungen geschaffen worden waren, ging es darum die Tests auch zu automatisieren, was bei inzwischen fast zweitausend manuellen Testfällen nicht einfach war.
Wir stellten also selber Change Requests ein, um gegenüber den Fachbereichen Transparenz zu erzeugen und die Product Owner mit ins Boot zu holen.
Die Product Owner aktualisierten die Prioritäten der Geschäftsprozesse und wählten für die Prio 1 Prozesse die damit verbundenen Testfälle aus. Diese zu automatisieren wurde dann Gegenstand der Testautomatisierungs Change Requeste.
Zusätzlich erweiterten wir die Definition of Done, also den Vertrag zwischen dem Team und dem Product Owner, der besagt, wann eine Anforderung „fertig“ ist, um den Passus
… zu jedem Change Request existieren automatisierte Tests, die die Nachhaltigkeit sichern.
Effekte der Testautomatisierung
Die Umsetzung dieser Maßnahmen dauerte zwei Releases.
Dadurch, dass die Software jetzt permanent integriert wurde und alle Arten von Tests in den Sprints statt fanden, sowie nach jedem Bau der Software die automatisierten Tests direkt dem Team eine Rückmeldung über die Qualität der Software gaben, lösten sich die Mikrowasserfälle auf, und Tests fanden permanent und parallel zur Entwicklung statt.
Das erlaubte im ersten Schritt den Quality Airbag auf zwei Wochen zu verkürzen, um ihn dann ganz aufzulösen und durch eine Woche Release Sprint zu ersetzen.
Die Tester hatten dadurch mehr Zeit für andere Testaufgaben, wie explorative Test Sessions und eine engere Einbindung der Fachbereiche. Die Entwickler erkannten die Vorteil ebenfalls schnell und lernten die Software so zu bauen, dass sie sich gut automatisiert testen ließ, und begannen auch verstärkt Tests auf Unitebene zu bauen.
Das führte nicht nur zu deutlich besserer Qualität, sondern auch zu einer Kapazitätserhöhung.
Die Anzahl der Hotfixes reduzierte sich auf durchschnittlich drei pro Release, und die Kapazität der Entwicklung in den drei Teams verdoppelte sich beinahe, da in einem Release mehr Zeit für Entwicklung zur Verfügung stand. Dadurch konnten deutlich mehr Anforderungen pro Release umsetzen. Neue Produkte waren früher am Markt und generieten zusätzliche Einnahmen. Einen Teil dieses Gewinnes konnten wir jetzt in weitere Entwicklungsteams investieren und damit wirtschaftlich sinnvoll skalieren.
Ausblick
Die agile Transition in der Entwicklung war geschafft, das Vertrauen der Anforderer in die Fähigkeiten der Teams und in Scrum gewonnen, und congstar konnte seine Erfolgsgeschichte weiter fortschreiben.
Dennoch gibt es jetzt noch einiges zu tun.
- die automatisierten Tests laufen noch recht lange, sodass ein Gesamtlauf nur nachts stattfinden kann. Hier gilt es mehr Fokus auf die Testautomatisierungspyramide zu legen und teure Ende zu Ende Tests zu minimieren und durch mehr Schnittstellen und vor allem Unit- und Komponenten-Tests zu ersetzen.
- Die Testauswertung muß intelligenter und mit dem Code verlinkt werden, sodass der Weg vom fehlgeschlagenen Testfall zur verursachenden Stelle im Source Code kürzer und effizienter wird.
- Die Aktivitäten des Release Sprints gilt es in die Sprints zu verlagern, um die Releases noch weiter verkürzen zu können.
- Wir haben gelernt, dass die weitere Skalierung jetzt durch die Architektur behindert wird und nicht mehr durch die Arbeit der Teams, und insbesondere die Qualitätssicherung, was uns vor neue Herausforderungen stellt.