Ganzes Team

Ein ganzes Team hat alle, die benötigt werden, um eine Story von der Idee bis zur Produktion zu bringen. Nicht über Abteilungen verteilt. Nicht auf andere Teams wartend. Alle, zusammen.

Für Software bedeutet das typischerweise:

• Entwickler (Frontend, Backend, Full-Stack)
• Tester/QA (falls getrennt von Entwicklern)
• UX/Design (zumindest in Teilzeit)
• Produkt/Kunde (verfügbar für Entscheidungen)
• Operations/DevOps (zur Unterstützung des Deployments)

Das Schlüsselprinzip: keine Übergaben. Arbeit wird nicht „über die Mauer geworfen" an ein anderes Team. Alle sind für die vollständige Lieferung verantwortlich.

Warum? Weil Übergaben der Ort sind, an dem Qualität stirbt. Der Entwickler versteht nicht ganz, was der Designer beabsichtigt hat. Der Tester kennt nicht die Grenzfälle, die der Entwickler berücksichtigt hat. Das Ops-Team versteht nicht, warum der Code diese Konfiguration benötigt. Jede Übergabe ist eine Übersetzung, und Übersetzungen verlieren Informationen.

Ein ganzes Team ist cross-funktional – das Team hat alle benötigten Funktionen. Aber Einzelpersonen müssen nicht multi-funktional sein (Experten in allem).

Sie könnten haben:

• Einen Frontend-Spezialisten, der etwas Backend kennt
• Einen Backend-Spezialisten, der grundlegende Ops-Aufgaben erledigen kann
• Einen Tester, der einfache Testautomatisierung schreiben kann
• Einen Designer, der Entwicklungseinschränkungen versteht

Das Team ist cross-funktional; Einzelpersonen sind T-förmig – tief in einem Bereich, breit genug, um zusammenzuarbeiten.

Vorteile von T-förmigen Personen:

• Sie können helfen, wenn andere einen Engpass haben
• Sie verstehen den vollständigen Kontext ihrer Arbeit
• Sie können bei cross-funktionalen Problemen pairen
• Sie erweitern ihre Fähigkeiten im Laufe der Zeit

XP ermutigt zum Lernen über Spezialisierungen hinweg, nicht zur vollständigen Beseitigung von Spezialisierungen. Das Ziel ist Zusammenarbeit und gemeinsames Eigentum, nicht einheitliche Expertise.

XP betonte ursprünglich physische Co-Location – alle im selben Raum. Während Remote-Arbeit dies verändert hat, bleibt das Prinzip: Machen Sie Arbeit sichtbar und Kommunikation einfach.

Ein informativer Arbeitsbereich zeigt:

• Woran das Team arbeitet (sichtbares Board)
• Wie die Arbeit voranschreitet (Burndown, Velocity)
• Wo Probleme existieren (blockierte Items, fehlschlagende Builds)
• Was als Nächstes kommt (priorisiertes Backlog)

Jeder, der vorbeigeht (oder einem Videoanruf beitritt), sollte den Status des Teams auf einen Blick verstehen können.

Digitale Äquivalente für verteilte Teams:

• Virtuelle Kanban-Boards (Jira, Linear, Trello)
• Dashboard-Bildschirme in Videoanrufen
• Slack-Kanäle für Updates
• Gemeinsame Dokumentation (Wikis, Notion usw.)

Das Ziel sind nicht die Tools – es ist Transparenz. Jeder sollte wissen, was passiert, ohne fragen zu müssen.

XP funktioniert am besten mit kleinen Teams: typischerweise 5–9 Personen.

Warum klein?

• Kommunikation wächst mit der Teamgröße (n × (n-1) / 2 Verbindungen)
• Kleine Teams benötigen weniger Koordinationsaufwand
• Jeder kann wissen, was alle anderen tun
• Entscheidungsfindung ist schneller
• Verantwortlichkeit ist klarer

Wenn Sie mehr Kapazität benötigen, erwägen Sie:

• Mehrere kleine Teams, die an verschiedenen Teilen arbeiten
• Teams, die um Features oder Domänen herum organisiert sind
• Gemeinsame Praktiken und Standards über Teams hinweg

XP skalieren ist ein eigenes Thema. Die Schlüsselerkenntnis: Machen Sie Teams nicht größer; schaffen Sie mehr Teams. Halten Sie jedes Team ganz und klein.

Die Schaffung eines ganzen Teams erfordert oft organisatorische Veränderungen:

Schritt 1: Identifizieren Sie alle benötigten Fähigkeiten Kartieren Sie den Weg von der Story zur Produktion. Wer ist beteiligt? Welche Übergaben existieren?

Schritt 2: Bringen Sie Menschen zusammen Versetzen Sie Menschen (physisch oder organisatorisch) in ein einziges Team. Dies kann Verhandlungen mit anderen Managern erfordern.

Schritt 3: Definieren Sie gemeinsame Ziele Das Team hat gemeinsam Erfolg oder scheitert gemeinsam. Nicht „Entwickler haben pünktlich geliefert, aber QA hat Bugs gefunden" oder „Design war großartig, aber Entwickler konnten es nicht bauen."

Schritt 4: Bauen Sie Cross-Skilling im Laufe der Zeit auf Pairen Sie über Spezialisierungen hinweg. Lassen Sie Tester mit Entwicklern pairen. Lassen Sie Entwickler Ops-Aufgaben erledigen. Verbreiten Sie Wissen schrittweise.

Erwarten Sie Widerstand. Spezialisten fühlen sich möglicherweise bedroht. Manager verlieren möglicherweise „ihre" Leute. Die Organisation ist möglicherweise nicht bereit. Ganze Teams erfordern organisatorische Zustimmung, nicht nur Veränderung auf Team-Ebene.