Bei uns in in der Postfiliale gibt eine gemeinsame Warteschlangen für drei Schalter. Einer von diesen Schaltern hat noch das Schild “Postbank-Beratung”, dort werden Postbankkunden bevorzugt bedient, man kann aber auch die normalen Post-Dienstleistungen bekommen.

Warum macht die Post eine Schlange für drei Schalter und nicht – wie im Supermarkt – drei separate Warteschlangen? Die Abarbeitungsgeschwindigkeit (Kapazität) wäre in beiden Varianten dieselbe, die Leute hinterm Schalter arbeiten ja nicht langsamer oder schneller.

Die Post macht es so, weil das Prinzip “eine Schlange für mehrere Schalter” Schwankungen in der Bearbeitungszeit ausgleichen kann. Wenn ein Vorgang sehr lange braucht (etwa eine Reklamation), werden die folgenden Kunden einfach an den anderen Schaltern weiter bedient. Bei der Methode “eine Schlange pro Schalter” hingegen wären alle Kunden blockiert, die das Pech haben, in der falschen Schlange zu stehen.

Der separate Postbank-Schalter sichert die Verfügbarkeit von Service für Postbankkunden. Gleichzeitig steht aber die Ressource zur Verfügung, um in Spitzenzeiten den normalen Postbetrieb mit abzudecken. Das wäre nicht möglich, wenn man einen spezialisierten Postbankschalter irgendwo anders in die Filiale gesetzt hätte.

Bei der Softwareentwicklung wollen wir natürlich auch die Durchlaufzeiten möglichst kurz halten. Und ebenso wie in der Postfiliale soll die Durchlaufzeit auch möglichst vorhersehbar also mit geringen Schwankungen behaftet sein.

Es ist ziemlich leicht, in das ungünstige Muster von “eine Schlange pro Schalter” zu verfallen: Da sind bestimmte Themen die Domäne eines einzelnen Entwicklers, nach dem Motto “Rabatt-Coupons? Das macht Felix”. Das hat die oben beschriebenen Auswirkungen: Wenn Felix etwas länger braucht (oder krank wird, oder zu einer Task-Force abgeordnet wird), verzögern sich auch seine anderen Aufgaben. Auch wenn man die Aufgaben eines Iterationszyklus zu früh einzelnen Entwicklern zuordnet, schafft man faktisch wieder mehrere einzelne Warteschlangen.

Idealerweise sollten alle Entwickler jederzeit jede Karte übernehmen können. Dann können wir nämlich so spät wie möglich entscheiden, wer etwas macht, und die Arbeit fließt einfach weiter, auch wenn einzelne Entwickler gerade blockiert sind.

Dazu empfiehlt es sich, z.B. am Wochenanfang die nächsten Karten mit dem gesamten Team zu besprechen. Dann bekommen alle das nötige Hintergrundwissen für jede Karte. Gemeinsam werden die Anforderungen geklärt, dabei findet man oft leichter den entscheidenden Spezialfall oder die Lücke in der Spezifikation. Außerdem aktualisiert diese Diskussion auch das Gesamtbild, das sich jede/r einzelne über die zu entwickelnde Software macht. Es ist also gut investierte Zeit, auch wenn am Ende nur einer die jeweilige Karte bearbeiten wird.

Wenn wir so jeden Einzelnen in die Lage versetzen, jede beliebige Karte zu bearbeiten, stehen die Karten in einer gemeinsamen Warteschlange, und Ausreißer in der Durchlaufzeit können eingedämmt werden.

Matthias Berth