Die Macht kleiner Batches - Lean Software Development

1Batch-Size-Ökonomie

Ein Batch ist eine Gruppe von Elementen, die zusammen verarbeitet werden. In der Fertigung: Teile, die in einem Durchlauf hergestellt werden. In der Software: Features, die in einem Release gebündelt werden.

Traditionelles Denken bevorzugt große Batches. Wenn das Einrichten der Maschine 30 Minuten dauert, stelle 100 Teile pro Durchlauf her statt 10. Verteile die Rüstkosten auf mehr Einheiten.

Diese Logik gilt auch für Software: Wenn das Deployment 2 Stunden dauert, bündle viele Features pro Deploy. Verteile den Overhead auf mehr Änderungen.

Aber diese Argumentation übersieht versteckte Kosten:

Bestandskosten: Große Batches erzeugen große Bestände. Teile warten. Features warten. Kapital ist gebunden. Feedback verzögert sich.

Qualitätskosten: Defekte in großen Batches betreffen mehr Elemente. Herauszufinden, welche Änderung den Bug verursacht hat, ist bei großen Releases schwieriger.

Verzögerungskosten: Kunden warten länger. Ein früh fertiggestelltes Feature wartet darauf, dass der Batch abgeschlossen wird.

Lernverzögerung: Du lernst erst aus der Kundenreaktion, wenn der gesamte Batch ausgeliefert ist. Monate an Arbeit könnten in die falsche Richtung gegangen sein.

Die Gesamtkosten großer Batches übersteigen oft die eingesparten Rüstkosten.

Der versteckte Trade-off

Große Batches tauschen Sichtbarkeit und Feedback gegen scheinbare Effizienz. Du fühlst dich effizient beim Verarbeiten großer Batches. Aber du bist länger blind für Probleme, du lernst langsamer und Bestände häufen sich. Die Effizienz ist illusorisch.

2Transaktionskosten reduzieren

Die zentrale Erkenntnis: Wenn du Transaktionskosten (Rüstkosten) reduzierst, werden kleine Batches wirtschaftlich.

Toyotas SMED (Single-Minute Exchange of Dies) reduzierte Maschinenwechsel von Stunden auf Minuten. Sobald der Wechsel günstig war, ergaben kleine Batches Sinn. Die Fabrik konnte herstellen, was benötigt wurde, wann es benötigt wurde, in jeder Menge.

In der Software umfasst der „Wechsel":

Build-Zeit
Dauer der Testsuite
Deployment-Komplexität
Overhead des Review-Prozesses
Release-Koordination

Jeder davon ist reduzierbar:

Schnelle Builds: Inkrementelle Kompilierung, Caching, kleinere Codebasen
Schnelle Tests: Paralleles Testen, intelligente Testauswahl, schnellere Unit-Tests
Einfache Deploys: CI/CD-Pipelines, Infrastructure as Code, Feature Flags
Leichte Reviews: Pair Programming, kleine PRs, Trunk-based Development
Keine Release-Koordination: Continuous Deployment eliminiert das Konzept

Wenn Transaktionskosten gegen null gehen, kann die Batch-Größe gegen eins gehen. Das ist Single-Piece-Flow: Jede Änderung geht einzeln in Produktion.

Continuous Deployment

Jeder Merge zu main löst automatisierte Tests und Deployment aus. Transaktionskosten: ~0 (automatisiert). Ein Entwickler merged 5 kleine Änderungen pro Tag. Jede ist innerhalb von Minuten in Produktion. Batch-Größe: 1 Änderung.

Das vierteljährliche Release

Deploys erfordern Genehmigung durch ein Change Advisory Board, Umgebungskoordination und Ausführung am Wochenende. Transaktionskosten: Tage an Aufwand. Releases erfolgen vierteljährlich mit 100+ gebündelten Änderungen. Herauszufinden, was kaputt ging, dauert Tage.

3Vorteile kleiner Batches

Wenn du kleine Batches erreichst, verbessert sich alles:

Schnelleres Feedback: Features erreichen Nutzer schnell. Du lernst, was funktioniert. Du kannst umschwenken.

Einfacheres Debugging: Wenn eine kleine Änderung ein Problem verursacht, ist die Ursache offensichtlich. Rollback ist einfach.

Geringeres Risiko: Jedes Deployment ist eine kleine Änderung. Der Wirkungsradius eines Bugs ist begrenzt.

Besserer Flow: Kleine Batches bewegen sich schneller durch das System. Die Lead Time sinkt.

Weniger Bestand: Keine großen Stapel wartender Arbeit, die darauf warten, released zu werden. Kapital ist nicht gebunden.

Höhere Qualität: Kleine Änderungen sind einfacher zu reviewen. Defekte werden früher erkannt.

Mehr Flexibilität: Du kannst schnell umpriorisieren. Du bist nicht an ein großes Release gebunden.

Team-Moral: Häufiges Ausliefern fühlt sich besser an als monatelanges Warten auf ein großes Release.

Der ultimative Ausdruck ist Continuous Deployment: Jede Änderung geht in Produktion, wenn sie fertig ist. Das ist Single-Piece-Flow für Software. Kein Batching, kein Warten, keine Koordination von Releases.

Wenn Continuous Deployment unmöglich scheint, frage: Welche Transaktionskosten müssten reduziert werden? Dann arbeite daran, sie zu reduzieren.

Beginne, wo du bist

Wenn du monatlich deployst, versuche wöchentlich zu deployen. Wenn wöchentlich, versuche täglich. Wenn täglich, versuche kontinuierlich. Jeder Schritt offenbart Hindernisse für den nächsten Schritt. Löse diese Hindernisse schrittweise.