Verschwendung 1: Teilweise erledigte Arbeit
Bestand in der Softwareentwicklung – Code, der existiert, aber nicht in Produktion ist.
1Bestand in der Wissensarbeit
In der Fertigung ist Bestand Teile und Produkte, die in Regalen liegen – gebundenes Geld, verbrauchter Platz, nicht gelieferter Wert. Lean Manufacturing hat Bestände bekanntlich auf nahezu null minimiert.
In der Softwareentwicklung ist Bestand weniger sichtbar, aber ebenso problematisch:
- Nicht zusammengeführte Branches: Code geschrieben, aber nicht integriert
- Offene Pull Requests: Änderungen warten auf Review
- Nicht veröffentlichte Features: Fertiggestellte Arbeit hinter Feature Flags
- Backlog-Einträge: Ideen dokumentiert, aber nicht gebaut
- Anforderungsdokumente: Spezifikationen geschrieben, aber nicht implementiert
- Designs: Mockups erstellt, aber nicht gebaut
Das ist teilweise erledigte Arbeit – investierter Aufwand, aber kein gelieferter Wert. Es ist die teuerste Form von Verschwendung, weil sie echte Investition ohne Ertrag darstellt.
Das Verfallsproblem
Physischer Bestand liegt im Regal. Software-Bestand verfällt. Ein nicht zusammengeführter Branch wird jeden Tag schwieriger zu mergen, während sich der Hauptbranch weiterentwickelt. Anforderungsdokumente veralten, während sich das Verständnis ändert. Je länger teilweise erledigte Arbeit liegt, desto mehr Aufwand ist nötig, sie fertigzustellen.
2Warum sich Bestand ansammelt
Teams erzeugen selten absichtlich Bestand. Er sammelt sich an durch:
Große Losgrößen: Je größer das Feature, desto länger dauert es bis zur Fertigstellung. Ein Drei-Monats-Projekt bedeutet drei Monate Bestand, bevor irgendein Wert geliefert wird.
Push-Systeme: Arbeit wird basierend auf Verfügbarkeit zugewiesen, nicht auf Kapazität. Wenn man mehr anfängt als man fertigstellen kann, wächst der Bestand.
Verzögertes Feedback: Warten auf Code-Reviews, QA oder Freigaben. Jede Warteschlange ist Bestandsaufbau.
Vorzeitige Arbeit: Einträge starten, bevor sie gebraucht werden. Spezifikationen für Features schreiben, die vielleicht nicht gebaut werden. Für imaginäre zukünftige Anforderungen designen.
Angst vor dem Zusammenführen: Teams, die sich vor Integration fürchten, halten Änderungen isoliert. Je länger sie warten, desto beängstigender wird die Integration – ein Teufelskreis.
Die Lösung ist nicht, schneller zu arbeiten – sondern kleiner. Losgrößen reduzieren. Continuous Integration implementieren. Arbeit basierend auf Kapazität pullen, nicht basierend auf Zuweisungen pushen.
Ein Team hat 47 offene Pull Requests, manche Monate alt. Jeder repräsentiert Investition, die keinen Wert liefert. Merge-Konflikte häufen sich. Kontext geht verloren. Schließlich werden PRs komplett aufgegeben – 100% Verschwendung.
Ein Team committed mehrmals täglich auf main. Kein Branch lebt länger als ein paar Stunden. PRs sind winzig und werden schnell reviewt. Bestand bleibt nahe null. Lead Time sinkt von Wochen auf Stunden.
3Teilweise erledigte Arbeit reduzieren
Strategien zur Bestandsreduzierung:
Fertigstellen vor Starten: WIP-Limits etablieren. Bevor man etwas Neues startet, etwas Laufendes fertigstellen. „Hör auf anzufangen, fang an fertigzustellen."
Losgrößen reduzieren: Große Features in kleine, unabhängig wertvolle Inkremente aufbrechen. Jedes Inkrement ausliefern, bevor das nächste gestartet wird.
Continuous Integration: Ständig auf main mergen. Branches nicht länger als einen Tag leben lassen. Integration durch Häufigkeit langweilig machen.
Schnelle Feedback-Schleifen: Wenn PRs tagelang auf Review warten, ist das Bestand. Review priorisieren. Schnell machen. Noch besser: Pair Programming, sodass Review eingebaut ist.
Pre-Work eliminieren: Keine Spezifikationen für Features schreiben, die nicht als nächstes kommen. Keine Systeme designen, die man nicht in diesem Sprint baut. Just-in-Time-Planung.
Das Ziel ist Flow: Arbeit bewegt sich durch das System, ohne sich an irgendeiner Stelle anzusammeln. Wenn man sieht, dass sich Bestand ansammelt, hat man ein Hindernis für Flow gefunden.
Messen Sie es
Zählen Sie Ihre laufende Arbeit. Wie viele Einträge sind gestartet, aber nicht fertig? Wie viele PRs sind offen? Wie viel nicht veröffentlichter Code existiert? Diese Zahlen tracken. Sie zu reduzieren ist meist der schnellste Weg zu schnellerer Lieferung.
- Teilweise erledigte Arbeit ist Bestand – Investition ohne Ertrag
- Software-Bestand verfällt, anders als physischer Bestand
- Große Losgrößen und Push-Systeme erzeugen Bestandsaufbau
- Fertigstellen vor Starten – hör auf anzufangen, fang an fertigzustellen
- Continuous Integration hält Bestand nahe null