Die Ausgangslage
Als wir dazukamen, war das Unternehmen ein Start-up mit 4 Leuten, wenig Know-how und begrenztem Budget. Um ohne großes Risiko entwickeln zu können, kamen externe Entwickler dazu. Dafür war viel Vertrauen nötig, auf beiden Seiten.
Über mehr als fünf Jahre ist daraus ein Mittelständler mit knapp 200 Leuten und rund 1.000 Kunden geworden. Dazwischen hat ein Investor vier einzelne Unternehmen gekauft und zu einem zusammengelegt. Danach mussten rund 12 Teams irgendwie zusammenarbeiten.
Wie sich der Engpass gezeigt hat
Am Anfang hatte das Team keine Ahnung, wie es sich bei dieser Art von Arbeit organisieren muss. Der Product Owner wurde schnell zum Flaschenhals: Er musste viel Projektmanagement machen, war gut im Umgang mit Stakeholdern, kannte aber kaum Methoden. Es gab genau einen Dev-Lead, über den alles lief. Sprints liefen ohne Daten und ohne Experimente, die Produktentwicklung war eher ziellos.
Nach der Fusion kamen vier Firmenkulturen dazu. Das neue Unternehmen kam nicht ins Laufen und nicht ins Liefern, nicht einmal Discovery hat funktioniert.
Woher er kam
Die Struktur war für vier Leute gebaut und nie mitgewachsen. Nach der Fusion lebten die alten Strukturen der vier Unternehmen einfach weiter. Jedes hatte seine Technik passend zur eigenen Organisation gebaut, genau so, wie es Conways Gesetz beschreibt. So entstanden vier Tech-Stacks, die dieselben Dinge doppelt entwickelten, obwohl die Fusion gerade das Teilen von Ressourcen möglich gemacht hätte. Der Tech-Stack hinkte außerdem den Kundenwünschen hinterher.
Was wir gemacht haben
Organisation
Wir haben die Organisation am gemeinsamen Kundenwertstrom neu geschnitten und die Teams auf durchgängige Business Cases ausgerichtet. Die Stellung des einen Dev-Leads haben wir aufgebrochen, damit Entscheidungen nicht mehr an einer Person hängen. Die Entwicklerorganisation haben wir komplett aufgebaut und strukturiert, mit DevOps, UI, Test, Entwicklung und Data.
Top- und Middle-Management haben gelernt, agile Teams lateral zu führen. Direkte Kommunikation haben wir eingefordert und vorgelebt, bis sie selbstverständlich war.
Prozess
Scrum haben wir eingeführt und später noch einmal korrigiert, als klar war, was nicht passt. Mit dem Wachstum auf rund 12 Teams kamen Elemente aus Scrum of Scrums, LeSS, SAFe und OKR dazu, jeweils nur so weit, wie sie geholfen haben. Die Product Owner haben wir über OKRs und agiles Portfoliomanagement auf gemeinsame Ziele ausgerichtet.
Refinement wurde einfacher und praktischer, Sprints bekamen Ziele. Reviews haben wir so gestaltet, dass auch der Vertrieb etwas mit dem anfangen konnte, was die Entwicklung gebaut hat.
IT
Den Tech-Stack haben wir auf die nächste Wachstumsstufe gebracht: ein gemeinsamer Stack mit Java, Spring Boot und Vue.js, eine AWS-Strategie mit Docker und Terraform und eine zentrale Lösung für Kundendaten und Identitäten. Die doppelt entwickelten Systeme haben wir schrittweise zusammengeführt, unter anderem mit dem Strangler-Fig-Pattern. Den Source Code haben wir aufgeräumt und ehrlich gemacht.
Was davon bleibt
Das Operating-Modell passt zum Kunden, seinem Markt und seinen Leuten und funktioniert dort heute noch gut. Die Teams planen strategisch und taktisch, ihr Outcome ist vorhersagbarer geworden. Auch Ab- und Zugänge im Team lassen sich seitdem gut verkraften.
