Entwicklungsteam zu langsam? Woran es wirklich liegt

An den Leuten liegt es fast nie. In den meisten langsamen Entwicklungsorganisationen, die wir uns ansehen, sind die Entwickler gut, und jeder Einzelne ist den ganzen Tag ausgelastet. Die Langsamkeit sitzt zwischen ihnen: in Warteschlangen, die niemand sieht, in Reviews, für die niemand Zeit hat, und in Kennzahlen, die Geschäftigkeit messen statt Lieferung.

Die üblichen Verdächtigen (an denen es meist nicht liegt)

Drei Erklärungen fallen in jedem Erstgespräch, und alle drei gehen meist daneben. „Wir brauchen bessere Leute“: Wer Senior-Entwickler in ein verstopftes System einstellt, bekommt teure Verstopfung. „Wir brauchen mehr Prozess“: Zusätzliche Rituale erhöhen die Abstimmungskosten in einem System, dessen Problem das Warten ist, nicht das Chaos. „Dem Team fehlt die Motivation“: Wer genau hinsieht, findet motivierte Leute, die fünfmal am Tag blockiert werden. Läge es an einem dieser drei Punkte, hätten die Gegenmittel längst gewirkt.

Was Teams tatsächlich langsam macht

1. Unsichtbare Warteschlangen. Eine Aufgabe mit zwei Tagen Arbeit verbringt drei Wochen im System: Sie wartet auf das Review, auf ein anderes Team, auf eine Entscheidung, auf das Deployment-Fenster. Das Warten sieht niemand, denn jeder Einzelne ist beschäftigt. Die Arbeit ist schnell; der Fluss ist langsam.

2. Ein Engpass, überall spürbar. Jedes System hat genau eine engste Stelle: die Leiterin, über deren Tisch jedes Review muss, die Testumgebung, die sich alle teilen, der eine Kollege, der das Abrechnungsmodul versteht. Alles andere zu beschleunigen ändert nichts. Diese eine Engstelle zu finden und zu weiten ändert alles.

3. Fehlende Verifikation. Ohne schnelle, verlässliche Tests ist jede Änderung doppelt langsam: Entwickler zögern, bevor sie etwas anfassen, und Fehler kommen aus der Produktion als ungeplante Arbeit zurück, die jeden Plan zerlegt. Dasselbe ist übrigens die häufigste Sperre für Agentic Coding: Ein KI-Agent ohne Verifikationsschleife kann die eigene Arbeit nicht prüfen, und der Produktivitätssprung bleibt aus.

4. Die falschen Kennzahlen. Story Points und Velocity messen die Schätzkultur, nicht die Lieferung. Ein Team kann „50 Punkte pro Sprint schaffen“, mit steigender Velocity, während Kunden Monate warten. Die Zahlen, die nicht lügen können: Durchsatz (fertige Aufgaben pro Woche) und Zykluszeit (von „begonnen“ bis „beim Kunden“).

Was in den ersten 30 Tagen zu tun ist

Kein Transformationsprogramm. Vier Schritte, der Reihe nach: den Fluss sichtbar machen (ein Board, das Wartezustände zeigt, nicht nur „in Arbeit“); die Zykluszeit messen, von Beginn bis Auslieferung, als Ausgangsbasis, an der sich jede Verbesserung messen lassen muss; den einen Engpass finden (wo sich die Arbeit staut, dort ist er); nur diesen weiten und danach erneut messen. Das ist der Kanban-Kern unseres Vorgehensmodells: anfangen mit dem, was da ist, ohne Radikalumbau.

Und es funktioniert. Bei Novadex haben wir die Entwicklungsorganisation genau so umgebaut: Am Ende stand eine Zykluszeit von 10 Tagen, gemessen, nicht geschätzt. Das Muster wiederholt sich: Das Team konnte es immer; das System darum herum konnte es nicht. Wie wir daraus ein 100-Tage-Engagement machen, steht unter Modernisierung der Entwicklungsorganisation, und die Fragen, die CTOs uns zuerst stellen, in den häufigen Fragen.