Was ist die Engineering-Team-Retrospektive?
Die Engineering-Team-Retrospektive richtet sich an Entwickler, QA, DevOps und Engineering Leads. Sie behandelt die technische Seite der Arbeit, also Codequalität, Tests, Pipelines und technische Schulden, und ebenso die menschliche Seite: wie das Team kommuniziert, Wissen geteilt und die Rufbereitschaft bewältigt hat. Das Board hat vier Spalten, und jede davon ist eine Frage. „Was lief gut?“ hält die Praktiken und Erfolge fest, die ihr beibehalten wollt. „Was hat uns ausgebremst?“ sammelt Blocker, Reibungspunkte und technische Schulden. „Wie haben wir zusammengearbeitet?“ betrachtet Kommunikation und gegenseitige Unterstützung im Team. „Was probieren wir als Nächstes?“ macht aus der Diskussion ein paar Experimente mit klaren Verantwortlichen. In TeamRetro bringen alle ihre Ideen gleichzeitig ein. Danach gruppiert das Team sie, stimmt über das Wichtigste ab und macht aus den wichtigsten Punkten nachverfolgte Maßnahmen. Führt die Retrospektive am Ende jedes Sprints, nach einem größeren Release oder als regelmäßigen Check-in durch. Haltet sie frei von Schuldzuweisungen, damit alle den ignorierten Flaky Test genauso offen ansprechen wie das Refactoring, auf das sie stolz sind.
Format der Engineering-Team-Retrospektive
Was lief gut?
Welche Engineering-Praktiken oder Erfolge wollen wir beibehalten?
Fragt nach konkreten Beispielen: eine Architekturentscheidung, die sich bewährt hat, ein reibungsloses Deployment, gutes Pairing, solide Testabdeckung. Wer benennt, was funktioniert hat, kann es leichter beibehalten.
Was hat uns ausgebremst?
Welche Blocker, Reibungen oder technischen Schulden haben uns gebremst?
Bringt Engpässe, technische Schulden, unklare Anforderungen und Reibung im Prozess ans Licht. Verzichtet auf Schuldzuweisungen und achtet auf wiederkehrende Probleme, die das Team realistisch lösen kann.
Wie haben wir zusammengearbeitet?
Wie gut haben wir kommuniziert und uns gegenseitig unterstützt?
Schaut darauf, wie Informationen geflossen sind, ob sich alle unterstützt gefühlt haben und wie Entscheidungen getroffen wurden. Entscheidungen in Direktnachrichten und Übergaben zwischen Zeitzonen kommen hier oft zur Sprache.
Was probieren wir als Nächstes?
Zu welchen Experimenten oder Verbesserungen verpflichten wir uns?
Fragt nach konkreten Experimenten, Prozessanpassungen oder technischen Investitionen für die nächste Iteration. Haltet sie klein und messbar, mit einer verantwortlichen Person für jede, damit ihr sie beim nächsten Mal überprüfen könnt.
Wann sollte diese Retrospektive durchgeführt werden?
- Am Ende jedes Sprints oder jeder Iteration, um Engineering-Praktiken und Lieferung zu überprüfen.
- Nach einem größeren Release, Incident oder Produktionsproblem, um ohne Schuldzuweisungen Erkenntnisse festzuhalten.
- Als regelmäßiger Check, um technische Schulden, Engpässe und Reibung in der Zusammenarbeit zu erkennen, bevor sie größer werden.
- Beim Onboarding neuer Engineers oder bei Änderungen der Teamstruktur, um sich auf eine gemeinsame Arbeitsweise zu einigen.
Vorschläge für Fragen zum Icebreaker
- Wenn eure Codebasis eine Stadt wäre, was für ein Ort wäre sie gerade?
- Auf welches Tool oder welche Technologie hättet ihr in diesem Sprint auf keinen Fall verzichten können?
Möchten Sie eine Aufwärmübung, bei der Ihr Team aktiv mitmacht, und nicht nur laut Antworten gibt? Kostenlose Icebreakers durchsuchen →
Ideen und Tipps für Ihre Retrospektive
- Verzichtet auf Schuldzuweisungen. Sprecht über Systeme, Prozesse und Umstände, nicht über einzelne Personen.
- Sammelt Ideen anonym und parallel vor der Diskussion, damit ruhigere Engineers genauso viel beitragen wie erfahrene.
- Nutzt Dot Voting, um die Themen mit der größten Wirkung auszuwählen, und hebt den Rest für eine andere Session auf.
- Einigt euch auf wenige konkrete Maßnahmen mit Verantwortlichen und überprüft sie zu Beginn der nächsten Retrospektive.
- Setzt für jede Spalte ein Zeitlimit, damit eine einzelne technische Debatte nicht die ganze Session beherrscht.
- Wechselt die Moderation regelmäßig, damit das Team die Verantwortung teilt und das Format frisch bleibt.
Häufig gestellte Fragen
Wie lange dauert eine Engineering-Team-Retrospektive?
Wann sollten wir eine Engineering-Team-Retrospektive durchführen?
Worin unterscheidet sie sich von einer normalen Sprint-Retrospektive?
Wer sollte an der Retrospektive teilnehmen?
Wie halten wir die Retrospektive frei von Schuldzuweisungen?
Wie stellen wir sicher, dass Maßnahmen wirklich umgesetzt werden?
Verwandte Vorlagen
Dankt gemeinsam den Müttern und Bezugspersonen, die euer Team geprägt haben.
Retrospektive „Wanderung zum Wasserfall“
Auf den Anstieg zurückblicken, dann den nächsten Pfad planen.
Cyber-Security-Ops-Retrospektive
Vorfälle, Kontrollen und Lücken gemeinsam im Security-Team auswerten.
Sprint-Klinik-Retrospektive
Die Probleme eures Sprints diagnostizieren und die passenden Lösungen verordnen