Warum Delivery-Probleme selten dort entstehen, wo man sie vermutet – eine kurze Geschichte aus einem konkreten Kundenprojekt
„Eigentlich läuft alles ganz gut.“ So begann das Gespräch mit dem Team in einem unserer Kundenprojekte. Die Zusammenarbeit war eingespielt, die Abläufe stabil, regelmäßig gingen neue Features live. Es gab keine größeren Störungen, keine offensichtlichen Probleme.
Wenig später ein anderes Gespräch – diesmal mit dem Management: „Wir investieren viel – aber der Impact bleibt aus.“
Zwei Perspektiven, die sich widersprechen. Und doch trafen beide die Realität.
Wenn Delivery funktioniert – und trotzdem nichts passiert
Das Team lieferte zuverlässig. Stories wurden umgesetzt, Releases kamen regelmäßig. Auch die Metriken passten: stabile Durchlaufzeiten, kontinuierliche Auslieferung, kaum Blocker. Alles deutete darauf hin, dass Delivery funktionierte.
Und trotzdem blieb die Frage: Warum verändert sich so wenig?
Die ersten Hinweise darauf waren leise.
Im Team fiel ein Satz wie: „Manchmal ist nicht ganz klar, warum wir etwas genau so bauen.“
Auf Stakeholder-Seite klang es ähnlich: „Das entspricht nicht ganz dem, was wir eigentlich gebraucht hätten.“
Kein klares Problem – aber ein wiederkehrendes Gefühl, dass etwas nicht ganz zusammenpasst.
Ein funktionierender Ablauf – mit kleinen Brüchen
Der Ablauf selbst wirkte schlüssig. Anforderungen wurden formuliert, dokumentiert und an das Team übergeben. Dort wurden sie gewissenhaft umgesetzt, inklusive aller Annahmen, die notwendig waren, wenn Informationen fehlten.
Während der Umsetzung tauchten Fragen auf – zunächst nur kleinere: Was genau ist gemeint? Wie ist ein bestimmter Fall zu behandeln? Die Antworten kamen zwar – aber oft verzögert oder nicht eindeutig. Also ging die Arbeit weiter.
Im Review zeigte sich dann ein vertrautes Bild: Das Projekt funktionierte – aber nicht ganz so, wie es sollte.
Also wurde nachgebessert. Hier eine Anpassung, dort eine Korrektur. Nichts Dramatisches, aber auch nichts Einmaliges. Mit der Zeit wurde klar: Das war kein Einzelfall, sondern ein Muster.
Features waren technisch korrekt, trafen aber nicht immer den eigentlichen Bedarf. Dinge funktionierten, fühlten sich aber unnötig kompliziert an. Und manches wurde gebaut, ohne später wirklich genutzt zu werden.
Kein Scheitern, aber auch kein echter Fortschritt.
Was im Delivery Audit sichtbar wurde
Erst im Delivery Audit wurde greifbar, was dahintersteckt.
Das Team arbeitete gut. Die Prozesse funktionierten. Auch die Tools lieferten die erwarteten Daten. Und trotzdem ging etwas verloren.
Was fehlte, war nicht der Output, sondern ein gemeinsames Verständnis.
Anforderungen wurden weitergegeben, aber nicht wirklich gemeinsam verstanden. Fragen wurden gestellt, aber oft erst dann, wenn die Umsetzung bereits lief. Feedback kam – nur häufig zu spät, um noch echte Wirkung zu entfalten.
Alle Beteiligten arbeiteten – nur nicht zur gleichen Zeit am selben Problem.
Die eigentliche Reibung enteht oft genau dort, wo Arbeit von einer Gruppe zur nächsten übergeht. In diesen Übergängen werden Dinge unterschiedlich interpretiert, Annahmen getroffen und Entscheidungen von ihrer späteren Wirkung entkoppelt.
Welche Hebel daraus entstanden sind
Aus dieser Analyse heraus wurden keine großen Transformationen vorgeschlagen, sondern gezielte, einfache Veränderungen.
Beispiele:
Übergaben werden bewusst durchbrochen, um früher gemeinsam zu klären, worum es eigentlich geht. Nicht erst dann, wenn etwas umgesetzt wird, sondern bevor Entscheidungen festgezogen sind.
Es kann auch hilfreich sein, während der Umsetzung einen kurzen gemeinsamen Abgleich einzubauen – nicht als Status, sondern als inhaltliche Rückversicherung: Sind wir noch auf dem richtigen Weg?
Gleichzeitig wird der Fokus in den Gesprächen verschoben: weg von der Frage, was konkret gebaut werden soll, hin zu dem, was sich dadurch eigentlich verändern soll.
Allein diese Verschiebung hat das Potenzial, Entscheidungen klarer und Diskussionen relevanter zu machen.
Was dieses Projekt deutlich gemacht hat
In diesem konkreten Fall lagen die Probleme nicht in der Umsetzung selbst. Sie entstanden vielmehr in den Zwischenräumen – dort, wo Verantwortung übergeht und Zusammenarbeit oft nur formal stattfindet.
Diese Stellen sind schwer zu erkennen, wenn man nur auf einzelne Bereiche schaut. Erst wenn man das Zusammenspiel betrachtet, wird sichtbar, wo Wert verloren geht.
Genau hier setzt ein Delivery Audit an: Es macht diese Zusammenhänge greifbar und zeigt, wo kleine Veränderungen einen großen Unterschied machen können.
Fazit
Es geht nicht darum, einzelne Teile zu verbessern, sondern darum zu verstehen, wie das System als Ganzes funktioniert – und wie gut seine Elemente miteinander verbunden sind.
Genau dort entscheidet sich, ob Arbeit tatsächlich Wirkung entfaltet.
Und jetzt?
Gerade wenn Delivery auf den ersten Blick gut funktioniert, lohnt sich ein genauerer Blick. Nicht auf einzelne Kennzahlen oder Prozesse, sondern auf die Momente dazwischen:
Dort, wo Anforderungen übergeben werden. Wo Annahmen entstehen. Und wo sich oft erst spät zeigt, dass etwas zwar gebaut wurde – aber nicht das Richtige. Genau hier liegt häufig ungenutztes Potenzial.
Die entscheidende Frage ist dabei nicht:
„Wo läuft es schlecht?“
Sondern:
„Wo könnte es deutlich besser wirken?“
Ein Delivery Audit hilft, diese Muster sichtbar zu machen – und gezielt dort anzusetzen, wo aus guter Arbeit auch tatsächliche Wirkung wird.
