Auslieferungsrhythmus ohne Planungsstau

Freitag, 16:30 Uhr. Sie öffnen Ihren Kalender, zählen die blau markierten Meeting-Blöcke und addieren. Neun Stunden diese Woche. sprint planning am Montag. Mid-sprint-Refinement am Mittwoch. Eine retro, die am Donnerstag zur weiteren Planungssitzung wurde. Drei Schätzrunden, die Sie angesetzt haben, weil Tickets noch nicht "bereit" waren. Und das Team hat ein Feature geliefert.

Es war nicht einmal das geplante Feature. Ein Senior IC im Team hatte Mittwochmorgen etwas offensichtlich Kaputtes bemerkt, bis Mittag einen PR geöffnet und ihn noch vor dem standup am Donnerstag gemergt. Das, was niemand beschrieben, niemand eingeschätzt, niemand auf das Board gestellt hatte.

Ihr Gedanke: Mein Team hat trotz meiner Planung geliefert, nicht wegen ihr.

Wenn Ihnen diese Situation bekannt vorkommt, ist dieser Leitfaden für Sie. Ich habe Engineering Manager genau durch dieses Muster gecoacht, und die Lösung lautet nicht "besser planen". Die Lösung lautet: weniger planen, anders strukturiert, mit einem echten Signal, das Sie tatsächlich beobachten.

Warum Planung Ihre Woche frisst (und nichts repariert)

Rechnen Sie durch. Sechs Engineers, zweistündiges planning alle zwei Wochen, plus eine Stunde Mid-sprint-Refinement, plus eine Stunde retro. Das sind 24 Engineer-Stunden pro sprint allein für formale Planung. Addieren Sie die Vorbereitung des EM (typischerweise 3 bis 4 Stunden pro sprint), die Vorbereitung des tech lead (2 Stunden) und das asynchrone Ticket-Grooming in Slack-Threads (nicht zählbar). Sie geben das Äquivalent einer vollen Woche eines Senior Engineers aus, alle zwei Wochen, für Planung.

Was kauft Ihnen das? Bei den meisten Teams, die ich gesehen habe, kauft es Schätzungen, die um das 3- bis 4-fache falsch liegen, einen backlog, der sowieso jede Woche neu priorisiert wird, und einen retro-Aktionspunkt, um den sich bis Mittwoch niemand mehr kümmert.

Die eigentliche Frage lautet nicht "Wie planen wir besser?" Sie lautet: "Wozu dient Planung eigentlich?" Auf das Wesentliche reduziert, produziert Planung drei Dinge, die ein Team braucht: eine kurze Liste, was als nächstes zu tun ist, benannte Verantwortliche und ein gemeinsames Bild davon, was riskant ist. Alles andere ist Theater.

Die Falle: Planungszeremonien fühlen sich produktiv an. Sie verlassen den Raum mit einem befüllten sprint-Board. Es sieht aus, als wäre Arbeit passiert. Aber befüllte sprint-Boards liefern keinen Code. ICs, die PRs schreiben, liefern Code. Jede Stunde, die Sie einen Engineer in einem Planungsmeeting halten, ist eine Stunde, in der er kein Problem durchdenkt und keinen PR öffnet.

Planung als Spike, nicht als Zeremonie

Hier ist der Perspektivwechsel: Planung ist ein Spike. Eine kurze, fokussierte Untersuchung mit klaren Inputs und Outputs. Keine wiederkehrende Zeremonie. Kein Kalenderblock voller Schrecken.

Eine Stunde. Einmal pro Woche. Gesamtteam optional, EM und tech lead erforderlich.

Eine Beispiel-Agenda, die ich mit drei verschiedenen Teams verwendet habe:

• 0 bis 10 Min., was geliefert wurde, was nicht. Das Board der letzten Woche durchgehen. Keine Schuldzuweisungen. Nur Status. Wenn etwas nicht geliefert wurde, den Grund in einem Satz benennen: "bei Review blockiert", "Umfang war größer als gedacht", "durch einen Vorfall unterbrochen." Das war's.
• 10 bis 25 Min., was blockiert ist. Alles, was länger als 48 Stunden ohne Bewegung feststeht. Der tech lead und EM treffen eine Entscheidung: jetzt entsperren, stoppen oder eskalieren. Entscheidungen, keine Diskussionen.
• 25 bis 50 Min., die nächsten 5 bis 7 Tickets. Nicht den ganzen sprint. Die nächsten 5 bis 7 Punkte. Für jeden: Verantwortlicher, grober Aufwand (klein, mittel, groß) und das eine Risiko, das eskalieren könnte. Keine story points. Keine Fibonacci-Folge. Kein Planning Poker.
• 50 bis 60 Min., offene Fragen. Alles, worüber sich jemand Sorgen macht und was oben nicht reingepasst hat. Schriftlich festhalten, wenn es nicht in 10 Minuten geklärt werden kann.

Das war's. Das Team, mit dem ich in einer 40-köpfigen Engineering-Organisation gearbeitet habe, hat die Planungszeit mit etwas Ähnlichem von 8 Stunden pro Woche auf 1 Stunde reduziert. Der Durchsatz stieg im ersten Monat, er sank nicht.

Das Schwierigste ist die Disziplin, den Raum zu verlassen, wenn die Stunde vorbei ist. Offene Frage? Aufschreiben, offline klären, asynchron entscheiden. Das Meeting nicht verlängern. Das Meeting endet zur vollen Stunde, jedes Mal, oder das Ganze fällt zurück in Zeremonie.

Die Debatte: 6-Wochen-Shape-Up vs. 2-Wochen-Sprint

In der Engineering-Management-Community gibt es eine langanhaltende Debatte über den Rhythmus: 2-Wochen-sprints (Scrum-ähnlich) versus 6-Wochen-Shape-Up-Zyklen (Basecamps Modell aus "Shape Up"). Den weltanschaulichen Streit spare ich Ihnen.

Verwenden Sie 6-Wochen-Zyklen, wenn Ihre Arbeit Feature-förmig ist. Sie haben 3 bis 6 Wochen sinnvollen, klar definierten Umfang. Das Team kann sich auf eine große Wette einlassen, sie sorgfältig bearbeiten und etwas Substanzielles liefern. Shape Up glänzt hier, weil das Appetite-Prinzip (maximale Zeit, die Sie aufwenden, bevor Sie den Umfang kürzen) im Modell eingebaut ist.

Verwenden Sie 2-Wochen-sprints, wenn Ihre Arbeit reaktiv ist. Kundeneskalationen, Infrastruktur-Vorfälle, Support-Engineering, Plattformarbeit, bei der Anfragen schneller eingehen als Sie sie planen können. Zwei-Wochen-sprints geben Ihnen eine engere Feedback-Schleife und erlauben Neupriorisierung, ohne dass es wie ein Strategiewechsel wirkt.

Der ehrliche Test: Stellen Sie Ihrem Team ohne Vorwarnung diese Frage. "Würden Sie lieber sechs Wochen auf eine große Wette setzen oder in zwei Wochen fünf kleine?" Verschiedene Teams geben verschiedene Antworten. Beide sind gültig. Die falsche Antwort ist, sie zu mischen. Zwei-Wochen-sprints mit 6-Wochen-förmiger Arbeit laufen zu lassen bedeutet, dass jeder sprint sich wie ein Teilerfolg anfühlt. 6-Wochen-Zyklen bei reaktiver Arbeit zu fahren bedeutet, dass der Zyklus in Woche 2 jedes Mal durch einen Kundenvorfall gesprengt wird.

Wählen Sie eines. Setzen Sie es ein Quartal durch. Dann neu bewerten.

Ticket-to-PR-Latenz: Das echte Signal

Vergessen Sie Velocity-Punkte. Vergessen Sie "Burn-down-Charts, die eigentlich Burn-up-Charts sind, weil ständig Umfang hinzukommt". Es gibt eine Zahl, die Ihnen sagt, ob Ihr Auslieferungsrhythmus funktioniert: die Ticket-to-PR-Latenz.

Definition: die verstrichene Zeit von dem Moment, in dem einem Engineer ein Ticket zugewiesen wird, bis er den ersten PR dafür öffnet.

Das war's. Keine story points. Keine Schätzungen. Nur zwei Zeitstempel.

Wenn diese Zahl bei einem Ticket, das Sie auf 5 Tage geschätzt haben, 4 oder mehr Tage beträgt, ist Ihre Planung defekt. Nicht weil der Engineer langsam ist. Weil das Ticket nicht ausreichend ausgearbeitet ist, um anzufangen. Er verbringt Tag 1, 2 und 3 damit herauszufinden, was das Ticket eigentlich bedeutet, was im Umfang liegt, was nicht, und was zu tun ist, wenn er in das unvermeidliche Labyrinth gerät. Das ist Planung, die in die Ausführung leckt.

Wie es gut aussieht: mediane Ticket-to-PR-Latenz unter 24 Stunden. p75 unter 48 Stunden. p90 unter 5 Tagen. Wenn Ihre Verteilung einen langen Ausläufer hat (einige Tickets liegen bei 10 oder mehr Tagen), sind das die Tickets, die Ihren sprint fressen, und das sind die, die Sie untersuchen sollten.

Erstellen Sie das Diagramm einmal, in welchem Tool auch immer Sie verwenden. Linear, Jira und Shortcut stellen diese Daten über ihre APIs bereit. Wöchentlich abrufen. Den Median beobachten. Wenn er steigt, hat sich die Planungsqualität verschlechtert. Wenn er sinkt, funktioniert etwas.

Das Muster "Geschätzt 3 Tage, gebraucht 11"

Jeder Engineering Manager hat das erlebt. Ticket auf 3 Tage geschätzt. Elf Tage später liegt es noch im Review. Der Engineer hat nicht gebummelt. Das Ticket war unzureichend ausgearbeitet.

Das ist kein Schätzungsproblem. Bessere Schätzungen werden es nicht beheben. Die Arbeit selbst war unklar, als sie in den sprint aufgenommen wurde, und "unklar und ich kläre es unterwegs" ist der Weg, aus einem 3-Tage-Ticket ein 11-Tage-Ticket zu machen.

Die Lösung ist eine 30-minütige Shaping-Session, bevor das Ticket in den sprint aufgenommen wird. Geleitet vom tech lead oder einem Senior IC. Das Ergebnis ist ein kurzes Shaping-Dokument, das vier Punkte abdeckt:

1. Im Umfang. Das konkrete Verhalten oder die Fähigkeit, die wir bauen. Konkret, nicht abstrakt.
2. Nicht im Umfang. Die zwei oder drei Dinge, die verwandt erscheinen würden, die wir aber explizit nicht tun. Das ist der wichtigste Abschnitt. Ohne ihn schleicht sich Scope Creep jedes Mal ein.
3. Das Labyrinth. Das bekannte Risiko: "Das könnte es erfordern, den Auth-Service anzufassen, und wenn das der Fall ist, halten wir an und überdenken den Umfang." Es vorab zu benennen bedeutet, dass der Engineer nicht eine Woche lang darin verschwindet.
4. Der Appetite. Maximale Zeit, die wir aufwenden, bevor wir den Umfang kürzen oder eskalieren. Keine Schätzung. Ein Budget.

Dreißig Minuten. Ein Dokument. Ein Ticket, das aus dem Shaping kommt, ist 4 bis 5 Mal wahrscheinlicher, nahe am Appetite zu landen als eines, das es nicht durchlaufen hat. Ich habe das bei Teams von 6 und Teams von 60 Personen beobachtet. Die Rechnung für den Zeitaufwand ist offensichtlich.

Tech-Debt-Budget: Die 20-Prozent-Regel

Zwanzig Prozent jedes sprints fließen in technische Schulden. Nicht "wenn Zeit ist". Nicht "wir kümmern uns nächstes Quartal darum". Eine feste, benannte, in der Planung sichtbare Zuteilung.

Wenn Sie das überspringen, häufen sich die Schulden auf. Bis zum dritten Quartal ist Ihr Auslieferungs-Durchsatz halb so hoch wie vorher, und niemand kann genau erklären warum. Der flackernde Test, der drei Wiederholungen braucht, um zu bestehen. Die Migration, die vor 18 Monaten temporär sein sollte. Der Service, den nur ein einziger Engineer deployen kann, der gerade in Elternzeit geht.

Zwanzig Prozent sind keine magische Zahl. Es ist die Untergrenze, unterhalb derer sich Schulden schneller anhäufen, als Sie sie abbauen können. Manche Teams brauchen in Aufholphasen 30 %. Manche können bei 15 % betrieben werden, wenn ihre Codebasis tatsächlich jung ist. Unterhalb von 15 % leihen Sie sich von der Velocity Ihres nächsten Quartals und werden es spüren.

Wie man entscheidet, welche Schulden man abbaut, in Prioritätsreihenfolge:

1. Kundenseitige Probleme. Bugs, die das Team umgangen hat, auf die Kunden aber noch stoßen. Performance-Probleme, die in Support-Tickets erscheinen. Immer an erster Stelle.
2. Entwicklerseitige Probleme. Langsame Tests, kaputte lokale Entwicklungsumgebung, Deployment-Fallen. Alles, was das Team eine Stunde oder mehr pro Woche kostet.
3. Theoretisches Aufräumen. Refactorings, die sich schön anfühlen würden, aber keinen zwingenden Grund haben. Letzte Priorität. Seien Sie ehrlich darüber, ob diese überhaupt in den sprint gehören.

Machen Sie die 20 % auf dem Board sichtbar. Kennzeichnen Sie Tickets mit "tech-debt". Berichten Sie den Prozentsatz in Ihrem wöchentlichen Planungs-Spike. Wenn ein sprint drei Wochen hintereinander unter 20 % fällt, ist das ein Signal.

Entsperrmuster: PR-Review-Frist und Entscheidungskalender

Zwei konkrete Mechanismen, die mehr bewegen als jede Planungsänderung:

PR-Review-Frist. Erstprüfung innerhalb von 4 Stunden während der Arbeitszeit. Keine Leitlinie. Eine verbindliche Zusage. Wenn ein PR 4 oder mehr Stunden ungeprüft bleibt, unterbricht der zugewiesene Reviewer das, woran er gerade arbeitet, und prüft ihn. Das klingt streng. Es funktioniert.

Die Teams, die das übernommen haben, liefern 2 bis 3 Mal mehr als vorher, und der Grund liegt auf der Hand: PRs, die 2 bis 3 Tage im Review sitzen, zwingen Engineers dazu, in eine andere Aufgabe zu wechseln, dann zurückzuwechseln, wenn das Review eingeht, und dann erneut zu wechseln, um Feedback zu adressieren. Jeder Wechsel kostet 30 bis 60 Minuten echter produktiver Zeit. Eine 4-Stunden-Frist bricht diese Schleife auf.

Der Wortlaut, den ich in die Teamvereinbarung aufnehmen würde:

Erstprüfung innerhalb von 4 Stunden während der Arbeitszeit, ausgenommen wenn ein Engineer in einem vorab angekündigten Fokus-Block ist. Reviews haben Vorrang vor anderer Arbeit, einschließlich des eigenen aktiven Tickets des Reviewers. Kommentar-Prüfungen zählen. Die Erwartung ist Feedback, nicht Genehmigung.

Entscheidungskalender. Ein 30-Minuten-Slot pro Woche, in dem EM und tech lead alles entscheiden, was noch aussteht. Architekturentscheidungen. Anbieterauswahlen. "Sollen wir Bibliothek A oder Bibliothek B verwenden?"-Fragen. Jede Frage, die länger als 48 Stunden in einem Slack-Thread liegt.

Ohne das ziehen sich Entscheidungen wochenlang hin. Engineers fragen einmal, bekommen ein "Ich denke darüber nach", und die Frage stirbt in einem Thread. Der Entscheidungskalender macht eine öffentliche Zusage: Bis Freitag 11:00 Uhr erhält diese Frage ein Ja, ein Nein oder ein "Wir brauchen noch 30 Minuten, um es zu prüfen". Kein "Ich melde mich bei Ihnen" mehr.

Beide Mechanismen sind rein technischer Natur. Sie erfordern keinen Kulturwandel und keine Überzeugungsarbeit. Sie führen sie am Montag ein und beginnen am Dienstag damit.

Wann eskalieren (und was "eskalieren" wirklich bedeutet)

Die meisten Engineering Manager missbrauchen das Wort "eskalieren". Sie denken, es bedeutet, zu ihrem Vorgesetzten zu gehen, wenn etwas brennt. Das ist keine Eskalation. Das ist ein Statusupdate mit zusätzlichen Schritten.

Eskalation bedeutet, die richtige unsichtbare Entscheidung sichtbar zu machen.

Drei Auslöser für echte Eskalation:

1. Der Umfang übersteigt den Appetite. Sie haben das Ticket auf einen 1-Wochen-Appetite ausgearbeitet. Der Engineer sagt Ihnen nun, es ist ein 3-Wochen-Problem. Die Entscheidung (machen wir es trotzdem? kürzen wir den Umfang? schieben wir es auf nächstes Quartal?) liegt außerhalb des Teams. Eskalieren.
2. Eine Abhängigkeit von einem anderen Team blockiert Sie seit 2 oder mehr Tagen. Sie haben gefragt. Sie haben nachgehakt. Nichts bewegt sich. Eskalieren Sie zum EM des anderen Teams, mit einer konkreten Anfrage und einer konkreten Frist. Nicht "Können Sie uns helfen?", sondern "Wir brauchen bis Donnerstag EOD ein Ja oder Nein, ob das Auth-Team das priorisieren kann."
3. Eine Architekturentscheidung betrifft mehr als Ihr Team. Sie sind dabei, eine neue Datenbank einzuführen. Ein neues Auth-Muster. Einen neuen Deployment-Ansatz. Wenn der Auswirkungsbereich größer als Ihr Team ist, eskalieren Sie nach oben, damit die Entscheidung auf der richtigen Ebene getroffen wird.

Eine 3-Zeilen-Eskalationsvorlage, die in Slack oder per E-Mail funktioniert:

Entscheidung erforderlich: [die konkrete Frage, formuliert als Ja/Nein oder Auswahl]
Warum jetzt: [was blockiert ist, wer betroffen ist, was das Warten kostet]
Frist: [wann Sie eine Antwort brauchen, mit konkretem Datum und Uhrzeit]

Das ist die gesamte Vorlage. Drei Zeilen. Kein Hintergrundabsatz. Wenn der Empfänger Kontext braucht, fragt er. Die Klarheit selbst ist das Entsperren.

Die ersten 30 Tage dieses neuen Rhythmus

Führen Sie das alles nicht am Montag auf einmal ein. Der schnellste Weg, das Vertrauen eines Teams zu verlieren, ist, ein neues Betriebsmodell anzukündigen und zu verlangen, es zu befolgen, bevor sie gesehen haben, dass irgendetwas davon funktioniert.

Ein 30-Tage-Rollout, der trägt:

Woche 1: Ein wiederkehrendes Meeting abschaffen. Wählen Sie das, das niemand mag. Wahrscheinlich das Mid-sprint-Refinement. Absagen. Beobachten, was schiefgeht. Meistens nichts. Wenn etwas schiefgeht, haben Sie erfahren, was dieses Meeting tatsächlich geleistet hat.

Woche 2: Den neuen 1-Stunden-Planungs-Spike einführen. Einmal durchführen. Eine kurze Nachricht ans Team schicken, in der das neue Format und der Grund erklärt werden. Die Stunde durchstehen. An die Zeitgrenze halten.

Woche 3: Ticket-to-PR-Latenz messen. Daten aus Ihrem Tool ziehen. Das Diagramm erstellen. Noch nicht teilen. Nur eine Woche selbst anschauen, um zu verstehen, wie Ihre Verteilung tatsächlich aussieht.

Woche 4: Daten mit dem Team auswerten und anpassen. Das Diagramm vorlegen. Fragen: "Was sehen wir? Was überrascht uns? Was würden wir ändern?" Das Team einbeziehen. Den Rhythmus entsprechend ihrer Rückmeldungen anpassen.

Bis Tag 30 haben Sie 6 oder mehr Stunden Planung durch 1 Stunde ersetzt, das eine Signal gemessen, das zählt, und dem Team einen Rhythmus gegeben, den es verteidigen kann. Sie haben auch Ihre Zeit zurück. Nutzen Sie sie für das, wofür ein Engineering Manager tatsächlich bezahlt wird: Probleme ausarbeiten, Mitarbeitende entsperren und Ihre Engineers weiterentwickeln.

Die Freitagnachmittag-Szene vom Anfang dieses Artikels? In 60 Tagen werden Sie sie nicht mehr wiedererkennen. Ihr Kalender hat einen Planungsblock, einen Entscheidungskalender-Block und viel leeren Raum. Ihr Team liefert mehr. Und der Senior IC, der früher trotz Ihres Prozesses geliefert hat, liefert nun wegen ihm.

Mehr erfahren

• Staff Software Engineer Stellenbeschreibung
• Einzelgespräche führen, auf die Ihre Mitarbeitenden sich freuen
• Ziele setzen mit einem widerstrebenden Team