Zum Hauptinhalt springen

Teamzuschnitt und Teammodelle

Teamzuschnitt ist kein HR-Thema.

Er bestimmt:

  • Systemgrenzen
  • Schnittstellen
  • Kopplung
  • Release-Zyklen
  • Qualität
  • Geschwindigkeit

Oder anders:

Architektur folgt Organisation.

Ein schlecht geschnittenes Team erzeugt ein schlecht geschnittenes System –
unabhängig von Technologie.

1. Warum Teamstruktur Architektur prägt

1.1 Conway’s Law​

Systeme spiegeln die Kommunikationsstrukturen der Organisation wider.

Wenn Teams:

  • stark fragmentiert sind → entstehen viele Schnittstellen
  • funktional getrennt sind → entstehen Übergaben
  • isoliert arbeiten → entstehen Integrationsprobleme

Teamstruktur ist damit ein Architekturwerkzeug.

Man gestaltet nicht nur Teams.
Man gestaltet Systemgrenzen.

1.2 Microservices ohne passende Teams​

Microservices funktionieren nur, wenn:

  • jedes Service-Team echte Ownership hat
  • Deployments unabhängig möglich sind
  • Schnittstellen stabil sind

Typischer Fehler:

  • 5 Microservices
  • aber 1 großes Backend-Team

Ergebnis:

  • keine echte Autonomie
  • viele interne Abhängigkeiten
  • Koordinations-Overhead
  • verteiltes Monolith-Verhalten

Microservices ohne passenden Teamzuschnitt erzeugen:

verteilte Komplexität ohne organisatorischen Gewinn.

Erst wenn Teams entlang fachlicher Kontexte geschnitten sind, entsteht echte Entkopplung.

2. Warum Teamgröße entscheidend ist

Teamzuschnitt ist nicht nur Erfahrungswert –
er ist kommunikationsökonomisch erklärbar.

2.1 Kommunikationskomplexität wächst quadratisch​

In einem Team mit n Personen entstehen:

n(n−1)/2 Kommunikationsbeziehungen

Beispiele:

  • 3 Personen → 3 Verbindungen
  • 5 Personen → 10 Verbindungen
  • 8 Personen → 28 Verbindungen
  • 12 Personen → 66 Verbindungen

Mit steigender Teamgröße wachsen:

  • Abstimmungsaufwand
  • Meeting-Zeit
  • Missverständnisse
  • Koordinationskosten

Ab einer bestimmten Größe dominiert Koordination die Wertschöpfung.

2.2 Brooks’ Law​

Fred Brooks formulierte:

„Adding manpower to a late software project makes it later.“

Warum?

Neue Personen erhöhen:

  • Kommunikationsaufwand
  • Einarbeitungszeit
  • Integrationskosten

Mehr Menschen bedeuten nicht automatisch mehr Geschwindigkeit –
sie erhöhen zunächst Komplexität.

2.3 Tuckman: Forming → Storming → Norming → Performing​

Bruce Tuckman beschrieb die Phasen der Teamentwicklung:

  1. Forming
  2. Storming
  3. Norming
  4. Performing

Große Teams verbleiben länger in:

  • Konflikt- und Abstimmungsphasen
  • impliziten Macht- und Rollenklärungen

Kleine Teams erreichen schneller produktive Stabilität.

Deshalb bleiben viele leistungsfähige Teams bewusst unter:

7–9 Personen.

3. Systemgetriebene Teamzuschnitte

Der Teamzuschnitt muss sich orientieren an:

  • Systemlogik
  • Risiko
  • Produktfokus
  • Qualitätsstufe
  • Release-Strategie

Nicht an Titeln oder historisch gewachsenen Abteilungen.

3.1 Backend-schwer / sicherheitskritisch​

Beispiel: Vollverschlüsseltes Backend, komplexes Datenmodell

→ Dediziertes Backend-Team
→ 1–n Frontend-Teams

Begründung:

  • Sicherheit und Datenmodell sind zentral
  • Konsistenz ist wichtiger als UI-Variabilität
  • Backend benötigt starke Ownership

3.2 UX-/Produkt-schwer​

Beispiel: Stark nutzerzentriertes Produkt

→ Mehrere Produkt-/Frontend-Teams
→ Backend als Plattform-Team

Begründung:

  • Nutzererlebnis ist Differenzierungsfaktor
  • Backend stabilisiert
  • Delivery-Geschwindigkeit entsteht im UI

3.3 Integrations-schwer​

Beispiel: Viele Drittsysteme

→ Integrationsteam
→ Produktteams konsumieren APIs

Begründung:

  • Schnittstellen brauchen starke Ownership
  • Externe Abhängigkeiten erhöhen Risiko
  • Fehler wirken systemweit

4. Feature-Teams vs. Plattform-Teams

Feature-/Produktteams​

  • liefern Business Value
  • tragen End-to-End-Verantwortung
  • besitzen ihren fachlichen Kontext

Plattform-/Enablement-Teams​

  • liefern Infrastruktur
  • reduzieren Komplexität
  • ermöglichen Autonomie
  • definieren Standards

Enablement bedeutet nicht Gatekeeping.
Es bedeutet Beschleunigung durch Struktur.

Wenn Plattform-Teams selbst Feature-Backlogs priorisieren müssen, entsteht Engpass-Architektur.

5. Teamzuschnitt im Qualitätskontext

Ab steigender Qualitätsstufe steigen auch strukturelle Anforderungen.

Stufe 1:

  • Kleine flexible Teams

Stufe 2:

  • Klare Rollen, Reviews, Tests etabliert

Stufe 3:

  • Plattform-/DevOps-Rolle notwendig
  • Test Engineering verankert

Stufe 4–5:

  • AppSec eigenständige Rolle
  • klare Trennung von Verantwortlichkeiten
  • formalisierte Governance

Hohe Qualitätsstufen ohne passende Rollen sind nicht tragfähig.

6. Anti-Patterns

  • Architektur-Team ohne Umsetzungskompetenz
  • QA als End-of-Chain-Abteilung
  • DevOps als Ticket-Queue
  • Security ohne Autorität
  • Unklare Ownership
  • Matrix-Strukturen ohne Verantwortlichkeit

Solche Strukturen erzeugen:

  • Übergaben statt Verantwortung
  • Verzögerungen statt Delivery
  • implizite Architektur

7. Beispiel-Konfiguration (mittelgroß)

  • 2–3 Produktteams (je 2–4 Dev + 1 Test)
  • 1 UX-Team (shared)
  • 1 DevOps/Platform-Team
  • 1 AppSec (shared, ab Stufe 4 Pflicht)

Kein Dogma – nur ein realistischer Startpunkt.

Kernaussage

Teamzuschnitt ist ein struktureller Hebel.

Er beeinflusst:

  • Architektur
  • Qualität
  • Geschwindigkeit
  • Skalierbarkeit

Wenn Teamstruktur und Systemstruktur nicht zueinander passen, entsteht Reibung.

Und Reibung wird immer im System sichtbar.