Die Situation gibt es immer wieder: Lange Zeit sind technische Schulden kein Thema, bzw. werden ignoriert. Irgendwann wird die Entwicklung immer langsamer, es treten mehr und mehr Probleme auf. Technische Schulden kommen langsam ins Bewusstsein. Es beginnt die Diskussion, wie man sie in den Griff bekommen kann. Zu dem Zeitpunkt hat sich aber schon soviel angehäuft, dass einzelne Teams überfordert sind. Schließlich müssen neue Anforderungen ja weiter umgesetzt werden.

Wenn Umbauten mehrere Teams betreffen und zu groß sind, als dass einzelne Teams sie “nebenbei” bearbeiten könnten, taucht irgendwann ganz automatisch die Idee auf, ein dediziertes Plattform-Team zu gründen. Ein Plattform-Team kann sich dieser Themen annehmen und dafür sorgen, dass alle anderen Teams wesentlich reibungsloser arbeiten können.

Die Idee ist, dass jedes Team natürlich immer noch für technische Schulden und Refactorings in seinem eigenen Kontext verantwortlich bleibt. Das Plattform-Team übernimmt nur, wenn alle (oder zumindest mehrere) Teams betroffen sind.

Grundsätzlich klingt das erstmal nach einer guten Idee. Es ist eine Möglichkeit die technischen Schulden in den Griff zu bekommen und gleichzeitig die Entwicklung weiter voranzutreiben, ohne die Teams zu überlasten.

Die Erfahrung zeigt leider, dass trotz der guten Absichten in der Praxis ein anderer Effekt eintritt.

  • Die erfahrensten Entwickler/-innen aus den Entwicklungsteams werden abgezogen, um das Plattform-Team aufzubauen, schließlich handelt es sich um zentrale Komponenten, die für alle relevant sind. Das Wissen und die Erfahrung werden hier gebraucht. Trotzdem ist dieses Vorgehen problematisch, da damit oft tragende Personen aus den Teams gerissen werden. Das hat viele Konsequenzen: Die Teams müssen sich neu finden. Es entstehen automatisch Reibungsverluste und mehr technische Schulden. Die Arbeitslast der einzelnen Teammitglieder steigt. Probleme die durch die ausgleichende Art der erfahrenen Entwickler/-innen in den Teams verhindert wurden, treten jetzt regelmäßig auf.

  • Durch die Einführung eines Plattform-Teams entstehen zusätzliche Abhängigkeiten in der Entwicklung. Ist ein Plattform-Team für die zentralen Komponenten verantwortlich, heißt das im Umkehrschluss auch, dass ggf. andere Teams auf das Plattform-Team warten müssen. Andersherum kann es vorkommen, dass das Plattform-Team Lösungen baut, obwohl noch gar nicht klar ist, ob sie von den Teams so benötigt werden. Werden Anpassungen an zentralen Komponenten benötigt, müssen sie kommuniziert und beim Plattform-Team priorisiert werden, was die Entwicklungsteams weiter blockieren kann. Kurz gesagt, es gibt eine weitere Abhängigkeit der Entwicklungsteams nach außen, die sie bremsen können.

  • Zurücklehnen der Teams. Ein weiterer Effekt eines Plattform-Teams ist leider auch, dass sich einzelne Teams nicht mehr in der Verantwortung sehen, größere technische Schulden selbst abzubauen. Statt wie bisher aktiv nach Lösungen zu suchen und sich ggf. die Zeit für Refactorings beim Product Owner zu holen, lehnen sich Teams eher zurück. Das Gefühl der Eigenverantwortung verschwindet und wird ersetzt durch eine Abhängigkeit zum Plattform-Team. Das ist - aus unserer Sicht - eines der größten Risiken, da nur die Teams wissen, welche technischen Schulden wirklich relevant sind und wie sie zu lösen wären.

  • Die Ursachen der technischen Schulden werden nicht behandelt. Ein Plattform-Team kann dazu beitragen technische Schulden abzubauen, es kann aber nicht verhindern, dass neue technische Schulden entstehen. Ein möglicher Treiber für technische Schulden ist schlechte Kommunikation zwischen den Teams. Mit einem Plattform-Team würde ein solches Problem weiter verstärkt, statt es zu lösen. Um technische Schulden langfristig in den Griff zu bekommen, ist es essentiell die Hauptursachen für den Aufbau der technischen Schulden zu finden und zu lösen, ansonsten wird auch ein Plattform-Team nicht helfen.

Wenn man trotz dieser Probleme und Risiken ein Plattform-Team aufsetzen möchte, gilt es ein paar wesentliche Punkte zu beachten. So lassen sich eventuell einige der negativen Effekte reduzieren, die dabei entstehen können.

  • Das Plattform-Team bietet technische Services oder Komponenten an, die von den anderen Teams benötigt werden und ihnen erlauben ihren Code einfacher zu gestalten. Das kann z.B. eine Komponente zum Hochladen von Bildern oder zum Versenden von Push Notifications sein. Es sind also generische Komponenten, die man auch in der Open Source Welt finden könnte.

  • Das Team unterstützt die anderen Teams dabei die Services oder Komponenten in ihren Code einzubauen und so ggf. eigene Lösungen loszuwerden (in anderen Worten: Altlasten abzubauen). Damit ist das Plattform-Team nah an den Problemen und Anforderungen der Umsetzungs-Teams. Es wird wahrscheinlicher, dass nur die Dinge umgesetzt werden, die wirklich benötigt werden und die technischen Services/Komponenten am Ende wirklich nützlich sind.

  • Das Team wird um eine erfahrene Entwickler/-in herum aufgebaut. Es sollte auf keinen Fall dazu kommen, dass zu viele (erfahrene) Entwickler/-innen aus den bestehenden Teams herausgenommen werden. Das heißt auch, lieber mit einem sehr kleinen Team zu starten statt zu viel Unruhe in alle anderen Teams zu bringen.

  • Alle technischen Komponenten sind Inner Source (intern Open Source), um Abhängigkeiten zwischen den Teams zu minimieren. So kann jedes Team, statt auf die Umsetzung seiner Anforderungen zu warten, sich mit dem Plattform-Team abstimmen und dann selbst in die Umsetzung gehen.

Es gibt noch viele weitere Fragen, mit denen man sich beschäftigen sollte, bevor man den Schritt in Richtung Plattform-Team wirklich geht, wie zum Beispiel:

  • Wie kann man sicherstellen, dass das Plattform-Team an Themen arbeitet die wirklich relevant sind?
  • Wie kann man sicherstellen, dass keine Kommunikationslücke zwischen dem Plattform-Team und den Produkt-Teams entsteht?
  • Wie kann man sicherstellen, dass das Plattform-Team nicht als ‘Elite-Team’ wahrgenommen wird oder sich selbst als solches sieht?

Insgesamt stehen wir dem Thema Plattform-Team recht skeptisch gegenüber. Wir sehen verschiedene Vorteile, die sich ergeben können. Es gibt sicher Unternehmen und Situationen in denen ein Plattform-Team genau der richtige Schritt sein kann. Trotzdem bleiben viele Risiken, die dazu führen können, dass ein Plattform-Team mehr Probleme schafft als es löst.

Live Webinar: Softwareentwicklung skalieren, ohne sich im Wachstumsprozess aufzureiben

„Im Webinar wurden genau die Pain Points angesprochen, die in unserem Wachstum gerade auftreten. Bei stetig steigender Zahl an Mitarbeitern im Dev & Product Team mussten wir selbst feststellen, wie schwierig es ist, eine sinnvolle Struktur aufzubauen, die bei jedem das Maximum an Effizienz und Leistung hervorbringt und gleichzeitig zu einer gesunden Arbeitsatmosphäre führt.”
Pascal von Briel, Co-Founder & CPO @ exporto GmbH