Das Team ist hochkarätig besetzt: Einige der erfahrensten Software-Entwickler:innen sind dem Aufruf eines technischen Managers gefolgt, mit problematischen, technischen Altlasten aufzuräumen. In der Vergangenheit waren verschiedene Versuche gescheitert. Dieses starke Team soll nun einen Weg finden, die Probleme zu lösen, die den Entwickler:innen schon viel zu lange Kopfschmerzen bereiten und eine effizientere Entwicklung verhindern.

Das Team stammt aus allen Teilen der Organisation. Drei Dinge verbinden die Teammitglieder:

• Sie sind handverlesen und die Herausforderung reizt sie.
• Sie sind nicht länger bereit, den aktuellen Zustand als unabänderbar zu akzeptieren.
• Sie sind entschlossen, im Bestandssystem aufzuräumen.

Den Frust unseres Teams dürften viele IT-ler:innen nachempfinden können: In 28,6% aller Firmen verursachen Wartung und Betrieb der Bestandssysteme einen höheren oder sogar deutlich höheren Aufwand, im Vergleich zu anderen Anwendungen. Und in gut 44% machen diese monolithischen Altsysteme mindestens 50% der geschäftskritischen Anwendungen aus (siehe Legacy-Modernisierung 2022), genau wie in unserem Beispiel.

Der anfängliche Enthusiasmus wich bald Ernüchterung: Das Projekt kam nicht in Fahrt. Es war schwierig, überhaupt ein plausibles Vorgehen zu entwerfen, denn es kamen immer wieder andere Themen dazwischen. Nach etwa sechs Monaten Arbeit auf anderen Baustellen – und ohne erkennbaren Fortschritt beim Kernthema – mehrten sich im Team die Stimmen, die den Sinn des ganzen Unterfangens bezweifelten.

Zu diesem Zeitpunkt hatte ich das Team schon einige Zeit als Agile Coach begleitet. Aus dieser Rolle heraus schlug ich dem verantwortlichen technischen Manager vor, die für mich erkennbare Abwärtsspirale aus Selbstzweifeln zu unterbrechen und in die Offensive zu gehen. Wir vereinbarten, in einem Workshop zu klären, ob es ein klares Mandat aus dem Unternehmen gibt – oder nicht. Im Folgenden schildere ich die überaus wechselhaften Stationen des anspruchsvollen Change Projekts, die zu diesem Workshop führten.

In diesem Beitrag erleben Sie mit, wie sich Teamstrukturen und Software-Architektur gegenseitig beeinflussen, was das mit den hier skizzierten Herausforderungen zu tun hat und welches Vorgehen dem Team geholfen hat, konstruktiv mit der Situation umzugehen.

Die Vorgeschichte

Das betreffende Unternehmen betreibt einen virtuellen Marktplatz für Immobilienfinanzierungen. Die Kunden an diesem Marktplatz sind einerseits Finanzierungsvermittler und andererseits Banken mit ihren Finanzierungsprodukten.

Der Marktplatz ist als digitale Plattform umgesetzt; diese wurde über einen längeren Zeitraum aufgesetzt und kontinuierlich weiterentwickelt. Verantwortlich für sie sind mehrere interdisziplinär zusammengesetzte Teams. Zu deren Aufgabengebieten gehören u. a. Software-Entwicklung, Produktmanagement und UX-Design.

In der Vergangenheit waren diese Teams entlang fachlich-technischen Überlegungen strukturiert. Dies erleichterte es, klare Verantwortlichkeiten zu schaffen und die Arbeit zwischen den Teams aufzuteilen.

Die Problematik der Kernkomponenten

Entsprechend verantworteten einzelne Teams jeweils einen Teil der Basis des Programmcodes. Daneben entstand eine ganze Reihe Kernkomponenten (Bild 1), in welchen übergreifende Funktionalitäten gebündelt wurden, die jeweils für viele Teams relevant waren (z.B. Nutzerauthentifizierung, E-Mail-Versand oder zentrale Datenbanken).

Die Verantwortung für diese Kernkomponenten teilten sich die Teams. Auch bei anderen Komponenten gab es gegenseitige Abhängigkeiten. Allerdings gab es hier eindeutige Zuständigkeiten. Bei den Kernkomponenten nicht.

Dieser Ansatz funktionierte jahrelang gut. Mit der Zeit wurden jedoch Probleme sichtbar, die eine Veränderung erforderten: Einerseits war die Struktur stärker orientiert an praktischen internen Erwägungen als an Markterfordernissen. Dies führte dazu, dass an der Umsetzung von Kundenanforderungen teilweise mehrere Teams arbeiteten, die sich untereinander abstimmen mussten. Diese Koordination war aufwendig. Der Abstimmungsbedarf und die gegenseitigen Abhängigkeiten führten manchmal zu langen Umsetzungszeiten und reduzierter Flexibilität beim angemessenen Reagieren auf Marktveränderungen.

Gleichzeitig wurden im Laufe der kontinuierlichen Wartung und Weiterentwicklung ursprünglich klar erkennbare Architekturgrundsätze immer weiter aufgeweicht. Aufgrund dessen war die gewachsene Software-Architektur immer schwieriger zu verstehen. Bei Veränderungen mehrten sich die bösen Überraschungen, wenn eine Anpassung an einer ganz anderen Stelle unvorhergesehene Probleme auslöste. Dieser Umstand resultierte in weiteren Verzögerungen bei der Umsetzung von neuen Themen und damit in reduzierter Reaktionsfähigkeit.

Näher an den Markt durch eine neue Struktur