Ein Scrum Master soll Impediments beseitigen. Das ist der Teil der Rolle, über den alle einig sind. Aber fragt ein Team, welches Impediment es dieses Quartal am stärksten ausgebremst hat, ist die ehrliche Antwort selten ein blockiertes Ticket oder eine fehlende Entscheidung. Es ist der Build, der zu lange dauert, die Merge Queue, die sich staut, der instabile Check, der die Hälfte der Runs abbricht. Die Impediments, die den Flow wirklich drosseln, sind systemisch und technisch — und genau die sind durch Facilitation nicht zu greifen.
Also werden sie nicht beseitigt. Sie werden getrackt. „Wir sollten uns mal die Pipeline ansehen“ wandert von Sprint zu Sprint, bis es kein Backlog-Eintrag mehr ist, sondern ein Mahnmal.
So eins hatte ich. Dann habe ich einen Agenten darauf angesetzt.
Das Impediment-Board hat eine Tiefenbegrenzung
Die Rolle des Scrum Masters wurde um eine bestimmte Art von Impediment herum entworfen: die organisatorische. Jemand wartet auf ein Approval. Zwei Teams brauchen dieselbe Umgebung. Eine Abhängigkeit kommt zu spät. Das sind Koordinationsprobleme, und die Werkzeuge dafür sind Koordinationswerkzeuge — eskalieren, verhandeln, moderieren, den Blocker sichtbar machen, bis jemand mit Autorität ihn löst.
Dieses Modell hat eine Tiefenbegrenzung. Es funktioniert bei Impediments, die ein nicht-technischer Moderator sehen und umgehen kann. Es scheitert an Impediments, die im System selbst stecken, denn ihre Beseitigung verlangt, das System zu lesen — nicht das Board. Kein Daily verkürzt einen Critical Path. Keine Eskalation schreibt einen CI-Workflow um. Man kann eine langsame Merge Queue sichtbar machen — rot an die Wand hängen — aber Sichtbarkeit ist keine Beseitigung.
Das ist die stille Lücke in der Art, wie die meisten Teams Delivery betreiben. Die Person, die für das Beseitigen von Impediments verantwortlich ist, kann die teuerste Klasse davon strukturell nicht beseitigen. Also werden die teuren als „Tech Debt“ oder „etwas für einen ruhigeren Sprint“ umklassifiziert — eine andere Art zu sagen, dass sie bleiben.
Was tatsächlich auf unserem Board lag: eine 14-Minuten-Merge-Queue
Das Impediment war in meinem Fall eine GitHub Merge Queue. Auf dem Papier war sie gesund — PRs wurden gemergt, Checks liefen grün, nichts brannte. Aber die Zahlen erzählten eine andere Geschichte, sobald ich hinsah. Bei P95 verbrachte ein einzelner PR rund 14,5 Minuten im Merge-Group-Processing und fast eine Stunde von „open“ bis „merged“. Sieben Merge-Group-Runs im Baseline-Sample waren fehlgeschlagen oder abgebrochen worden — Churn, der kein Signal über den Code lieferte, nur über die Pipeline.
Nichts davon ist durch Facilitation lösbar. Es gibt kein Gespräch, das einen verketteten CI-Job schneller macht. Der einzige Weg führt durch das Lesen des Workflows, das Finden des echten Constraints und dessen Änderung. Genau diese Arbeit liegt außerhalb der Reichweite eines klassischen Scrum Masters — und genau diese Arbeit kann ein Agent leisten.
Der Agent lieferte die Diagnose, nicht nur den Fix
Das Interessante war nicht, dass der Agent eine YAML-Datei editiert hat. Es war, dass er diagnostiziert hat, welche Änderung zählt. Er las den Merge-Group-Workflow, erkannte, dass die erforderlichen Jobs hinter einem Build-Schritt verkettet waren, der sie gar nicht blockieren musste, und flachte den Critical Path ab, sodass sie parallel laufen konnten. Diese eine Änderung traf den dominanten Engpass: Das Quality Gate fiel von 13,98 Minuten bei P95 auf 2,63.
Von dort arbeitete er sich durch die kleineren Impediments — jedes eines, das ein menschlicher Reviewer erst bemerken und ernst nehmen müsste:
- Er hörte auf, das .NET SDK auf Self-Hosted Runnern neu zu installieren, die es bereits mitbrachten — was zugleich eine Klasse von Queue-Churn durch SDK-Drift beseitigte.
- Er normalisierte die Burst-Kapazität der Runner, sodass kurze Jobs nicht mehr minutenlang auf einen Slot warteten — die Art Scheduling-Lücke, die nur im Tail sichtbar wird.
- Er nahm ein lautes, nicht erforderliches UI-QA-Gate aus dem Merge-Group-Druck und entfernte vier nicht-blockierende Fehlschläge, die Queue-Arbeit und Fehlalarme erzeugten.
- Er stabilisierte das Install-Tooling, besonders einen Secret-Scanning-Schritt, dessen Setup-Fehler begleitende Runs abgebrochen hatte — Churn durch Install-Flakes, der sich als echte Fehler tarnte.
Der kombinierte Effekt, gemessen gegen die Baseline vor der Änderung:
| P95-Metrik | Vorher | Nachher | Verbesserung |
|---|---|---|---|
| Queue Wait | 0,35 Min | 0,30 Min | 14,3% |
| Processing Time | 14,45 Min | 2,73 Min | 81,1% |
| Queue Cycle Time | 14,79 Min | 3,03 Min | 79,5% |
| End-to-End-PR-Zyklus | 59,03 Min | 6,53 Min | 88,9% |
Der Churn ging von sieben fehlgeschlagenen oder abgebrochenen Merge-Group-Runs in der Baseline auf null im beobachteten Sample nach dem Fix. Auch die nicht erforderlichen fehlgeschlagenen Merge-Group-Checks fielen auf null.
Ein ehrlicher Vorbehalt, weil die Zahlen ihn verdienen: Die „Nachher“-Werte stammen aus dem aktuellen Post-Fix-Sample, nicht aus einem vollen Zehn-Tage-Fenster, das der ursprünglichen 95-PR-Baseline entspricht. Die Richtung ist eindeutig; die statistische Äquivalenz ist noch nicht da. Das sage ich lieber, als es wegzurunden — eine Metrik, die man nicht qualifizieren kann, ist eine Metrik, der man nicht trauen kann.
Warum das eine Human-in-the-Loop-Geschichte ist, keine Ersatz-Geschichte
Es wäre leicht, das als „der Agent hat den Job des Scrum Masters gemacht“ zu lesen. Das ist die falsche Lehre. Der Agent hat nie entschieden, dass die Merge Queue es wert war, behoben zu werden, hat sie nie gegen das Übrige auf dem Board abgewogen und das Ergebnis nie verantwortet. Das tat ich. Der Agent schlug vor; ich gab die Änderung frei, bevor sie ausgeliefert wurde. Die Verantwortung wanderte nicht — sie blieb exakt da, wo sie war.
Was wanderte, war die Reichweite. Der Agent erweiterte das Spektrum der Impediments, die tatsächlich beseitigt statt nur benannt werden können. Und das konnte er nur, weil das System überhaupt observierbar war: Ohne die P95-Baseline hätte es nichts zu diagnostizieren gegeben und keine Möglichkeit zu wissen, dass die Änderung wirkt. Die Merge Queue fühlte sich in Ordnung an. Die Daten sagten, sie kostet eine Stunde pro PR. Man kann nicht verbessern, was man nicht misst — und man kann keinen Fix an einem System delegieren, das man nicht sieht.
Das ist dasselbe Muster, auf das ich mit Agenten in echter Infrastruktur immer wieder stoße. Sie ersetzen nicht das Urteil darüber, was zählt. Sie verkürzen den Abstand zwischen der Entscheidung, dass etwas zählt, und der Fähigkeit, etwas dagegen zu tun.
Das Reichweiten-Upgrade
Jahrelang war die Grenze beim Beseitigen von Impediments nicht Wille oder Prozessreife. Es war Reichweite — die Lücke zwischen der Person, die für den Flow verantwortlich ist, und der Tiefe, in der der Flow tatsächlich bricht. Agile gab Teams eine Rolle, um Impediments zu benennen, und ein Ritual, um sie sichtbar zu machen. Es gab dieser Rolle nie die Fähigkeit, in einen CI-Workflow zu greifen und das eine zu beseitigen, das zählte. Hier ist der Punkt, wo KI auf euren Delivery-Prozess trifft — nicht als neue Zeremonie, sondern als Veränderung dessen, was die bestehenden auflösen können.
Das Board war nie der Engpass. Die Diagnosetiefe war es.