Kollabe
Rückschauen
Planungspoker
Standups
Eisbrecher
Preise
Armaturenbrett

Beiträge

Brauchen Startups Retrospektiven?

Illustration eines kleinen Startup-Teams aus vier Personen in einem engen Büro mit Laptops, Klebezetteln auf einem einzelnen Whiteboard und einem Release-Kalender an der Wand, energiegeladen und leicht chaotisch
Kelly Lewandowski

Kelly Lewandowski

Zuletzt aktualisiert am 25/07/20267 Min. Lesezeit

Die Frage taucht alle paar Wochen in den Agile-Subreddits auf, meistens von jemandem aus einem Startup, und meistens ungefähr so formuliert: Wir sind fünf Leute, wir sitzen im selben Slack-Channel, wir shippen jeden Tag, wir haben keine Sprints. Warum sollten wir ein Meeting ansetzen, um darüber zu reden, wie wir arbeiten, wenn wir sowieso ständig darüber reden, wie wir arbeiten? Die Antworten sind fast immer schlechter als die Frage. "Inspect and adapt." "Continuous improvement." "Steht so im Scrum Guide." Nichts davon ist ein Grund. Das sind Slogans, und ein Gründer, der Runway verbrennt, riecht einen Slogan schon einen Kilometer gegen den Wind. Hier also die eigentliche Antwort, inklusive dem Teil, in dem der Einwand recht hat.

Was an dem Einwand richtig ist

Die Retro, die die meisten vor Augen haben, ist ein 90-Minuten-Meeting mit Facilitator, Timer, Mad-Sad-Glad-Board und acht Action Items, die danach niemand mehr anschaut. Dieses Format existiert, weil eine 40-köpfige Engineering-Organisation einen formalen Kanal für Feedback braucht. Informelle Kanäle skalieren nicht über ungefähr ein Dutzend Leute hinaus, also baut man sich eine Ceremony, die sie ersetzt. Ein Startup hat den informellen Kanal. Er funktioniert. Das meiste, was eine Konzern-Retro am Donnerstag ans Licht bringt, wusste ein Fünf-Personen-Team schon am Dienstag und hat es am Mittwoch behoben. Die Kosten sind auch real. Fünf Leute in einem 90-Minuten-Meeting sind der Großteil eines Engineering-Tages, alle zwei Wochen, in einer Firma, deren Runway in Monaten gemessen wird. Wenn dir jemand sagt, du sollst das machen, weil das Framework es so vorsieht, ignorier ihn. Du machst kein Scrum. Du baust eine Firma.

Was er übersieht

Ständiges Reden ist hervorragend bei Einzelfällen und nutzlos bei Mustern. So sieht das in der Praxis aus. Staging frisst einen Nachmittag. Jemand behebt es, postet in Slack, alle machen weiter. Drei Wochen später passiert es wieder, anderes Symptom, dieselbe Ursache. Jemand behebt es wieder. Niemand sagt "das ist jetzt das vierte Mal in diesem Quartal", weil niemand mitzählt. Jeder einzelne Fall war klein genug, um ihn wegzustecken, und der Fix war schnell genug, dass das Muster für niemanden jemals sichtbar wurde. Die Häufigkeit ist die Information, und kontinuierliches Feedback wirft die Häufigkeit weg. Du siehst sie erst, wenn jemand dieselbe Beschwerde zweimal aufschreibt und die beiden Zettel nebeneinander landen. Illustration einer Person, die auf einer langen Zeitachse immer wieder dasselbe kleine Feuer austritt, während das identische Feuer in Abständen hinter ihr erneut auftaucht, und einer Lupe, die das sich wiederholende Muster sichtbar macht Wir haben uns das über eine Million Retro-Karten hinweg angesehen, geschrieben von echten Teams. Die häufigsten Beschwerden waren nicht dramatisch. Testing und QA führen die Liste mit 10.2% aller Beschwerdekarten an, gefolgt von Tickets und Anforderungen mit 8.1% und Deployments und Releases mit 4.9%. Kommunikation, also das, was alle für das eigentliche Problem halten, kam auf 1.9%. Achte darauf, was diese Top-Einträge gemeinsam haben. Es sind alles langsam schwelende strukturelle Probleme, die an keinem einzelnen Nachmittag jemandes Notfall sind. Genau deshalb kommen sie nie im Flurgespräch auf, und genau deshalb summieren sie sich.

Dein Feedback-Loop läuft nur in eine Richtung

Das hier ist spezifisch für Startups, und Gründer unterschätzen es durchweg. Bei fünf Leuten unterschreibt die lauteste Stimme im Raum meistens auch die Gehaltsabrechnungen. Das macht niemanden zu einer schlechten Führungskraft. Das passiert einfach, wenn die Person mit dem meisten Kontext und der stärksten Überzeugung in jedem einzelnen Gespräch sitzt. Junior-Entwickler widersprechen einem Gründer nicht im laufenden Thread über dessen eigene Architekturentscheidung. Eine schriftliche Retro, in der alle einreichen, bevor irgendwer liest, ist der billigste Fix dafür, den ich kenne. Fünf Minuten Stille, und es verändert, was du zu hören bekommst, weil Leute eine Sorge tippen, die sie nie laut aussprechen würden, während der CTO mitten im Satz ist. Wenn du die längere Version davon willst, warum das wichtig ist: Wir haben separat über psychologische Sicherheit in agilen Teams geschrieben.

Die Rechnung kommt bei Mitarbeiter Nummer sieben

Startups bleiben nicht bei fünf Leuten. Das ist ja der ganze Sinn der Übung. Entscheidungen, die im Flur fallen, hinterlassen keine Spur. Das Gründungsteam weiß noch, warum der Billing-Service so aussieht, wie er aussieht, und warum niemand den Import-Job anfasst. Stell in einem Quartal sechs Entwickler ein, und keiner davon hat irgendetwas davon. Sie rollen Entscheidungen neu auf, die du im März geklärt hast, und du verbringst dein Quartal damit, alles noch mal zu erklären, statt zu bauen. Eine Retro-Historie ist das billigste institutionelle Gedächtnis, das du kaufen kannst, vor allem deshalb, weil du das Gespräch sowieso geführt hättest. Es aufzuschreiben ist der einzige zusätzliche Aufwand.

Die Startup-Version einer Retro

Fünfundzwanzig Minuten, alle zwei Wochen, oder monatlich, wenn dein Zyklus langsamer ist. Keine Facilitator-Schulung, kein Icebreaker, kein Sprint nötig.
  1. Fünf Minuten in Stille schreiben
    Drei Fragen reichen völlig: Was hat uns ausgebremst, was hat besser funktioniert als erwartet, worauf laufen wir gerade zu. Alle tippen gleichzeitig, niemand liest, bis der Timer abgelaufen ist.
  2. Fünf Minuten gruppieren und abstimmen
    Zieh Duplikate zusammen. Die Duplikate sind genau das Signal, wegen dem du hier bist. Danach bekommt jeder zwei Stimmen.
  3. Nur die zwei wichtigsten Themen besprechen
    Zehn Minuten, zwei Themen. Alles andere bleibt als Aufzeichnung auf dem Board stehen. Du willst nicht den ganzen Monat lösen, du willst die eine Sache finden, die dich still und leise immer wieder Tage kostet.
  4. Mit einer Änderung und einem Namen rausgehen
    Einer. Keine Liste. Weis sie einer Person zu und gib ihr ein Datum, dann prüf sie zu Beginn der nächsten Retro.
Async funktioniert in dieser Größe sogar noch besser. Niemand muss dafür in einem Raum sitzen. Stell das Board Montagmorgen rein, lass die Leute über den Tag verteilt Karten schreiben, und nehmt euch fünfzehn Minuten gemeinsam für die zwei wichtigsten Punkte. Ein Kollabe-Retrospektive-Board mit den Spalten Start, Stop und Continue, gefüllt mit Karten eines Fünf-Personen-Teams, daneben öffentliche und anonyme Team-Umfragen

Wann du sie wirklich weglassen kannst

Da bin ich lieber ehrlich, als dir eine Ceremony zu verkaufen.

Zwei Co-Founder, die den ganzen Tag pairen, vor dem Produkt, ohne Angestellte. Euer Dienstagsspaziergang ist die Retro. Macht ihn einmal im Monat bewusst und schreibt auf, was ihr entscheidet.

Der Zyklus, in dem wegen eines einzigen Vorfalls alles schiefgegangen ist. Macht stattdessen ein richtiges Postmortem, das ist das bessere Format für ein einzelnes Ereignis mit klarer Ursache.

Ihr macht bereits ein monatliches schriftliches Review, in dem gefragt wird, was euch ausbremst. Das ist eine Retro. Behaltet sie und spart euch das zweite Meeting.

Was nicht als gültiger Grund zählt: "wir haben zu viel zu tun." Fünf Leute für 25 Minuten sind rund zwei Stunden Firmenzeit im Monat. Ein einziges wiederholt fehlgeschlagenes Deployment kostet dich an einem einzigen Nachmittag mehr, und davon hattest du vier.

Also, brauchst du eine

Wenn du ein Startup mit mehr als drei Leuten bist und irgendeine Absicht hast, einzustellen: ja, aber nicht die Version, die du dir gerade vorstellst. Was du brauchst, ist eine kurze, wiederkehrende Gewohnheit, Dinge aufzuschreiben und zu schauen, was sich wiederholt. Die Ceremony ist optional. Die Aufzeichnung nicht. Fang mit einem Board und drei Fragen an. Wenn du einen Ort dafür suchst: Kollabes Retrospektiven sind für kleine Teams kostenlos, funktionieren async und lassen Leute anonym einreichen, damit die Meinung des Gründers nicht das Erste ist, was alle lesen. Unser Generator für Retro-Vorlagen baut dir aus einer einzeiligen Beschreibung deines Teams ein Format, falls du lieber keines selbst aussuchen willst.

Alle zwei Wochen passt für die meisten Teams, die kontinuierlich ausliefern. Monatlich ist in Ordnung, wenn dein Zyklus langsamer ist oder das Team unter fünf Leuten liegt. Mehr Details in unserem Guide dazu, wie oft du Retrospektiven machen solltest.

Ja. Häng sie an den Kalender statt an eine Iteration. Eine Retro braucht einen Zeitraum, auf den sie zurückblickt, und "die letzten zwei Wochen" ist ein Zeitraum.

Nein. In Startup-Größe kann die Person, die den Termin ansetzt, ihn auch leiten. Die eine Regel, die es wert ist, durchgesetzt zu werden: Alle schreiben, bevor irgendwer redet.

Anonyme Einreichung hilft selbst dann, wenn alle erraten können, wer was geschrieben hat, weil sie den Moment wegnimmt, in dem man entscheiden muss, ob man den Mund aufmacht. Probiert es zwei Runden lang und vergleicht, was auf dem Board landet.