Flow first. Framework second.

Warum es egal ist, ob du Scrum, Kanban oder OKRs nutzt. Solange Arbeit nicht fließt.

Eine Sache, die mich wirklich auf die Palme bringen kann, ist die Tatsache, dass in vielen Teams und Unternehmen eine neue Methoden- bzw. Framework-Sau nach der nächsten durchs Dorf getrieben wird. Ich verstehe, dass dahinter oft der Wunsch steht, die Organisation zu verbessern. Leider sehe ich zu oft, dass damit nur oberflächliche Verbesserungen einhergehen. Wenn überhaupt.

Eher sehe ich, dass Regelwerke nicht sauber gelebt werden. Dass Rollen und Verantwortlichkeiten nicht geklärt sind. Dass Vanity-Metriken wie der heilige Delivery-Gral in die Management-Ebenen emporgehoben werden. Was leider nicht passiert, ist den Blick auf Time-to-Value zu richten. Darauf zu schauen, wie lange Arbeit von wo bis wo und wie durchs Unternehmen fließt.

Fragen, die man sich stellen sollte: Wo stockt es? Warum stockt es? Wie viele Hand-Offs passieren zwischen den einzelnen wertschöpfenden Arbeitsschritten? Wo ist wie lange Wartezeit? Was ist überhaupt ein wertschöpfender Arbeitsschritt und wo wird lediglich verwaltet, abgesegnet, gewartet? Ist das „Waste"? Und nach Lean: How to eliminate waste?

Ich glaube, das eigentliche Problem liegt tiefer als die Wahl des richtigen Frameworks. Und genau darum soll es in diesem Artikel gehen.

Das eigentliche Problem: Frameworks lösen keine Flow-Probleme

Scrum optimiert, wie ein Team arbeitet. Kanban macht Arbeit sichtbar. OKRs richten Ziele aus. SAFe skaliert agile Praktiken. Alles legitime Ansätze. Aber keiner von ihnen beantwortet die eine entscheidende Frage: Wie schnell fließt Wert von der Idee bis zum Kunden?

Das ist kein Versäumnis dieser Frameworks. Es ist schlicht nicht ihr Job. Scrum kümmert sich um den Sprint, nicht um die sechs Wochen Wartezeit davor, in denen ein Ticket in irgendeiner Backlog-Warteschlange lag. Kanban zeigt dir die Spalten auf dem Board, aber nicht die drei Abteilungen, die ein Feature durchlaufen muss, bevor es überhaupt ins Board kommt. OKRs definieren, wohin du willst. Aber nicht, warum du dort nicht ankommst.

Und genau das ist die Falle. Diese Frameworks erzeugen das Gefühl von Fortschritt. Das Board ist voll. Die Sprints werden abgeschlossen. Die Velocity steigt. Aber niemand fragt: Und was kommt beim Kunden an? Wann kommt es an? Und wie viel von dem, was wir hier tun, erzeugt überhaupt Wert?

Das Ergebnis kennt man. Teams mit hoher Velocity und gleichzeitig miserabler Time-to-Market. Teams, die unfassbar beschäftigt sind und trotzdem zu langsam liefern. Ein Feature, das vier Sprints durchläuft und am Ende trotzdem drei Monate braucht, bis es beim Kunden ist. Nicht weil die Entwickler langsam sind. Sondern weil zwischen den Sprints Wochen liegen, in denen nichts passiert. Warteschlangen. Freigabeprozesse. Abstimmungsrunden. Hand-Offs zwischen Teams, die unterschiedliche Prioritäten haben.

Das Problem ist nicht das Framework. Das Problem ist, dass niemand den end-to-end Fluss von Arbeit durch die Organisation betrachtet. Niemand fragt: Was passiert mit einer Idee, nachdem sie entstanden ist? Welchen Weg nimmt sie? Wie viele Stationen durchläuft sie? Wie lange liegt sie an jeder Station? Und wie viel von dieser Zeit ist tatsächlich wertschöpfende Arbeit?

Eine Analogie, die ich gerne nutze: Du kannst den Motor eines Autos so lange tunen, wie du willst. Wenn die Straße voller Schlaglöcher ist, wirst du trotzdem nicht schneller ankommen. Die Straße ist der Fluss. Der Motor ist das Framework. Die meisten Unternehmen tunen den Motor. Und wundern sich dann, warum es holpert.

Was wäre also, wenn man nicht das nächste Framework einführt, sondern stattdessen den Fluss selbst zum Gegenstand macht? Wenn man fragt: Wie kommt Arbeit von A nach B? Wo bleibt sie liegen? Und warum?

Flow Engineering: Den Fluss sichtbar machen

Genau hier setzt Flow Engineering an. Entwickelt von Steve Pereira und Andrew Davis und beschrieben in ihrem gleichnamigen Buch. Flow Engineering ist kein weiteres Arbeitsframework. Es ist ein Satz kollaborativer Mapping-Übungen, die den Fluss von Arbeit sichtbar, besprechbar und verbesserbar machen.

Die Grundlage ist nicht neu. Value Stream Mapping kennen viele aus dem Lean-Kontext. Was Flow Engineering anders macht, ist die Art der Umsetzung. Statt monatelanger Analyse-Projekte setzen Pereira und Davis auf schnelle, kollaborative Workshops mit den Menschen, die die Arbeit tatsächlich tun. Das ist kein Top-Down-Programm. Es ist ein Gespräch über den Fluss. Strukturiert durch fünf Maps.

Die fünf Maps

1. Outcome Map: Das Ziel klären

Bevor du den Fluss verbesserst, musst du wissen, wohin du willst. Die Outcome Map ist ein kollaborativer Workshop, in dem ein Team oder eine Gruppe von Stakeholdern ein klares Zielverständnis erarbeitet. Klingt trivial. Ist es nicht. In der Praxis stellt sich hier oft heraus, dass verschiedene Beteiligte völlig unterschiedliche Vorstellungen davon haben, was eigentlich erreicht werden soll. Unausgesprochene Annahmen kommen auf den Tisch. Zweifel werden sichtbar. Und das ist gut so. Denn nur mit einem klaren, gemeinsam getragenen Ziel lohnt sich die Arbeit an den nächsten Maps.

2. Current State Value Stream Map: Den Ist-Zustand sichtbar machen

Hier wird es konkret. Die aktuelle Wertschöpfungskette wird Schritt für Schritt visualisiert. Von der Idee bis zur Auslieferung an den Kunden. Entscheidend sind dabei zwei Zeiten: Cycle Time (wie lange wird tatsächlich gearbeitet?) und Wait Time (wie lange liegt die Arbeit herum?). In vielen Organisationen ist das Verhältnis erschreckend. Es gibt Value Streams, in denen die tatsächliche Arbeitszeit weniger als 20% der Gesamtdurchlaufzeit ausmacht. 80% Wartezeit. Nicht weil die Leute langsam sind. Sondern weil der Fluss nicht stimmt.

Das Ziel dieser Map ist nicht Perfektion. Es geht darum, den einen größten Engpass zu identifizieren. Die Theory of Constraints lehrt uns: Jedes System hat genau eine primäre Begrenzung. Diese zu finden ist der erste Schritt.

3. Dependency Map: Abhängigkeiten verstehen

Wenn du den Engpass identifiziert hast, zoomst du rein. Die Dependency Map zeigt, welche externen Teams, Tools, Prozesse oder Freigaben den Engpass verursachen oder verschärfen. Hier wird oft sichtbar, was vorher unsichtbar war. Versteckte Abhängigkeiten, die niemand dokumentiert hat. Der eine Slack-Channel, ohne den nichts weitergeht. Die eine Person, die als Bottleneck fungiert, weil nur sie die Freigabe erteilen darf. Das eine System, das nur zu bestimmten Zeiten deployed werden kann.

Es kommt vor, dass eine Dependency Map eines einzelnen Entwicklungsteams sieben externe Abhängigkeiten offenlegt. Von denen das Team selbst nur drei bewusst benennen kann. Vier sind „unsichtbar", weil sie als normal empfunden werden. „So läuft das hier halt." Genau das ist der Punkt. Was als normal gilt, ist oft der Grund, warum nichts fließt.

Die Dependency Map macht dieses unsichtbare Netzwerk sichtbar. Und das allein verändert schon die Konversation. Plötzlich diskutiert man nicht mehr über „warum ist das Team so langsam", sondern über „warum hat das Team sieben Abhängigkeiten, von denen es vier nicht beeinflussen kann".

4. Future State Map: Den Soll-Zustand definieren

Jetzt wird es gestalterisch. Basierend auf den Erkenntnissen aus den vorherigen Maps entwirft das Team gemeinsam einen verbesserten Zustand des Value Streams. Was würde der Fluss aussehen, wenn wir den Engpass beseitigt hätten? Welche Schritte können wir eliminieren, automatisieren oder parallelisieren? Wo können wir Hand-Offs reduzieren? Wo können wir Entscheidungskompetenzen näher an die wertschöpfende Arbeit verlagern?

Der Future State ist keine Utopie. Er ist ein realistisches Zielbild, das in einem überschaubaren Zeitraum (typischerweise drei Monate) erreichbar sein sollte. Das folgt dem PDSA-Zyklus (Plan-Do-Study-Act). Du definierst einen Soll-Zustand, arbeitest darauf hin, überprüfst die Ergebnisse und passt an. Dann beginnt der Zyklus von vorne. Keine Big-Bang-Transformation. Iterative Verbesserung, basierend auf echten Daten.

5. Flow Roadmap: Den Weg dahin planen

Die fünfte Map übersetzt Erkenntnisse in Aktion. Die Flow Roadmap priorisiert Verbesserungen über Zeithorizonte (Now, Next, Later), definiert Verantwortlichkeiten, Metriken und Methoden. Was machen wir sofort? Was nehmen wir uns als nächstes vor? Was parken wir bewusst?

Das Entscheidende: Die Roadmap gehört den Leuten, die die Arbeit tun. Nicht dem Management. Nicht der Beratung. Dem Team. Das ist nicht nur eine philosophische Position. Es ist praktisch notwendig. Verbesserungen, die von den Beteiligten selbst identifiziert und priorisiert wurden, haben eine ungleich höhere Chance, tatsächlich umgesetzt zu werden. Weil die Leute verstehen, warum sie wichtig sind. Weil sie selbst die Schmerzen gesehen haben, die sie adressieren.

Warum das funktioniert

Flow Engineering funktioniert, weil es drei Dinge gleichzeitig tut, die sonst selten zusammenkommen. Es schafft Value, also ein klares Zielverständnis. Es schafft Clarity, also Transparenz über den Ist-Zustand. Und es ermöglicht Flow, also den Weg zum Soll-Zustand. Dabei baut es auf bewährten Prinzipien auf. Lean, Theory of Constraints, Little's Law, Systemdenken.

Und was oft unterschätzt wird: Flow Engineering ist nicht auf Software-Entwicklung beschränkt. Alles, was einen Anfang und ein Ende hat. Hiring, Kunden-Onboarding, Angebotslegung, Support-Prozesse. All das kann als Value Stream betrachtet und verbessert werden. Die Frage „Wie fließt Arbeit von A nach B?" ist universell.

Flow Framework: Den Fluss messen

Flow sichtbar machen ist der erste Schritt. Aber wie misst du, ob sich etwas verbessert? Und wie kommunizierst du das an Stakeholder, die keine Lust haben, sich durch Value Stream Maps zu arbeiten?

Hier kommt das Flow Framework von Mik Kersten ins Spiel. In seinem Buch „Project to Product" argumentiert Kersten, dass die meisten Unternehmen immer noch in Projekten denken. Obwohl sie längst im Zeitalter der Produkte leben. Projekte haben einen Anfang und ein Ende. Produkte nicht. Produkte sind langlebige Wertströme, die kontinuierlich Wert liefern. Und sie brauchen andere Metriken als Gantt-Charts und Meilensteine.

Die vier Flow Items

Kersten definiert vier Typen von Arbeit, die durch jeden Wertstrom fließen:

Features sind neue Funktionalität, die direkt Kundenwert schafft. Das, wofür Kunden bezahlen.

Defects sind Qualitätsprobleme, die den Kundenwert mindern. Bugs, Fehler, Ausfälle.

Risks sind Arbeit an Sicherheit, Compliance und Regulatorik. Unsichtbar für den Kunden, wenn es gut läuft. Schlagzeilen, wenn nicht.

Debt sind technische Schulden. Architektur-Verbesserungen, Refactoring, Infrastruktur-Updates. Das, was man immer „später" macht. Bis „später" zu „nie" wird.

Diese Kategorisierung klingt einfach. Ist sie auch. Und genau darin liegt ihre Stärke. In den meisten Organisationen wird Arbeit in Epics, Stories, Tasks, Subtasks und was weiß ich zerlegt. Aber niemand fragt: Wie viel unserer Kapazität fließt eigentlich in neue Features versus wie viel in die Reparatur von kaputten Dingen? Wie viel Zeit investieren wir in technische Schulden versus Compliance? Die vier Flow Items machen diese Verteilung sichtbar. Und damit besprechbar.

Die Verteilung dieser vier Items sagt mehr über die Gesundheit einer Organisation als jede Velocity-Metrik. Wenn 60% der Kapazität in Defects fließt, ist das kein Feature-Problem. Es ist ein Qualitätsproblem. Wenn technische Schulden nie adressiert werden, entsteht das, was Kersten die „Tech Debt Death Spiral" nennt. Die Flow-Geschwindigkeit sinkt, weil alte Systeme alles verlangsamen. Die Defect-Rate steigt, weil der Code fragiler wird. Die Team-Zufriedenheit fällt, weil niemand gern an einem System arbeitet, das bei jeder Änderung bricht. Und das Management reagiert mit noch mehr Druck auf Feature-Delivery. Weil es die einzige Metrik ist, die es kennt. Ein Teufelskreis, der sich nur durchbrechen lässt, wenn alle vier Flow Items als gleichwertig betrachtet werden.

Die Flow Metrics

Kerstens Framework definiert fünf Metriken, die den Fluss messbar machen:

Flow Velocity misst, wie viele Items pro Zeiteinheit abgeschlossen werden. Nicht zu verwechseln mit der Sprint-Velocity aus Scrum. Hier geht es um abgeschlossene Einheiten im Wertstrom, nicht um geschätzte Story Points.

Flow Time misst, wie lange ein Item von Anfang bis Ende braucht. Von dem Moment, in dem die Arbeit beginnt, bis sie beim Kunden ankommt. Das ist die Metrik, die Time-to-Value am direktesten abbildet.

Flow Efficiency ist das Verhältnis von aktiver Arbeitszeit zu Gesamtdurchlaufzeit. In den meisten Organisationen liegt dieser Wert bei erschreckend niedrigen 15-25%. Der Rest ist Wartezeit. Genau das, was eine Value Stream Map sichtbar macht.

Flow Load misst, wie viel Work-in-Progress im System ist. Little's Law sagt uns: Je mehr WIP, desto länger die Durchlaufzeit. Mehr angefangene Arbeit bedeutet nicht mehr erledigte Arbeit. Es bedeutet mehr Kontextwechsel, mehr Abhängigkeiten, mehr Chaos.

Flow Distribution zeigt, wie sich die Arbeit auf die vier Item-Typen verteilt. Diese Metrik ist besonders aufschlussreich, weil sie die strategische Frage beantwortet: Investieren wir in die Zukunft (Features) oder reparieren wir die Vergangenheit (Defects, Debt)?

Das Schöne daran: Diese Metriken sprechen eine Sprache, die auch Business-Stakeholder verstehen. Kein Scrum-Jargon, keine Story Points, keine abstrakten Burndown-Charts. Stattdessen: Wie schnell liefern wir Wert? Wo investieren wir unsere Kapazität? Und stimmt die Balance? Ein CTO kann damit ebenso arbeiten wie ein CFO. Und genau das ist der Punkt. Denn solange Technologie und Business unterschiedliche Sprachen sprechen, kann kein Fluss entstehen.

Flow Engineering + Flow Framework

Die beiden Ansätze ergänzen sich. Flow Engineering nach Pereira und Davis gibt dir die Werkzeuge, um den Fluss sichtbar zu machen und zu verbessern. Auf Team- und Organisationsebene, in kollaborativen Workshops. Kerstens Flow Framework gibt dir die Metriken, um den Fortschritt zu messen und mit dem Business zu kommunizieren. Das eine ohne das andere ist nur halb so wirkungsvoll. Sichtbarkeit ohne Messung bleibt anekdotisch. Messung ohne Sichtbarkeit bleibt abstrakt.

KI als Flow-Beschleuniger. Aber nur, wenn der Fluss stimmt.

Und dann ist da noch KI. Das Thema, an dem aktuell niemand vorbeikommt. Und ja, KI hat enormes Potenzial, den Fluss von Arbeit zu beschleunigen. Aber, und das ist der entscheidende Punkt: nur dann, wenn der Fluss vorher verstanden und gestaltet ist.

Es gibt einen Satz, der es gut auf den Punkt bringt: Wenn du Automatisierung auf ein kaputtes System anwendest, reparierst du es nicht. Du skalierst die Dysfunktion.

Und genau das passiert gerade in vielen Organisationen. KI wird eingeführt, weil KI gerade eingeführt wird. Ein Copilot hier, ein Chatbot da, ein bisschen Automatisierung dort. Ohne zu fragen: Wo im Fluss schafft das tatsächlich Wert? Und wo schafft es nur neue Komplexität?

Es gibt drei Ebenen, auf denen KI den Fluss von Arbeit tatsächlich verbessern kann. Wenn sie richtig eingesetzt wird.

Ebene 1: Informationsfluss

In vielen Organisationen ist der größte Engpass nicht die Arbeit selbst, sondern das Warten auf Informationen. Warten auf Freigaben. Warten auf Kontext. Warten, bis jemand die richtige Slack-Nachricht liest. Warten, bis das Meeting stattfindet, in dem die Entscheidung getroffen wird, die schon vor zwei Wochen hätte getroffen werden können.

KI kann hier helfen, indem sie Wissenssilos aufbricht. Ein KI-gestütztes System, das relevante Informationen automatisch aggregiert, zusammenfasst und den richtigen Personen zur richtigen Zeit zur Verfügung stellt, kann Wartezeiten massiv reduzieren. Denk an ein Team, das auf Kontext aus einem anderen Fachbereich wartet. Statt Tage auf eine Antwort zu warten, könnte eine KI die relevanten Dokumente, Entscheidungen und Daten aus verschiedenen Systemen zusammenführen und in Sekunden bereitstellen. Nicht durch Beschleunigung der eigentlichen Arbeit. Sondern durch Eliminierung der Wartezeit davor.

Aber Voraussetzung dafür ist, dass du weißt, wo die Wartezeiten sind. Und genau das liefert eine Current State Value Stream Map.

Ebene 2: Prozessdesign

KI kann helfen, Durchlaufzeiten zu analysieren, Muster in Engpässen zu erkennen und Vorhersagen über Flow-Probleme zu treffen, bevor sie entstehen. Predictive Analytics auf Flow Metrics ist ein Bereich mit enormem Potenzial. Stell dir vor, dein System erkennt automatisch, wenn die Flow Distribution kippt. Wenn plötzlich mehr Kapazität in Defects fließt als in Features. Oder wenn die Flow Time bei einem bestimmten Team-Typ systematisch ansteigt. Das ist kein Science-Fiction. Das ist heute machbar, wenn die Datengrundlage stimmt.

Und genau da ist der Haken. Kerstens Flow Framework braucht saubere Daten. Es braucht eine klare Kategorisierung in Features, Defects, Risks und Debt. Es braucht definierte Value Streams mit messbaren Grenzen. Ohne das ist KI-gestützte Flow-Analyse nur ein weiteres Dashboard, das niemand versteht.

Ebene 3: Operative Wertschöpfung

Die offensichtlichste Ebene. KI kann nicht-wertschöpfende Arbeitsschritte automatisieren. Code Reviews, Testgenerierung, Dokumentation, Statusberichte, Zusammenfassungen von Meetings. All das sind Schritte, die in einem Value Stream oft als Waste identifiziert werden. Nicht weil sie unnötig sind, sondern weil sie manuell Zeit kosten, die nicht direkt Kundenwert erzeugt.

Aber auch hier gilt: Zuerst den Fluss verstehen, dann automatisieren. Flow Engineering hilft dir durch die Dependency Map zu identifizieren, welche Hand-Offs und Wartezeiten tatsächlich eliminierbar sind. Nicht alles, was automatisierbar ist, sollte automatisiert werden. Und nicht alles, was langsam ist, ist Waste. Manchmal ist eine manuelle Review der Schritt, der Qualität sichert. Die Kunst ist, den Unterschied zu kennen.

KI braucht Flow. Und Flow braucht Klarheit.

Was sich wie ein Henne-Ei-Problem anfühlt, hat eine klare Reihenfolge. Erst den Fluss verstehen (Flow Engineering), dann messen (Flow Framework), dann intelligent automatisieren (KI). Ohne die ersten beiden Schritte wird KI zur nächsten Framework-Sau, die durchs Dorf getrieben wird. Mit vielen Versprechen. Und wenig Wirkung.

Informations- und Prozessdesign muss so gestaltet werden, dass Arbeit fließen kann. KI ist ein Werkzeug, das diesen Fluss beschleunigen kann. Aber Werkzeuge brauchen eine Richtung. Und die kommt nicht aus der Technologie. Sie kommt aus dem Verständnis des Flusses.

Flow first. Immer.

Am Ende ist es simpel. Nicht einfach, aber simpel.

Es geht nicht darum, das nächste Framework einzuführen. Nicht darum, ob Scrum besser ist als Kanban oder ob OKRs die Lösung für alles sind. Es geht auch nicht darum, ob und wie schnell du KI einführst.

Es geht darum, hinzuschauen. Zu fragen: Wo fließt Arbeit? Wo nicht? Und warum?

Flow Engineering gibt dir die Werkzeuge, um diese Fragen kollaborativ zu beantworten. Kerstens Flow Framework gibt dir die Sprache, um die Antworten messbar zu machen. Und KI kann dir helfen, den Fluss zu beschleunigen. Wenn du weißt, wo.

Die Organisationen, die wirklich besser werden, sind nicht die mit dem neuesten Framework an der Wand. Es sind die, die verstanden haben, wie Arbeit durch ihre Strukturen fließt. Die sich trauen, hinzuschauen, wo es stockt. Die bereit sind, die unbequemen Fragen zu stellen. Die akzeptieren, dass Verbesserung kein Event ist, sondern ein fortlaufender Prozess. Schritt für Schritt, Map für Map, Constraint für Constraint.

Und manchmal ist die wichtigste Verbesserung nicht die nächste Automatisierung oder das nächste Tool. Manchmal ist es das Gespräch, das endlich stattfindet. Zwischen den richtigen Leuten. Über die richtigen Fragen.

Der Rest ergibt sich daraus.