Die sechs Entscheidungen, mit denen ein kleines Team schnell liefert, ohne Dinge kaputtzumachen.
Schnelle kleine Teams sind nicht kleine Teams, die länger arbeiten. Es sind kleine Teams, die bewusst entschieden haben, was sie nicht tun. Die Geschwindigkeit ist die Folge einer kurzen Liste von Entscheidungen, die am Anfang getroffen und danach verteidigt werden — keine Begabung, die manche Gruppen zufällig haben und andere nicht.
Hier sind die sechs Entscheidungen, zu denen wir in jedem neuen Projekt standardmäßig greifen. Nicht weil sie gerade in Mode sind, nicht weil sie in einer Beraterfolie standen, sondern weil wir sie in echten Projekten bei drei, vier und sechs Ingenieurinnen überleben gesehen haben. Wenn ein Punkt in der Liste ideologisch klingt, lesen Sie ihn als "das ist die Version, die wir einer skeptischen Senior-Kollegin im Gespräch verteidigen würden" — das ist die Messlatte.
Ein Backlog, gnadenlos aufgeräumt.
Eine Liste, nicht drei. Kein Roadmap-Dokument plus Jira-Projekt plus Notion-Wiki mit "irgendwann"-Einträgen — eine Fläche, die das ganze Team anschaut und die eine neue Kollegin in fünfzehn Minuten liest. Die Kosten der Fragmentierung liegen nicht im Aufwand, drei Tools zu pflegen. Die Kosten sind, dass niemand je das ganze Bild sieht — und deshalb nichts wirklich geschlossen wird.
Die Liste wird wöchentlich aufgeräumt. Alles, was sich seit einem Monat nicht bewegt hat, wird entweder diese Woche erledigt oder gelöscht. Wir haben nie einen Sprint an einem Ticket scheitern sehen, das wir gelöscht haben. Wir haben regelmäßig Sprints an der Masse von Tickets scheitern sehen, die niemand anpacken wollte — und die niemand zu schließen bereit war.
Ein Backlog mit 400 offenen Punkten ist kein Backlog. Es ist ein Friedhof und ein ungepflegter Garten.
- Älter als 30 Tage und keine Bewegung: gelöscht.
- Kein Owner: gelöscht.
- Kein benannter Nutzer oder Use-Case: gelöscht.
- Von jemandem geöffnet, der nicht mehr im Projekt ist: gelöscht, außer jemand rettet es aktiv.
Inszenieren Sie das Rollout, nicht den Code.
Main ist jederzeit releasebar. Langlebige Branches sind der Ort, an dem Qualität stirbt — sie sammeln Kontext, den niemand mehr erinnert, driften von der Form des Codebase weg und erzeugen am Ende einen Merge-Tag, für den sich niemand gern bereithält. Wenn eine Änderung zu groß ist, um sie heute hinter einem Feature-Flag auszuliefern, dann ist die Änderung zu groß.
Konkret heißt das: Jedes nicht-triviale Feature liegt hinter einem Schalter per Environment-Variable, wird in Schritten ausgerollt und bringt seinen eigenen Rollback-Plan in der Commit-Message mit. Wir liefern lieber zehn einzeilige Flag-Umschaltungen aus als einen 2.000-Zeilen-Merge. Die Arbeit, die zählt, ist das Inszenieren des Rollouts — nicht das Inszenieren des Quellcodes.
- Feature-Flag hinter einer Environment-Variable, Default aus.
- Dark Launch: Code an, Nutzer aus, Telemetrie an.
- Gestaffelter Rollout (1 %, 10 %, 50 %, 100 %) mit klaren Ausstiegskriterien pro Stufe.
- Automatisches Rollback bei Fehlerraten-Regression, ohne dass ein Mensch es freigibt.
Wöchentliche Demos, keine wöchentlichen Updates.
Die Demo ist das Medium. Ein schriftliches Status-Update ist ein Abstieg — es liest sich gut, es kostet eine Stunde beim Schreiben, und es verdeckt die Wahrheit, dass noch nichts tatsächlich auf einem Bildschirm funktioniert. Wenn es in dieser Woche nichts zu zeigen gibt, ist das die Information. Sagen Sie es, laut, vor dem ganzen Team. Das Unbehagen ist das Signal.
Wir hatten Wochen, in denen die Demo "wir haben 600 Zeilen toten Code gelöscht und drei Bugs geschlossen; hier ist das Diff" war. Das sind gute Wochen. Sie lassen sich schlecht in eine Stakeholder-Folie drücken, aber danach landet das nächste Feature auf einem Codebase, in dem man wirklich einfacher arbeiten kann. Ein Team, das eine Löschung mit ruhigem Gesicht vorführen kann, ist ein Team, das liefern wird.
Kaufen Sie die Tools, die eine Rolle ersetzen, nicht die, die ein Meeting ersetzen.
Observability, CI-Runner, Error-Tracker, Log-Suche, eine schnelle lokale Entwicklungsschleife — jeden Euro wert. Diese Werkzeuge komprimieren eine Rolle: die Person, die sonst einen Vormittag durch Produktions-Logs greppt, die Person, die sonst vierzig Minuten auf einen Testlauf wartet, die Person, die sonst erst über eine Kundenmeldung von der Regression erfährt. Bezahlen Sie dafür, bezahlen Sie für Upgrades, rechtfertigen Sie die Position nicht.
Noch ein Projekt-Tracking-Tool, noch eine Slack-Integration, die Status in einen Channel postet, noch ein Dashboard, das die vier Dashboards aggregiert, die Sie schon haben — nicht. Diese Werkzeuge ersetzen keine Rolle. Sie ersetzen ein Ritual, und das Ritual war billig. Die Rechnung ist es nicht.
Die besten Werkzeuge komprimieren eine Rolle. Die schlechtesten komprimieren ein Ritual.
Schreiben Sie ADRs, keine Design-Docs.
Ein ADR (Architecture Decision Record) umfasst fünf bis fünfzehn Zeilen und hält das Warum fest. Ein Design-Doc hat acht Seiten und hält fest, wie das Problem am Donnerstag um 16 Uhr aussah, als wir müde waren. Sechs Monate später ist das ADR noch lesbar und erklärt Ihnen die Abwägung; das Design-Doc ist ein Ausstellungsstück, das dem Code widerspricht, den es eigentlich beschreiben sollte.
Wir halten ADRs im Repo, direkt neben dem Code, den sie binden, unter vier festen Überschriften. Vier, nicht zwölf. Die Disziplin liegt in der Kürze: Wer das Warum einer Entscheidung nicht in einem Absatz sagen kann, hat die Entscheidung nicht zu Ende getroffen.
- Context — was die Entscheidung erzwungen hat, in einem Absatz.
- Decision — was wir gewählt haben, in einem Satz.
- Consequences — was das leichter macht und was schwerer.
- Revisit when — die konkrete Bedingung, die das kippen würde.
Zwei-Personen-Review auf allem, was die Produktion berührt.
Zwei Reviewer, nicht vier. Zwei ist das Minimum, das die Klasse von Fehlern fängt, die ein einzelnes Augenpaar übersieht. Vier verdünnt Verantwortung — alle nehmen an, jemand anderes lese sorgfältig, und niemand tut es. Die schlechtesten Code-Reviews, die wir gesehen haben, lagen auf Pull Requests mit sechs Approvals und einem Bug, der am darauffolgenden Montag live ging.
Das Review muss ein echtes Review sein. Pair Programming zählt — zwei Personen, eine Tastatur, eine Entscheidungsspur. Ein Rubber-Duck-Thread in Slack, in dem jemand die Änderung durchgegangen ist, bevor der Pull Request geöffnet wurde, zählt. Ein Kommentar auf GitHub, der zwölf Sekunden nach dem Öffnen des Pull Requests "LGTM" liest, zählt nicht, hat nie gezählt, und das Team, das so tut als ob, erfährt im nächsten Produktions-Incident, welchen es verursacht hat.
Diese sechs Entscheidungen sind keine Tricks. Sie erzeugen keinen heldenhaften Sprint, der das Team für ein Quartal gut aussehen lässt. Sie zinsen sich auf. Ein kleines Team, das nach zwei Jahren so arbeitet, liefert mehr aus als ein größeres Team, das sich auf keine dieser Entscheidungen eingelassen hat — weil jede Woche die Disziplin eine weitere Woche sauberer Landebahn einbringt statt einer weiteren Woche Schulden.
Geschwindigkeit in einem kleinen Team ist eine Disziplin, kein Talent.