Wenn man Teams beim Arbeiten zusieht, sieht man selten das eigentliche Problem. Man sieht Menschen, die fleissig Tickets bearbeiten. Man sieht Boards, die sauber aussehen. Man sieht vielleicht sogar ein Velocity-Chart, das ordentlich wirkt.
Was man nicht sieht, sind die Abhängigkeiten. Sie laufen wie unsichtbare Fäden quer durchs Board, und sie werden fast immer zu spät entdeckt. Im Refinement. Im Planning. Oder, am schlimmsten, wenn der Sprint schon läuft.
Dann passiert, was immer passiert: Das Ticket blockiert. Jemand sucht sich schnell eine andere Aufgabe. Der Kontext wechselt, der Fokus geht verloren, Stories werden nicht fertig, Spill-overs häufen sich. Und das Sprintziel — falls es überhaupt eines gab — ist plötzlich in Gefahr.
So weit die Diagnose, die jeder kennt. Interessant wird es bei der Frage, wo die Fäden eigentlich hinlaufen.
Wo alle suchen, und wo es tatsächlich klemmt
Die Standardantwort lautet: bei den anderen Teams. Deshalb sehen die üblichen Gegenmassnahmen auch so aus — Abhängigkeitsboards, Scrum of Scrums, Team-Topologien, Schnittstellen zwischen Squads.
Eine Untersuchung von SINTEF und der Blekinge Tekniska Högskola, vorgestellt auf der EASE 2025, hat das im Frühjahr 2025 nachgemessen. Siebzehn Interviews aus neun Teams in zwei grossen nordischen Fintech-Unternehmen, beide seit über zehn Jahren agil, beide mit Teams, die mehrmals täglich deployen. Die Frage an die Teams war schlicht: Wo entstehen bei euch die längsten Verzögerungen?
Die Antwort war nicht das, was man erwartet.
Innerhalb der Teams: fast nichts. Die Arbeit, die ein Team selbst in der Hand hat, läuft. Code Reviews im Team wurden nur von zwei Teams überhaupt als Engpass genannt.
Zwischen den Entwicklungsteams: einiges, aber meist nur mässige Verzögerungen — und grösstenteils spezifisch für einzelne Teams, nicht systematisch. Ein Teamleiter erklärte, Pull Requests aus dem Nachbarteam gingen schnell durch, weil man ohnehin nebeneinander sitze und es direkt kläre.
Zwischen Entwicklungsteams und Supportfunktionen: hier wurde es ernst. Legal, Sicherheitsabteilung, Business Development, die Einheit, die die Datenbank verwaltet, die Einheit, die das Kernsystem betreut. Diese Abhängigkeiten wurden nicht nur in mehreren Teams genannt, sondern in beiden Unternehmen — ein Hinweis darauf, dass sie generisch sind und nicht am jeweiligen Kontext hängen.
Zwischen Entwicklungsteams und externen Anbietern: am schlimmsten. Ein Team berichtete, Änderungen am extern betriebenen Kernsystem dauerten zwischen einer Woche und drei Monaten, weil der Lieferant in Phasen plant.
Die Zahl, die hängen bleibt: Ein Teamleiter beschrieb, dass es anderthalb Monate Hin und Her gekostet habe, um eine einzige Zeile in einer Datenbank ändern zu lassen — weil das Team die Rechte dafür nicht hatte und die Änderung bei einer zuständigen Einheit bestellen musste.
Anderthalb Monate. Eine Zeile.
Warum die Grenze so hart ist
Die Erklärung ist unspektakulär und genau deshalb so hartnäckig: Die Supportfunktionen arbeiten nach anderen Regeln.
Sie haben eine andere Taktung — wer im Quartal plant, kann einem Team, das täglich liefert, nicht folgen. Sie kommunizieren über terminierte Meetings statt über einen Chat-Kanal, und ein Termin in zwei Wochen ist eine Wartezeit von zwei Wochen. Sie haben Freigabekulturen, die auf Risikovermeidung ausgelegt sind, nicht auf Durchsatz. Und sie haben oft schlicht zu wenig Kapazität, um Anfragespitzen aus mehreren Teams gleichzeitig zu bedienen.
Nichts davon ist Böswilligkeit. Es ist ein Taktunterschied.
Und hier liegt der Punkt, den ich für den wichtigsten des ganzen Themas halte: Agile Frameworks lösen das nicht für dich. Sie beschreiben, wie Teams untereinander koordinieren — Schnittstellen, Synchronisationspunkte, gemeinsame Planung. Was sie nicht beschreiben können, ist, wie du mit einer Rechtsabteilung zusammenarbeitest, die weder deine Kadenz noch deine Sprache hat. Das ist keine Framework-Schwäche. Das ist eine Aufgabe, die jemand in deiner Organisation persönlich übernehmen muss.
Warum du sie nicht an Entwickler delegieren kannst
In der Praxis wandert diese Aufgabe fast immer nach unten — egal ob sie beim PO, beim Scrum Master oder beim RTE hätte bleiben sollen. Nicht per Ansage, sondern durch Unterlassung: Niemand klärt es vorher, also klärt es der, der drauf stösst.
Das ist nicht nur ineffizient, es ist unfair. Ein Entwickler, der auf eine Freigabe der Sicherheitsabteilung wartet, hat weder den Kontakt noch das Mandat noch die Übersicht, um die Priorisierung dort zu beeinflussen. Er kann eine Anfrage stellen und warten. Mehr nicht. Und während er wartet, wechselt er den Kontext, und du zahlst den Preis zweimal — einmal für die Verzögerung, einmal für den verlorenen Fokus.
Genau deshalb ist die Frage „Wer ist verantwortlich?" keine rhetorische.
Die Antwort auf die Verantwortungsfrage
Es hilft, Abhängigkeiten nach dem zu sortieren, was sie eigentlich sind. Diane Strode hat dafür drei Grundtypen beschrieben, und sie sind praktisch, weil jede Sorte eine andere Person braucht:
Wissensabhängigkeiten — es fehlt Information, um weiterzuarbeiten. Welche Geschäftsregel gilt hier? Was heisst dieses Feld fachlich? Das gehört dem Product Owner. Nicht, weil er es weiss, sondern weil er weiss, wen man fragt.
Ressourcenabhängigkeiten — es fehlt ein Zugang, ein Recht, eine Person, ein System. Datenbankrechte, Testdaten, ein Spezialist aus einem anderen Team. Das gehört dem Scrum Master oder RTE, weil es organisatorische Reichweite braucht, nicht fachliche.
Prozessabhängigkeiten — etwas muss erst freigegeben, geprüft oder geliefert werden, bevor es weitergeht. Legal, Compliance, Sicherheitsprüfung, externer Lieferant. Das gehört ebenfalls der Rolle mit organisatorischer Reichweite — und zwar der, die auch beim Management vorstellig werden darf, wenn die Wartezeit unvertretbar wird.
Was in keinem Fall funktioniert: die Aufgabe als vierten Hut auf einem vollen Kopf zu vergeben. Ein Scrum Master, der bereits vier Teams betreut und zwölf Meetings pro Woche moderiert, wird keine Abhängigkeit zur Rechtsabteilung vorab klären. Nicht aus Unfähigkeit, sondern weil dafür keine Stunde übrig ist. Wenn du willst, dass jemand diese Arbeit macht, musst du sie ihm als Arbeit geben — mit Namen, mit Zeit, mit Mandat. Sonst passiert sie nicht, und du hast dich nur besser gefühlt.
Was „managen" wirklich heisst
Viele reden von Dependency Management und meinen damit: aufschreiben, dass es eine Abhängigkeit gibt. Ein Ticket, ein Label, eine Zeile im Board. Das ist wertlos. Eine dokumentierte Abhängigkeit blockiert genauso zuverlässig wie eine undokumentierte.
Managen heisst drei Dinge, und nur alle drei zusammen zählen:
Früh identifizieren — vor der Umsetzung, nicht währenddessen. Der späteste sinnvolle Zeitpunkt ist das Refinement.
Vorab klären — mit den Personen, die sie tatsächlich auflösen können. Nicht mit deren Postfach.
Absichern — mit einem Datum, das vor deinem Sprintstart liegt, und mit jemandem, der nachfasst.
Alles andere ist Selbstbetrug mit Jira-Unterstützung.
Der eine Eingriff
Wenn du nur eine Sache änderst, dann diese:
Ergänze dein Refinement-Template um ein Feld: Wer muss was liefern, bis wann, und wer fragt an? Eine Story, in der dieses Feld leer ist, geht nicht in den Sprint.
Kein Tool, kein neues Meeting, keine Rolle. Ein Feld und eine Regel. Der Effekt ist, dass die Frage überhaupt gestellt wird — und zwar zu einem Zeitpunkt, an dem eine Antwort noch etwas ändert. Die meisten Abhängigkeiten sind nämlich nicht unlösbar. Sie sind nur zu spät entdeckt.
Wie du Refinements so aufsetzt, dass dafür Platz ist, habe ich an anderer Stelle beschrieben. Dieses Feld ist die kleinste sinnvolle Ergänzung dazu.
Die Warteschlange verschwindet nicht, sie wandert
Ein Nachwort, weil gerade viele glauben, KI löse das Problem: Sie löst es nicht, sie verschiebt es.
Der DORA-Report 2025 von Google Cloud beschreibt KI als Verstärker — sie vergrössert die Stärken einer Organisation ebenso zuverlässig wie ihre Dysfunktionen. Und die Telemetriedaten von Faros aus 2026, erhoben über 22'000 Entwickler in mehr als 4'000 Teams, zeigen, wo das landet: Die mediane Zeit im Pull-Request-Review ist um 441 Prozent gestiegen. Angefangene Aufgaben, die wieder zurückfallen, nahmen um 13,8 Prozent zu. Und 26 Prozent mehr laufende Aufgaben zeigen sieben Tage oder länger überhaupt keine Aktivität. (Faros verkauft Messwerkzeuge, das gehört dazugesagt — die Richtung deckt sich aber mit dem, was DORA unabhängig findet.)
Schneller schreiben heisst nicht schneller liefern. Es heisst, dass die Schlange woanders steht.
Die Frage ist nicht, ob du Abhängigkeiten hast. Die Frage ist, ob jemand mit Namen und mit Zeit dafür zuständig ist, sie aufzulösen, bevor dein Team davorsteht.
Nächste Schritte
Wenn dieselben Blocker jeden Tag im Daily auftauchen: Dann sind es keine Blocker, sondern ungeklärte Abhängigkeiten — und dein Daily ist der falsche Ort dafür. → Warum dein Daily nichts bringt - und warum du es trotzdem behalten solltest
Wenn dein Team ständig zwischen Tickets springt: Das ist meist kein Disziplinproblem, sondern ein Wartezeitproblem. → Task-Switching ist kein Fehler - es ist ein Symptom
Wenn das Refinement dafür keinen Platz hat: → Die Kunst des effizienten Refinements
Wenn gar kein fester Rhythmus da ist, in dem das stattfinden könnte: → Heartbeat im Scrum Team: Warum feste Strukturen der Schlüssel zur Effizienz sind
Probier das eine Feld zwei Sprints lang aus und schreib mir, was es zutage gefördert hat. → Taleon LinkedIn
Quellen
- Tkalich, A.; Klotins, E.; Moe, N. B. — «Identifying Critical Dependencies in Large-Scale Continuous Software Engineering», Proceedings of EASE 2025, Istanbul. https://arxiv.org/abs/2504.21437
- Strode, D. E. — «A dependency taxonomy for agile software development projects», Information Systems Frontiers, 18(1), S. 23–46. https://doi.org/10.1007/s10796-015-9574-1
- DORA / Google Cloud — «State of AI-assisted Software Development», 2025. https://dora.dev/research/2025/dora-report/
- Faros AI — «AI Engineering Report 2026: The Acceleration Whiplash», Telemetriedaten von über 22'000 Entwicklern. https://www.faros.ai/research/ai-acceleration-whiplash