Ein Framework zur systematischen Beseitigung von Verschwendung und zur Schaffung von Flow.
Alles beginnt mit Wert – und Wert wird vom Kunden definiert, nicht von Ihnen.
Das klingt offensichtlich, wird aber routinemäßig ignoriert. Teams bauen Features, die Kunden nie verlangt haben. Sie überladen Lösungen mit Komplexität, die niemand braucht. Sie optimieren interne Prozesse, die die Kundenerfahrung nicht beeinflussen.
Wert ist das, wofür der Kunde bereit ist zu zahlen. Alles andere ist Verschwendung.
In der Softwareentwicklung bedeutet das:
Bevor Sie Verschwendung beseitigen können, müssen Sie verstehen, wie Wert aussieht. Das erfordert tatsächliche Gespräche mit Kunden, Beobachtung, wie sie Ihr Produkt nutzen, und Messung von Ergebnissen – nicht nur das Ausliefern von Features.
Häufige Falle
Verwechseln Sie nicht Aktivität mit Wert. Features zu bauen ist Aktivität. Features auszuliefern, die Kunden lieben und für die sie bezahlen, ist Wert. Beides ist nicht dasselbe.
Ein Wertstrom ist die Abfolge aller Aktivitäten, die erforderlich sind, um Wert an einen Kunden zu liefern – vom ersten Konzept bis zum gelieferten Produkt.
Diesen Strom abzubilden bedeutet, jeden Schritt, jede Übergabe, jede Wartezeit zu visualisieren. Sie zeichnen den aktuellen Zustand ehrlich auf und zeigen, wo Arbeit tatsächlich fließt und wo sie stecken bleibt.
In der Fertigung könnte das sein: Rohmaterialien → Bearbeitung → Montage → Prüfung → Versand.
In der Softwareentwicklung könnte es sein: Idee → Priorisierung → Design → Entwicklung → Code Review → Testing → Deployment → Monitoring.
Die meisten Teams haben ihren Wertstrom nie abgebildet. Sie optimieren lokal – machen einen Schritt schneller – ohne das Ganze zu sehen. Aber die Verbesserung eines Nicht-Engpass-Schritts hilft dem System nicht. Oft macht es die Dinge schlimmer, indem es Bestände vor dem Engpass aufbaut.
Die Abbildung zeigt:
Sie können nicht verbessern, was Sie nicht sehen können. Die Abbildung macht das Unsichtbare sichtbar.
Sobald Sie den Wertstrom sehen können, ist das Ziel, Flow zu schaffen: Arbeit bewegt sich reibungslos und kontinuierlich von Anfang bis Ende, ohne Warten, ohne Stapelbildung, ohne Unterbrechungen.
Perfekter Flow ist Einzelstückfluss – jedes Element bewegt sich durch den gesamten Wertstrom ohne anzuhalten. In der Fertigung bedeutet das ein Auto nach dem anderen durch die Fabrik. In der Softwareentwicklung bedeutet das ein Feature nach dem anderen von der Idee bis zur Produktion.
Hindernisse für Flow sind:
Flow zu schaffen bedeutet nicht, schneller zu arbeiten. Es bedeutet, die Hindernisse zu beseitigen, die Arbeit verlangsamen. Oft bedeutet das, weniger auf einmal zu tun – kontraintuitiv, aber wahr.
Flow-Effizienz misst wertschöpfende Zeit als Prozentsatz der gesamten Durchlaufzeit. In den meisten Wissensarbeiten liegt sie bei 5-15%. Die anderen 85-95% sind Wartezeit. Flow zu verbessern bedeutet, Wartezeit anzugreifen, nicht Arbeitszeit.
Prinzip 4: Pull etablieren
In einem Push-System wird Arbeit basierend auf Zeitplänen und Prognosen zugewiesen. In einem Pull-System wird Arbeit basierend auf Kapazität und Nachfrage gestartet. Nichts bewegt sich, es sei denn, etwas nachgelagert signalisiert, dass es bereit ist.
Das klassische Pull-Signal ist die Kanban-Karte: Wenn Sie ein Element abschließen, ziehen Sie das nächste. Sie starten keine neue Arbeit nur, weil sie im Backlog ist – Sie starten sie, weil Sie Kapazität haben.
Pull-Systeme:
Prinzip 5: Perfektion anstreben
Lean ist kein Ziel – es ist eine Richtung. Das letzte Prinzip ist kontinuierliche Verbesserung: unermüdlich Perfektion anstreben, auch wenn Sie sie nie erreichen werden.
Das bedeutet:
Das Streben endet nie. Toyota verbessert sich seit über 70 Jahren und findet immer noch Wege, besser zu werden. Das Ziel ist nicht, „Lean zu werden" und aufzuhören – es ist, Verbesserung in die tägliche Arbeit einzubauen.
Ein Team mit WIP-Limit von 3 in der Entwicklung hat 3 Elemente in Bearbeitung. Sie starten Element #4 nicht, bis eines fertig ist. Das verhindert Überlastung und schafft vorhersagbaren Flow.
Ein Team „macht Kanban", hat aber keine WIP-Limits. Arbeit wird basierend auf Sprint-Planung zugewiesen. Elemente häufen sich in „In Bearbeitung" ohne Einschränkung. Das ist Push mit einem Kanban-Board – kein Pull.