Sie kennen das Symptom. Die Ingenieure bauen das auf, was sie aus der Spezifikation verstanden haben. Das Produkt schaut sich das Ergebnis an und meint, das sei nicht ganz das, was es meinte. Design weist darauf hin, dass die Interaktion anders funktionieren sollte. Das Marketing fragt, warum die letzte Woche angekündigte Funktion nicht in der Veröffentlichung enthalten ist. Und jeder verlässt die Retrospektive, nachdem er „Kommunikation“ als Problem besprochen hat, ohne dass sich etwas geändert hat.
Standard-Retrospektivformate sind nicht für funktionsübergreifende Spannungen konzipiert. „Was ist gut gelaufen / was nicht?“ behandelt das Team als eine Einheit, die die Lücken zwischen den Funktionen schließt. Die interessanten Probleme – falsch ausgerichtete Prioritäten, fehlerhafte Übergaben, fehlender Kontext – liegen in den Bereichen zwischen PM, Technik, Design und Markteinführung. Sie brauchen ein Retrospektivformat, das sich auf die Suche nach ihnen macht.
Warum funktionsübergreifende Retros einen anderen Ansatz brauchen
In einem Team mit nur einer Funktion teilen alle ungefähr den gleichen Kontext. Eine Retrospektive des Ingenieurteams kann ein gemeinsames Verständnis der Codebasis, der Tools und der technischen Kompromisse voraussetzen.
Funktionsübergreifende Teams haben diesen Luxus nicht. Jede Funktion optimiert für unterschiedliche Dinge:
- Produkt konzentriert sich auf Kundenergebnisse und geschäftliche Auswirkungen
- Engineering konzentriert sich auf technische Qualität, Wartbarkeit und Liefergeschwindigkeit
- Design konzentriert sich auf die Kohärenz des Benutzererlebnisses und die Benutzerfreundlichkeit
- GTM (Marketing, Vertrieb, Support) konzentriert sich auf Positionierung, Markteinführungsbereitschaft und Kundenkommunikation
Dabei handelt es sich nicht um widersprüchliche Ziele. Sie ergänzen sich. Aber sie erzeugen natürliche Spannungspunkte, die erst sichtbar werden, wenn man dasselbe Werk aus mehreren Blickwinkeln betrachtet. Ein Feature kann technisch gut gebaut, schlecht gestaltet, richtig positioniert sein und trotzdem am Kundenbedürfnis vorbeigehen. Jede Funktion hätte eine andere Einschätzung zum Verlauf des Sprints.
Das Format: Funktionsperspektiven + Ausrichtungsspalte
Richten Sie fünf Spalten ein:
Produktperspektive – Wie sah dieser Zyklus aus Produktsicht aus? Wurden die richtigen Probleme priorisiert? Haben Kundenerkenntnisse Eingang in die Arbeit gefunden? Wurden die Kompromisse mit Bedacht eingegangen?
Ingenieursperspektive – Wie sah dieser Zyklus aus technischer Sicht aus? Waren die Anforderungen klar genug, um darauf aufzubauen? Gab es technische Einschränkungen, die bei der Planung nicht berücksichtigt wurden? Wo wurde nachgearbeitet?
Design-Perspektive – Wie sah dieser Zyklus vom Design aus aus? Entsprach die endgültige Implementierung dem beabsichtigten Erlebnis? Wurden Designentscheidungen mit ausreichend Kontext zu technischen Einschränkungen getroffen? Wo gab es Lücken zwischen dem Design und dem, was geliefert wurde?
GTM-Perspektive – Wie sah dieser Zyklus aus Sicht der Markteinführung aus? Wurde das Team darüber informiert, was wann versandt wurde? Gab es Überraschungen, die sich auf die Nachrichtenübermittlung, die Dokumentation oder die Supportbereitschaft auswirkten?
Ausrichtung – Dies ist die wichtigste Spalte. Nach dem Ausfüllen der Funktionsspalten identifiziert das Team funktionsübergreifende Themen. Das sind Ihre echten Verbesserungsmöglichkeiten.
So erleichtern Sie es
Funktionsübergreifende Retros sind schwieriger zu ermöglichen als Retros mit nur einem Team, da die Machtdynamik unterschiedlich ist. Folgendes funktioniert:
Rotieren Sie den Moderator zwischen den Funktionen. Lassen Sie ihn nicht immer vom PM oder Scrum Master ausführen. Wenn ein Ingenieur moderiert, stellt er natürlich unterschiedliche Fragen. Wenn ein Designer moderiert, fallen ihm unterschiedliche Muster auf. Rotation fördert auch Empathie: Wenn Sie einer Gruppe, zu der auch Ihre Funktion gehört, einen Retro-Vortrag ermöglichen, müssen Sie Raum für Perspektiven lassen, die sich von Ihren eigenen unterscheiden.
Verwenden Sie anonyme Eingaben für die Funktionsspalten. Menschen gehen ehrlicher mit funktionsübergreifenden Reibungen um, wenn ihr Name nicht angehängt ist. „Anforderungen waren unklar und wurden dreimal geändert“ ist einfacher, auf eine anonyme Karte zu schreiben, als laut vor dem PM zu sagen, der diese Anforderungen geschrieben hat.
Timeboxen Sie die Spalte jeder Funktion gleichmäßig. Ohne Struktur dominiert die lauteste Funktion. Geben Sie jeder Spalte fünf bis sieben Minuten Diskussionszeit. Dadurch wird sichergestellt, dass die Technik das Design nicht überrollt und GTM nicht übersprungen wird, weil das Team keine Zeit mehr hat.
Beschreiben Sie alles als Prozessprobleme, nicht als Personalprobleme. „Die Übergabe vom Entwurf an die Technik enthielt keine Interaktionsspezifikationen“ ist umsetzbar. „Der Designer hat nicht klar kommuniziert“ ist eine Schuldzuweisung, die das Gespräch beendet.
Das Übergabeproblem
Wenn es ein Problem gibt, das bei funktionsübergreifenden Retros häufiger auftritt als bei jedem anderen, dann sind es fehlerhafte Übergaben. In den Momenten, in denen die Arbeit von einer Funktion zur nächsten übergeht, gehen Informationen verloren.
Häufige Fehlerquellen bei der Übergabe:
PM zum Design: Produktanforderungen, denen es an ausreichendem Kontext zum Kundenproblem mangelt, was Designer dazu veranlasst, Annahmen zu treffen. Oder Anforderungen, die zu präskriptiv sind und Designer daran hindern, den Lösungsraum zu erkunden.
Design to Engineering: Designergebnisse, die keine technischen Einschränkungen, Grenzfälle oder Reaktionsverhalten berücksichtigen. Oder Entwürfe werden so spät übergeben, dass die Ingenieure mit dem Bau beginnen müssen, bevor sie fertiggestellt sind.
Engineering für GTM: Features abgeschlossen, ohne dass das Marketing genügend Vorlaufzeit für die Vorbereitung von Positionierung, Dokumentation oder unterstützenden Materialien hatte. Oder Änderungen im Umfang, die nicht kommuniziert werden und zu ungenauen Ankündigungen führen.
GTM zum Produkt: Kundenfeedback und Marktsignale aus Vertrieb, Support und Marketing, die nicht in die Produktpriorisierung einfließen.
In Ihrer Retrospektive sollten Sie explizit nach den Übergaben fragen: Welche verliefen reibungslos, welche verursachten Probleme und was würde die nächste Übergabe verbessern. Mit der Zeit entsteht dadurch eine Rückkopplungsschleife, die die Nähte zwischen den Funktionen enger macht.
Maßnahmen, die tatsächlich eine Zusammenarbeit erfordern
Der größte Fehler bei funktionsübergreifenden Retros besteht darin, Maßnahmen einzelnen Funktionen zuzuordnen. „Die Technik wird eine bessere Dokumentation schreiben“ oder „Das Design wird früher liefern“ sind Einzelfunktionsverpflichtungen, die sich nicht mit der funktionsübergreifenden Grundursache befassen.
Bessere Maßnahmen sehen so aus:
- PM und technischer Leiter paaren sich zu Akzeptanzkriterien vor Beginn des Sprints, wobei die Übergabe durch eine gemeinsame Arbeitssitzung ersetzt wird
- Designer nimmt am ersten Tag der Implementierung teil für komplexe Funktionen, um Fragen in Echtzeit statt durch asynchrone Kommentare zu beantworten
- Das Engineering gibt GTM eine „Versandprognose“ in der Mitte des Sprints mit Konfidenzniveaus, sodass das Marketing planen kann, ohne sich auf ein binäres „Erledigt/Nicht-Erledigt“-Signal zu verlassen
- Monatlicher funktionsübergreifender Alignment-Check, bei dem jede Funktion ihre aktuellen Prioritäten mitteilt und das Team Konflikte identifiziert, bevor sie zu Problemen werden
Das Muster: Maßnahmen, die Berührungspunkte zwischen Funktionen schaffen, anstatt eine Funktion isoliert zu verbessern.
Umgang mit unangenehmen Dynamiken
Seien wir ehrlich, was funktionsübergreifende Retros so schwierig macht. Es sind echte Machtdynamiken im Spiel.
Der PM hat oft das letzte Wort über Prioritäten. Dies kann Ingenieuren und Designern das Gefühl geben, dass Retro performativ ist – sie können Probleme aufwerfen, aber der PM entscheidet, was getan wird. Bekämpfen Sie dies, indem Sie sicherstellen, dass Technik und Design echte Verantwortung für die Funktionsweise ihrer Funktion haben, auch wenn das Produkt Eigentümer dessen ist, was gebaut wird.
Dienstaltersunterschiede zwischen den Funktionen. Wenn der VP of Engineering mit einem Junior-Designer im Retro-Stil ist, wird das Gespräch ohne aktive Moderation nicht ausgewogen sein. Überlegen Sie, ob die richtigen Leute im Raum sind oder ob einige Retros auf Augenhöhe stattfinden sollten.
Historische Missstände. Funktionsübergreifende Teams tragen oft ungelöste Frustrationen aus vergangenen Zyklen mit sich. Die ersten paar Retros könnten vom Entlüften dominiert sein. Lass es geschehen. Beseitigen Sie den Rückstand an Frustration, damit Sie sich auf konstruktives Terrain begeben können. Erwarten Sie jedoch, dass sich der Fokus nach den ersten Sitzungen auf zukunftsweisende Verbesserungen verlagert.
Ungleichgewicht zwischen Remote- und Co-Location-Teilnehmern. Wenn einige Funktionen im Büro und andere remote stattfinden, sind die Remote-Teilnehmer strukturell im Nachteil. Nutzen Sie ein vollständig digitales Retro-Format, bei dem jeder über dieselbe Schnittstelle Beiträge leistet, unabhängig vom Standort.
Wie im Laufe der Zeit Gutes aussieht
Sie werden wissen, dass funktionsübergreifende Retros funktionieren, wenn:
- Übergabebeschwerden nehmen ab, da das Team die Übergangspunkte proaktiv verbessert
- Die Funktionen beginnen, sich gegenseitig den Kontext zu geben, anstatt darauf zu warten, dass sie gefragt werden
- Bei Aktionselementen ist natürlich die Zusammenarbeit mehrerer Funktionen erforderlich
- In der Spalte „Ausrichtung“ werden weniger Elemente generiert, da die Ausrichtung zur Standardeinstellung wird
- Menschen aus unterschiedlichen Funktionen beziehen sich bei der Planung von Gesprächen außerhalb des Retro-Bereichs auf die Perspektiven der anderen
Dies geschieht nicht in einer Sitzung. Es dauert drei bis fünf Zyklen, bis das Team genügend Vertrauen und eine gemeinsame Sprache aufbaut, um wirklich produktive funktionsübergreifende Gespräche zu führen. Bleib dabei.
Praktische Tipps
Beginnen Sie mit einem Pilotprojekt. Wenn Ihr Team noch nie ein funktionsübergreifendes Retro durchgeführt hat, beginnen Sie mit einer einzelnen Sitzung, die sich auf den neuesten Start oder Meilenstein konzentriert. Dies gibt dem Format ein konkretes Thema und vermeidet die Unklarheit darüber, „wie läuft die Zusammenarbeit im Allgemeinen.“
Beschränken Sie sich auf maximal 75 Minuten. Funktionsübergreifende Retros sind schwerer als Standard-Retros, weil es mehr Perspektiven zu hören gibt. Aber eine Dauer von mehr als 75 Minuten führt zu Ermüdung und schlechterer Qualität. Seien Sie diszipliniert beim Timeboxing.
Teilen Sie eine funktionsübergreifende Zusammenfassung. Senden Sie nach der Retro eine kurze Zusammenfassung der wichtigsten Themen und Maßnahmen an alle Beteiligten, auch an Personen, die nicht im Raum waren. Dies schafft Transparenz und Verantwortlichkeit.
Führen Sie sie nicht bei jedem Sprint durch. Alle zwei bis vier Wochen sind normalerweise für funktionsübergreifende Retros geeignet. Dazwischen können einzelne Funktionen ihre eigenen Retrospektiven durchführen, die sich auf funktionsspezifische Verbesserungen konzentrieren.
Probieren Sie NextRetro kostenlos aus – Führen Sie funktionsübergreifende Retrospektiven mit anonymen Karten, anpassbaren Spalten für jede Funktion und Abstimmungen zur Priorisierung von Ausrichtungsproblemen durch.
Letzte Aktualisierung: Februar 2026
Lesezeit: 7 Minuten
