Wenn ein Team langsam liefert, liegt die Ursache fast nie bei den Entwicklern. Es sind meist vier oder fünf konkrete Reibungspunkte, die niemand gemessen hat.
«Das Team ist langsam» ist ein Symptom, und Gründer diagnostizieren es meist fälschlich als Personalproblem. Nach unserer Erfahrung ist es fast immer ein Systemproblem: Arbeit wartet in Warteschlangen, Änderungen sind groß und riskant, Deployment macht Angst, und niemand hat Zahlen, mit denen sich argumentieren ließe.
Beginnen Sie mit vier Messgrößen
Diese vier sind gut etabliert und — wichtiger — diagnostisch: Jedes schlechte Ergebnis zeigt auf eine bestimmte Problemklasse.
| Metrik | Was sie bei schlechtem Wert offenlegt |
|---|---|
| Deployment-Frequenz | Zu große Batches, Deploys werden als Ereignisse behandelt |
| Durchlaufzeit für Änderungen | Wartezeit — meist Code Review oder QA-Warten, nicht das Programmieren |
| Fehlerrate von Änderungen | Schwaches Testing oder fehlende Staging-Parität |
| Wiederherstellungszeit | Kein geprobter Rollback, schlechte Observability |
Die üblichen Befunde
Code Review ist ein Engpass, kein Qualitätstor
- Pull Requests sind zu groß, um sinnvoll geprüft zu werden, also wird Review zum Genehmigungstheater
- Keine Erwartung an die Review-Reaktionszeit, also liegen Änderungen tagelang
- Ein einziger Senior ist der einzige Approver — eine Warteschlange mit einem einzigen Schalter
Deployment ist ein Ereignis
- Manuelle Schritte, die nur eine Person kennt
- Kein Rollback, dem jemand traut, also werden Releases gebündelt, was sie riskanter macht, was sie seltener macht
- Deploys in ruhigen Zeiten geplant — ein starkes Signal, dass das Team dem Prozess nicht traut
Arbeit ist gar nicht definiert
- Tickets, die ein Gespräch erfordern, bevor jemand anfangen kann
- Keine gemeinsame Definition of Done, also pendelt Arbeit zwischen Engineering und QA
- Zu viel gleichzeitig in Arbeit — alle beschäftigt, nichts wird fertig
Was zuerst zu ändern ist
- Deploys langweilig machen — automatisieren, Rollback ergänzen, üben. Alles andere verbessert sich, sobald das Ausliefern sicher ist.
- Batch-Größe verkleinern — kleinere Änderungen sind leichter zu prüfen, sicherer auszuliefern, schneller zu diagnostizieren.
- Ein Review-SLA setzen — Stunden, nicht Tage, mit einem zweiten Approver, damit nie eine Person der Engpass ist.
- Work in Progress begrenzen — Fertigwerden schlägt Anfangen.
- Das messen, was Kunden spüren, damit Vorfälle intern gefunden statt gemeldet werden.
Geschwindigkeit und Sicherheit sind in der Softwarelieferung kein Zielkonflikt. Teams, die am häufigsten deployen, haben auch die niedrigsten Fehlerraten — weil kleine, häufige, umkehrbare Änderungen zugleich schneller und sicherer sind.
Arbeitsabläufe untersuchen statt Menschen nach Kennzahlen sortieren
Vergleichbare Aufgaben zeigen Engpässe im System. Wartezeit und Nacharbeit erklären, ohne Aktivitätszahlen mit Produktivität gleichzusetzen.
- Mehrere abgeschlossene Änderungen einschließlich dringender Korrektur auswählen.
- Warteschlangen, Review-Runden, Übergaben und Deployment-Hürden messen.
- Eine Verbesserung mit Ausgangswert und Prüftermin erproben.
Häufige Fragen
Wie lange dauert ein Audit der Engineering-Prozesse?
Typischerweise ein bis zwei Wochen: Lieferdaten erheben, das Team interviewen, ein echtes Release beobachten und das Tooling prüfen. Das Ergebnis sollte eine kleine Zahl priorisierter Änderungen mit erwarteter Wirkung sein, kein Reifegradmodell-Score.
Werden Sie uns sagen, dass wir Scrum einführen sollen?
Nein. Methodik ist selten die Beschränkung — Wartezeit, Batch-Größe und Deployment-Risiko sind es. Teams haben unter jedem Framework gut geliefert und unter allen schlecht; die Zeremonie zu ändern, ohne diese drei Dinge zu ändern, bewirkt nichts.
Unser Team sagt, es braucht mehr Entwickler. Stimmt das?
Manchmal, aber in einen Prozessengpass hinein einzustellen macht es erst schlimmer — mehr Leute produzieren mehr laufende Arbeit gegen dieselben Review- und Deployment-Warteschlangen. Messen Sie zuerst, wohin die Zeit tatsächlich geht; wenn das meiste davon Wartezeit ist, ist Einstellen nicht die Lösung.
Sind rohe Lieferkennzahlen zum Teamvergleich geeignet?
Nur mit Kontext zu Produkt, Aufgaben und Betriebsbedingungen. Trends helfen bei der Diagnose; bloße Mengen belegen keine individuelle oder gemeinsame Wirksamkeit.
Liefert Ihr Team langsamer als es sollte?
Wir messen, wohin die Zeit wirklich geht, und beheben die größten Beschränkungen — meist in Wochen, nicht in Quartalen.
Weiterführend
Postmortems, die tatsächlich gelesen werden: Best Practices
Die meisten Postmortems sind Archäologie: ein genaues Protokoll von etwas, das niemand ändern wird. Ein nützliches erzeugt eine kleine Zahl von Dingen, die tatsächlich erledigt werden.
Technisches MVP-Audit: Was wir in den ersten 48 Stunden prüfen
Die meisten MVP-Audits produzieren ein Dokument. Ein nützliches produziert Entscheidungen: Was brennt, was kann warten, und was kostet die Behebung.