🧭 Einführung
Stell dir folgendes Szenario vor: Mehrere Teams, ein Produkt, ein gemeinsames Ziel. Auf dem Papier klingt es einfach. Doch im Laufe der Entwicklung schleichen sich Reibungspunkte ein: Verzögerungen, Missverständnisse, wiederholte Gespräche und Nacharbeiten. Nicht etwa, weil die Beteiligten nicht zusammenarbeiten wollen, sondern weil die bestehende Struktur dies erschwert.
Es kommen immer mehr Meetings hinzu. Immer mehr Rollen entstehen, um die Koordination zu übernehmen. Und langsam, ohne dass man es merkt, verwandelt sich die Zusammenarbeit in eine Reihe von Statusberichten anstatt in eine echte gemeinsame Entwicklung.
Dieser Leitfaden richtet sich an alle, die diesen Kreislauf durchbrechen wollen.
Anstatt weitere Schichten einzuführen, zeigen wir Wege auf, wie sich Reibung durch spontane, informelle und dezentralisierte Zusammenarbeit verringern lässt, mit Fokus auf synchrone Zusammenarbeit. Es geht um praktische Techniken, keine theoretischen Idealvorstellungen. Sie helfen Teams, die am selben Produkt arbeiten, in Echtzeit wirklich zusammenzuarbeiten.
Der Leitfaden stellt erprobte Praktiken für effektive teamübergreifende Zusammenarbeit in Produktgruppen vor. Wenn Teams wachsen und mehrere Teams an einem gemeinsamen Produkt arbeiten, wird Koordination entscheidend. Aber Koordination muss nicht mehr Prozess oder mehr Management bedeuten. Der Schlüssel liegt darin, Verzögerungen und Missverständnisse durch direkte, spontane und informelle Zusammenarbeit zu reduzieren. Die vorgestellten Techniken zielen darauf ab, synchrone Zusammenarbeit zu maximieren, also gemeinsames Arbeiten zur gleichen Zeit, und die Komplexität und Verzögerung durch asynchrone Übergaben zu minimieren.
🌐 Was ist ein „End-to-End“-Team?
Bevor wir auf konkrete Techniken zur teamübergreifenden Zusammenarbeit eingehen, ist ein strukturelles Fundament entscheidend: die Teamstruktur. Die in diesem Leitfaden beschriebenen Praktiken funktionieren nur, wenn Teams so strukturiert sind, dass sie eigenverantwortlich arbeiten können. Ohne diese Grundlage wird jede Zusammenarbeit zu einem Abhängigkeitsmanagement.
Ein "End-to-End" Team ist ein funktions- und komponentenübergreifendes Team, das ein vollständiges, kundenorientiertes Feature eigenständig, also von der Idee bis zum auslieferbaren Produkt, umsetzen kann. Diese Teams verfügen über alle notwendigen Fähigkeiten, um Wert zu liefern, ohne Übergaben oder externe Freigaben. Sie übernehmen technische und fachliche Verantwortung und sind so organisiert, dass sie Verzögerungen durch externe Abhängigkeiten vermeiden.
In LeSS nennt man diese Teams Feature Teams. Wichtig: Ein Feature Team fokussiert sich nicht nur auf Features, sondern auf das Liefern von Kundennutzen durch vollständige Ende-zu-Ende-Funktionalität. In anderer Literatur, z. B. in „Transformed“ von Marty Cagan, werden diese Teams als "Empowered Product Teams" bezeichnet.
Ein solches Team muss nicht zwangsläufig über mehrere Sprints hinweg am selben Feature arbeiten. Vielmehr ermöglicht diese Struktur Flexibilität: Teams können Arbeiten je nach Priorität und Verfügbarkeit aufnehmen oder fortführen, da das nötige gemeinsame Verständnis und Integration vorhanden ist.
Aber selbst gut aufgestellte End-to-End-Teams arbeiten nicht isoliert. Wenn mehrere Teams am selben Produkt arbeiten, entstehen automatisch gemeinsame Ziele, Überschneidungen und geteilte Infrastruktur. Daraus entsteht ein Koordinationsbedarf. Und obwohl asynchrone Abhängigkeiten wie Übergaben oder schriftliche Freigaben vermieden werden sollten, müssen die Teams auf synchrone Zusammenarbeit zurückgreifen, um schnelles Feedback, direkte Entscheidungen und ein stimmiges Produkt zu gewährleisten.
🤝 Warum sollte man synchrone Abhängigkeiten maximieren?
Um Missverständnisse zu vermeiden, ist es wichtig, zwischen zwei verwandten, aber unterschiedlichen Konzepten zu unterscheiden, die in diesem Artikel verwendet werden: synchronen Abhängigkeiten und synchroner Zusammenarbeit.
Synchrone Zusammenarbeit beschreibt die Art und Weise, wie Menschen miteinander arbeiten, z.B. durch Interaktionen in Echtzeit wie Gespräche, Workshops, gemeinsame Planung, Pairing oder spontane Abstimmungen. Es geht um direkte menschliche Interaktion ohne Verzögerung.
Synchrone Abhängigkeiten maximieren hingegen beschreibt ein spezifisches Teamverhalten (ein Begriff, eingeführt von Bas Vodde in einem Vortrag auf der LeSS-Konferenz in Warschau). Es bedeutet, dass Teams bewusst verwandte Product Backlog Items auswählen, oft innerhalb desselben übergeordneten Themas, sodass sie während desselben Sprints an miteinander verbundenen Problemen arbeiten. Dadurch schaffen Teams gezielt Situationen, in denen synchrone Zusammenarbeit notwendig und wertvoll wird.
Das Ziel ist nicht, Team-Autonomie zu verringern oder Koordination im Voraus zu erzwingen. Teams sollten immer in der Lage sein, unabhängig Wert zu liefern. Doch wenn mehrere Teams am gleichen Produkt arbeiten, führen gezielte Überlappungen bei verwandter Arbeit zu natürlichen Berührungspunkten. Diese absichtliche Überschneidung fördert gemeinsames Verständnis, ermöglicht Lernen und unterstützt direkte Integration, wenn sie gebraucht wird.
Wir wollen synchrone Zusammenarbeit maximieren, weil sie:
- Kommunikationsverzögerungen und -verzerrungen reduziert,
- die Notwendigkeit von Koordinationsrollen und Zwischeninstanzen eliminiert,
- gemeinsames Verständnis und geteilte Verantwortung fördert,
- Lernen und Anpassungsfähigkeit beschleunigt.
Im Gegensatz dazu führt asynchrone Zusammenarbeit, wie z. B. durch Koordination über Tickets, Dokumente, E-Mails oder Prozesse, zu Übergaben, Wartezeiten, Informationsverlusten und vermeidbaren Fehlern.
Wichtig: Synchrone Zusammenarbeit bedeutet nicht mehr Meetings. Es bedeutet: die richtigen Gespräche zur richtigen Zeit mit den richtigen Personen.
🔧 Überblick über Techniken der teamübergreifenden Zusammenarbeit
Hier ist ein Überblick über die wichtigsten Praktiken, die teamübergreifende Zusammenarbeit in der Praxis ermöglichen.
Technik |
Beschreibung |
Ein (gemeinsamer) Sprint |
Alle Teams arbeiten im gleichen Sprint-Rhythmus – mit gemeinsamer Planung, Review, Retrospektive und Auslieferung. |
Sprint Planning (Part 1) |
Zu Beginn des Sprints stimmen sich die Teams ab: Wer nimmt was, welche Abhängigkeiten gibt es, wie geht man mit Überschneidungen um? |
Multi-Team Product Backlog Refinement |
Teams verfeinern gemeinsam Items: Verständnis klären, Aufwand schätzen, Arbeit aufteilen. |
Communities |
Freiwillige teamübergreifende Gruppen zu Themen wie Testen, UX oder Architektur – für Lernen, Abstimmung und gemeinsame Weiterentwicklung. |
Direkte teamübergreifende Kommunikation |
Teammitglieder sprechen direkt miteinander – persönlich, per Chat oder im gemeinsamen Arbeiten – ohne Eskalationsketten. |
Ein gemeinsames Product Backlog |
Alle Teams arbeiten aus einem gemeinsamen Backlog – für maximale Transparenz und priorisierte Zusammenarbeit. |
🔍 Details zu den Praktiken
Ein (gemeinsamer) Sprint
Alle Teams arbeiten in einem gemeinsamen Sprint mit demselben Start- und Enddatum. Dies ermöglicht eine abgestimmte Planung, eine gemeinsames Review und ein integriertes Inkrement.
🔹 Typische Themen, die hier behandelt werden:
- Verteilung von hoch priorisierten Backlog-Elementen auf mehreren Teams in einer (gemeinsamen) Sprintplanung
- (Eine) gemeinsame Retrospektive am Ende des Sprints
- (Ein) gemeinsames Sprint-Review für alle Teams am Ende des Sprints
Sprintplanung (Teil 1)
Die Teams treffen sich zu Beginn des Sprints, um Einträge aus dem Backlog zu ziehen, Ziele abzustimmen und Transparenz darüber zu schaffen, woran die Teams arbeiten. Ziel dieses Meetings ist nicht die Koordination von Verantwortlichkeiten. Vielmehr entsteht Koordination während des Sprints durch direkte Kommunikation bei auftretenden Überschneidungen oder Abhängigkeiten.
🔹 Typische Themen, die hier behandelt werden:
- „Wer startet mit der Umsetzung der Zahlungsintegration?“
- „Team A und Team B benötigen beide eine neue API. Wer fängt an und wie bleiben wir abgestimmt?“
- „Wie können wir uns gegenseitig beim Lernen helfen?“
Multi-Team Product Backlog Refinement
Mehrere Teams arbeiten gemeinsam an der Verfeinerung von Product-Backlog-Einträgen, indem sie diese aufteilen, ihren Zweck klären und das gemeinsame Verständnis der Fachdomäne aufbauen. Ziel ist es, Wissenslücken zu schließen und die Anpassungsfähigkeit zu erhöhen, indem mehr Teams mit einem breiteren Spektrum an Backlog-Einträgen konfrontiert werden. Dies beinhaltet häufig die direkte Interaktion mit Kunden oder Fachexperten.
🔹 Typische Themen, die hier behandelt werden:
- „Welches Problem soll gelöst werden? Was ist das gewünschte Ergebnis?“
- „Wie könnten wir dieses Feature sinnvoll schneiden?“
- „Wie lässt sich am schnellsten ein erster Mehrwert erzielen?“
Communities
Teamübergreifende Gruppen treffen sich regelmäßig zu gemeinsamen technischen oder fachlichen Themen (z. B. Testautomatisierung, Architektur, UX), und vor allem zum Lernen und Wissensaustausch. Ihr Hauptziel ist es, die Erkundung zu fördern, das Verständnis zu vertiefen und die kollektive Expertise auszubauen, anstatt Entscheidungsgremien zu bilden.
🔹 Typische Themen, die hier behandelt werden:
- Neue Teststrategien erkunden, anhand von Beispielen aus den Teams
- Austausch von Erkenntnissen aus den jüngsten architektonischen Veränderungen
- Untersuchung von DevOps-Praktiken, die in verschiedenen Teams angewendet werden
- Einladung interner oder externer Experten zum Teilen neuer Impulse
Direkte teamübergreifende Kommunikation
Teammitglieder nehmen direkt Kontakt auf, z. B. durch spontane Gespräche, Paarbildung, gemeinsames Debugging, ohne dabei Rollen oder Hierarchien zu berücksichtigen.
🔹 Typische Themen, die hier behandelt werden:
- „Können wir uns bei diesem CI-Pipeline-Update abstimmen?“
- „Lass uns die API-Änderung abstimmen. Sie betrifft uns beide.“
- „Wir arbeiten im selben Modul. Wollen wir gemeinsam daran mobben?“
Ein gemeinsames Product Backlog
Keine separaten Team-Backlogs. Ein gemeinsames Product Backlog mit einem Product Owner sorgt für eine gemeinsame Sicht auf Prioritäten und Ziele.
🔹 Typische Themen, die hier behandelt werden:
- „Sollten wir das Onboarding für mobile Geräte in der Prioritätenliste nach oben verschieben? Steht das im Einklang mit unserem aktuellen Produktziel?“
- „Passt diese Funktion zu unserer Multi-Market-Strategie?“
- „Sind dies die wertvollsten Initiativen in diesem Quartal, basierend auf den aktuellen Prioritäten des Product Owners?“
(Wichtig: Die Verantwortung für die Priorisierung liegt stets beim Product Owner. Teams können und sollten Vorschläge einbringen oder Erkenntnisse liefern, die die Reihenfolge des Backlogs beeinflussen, aber die Entscheidung trifft der Product Owner.)
❓Häufig gestellte Fragen zur teamübergreifenden Zusammenarbeit
Wo diskutieren wir Verbesserungen an der Continuous-Integration-Pipeline?
Überall, wo es sinnvoll ist! Häufige Orte sind z. B. eine relevante Community (wie eine DevOps-Community, falls vorhanden) oder die Gesamtretrospektive. Wichtig ist, dass diese Verbesserungen sichtbar gemacht und bei Bedarf auch ins Product Backlog aufgenommen werden.
Wo werden Teststrategien für verschiedene Codebereiche (Komponenten) diskutiert?
Auch hier gilt: überall wo es passt! Oft geschieht das in relevanten Communities wie der Testing-Community (falls vorhanden) oder in der jeweiligen Komponenten-Community.
Wer legt technische Standards wie Logging-Frameworks oder API-Konventionen fest?
Diese Themen können in den entsprechenden technischen Communities (z. B. Architektur oder Backend) diskutiert werden. Um jedoch sicherzustellen, dass sich die Communities auf das Lernen konzentrieren und nicht zu Entscheidungsgremien werden, ist es ratsam, Entscheidungen extern zu treffen. Idealerweise aktualisiert eine kleine Gruppe von Personen aus verschiedenen Teams die Dokumentation der technischen Standards bedarfsweise und kommuniziert die Änderungen an die anderen.
Was tun, wenn mehrere Teams dieselbe Datenbankstruktur ändern möchten?
Wenn ein Team erkennt, dass eine Änderung notwendig ist, kann es diese selbstständig umsetzen und andere informieren. Bei Unsicherheit: gemeinsam mit anderen Teams pairen, direkt kommunizieren oder in einer Community diskutieren. Gemeinsame Refinements helfen, solche Themen früh zu erkennen – eine formale Koordination ist aber meist nicht nötig.
Wo wird über die Branching-Strategie gesprochen?
Wo immer es sinnvoll ist – oft direkt von den betroffenen Personen. Communities wie DevOps können helfen, Optionen kennenzulernen. Entscheidungen entstehen häufig auch durch direkte Zusammenarbeit, Pairing oder Gespräche. Wichtig ist Transparenz und gute Kommunikation.
Wo wird die gemeinsame Definition of Done gepflegt oder aktualisiert?
Änderungen der Definition of Done können auf vielfältige Weise angestoßen werden, beispielsweise durch Retrospektiven, Verbesserungsinitiativen oder umfassendere Organisationsveränderungen. Da die Definition of Done letztlich ein Messinstrument der Anpassungsfähigkeit der Organisation ist, erfolgen Aktualisierungen häufig im Rahmen von Verbesserungsgesprächen oder durch das Management. Die Dokumentation kann dort erfolgen, wo sie am sichtbarsten und nützlichsten ist. Ein bestimmtes Forum ist nicht erforderlich.
Wie werden teamübergreifende technische Schulden identifiziert und priorisiert?
Technische Schulden lassen sich auf vielfältige Weise identifizieren, beispielsweise im Rahmen regelmäßiger technischer Reviews, gemeinsamer Backlog-Verfeinerungen oder durch spontane Teambesprechungen. Teams sollten ihren Code zwar kontinuierlich verbessern, doch signifikante oder wiederkehrende technische Schulden sollten transparent gemacht und dem Product Backlog hinzugefügt werden, um sie sichtbar zu machen und zu priorisieren.
Wie gehen wir mit Bugs in einer bestimmten Komponente um?
Jedes Team kann Bugs beheben, unabhängig davon, welches Team sie ursprünglich verursacht hat. Wenn ein Team einen Fehler erkennt und beheben kann, sollte es dies tun und dabei gleichzeitig mehr über die Komponente lernen. Ist die Zuständigkeit unklar, können die Teams dies direkt untereinander oder während des Refinements oder der Sprint-Planung klären. In jedem Fall sollte der Fehler im Product Backlog sichtbar gemacht werden, um Transparenz zu gewährleisten und eine mögliche Nachverfolgung zu ermöglichen.
🤔 Sind das nicht zu viele Meetings?
Es mag sich nach mehr Koordination anfühlen, doch in der Praxis ist es oft weniger.
Durch die Vermeidung asynchroner Abhängigkeiten sparen wir Zeit und Energie, indem wir Folgendes eliminieren:
- Nacharbeit aufgrund von Missverständnissen
- Eskalationen und Fehlausrichtungen
- Verzögerungen durch Warten auf Antworten,
- Verwirrung durch fragmentierte Informationen.
Statt aufwendiger Planung oder nachträglicher Klärung ermöglichen synchrone Techniken schnelles Feedback und gemeinsame Verantwortung.
Sie ersetzen viele unproduktive Status-Meetings, Berichte und Management-Schleifen, ohne zusätzlichen Overhead.
🚫 Was sollte vermieden werden? (Anti-Pattern)
Team-spezifische Produktverantwortliche
Team-spezifische Product Owner führen zu isolierten Backlogs und Koordinationsproblemen. Wenn jedes Team einen eigenen Product Owner hat, leidet die Abstimmung über das gesamte Produkt hinweg oder führt zu erhöhtem zusätzlichen Koordinationsaufwand. Die Teams optimieren letztendlich lokal, und die übergeordnete Produktvision leidet. Stattdessen sollte ein einziger Product Owner die Prioritäten aller am Produkt arbeitenden Teams festlegen, während jedes Team von kompetenten Product Managern unterstützt wird.
Separate Team-Backlogs
Getrennte Team-Backlogs führen zu Prioritätenkonflikten, mangelnder Fokussierung und geringerer Transparenz. Bei mehreren Backlogs ist unklar, was wirklich wichtig ist, und Teams können sich hinsichtlich ihrer Ziele auseinanderentwickeln. Ein gemeinsamer Backlog stellt sicher, dass sich Teams auf die wichtigsten Aufgaben aus produktweiter Perspektive konzentrieren.
Koordinierungsrollen (Projektmanager, Teamleiter)
Koordinierungsrollen (wie Teamleiter oder Projektmanager) bekämpfen die Symptome, nicht die Ursachen. Wenn Koordination an Einzelpersonen delegiert wird, anstatt in Teamstrukturen und -verhalten integriert zu sein, entstehen Engpässe. Diese Rollen verzögern oft die Entscheidungsfindung und verringern die Eigenverantwortung im Team, statt eine direkte Zusammenarbeit in Echtzeit zu fördern.
Koordination über Tickets
Die Koordination über Tickets verzögert die Kommunikation und schwächt die Verantwortlichkeit. Tickets eignen sich zwar zur Priorisierung von Aufgaben, sind aber kein adäquater Ersatz für ein persönliches Gespräch. Werden Abhängigkeiten über Ticket-Warteschlangen verwaltet, nehmen Missverständnisse zu und die Problemlösung verlangsamt sich. Echte Zusammenarbeit entsteht durch den direkten Austausch.
Komponenten-Teams
Teams mit Fokus auf technische Komponenten erzwingen häufige Übergaben und behindern das Lernen. Diese Teams spezialisieren sich auf eng begrenzte Systemebenen (wie Frontend, Backend oder Datenbank), können aber nicht selbstständig Kundennutzen generieren. Dies führt zu langen Abhängigkeitsketten, erschwert die Integration und reduziert das funktionsübergreifende Lernen.
