Team-Setups in größeren Projekten: teamübergreifend liefern

Moderne Features passen nicht mehr in ein einzelnes Team. Das ist längst normal. 

Ein IoT-Device sendet Events. Ein MQTT-Service leitet sie weiter. Eine Mobile App zeigt sie an. Dazu kommen Deployment auf AWS, ein Datenbank-Schema, Push Notifications, UX für die Edge-Cases, IT Security für Authentifizierung und Datenschutz, und Operations für drei Umgebungen. 

Das sind fünf bis sechs Disziplinen. Viele Unternehmen haben dafür getrennte Teams. Und genau da fängt das Problem an. 

Das Paradoxon: „you build it, you run it“ – aber die Teams sind getrennt

„You build it, you run it“ ist ein sauberes Prinzip. Werner Vogels hat es 2006 in einem ACM-Queue-Interview populär gemacht: Das Team, das die Software baut, betreibt sie auch.¹ Kein „über den Zaun werfen“ an ein separates Operations-Team. 

Das funktioniert nur, wenn ein Team die Sache auch von Anfang bis Ende können darf. Wenn Development, UX, Operations und Architecture in getrennten Abteilungen mit eigenen Prioritäten sitzen, verschwindet die Ende-zu-Ende-Verantwortung im Abstimmungs-Overhead. 

Ich beobachte im aktuellen Projekt genau diese Entwicklung: UX, Operations und Architecture werden aus den Entwicklerteams herausgelöst. Die Abstimmung fehlt oder ist nur mühsam möglich. Unterschiedliche Prioritäten führen zu Verzögerungen. Fehlende Informationen kosten Zeit. 

Meine Schätzung aus der Praxis: Hätten wir unser IoT-Feature (Device → MQTT → Push Notifications → Mobile App) über vier separate Teams mit jeweils eigener Roadmap umgesetzt, hätten wir allein durch Abstimmung und konkurrierende Priorisierung mindestens 30 % mehr Zeit verloren. 

Der Grund ist strukturell. Conway hat schon 1968 beschrieben, dass die Architektur eines Systems die Kommunikationsstruktur der Organisation abbildet.² Wer die Zusammenarbeit an einem Feature auf getrennte Teams verteilt, bekommt ein Feature, das an genau diesen Grenzen bricht. 

Die Lösung: Ein Team mit echtem Durchsatz

Wir haben es anders gemacht. Ein Team war im Lead – eher zufällig, weil es die Fäden zusammenhalten konnte: notewendige Fähigkeiten, den Kontext und die Kapazität. 

Das zeigt einen wichtigen Punkt: Diese Rolle muss nicht formal vergeben werden. Sie ist eine Kapazität, keine Hierarchie. Das Team konnte sich frühzeitig mit Problemen befassen und konnte schnell reagieren, weil es einen Überblick für alle anderen Disziplinen erschaffen konnte. 

In der Sprache von Team Topologies ist das ein stream-aligned Team: entlang eines Wertstroms aufgestellt, cross-funktional, verantwortlich vom Konzept bis in den Betrieb.³

On-site Coworking: der konzentrierte Block

Teams wurden an einen Tisch geholt. Vor Ort, ein bis zwei Tage wurde intensiv am Durchstich gearbeitet. 

Das war Nase-an-Nase-Arbeit statt Meeting-Marathon. Zusammen mit UX wurde geklärt, was die App bei einem Verbindungsabbruch zeigen soll. Der Prototyp wurde erst als PoC aufgesetzt, später flossen diese Erkenntnisse in Terrraform Scripte. Architektur-Fragen zu den Schnittstellen wurden am Whiteboard entschieden. 

Ein konzentrierter Block ersetzt Wochen aus Nachrichten-Pingpong. Danach hatten wir einen ersten Durchstich – den Kern des Features, der end-to-end funktioniert. 

Konzepte als Vorschlag, nicht als Vorgabe

Das Lead-Team hat ein technisches Konzept erarbeitet: MQTT-Topic-Struktur, Push-Notification-Flow, Datenbank-Schema, Deployment-Strategie. Alles dokumentiert und begründet. 

Dieses Konzept ging als Vorschlag an die anderen Teams. Sie haben ihre Expertise eingebracht: „Für unseren Use-Case brauchen wir hier noch X.“ – „Das Schema passt nicht zu unserer Infrastruktur, geht auch Y?“ 

Das ändert die Dynamik. Alle Beteiligten sind in das gleiche Konzept investiert, statt eine fremde Vorgabe umsetzen zu müssen. Team Topologies nennt so eine enge, zeitlich begrenzte Zusammenarbeit „Collaboration“ – hoher Durchsatz, bewusst befristet.[^3] 

IT Security gehört von der Konzeptionsphase an ins Team

Eine Disziplin fehlt in den meisten Aufzählungen dieser Art noch: IT Security. Sie nimmt eine immer größere Rolle ein – und genau wie UX oder Operations funktioniert sie nur, wenn sie teamübergreifend mitgedacht wird. 

Der übliche Fehler: Security wird von außen im Nachhinein definiert. Ein Architektur-Review nach der Umsetzung, ein Pentest kurz vor dem Launch, eine Checkliste, die am Ende abgehakt wird. Das Problem dabei ist nicht die Sorgfalt der Prüfung, sondern der Zeitpunkt. Wer Sicherheitsanforderungen erst stellt, wenn die Architektur schon steht, bekommt Nachbesserungen statt eines sicheren Designs. 

Wenn Software von Grund auf sicher sein soll, muss das in der Konzeptionsphase passieren – mit allen beteiligten Parteien am Tisch. Bei unserem IoT-Feature bedeutete das: Wie authentifiziert sich das Device? Welche Daten dürfen im MQTT-Payload überhaupt stehen? Wie wird die Push-Notification-Pipeline gegen Missbrauch abgesichert? Solche Fragen lassen sich nicht sauber beantworten, wenn Security erst nach dem ersten Durchstich dazukommt. 

Auch hier gilt dasselbe Muster wie bei den anderen Disziplinen: Je schwieriger die Abstimmung, desto größer die Gefahr, dass Lücken entstehen – nicht aus Nachlässigkeit, sondern weil niemand mit dem vollen Kontext zur richtigen Zeit am Tisch sitzt. 

Terraform für schnelle Änderungen

Ein großes Problem bei teamübergreifenden Features sind die vielen Umgebungen: Test, Integration, Produktion – jeweils eigene Konfiguration und Secrets. 

Wir haben alles in Terraform gepackt. Änderte sich etwas – eine neue Queue, ein anderer Lambda-Timeout, ein zusätzliches SNS-Topic – passte das Lead-Team das Script an und deployte in Minuten. Kein manuelles Klicken in der AWS-Console, kein JIRA Ticket, keine Wartezeit auf ein anderes Team. Zudem waren Änderungen für jeden transparent nachvollziehtbar. 

Learnings aus der Testphase liefen so direkt nach Integration und dann in Produktion. Änderungen am Setup und die Deployments der einzelnen Umgebungen waren eine Sache von Minuten, nicht von Tagen. 

Kontinuierlich lernen: von der Testphase in den Betrieb

Nach dem Launch wurde es interessant. Wir haben beobachtet, wo die Last lag, welche Notifications wirklich nötig waren und wo die Latenz Probleme machte. 

Jede Erkenntnis konnten wir schnell umsetzen, weil dasselbe Team mit demselben mentalen Modell weiterarbeitete. Die Learnings aus der ersten Testphase nutzen wir bis heute für die Optimierung im produktiven Betrieb – das spart echtes Geld: weniger AWS-Kosten, weniger Datenbank-Last, bessere User Experience. 

Hätte nach dem Launch ein anderes Team den Betrieb übernommen, wären diese Optimierungen deutlich langsamer oder gar nicht gekommen. 

Wissen und Verantwortung lassen sich nicht auslagern – auch nicht an KI

Ein Einwand liegt nahe: Lässt sich das Kontextwissen nicht dokumentieren und weiterreichen – notfalls von einer KI aufbereitet? 

Meiner Erfahrung nach nicht vollständig. KI kann Dokumentation zusammenfassen, Muster erkennen und beim Onboarding helfen. Das Wissen, das einzelne Personen während der Entwicklung aufbauen – warum eine Entscheidung so und nicht anders fiel, welche Edge-Cases bewusst in Kauf genommen wurden, welche Sackgassen schon getestet sind – steht in keinem Dokument vollständig. Es entsteht im Tun und lebt in den Köpfen der Beteiligten. 

Echte Verantwortung kann deshalb nur das Team übernehmen, das an der Entwicklung selbst beteiligt war. Verantwortung setzt Verständnis voraus, und Verständnis entsteht durch Beteiligung. 

Daraus folgt eine praktische Empfehlung: Wenn den Betrieb am Ende ein separates Team übernehmen soll, dann sollten dessen Mitglieder sich schon während der Entstehung aktiv einbringen – als Teil der Coworking-Sessions und der Konzeptarbeit, nicht als Zuschauer in einem Übergabe-Meeting. So wandert das Wissen mit den Menschen, nicht nur mit den Dokumenten. Das deckt sich mit der DORA-Forschung: Hohe Delivery-Performance entsteht durch geteilte Verantwortung über den gesamten Lebenszyklus, nicht durch isolierte Ownership einzelner Abteilungen.⁴

Das liegt auch daran, wie sich Wissen über den Lebenszyklus einer Software entwickelt: nicht statisch, sondern quasi Event-basiert. Jede Entscheidung, jeder Incident, jedes Learning aus dem Betrieb verändert den Kontext ein Stück weiter. Ein Übergabe-Dokument kann immer nur einen Snapshot festhalten – den Zustand zu einem bestimmten Zeitpunkt. Das ist besser als nichts, aber ein Teil des Gesamtkontextes geht dabei zwangsläufig verloren, weil die Ereignisse danach nicht mehr im Dokument ankommen, sondern nur noch in den Köpfen derer, die sie erlebt haben. 

Das führt zu einer Unterscheidung, die für die Bewertung solcher Setups entscheidend ist: Betrachtet man den Lebenszyklus eines einzelnen Softwarebausteins, oder den Lebenszyklus des ganzen Features – teamübergreifend, über mehrere Plattformen und Komponenten hinweg? Der Lebenszyklus einer einzelnen Software für sich genommen hat deutlich weniger Wert. Er beantwortet nur, was ein Teil des Systems tut, nicht, warum das Feature als Ganzes so funktioniert, wie es funktioniert. Erst der durchgängige Blick über alle beteiligten Teams und Komponenten macht den Kontext vollständig – und genau dieser durchgängige Blick geht verloren, wenn Wissen an Team- oder Systemgrenzen per Snapshot übergeben wird, statt kontinuierlich mitzuwachsen. 

Warum das funktioniert

Der Engpass bei teamübergreifenden Features liegt selten in der Technik. Er liegt im fehlenden gemeinsamen mentalen Modell. 

Arbeiten fünf Teams unabhängig, haben sie fünf verschiedene Vorstellungen vom System: fünf verschiedene Annahmen über Schnittstellen, Toleranzen und Zuständigkeiten. Die Koordination selbst wird zur Fehlerquelle. 

Ein Lead-Team mit Zugriff auf alle Disziplinen schafft eine gemeinsame Quelle der Wahrheit: eine konsistente Vision, iterativ verbessert durch das Feedback der anderen Expert:innen. On-site Coworking verdichtet die Abstimmung. Terraform erlaubt schnelle Iterationen ohne Genehmigungsschleifen. Kontinuierliches Monitoring hält das Team lernfähig. 

Das ist bekannt, wird aber oft übersehen

Team Topologies, Squad-Modelle, cross-funktionale Teams – all das ist gut dokumentiert.[^3] Trotzdem halten viele Organisationen daran fest, Operations in der Ops-Abteilung, UX im Design und Development im Engineering zu belassen. 

Für stabile, gut verstandene Features trägt das. Für neue Features, deren Richtung sich mit jedem Learning ändert, bremst es messbar. Der Grund sind die Strukturen, nicht die Menschen. 

Fazit

Wenn dein nächstes größeres Feature mehrere Disziplinen braucht, hat sich für uns dieses Vorgehen bewährt: 

1. Ein Lead-Team: die Gruppe, die den Kern zusammenhält – praktisch, ohne Hierarchie, mit Zugriff auf die nötigen Expert:innen.
2. Konzentrierter Block: ein bis zwei Tage on-site, um das gemeinsame mentale Modell aufzubauen.
3. Konzept als Vorschlag: die Expertise der anderen Teams integrieren, statt sie zu überstimmen – IT Security inklusive, und zwar von der Konzeptionsphase an, nicht als nachträgliche Prüfung.
4. Automation: Terraform und CI/CD, damit Änderungen in Minuten validiert werden.
5. Kontinuierliche Learnings: nach dem Launch mit demselben Team weiter optimieren – und das Ops-Team von Anfang an einbinden. Wissen entsteht Event-basiert über den ganzen Lebenszyklus des Features, nicht als einmaliger Snapshot.

Der ehrliche Vorbehalt: Ein Lead-Team skaliert nicht beliebig. Bei sehr vielen beteiligten Teams braucht es zusätzlich klare Schnittstellen und Plattform-Teams, die wiederkehrende Aufgaben abnehmen. Und On-site Coworking kostet Reisezeit und Geld – es lohnt sich für den ersten Durchstich, nicht für jede kleine Änderung. 

Das meiste davon ist vor allem eine Haltung – und die entscheidet, ob ein teamübergreifendes Feature in Wochen oder in Monaten steht. 

Wie sieht eure Team-Struktur aus? Habt ihr ähnliche Probleme mit teamübergreifenden Features – oder einen anderen Weg gefunden, das zu lösen?

Quellen

1. Werner Vogels: A Conversation with Werner Vogels — ACM Queue, 2006. queue.acm.org/detail.cfm?id=1142065  ↩
2. Melvin E. Conway: How Do Committees Invent? — Datamation, 1968. melconway.com/Home/Conways_Law.html — Einordnung bei Martin Fowler: martinfowler.com/bliki/ConwaysLaw.html  ↩
3. Matthew Skelton, Manuel Pais: Team Topologies (2019). Kernkonzepte: teamtopologies.com/key-concepts  ↩
4. DORA: State of DevOps Report 2024 und DORA Metrics Guide. dora.dev/research/2024/dora-report · dora.dev/guides/dora-metrics  ↩