Der sichtbare Implementierungsengpass bündelt mehrere Wartezeiten

Beobachtung des Nutzers

Der Nutzer beschreibt am 23. August 2026 die eigentliche Implementierung im gegenwärtigen Scrum-Prozess als häufig sichtbaren Flaschenhals. Nach seiner noch nicht gemessenen Einschätzung nimmt jedoch nicht primär das Schreiben von Code die meiste Zeit ein. Fortschritt und Abschätzbarkeit werden wiederholt durch mehrere Bestandteile der als Implementierung behandelten Arbeit beeinträchtigt:

• Ermittlung konkreter Anforderungen;
• Klärung einer geeigneten Umsetzung in einem als zu komplex empfundenen System;
• Review und Test;
• Build und sicherer Rollout.

Die Beobachtung beschreibt die Wahrnehmung eines Beteiligten. Sie ist noch nicht durch Zeitdaten, eine gemeinsame Wertstromanalyse oder den Vergleich mehrerer Tickets bestätigt.

Zeitpunkte der Arbeitsschritte lassen sich nach Auskunft des Nutzers prinzipiell aus den vorhandenen Werkzeugen rekonstruieren. Schwieriger ist die kausale Zuordnung von Schätzabweichungen: Unklare Anforderungen, überraschende technische Komplexität und Probleme beim Rollout können einander bedingen oder erst spät sichtbar werden.

Features werden im beschriebenen Prozess mit Story Points nach erwarteter Komplexität geschätzt; Bugs werden nicht geschätzt. Story Points sind damit kein direktes Maß für Kalenderzeit oder tatsächlichen Arbeitsaufwand. Der ungeschätzte Bug- und Nacharbeitsstrom kann verfügbare Kapazität und Durchlaufzeit beeinflussen, ohne in der Feature-Schätzung sichtbar zu werden.

Bugs werden als unabhängige Tickets geführt. Eine Verbindung zum verursachenden Feature wäre nach Einschätzung des Nutzers häufig, aber nicht zuverlässig möglich; sie wird derzeit nicht explizit erfasst und kann deshalb nicht ausgewertet werden. Historische Daten erlauben somit keine belastbare Zuordnung späterer Qualitätsarbeit zu einzelnen Features.

Vorläufige Interpretation

Der Ticketzustand „in Umsetzung“ könnte aktive Programmierzeit, fachliche und technische Klärung, Rückläufe sowie Wartezeiten in Review, Test und Delivery verdecken. Eine Beschleunigung der Codeerzeugung würde dann nur einen Teil des sichtbaren Engpasses adressieren und könnte den Druck auf nachgelagerte Prüf- und Freigabeschritte erhöhen.

Diese Interpretation passt zur externen Warnung, Coding-Metriken nicht mit Gesamtdurchsatz gleichzusetzen. Development Value Stream Mapping schlägt vor, Lead Time, aktive Process Time und den Anteil vollständig und korrekt übergebener Arbeit je Schritt einschließlich der Rückläufe zu erheben. Die ACM-Synthese zu GenAI und Software Engineering argumentiert ebenfalls, dass Codeerzeugung häufig nicht die eigentliche Engstelle ist. Beide Quellen bestätigen jedoch noch nicht, dass dies im beschriebenen Team tatsächlich der Fall ist.

Nächster Prüfschritt

Für eine kleine Stichprobe abgeschlossener und laufender Funktionen sollten aktive Arbeit, Wartezeit und Rückläufe mindestens für Anforderungsklärung, Systemanalyse, Coding, Review, Test, Build, Deployment und erste Produktionsprüfung rekonstruiert werden. Erst danach lässt sich begründet auswählen, welche Arbeitsschleife ein agentisches Experiment verbessern soll.

Eine rein retrospektive Ursachenzuordnung wäre anfällig für Erinnerungseffekte und vorschnelle Ein-Ursachen-Erklärungen. Für neu beginnende Tickets sollten deshalb die zu Beginn bekannten Unsicherheiten festgehalten und auftretende Blockaden zeitnah mit Haupt- und Mitursachen markiert werden. Die Auswertung sollte unterscheiden, ob eine Abweichung durch veränderten Umfang, zuvor unbekannte Arbeit, Wartezeit, Nacharbeit oder Ausführungsvarianz entstand und ob sie früher erkennbar oder vermeidbar gewesen wäre.

Für ein Agentic-Engineering-Experiment sollten daher mindestens drei Ebenen getrennt bleiben: Story Points für die relative Planung von Features, Flow-Metriken für deren tatsächliche Durchlauf- und Wartezeit sowie Qualitätsmetriken einschließlich ungeplanter Bugs und Nacharbeit. Ein Feature sollte für die Auswertung nicht bereits mit erzeugtem oder gemergtem Code, sondern erst nach sicherem Rollout und einer festgelegten Beobachtungsphase als abgeschlossen gelten.

Für die ausgewählten Experiment-Features könnte die Bug-Triage prospektiv eine optionale Beziehung samt Zuordnungssicherheit erfassen. Dabei sollte zwischen durch das Feature neu eingeführten Fehlern, durch das Feature lediglich sichtbar gewordenen Altproblemen sowie ungeklärten oder unabhängigen Bugs unterschieden werden. Eine solche Zuordnung dient dem Lernen über Qualitätsfolgen und nicht der individuellen Schuldzuweisung.