Delivery by Design – Teil 1: Warum Delivery ohne Flow scheitert

Im Januar widmen wir uns bei How Others Do vollständig dem Solution Pattern 1: Flow‑Orientierung.
Dieser Artikel ist der Auftakt unserer vierteiligen Blogserie, die wir Ende des Monats mit einem Live‑Online‑Webinar abschließen.

Wir beginnen mit Flow, weil wir in nahezu jedem Unternehmen dasselbe Grundmuster beobachten:
Alle wollen schneller liefern. Die Teams engagieren sich, arbeiten hart, investieren viel. Doch am Ende zieht sich alles, Entscheidungen dauern, Abstimmungen verzögern Prozesse und Ergebnisse kommen viel später an, als es eigentlich möglich wäre.

Und die Daten unterstützen genau diese Wahrnehmung:

Kurz gesagt:
Flow beschreibt, wie Arbeit tatsächlich durch ein System fließt –
von der ersten Idee bis zum realen Kundennutzen.

Nicht, wie beschäftigt Teams sind.
Nicht, wie viele Tickets offen sind.
Sondern wie reibungslos, vorhersehbar und wirksam Wert entsteht.

1. Der Delivery‑Blindspot: Warum Geschwindigkeit kein Teamproblem ist

Wenn Delivery ins Stocken gerät, wird der Ruf nach mehr Tempo laut, doch Geschwindigkeit der umsetzenden Teams ist fast nie das eigentliche Problem.
Wir hören in diesen Situationen immer wieder dieselben Reflexe: „Wir müssen schneller werden“, „Wir brauchen mehr Leute“, „Wir brauchen bessere Tools“, „Wir müssen uns besser abstimmen“.

Wir haben all diese Maßnahmen in Organisationen gesehen, und in vielen dieser Fälle sogar begleitet. Trotzdem blieb die zentrale Erkenntnis immer dieselbe:

-> Delivery scheitert nicht an Tempo. Delivery scheitert an fehlendem Flow.

Wenn Arbeit nicht ungehindert fließen kann, entstehen Wartezeiten, Übergaben, Blockaden, Rückfragen und fragmentierte Arbeitspakete und ein Umfeld, das Teams zwangsläufig ausbremst, egal wie sehr sie sich bemühen.

2. Die Symptome: Woran du erkennst, dass euch Flow fehlt

Aus den letzten Jahren haben wir vier Symptome als Pattern herausgegriffen, die in unterschiedlichsten Organisationen auftreten.
Alle vier zeigen sich zunächst als Delivery‑Probleme, sind aber im Kern Flow‑Probleme.

Symptom 1: Eingeschränkte Reaktionsfähigkeit

(„Wir arbeiten schnell, aber alles hängt irgendwo fest.“)

Bei einem großen Automobilhersteller im Süden Deutschlands haben wir erlebt, wie Teams trotz hoher Professionalität kaum vorankamen, weil entscheidende Schritte im Wertstrom unvorhersehbar blockierten.

Die Teams selbst arbeiteten zügig und äußerst sauber. Doch wann immer Entscheidungen oder Freigaben aus dem Betriebsrat, der IT‑Security oder anderen nicht agilen Abteilungen notwendig waren, geriet der gesamte Prozess aus dem Takt. Mal kam Feedback innerhalb weniger Wochen, mal über Monate gar nicht, und gelegentlich musste der komplette Vorgang neu gestartet werden.

Ein Satz, den wir dort gehört haben, hat sich uns eingebrannt:

„Wir haben alles fertig. Wir wissen nur nicht, wann wir weitermachen dürfen.“

Die Wartezeit übertraf die eigentliche Arbeitszeit um ein Vielfaches. Trotzdem versuchte man ausschließlich, die Arbeit innerhalb der Teams zu optimieren und nicht die Engpässe zwischen ihnen. Ein klassischer Fall: Delivery wirkt langsam, aber eigentlich fehlt Flow.

Symptom 2: Feuerwehr‑Modus

(„Wir sind stolz auf Chaos, weil wir es so gut löschen.“)

In Service‑ und Incident‑Management‑Bereichen sehen wir häufig ein anderes Muster: Teams, die sich über ihre Fähigkeit definieren, ständig auf unvorhergesehene Probleme zu reagieren.

Ein Workplace‑Team erklärte einmal voller Überzeugung:

„Wir sind richtig gut im Feuer löschen.“

Was gut gemeint war, zeigte jedoch ein tiefes Problem:
Es gab kaum Zeit für Stabilisierung, Verbesserung, Prävention oder Qualität.
Brände wurden gelöscht, aber nie vermieden. Die Abhängigkeit von einzelnen Schlüsselpersonen war enorm und das gesamte System befand sich in einer Schleife aus Reaktivität und Erschöpfung.

Das ist kein Delivery‑Erfolg, es ist ein Alarmzeichen für fehlenden Flow.

Symptom 3: Unklare Prioritäten

(„Alles ist Top-Priorität. Und deshalb wird nichts fertig.“)

Genau mit diesem Verständnis war bei einem Finanzdienstleister der Softwareentwicklungsprozess organisiert.

Die Anforderungen wurden vollständig im Fachbereich erstellt und anschließend an die IT zur technischen Umsetzung übergeben. Auf dem Papier war der Prozess klar getrennt. In der Realität funktionierte er kaum.

Im Fachbereich fehlten die notwendigen Kompetenzen, um Anforderungen so zu formulieren, dass sie technisch eindeutig, konsistent und umsetzbar waren. Rückfragen waren die Regel, nicht die Ausnahme. Anforderungen wurden mehrfach überarbeitet, neu interpretiert oder verzögert.

Eine gemeinsame Verantwortung für das Ergebnis gab es nicht.
Der Fachbereich fühlte sich für die fachliche Idee zuständig, die IT für die technische Umsetzung. Wenn etwas nicht funktionierte, begann das Fingerpointing:

„Die Anforderungen waren unklar.“
„Die Umsetzung hat das falsch interpretiert.“
„So war das aber nicht gemeint.“

Zusätzlich verschärfte ein struktureller Zielkonflikt die Situation.
Die beteiligten Bereiche hatten unterschiedliche Zielvereinbarungen in der Linie. Während der Fachbereich auf Time-to-Market und Umfang optimiert wurde, standen für die IT Stabilität, Auslastung oder Budgettreue im Vordergrund.

Das Ergebnis war vorhersehbar:
Viele Übergaben, lange Klärungsschleifen, Frustration auf beiden Seiten und ein massiv gestörter Flow.

Das Problem war nicht die Qualität einzelner Mitarbeitender.
Das Problem war ein Prozessdesign, das Verantwortung trennt, wo sie gemeinsam getragen werden müsste.
Ein Mitarbeiter sagte uns damals:

„Der Fachbereich beschreibt, was er braucht, die IT setzt es um. So sind die Rollen doch eigentlich klar geregelt.“

Wenn alles wichtig ist, wird nichts fertig.
Das ist kein Priorisierungsproblem, es ist ein Flowproblem.

Symptom 4: Hoher Koordinationsaufwand

(„Wir reden mehr über Arbeit, als dass wir arbeiten.“)

Bei einem Finanzdienstleister, den wir begleiten durften wurde eine Taskforce ins Leben gerufen, um die ausufernde Meeting-Kultur in den Griff zu bekommen. Jedes Meeting sollte künftig klar definierte Ziele haben, eine Agenda, einen festgelegten Teilnehmerkreis, einen benannten Protokollanten und ein dokumentiertes Ergebnis.

Das Regelwerk war durchdacht, abgestimmt und sauber eingeführt. Und ja, es ist grundsätzlich sinnvoll, sich zu fragen, was in einem Meeting erreicht werden soll.

Doch eine entscheidende Frage wurde nicht gestellt:

Warum brauchen wir eigentlich so viele Meetings?

Statt die Ursachen zu analysieren, wurde das Symptom optimiert.
Meetings wurden besser strukturiert – aber nicht weniger.
Abstimmungen wurden sauberer – aber nicht kürzer.
Koordination wurde effizienter – aber nicht überflüssig.

Die eigentlichen Flow-Stopper blieben unangetastet:
unklare Verantwortlichkeiten, fehlende End-to-End-Ownership, fragmentierte Wertströme und Entscheidungen, die nicht dort getroffen werden konnten, wo die Arbeit passierte.

Das Ergebnis: Mehr Disziplin im Stillstand. Kein echter Flow.

“Wir verlieren zu viel Zeit in Meetings. Wenn wir sie sauber strukturieren, bekommen wir das in den Griff“

Realität und Studien zeigen dieselbe Tendenz:
392 Stunden Meeting‑Zeit pro Jahr, dazu 127 Stunden verlorener Fokus.
So kann kein Flow entstehen.

3. Die systemischen Ursachen: Warum diese Symptome immer wieder auftreten

Hinter diesen Symptomen stehen drei strukturelle Problem‑Patterns, die wir in praktisch jeder Organisation wiederfinden, unabhängig von Branche oder Größe.

Entscheidend ist:
Diese Symptome sind keine Zufälle.
Sie entstehen systematisch und fast immer aus denselben strukturellen Mustern.

Problem 1: Silostrukturen

(„Wir sind gemeinsam agil, aber getrennt organisiert.“)

Bei einer SAFe‑Einführung in einem Automatisierungsunternehmen wurde sehr deutlich, wie schnell gute Absichten im Rahmen funktionaler Strukturen verpuffen können. Business und IT sollten näher zusammenrücken, arbeiteten de facto aber weiterhin getrennt.

Teams hatten plötzlich zwei oder sogar drei Product Owner, eine Vielzahl an Produktmanagern (bis zu 11 Stück für einen Bereich) und gleichzeitig keinerlei echte End‑to‑End‑Verantwortung.
Ein PO brachte es auf den Punkt:

„Wir sind jetzt agil, aber wir arbeiten noch genauso wie vorher. Der Demand Manager heißt jetzt nur PO“

Silos lassen sich nicht durch Frameworks abschaffen.
Ohne Wertstrom‑Schnitt durchbrechen sie Flow.

Problem 2: Suboptimales Demand‑Management

(„Zu viel rein, nichts kommt raus.“)

Ein Kunde zeigte uns ein extremes Beispiel dafür, wie fehlende Struktur im Upstream zu völliger Überlastung führt.
Anfragen prasselten ungefiltert aus allen Richtungen ein, wurden nicht kategorisiert und nach dem Prinzip „oben sticht unten“ in die Teams gedrückt.

Ein Mitarbeiter formulierte es treffend:

„Ich weiß morgens nie, woran ich abends arbeiten werde. Da kommt irgendwo ein Auftrag her und schon darf ich meinen Plan umwerfen.“

Multitasking, ständiges Umschalten und völlig fehlender Fokus machten jede Form von Delivery nahezu unmöglich.
Nicht die Teams waren das Problem, sondern der fehlende Wertstrom.

Problem 3: Unklare Rollen & Zuständigkeiten

(„Wer entscheidet eigentlich?“)

Wir begegnen dieser Ursache in so gut wie jedem Projekt:
Entscheidungen bleiben hängen, Verantwortungen verschwimmen, Ownership fehlt.

Ob in Freigabeprozessen, in agilen Setups, bei Priorisierungen oder in cross‑funktionalen Abstimmungen, immer wieder hören wir Sätze wie:

„Wir haben es geklärt, aber niemand fühlt sich verantwortlich.“

Ohne klare Entscheidungspunkte stockt jeder Flow.
Und ohne Flow gibt es keine stabile, vorhersehbare Delivery.

Diese Unklarheiten wirken wie Sand im Getriebe.
Nicht sichtbar, aber überall spürbar und tödlich für Flow.

4. Die Wahrheit: Delivery beginnt mit Flow und nicht mit Tempo

Flow ist der entscheidende Mechanismus, der bestimmt, wie schnell eine Organisation Wert schafft.

Dabei geht es nicht um Geschwindigkeit im Sinne von „Teams müssen schneller arbeiten“, sondern um die Bedingungen, unter denen Arbeit überhaupt vorankommt:

  • transparente Wertströme
  • klare Verantwortlichkeiten
  • realistische Priorisierungen
  • minimale Übergaben
  • reduzierte Wartezeiten
  • weniger Fragmentierung

Die Wirkung ist vielfach belegt:
70 % der Unternehmen berichten höhere Produktivität durch Lean-Praktiken,
und Lean‑Projekte werden im Schnitt 30 % schneller abgeschlossen als traditionelle Ansätze. (Quelle: FullScale.io (Lean Enterprise Institute))

Flow ist das Betriebssystem moderner Delivery.
Wenn Flow funktioniert, fällt Delivery fast automatisch leichter.
Wenn Flow fehlt, wird jede Form von Geschwindigkeit zum mühsamen Kraftakt.

5. Wie es nächste Woche weitergeht (Teil 2)

In Teil 2 geht es um die zentrale Frage:

👉 Wie finde ich meinen Wertstrom und warum ist er der Startpunkt jeder Verbesserung?

Denn Flow entsteht nicht im Team, sondern im System.
Und der Wertstrom zeigt, wie dieses System tatsächlich arbeitet.

Wer hier Klarheit gewinnt, erkennt sehr schnell, warum viele Optimierungsinitiativen ins Leere laufen.

6. Webinar: Delivery by Design – Anmeldung öffnet bald

Am Ende der Serie vertiefen wir das Thema in unserem Live‑Online‑Webinar:

„Delivery by Design – Wie Flow eure Lieferfähigkeit verändert.“

Darin zeigen wir,
wie du Flowstopper sichtbar machst,
wie du Wertströme pragmatisch mappst
und wie Delivery in 30 Tagen messbar besser werden kann.

Das Webinar richtet sich an Führungskräfte, Produktverantwortliche, Coaches und alle,
die merken: Wir arbeiten viel, aber der Wert fließt nicht.

Die Anmeldung startet in Kürze.

7. CTA

Wenn du Teil 2 nicht verpassen möchtest:
👉 Folge uns auf LinkedIn

, , , , , , , ,