Ich fürchte, wenn wir hier bei SoftwareLiefern.de von Warteschlangen in IT-Organisationen reden, klingt das immer etwas weit hergeholt. Wir vergleichen ja oft die Aufgaben (Tickets, User Stories) mit den Leuten, die in einer Warteschlange anstehen und darauf warten, bedient (=abgearbeitet) zu werden. Dann reden wir von Ankunftsrate, Abarbeitungsrate, “Vordrängeln” usw.

Warteschlange vor dem Louvre. Quelle: Wikipedia

Aber ein Software-Entwicklungsprozess ist ja alles andere als einfach. Da gibt es mehrere Phasen (Analyse, Entwicklung, Tests o.ä.), und vor jeder einzelnen Phase kann sich eine Warteschlange bilden. Manchmal muss ein Ticket ein paar Schritte zurück gehen im Prozess, weil ein Problem gefunden wurde, manchmal kann auch ein Schritt übersprungen werden. Dann haben wir noch mehrere Teammitglieder mit unterschiedlichen Spezialisierungen, ungeplante Arbeit, die die Pläne über den Haufen wirft usw. Die Schlange vor dem Museum oder an der Supermarktkasse ist dann doch ein zu einfaches Modell, oder?

Als mentales Modell möchte ich Ihnen heute die Abläufe beim Essen in einer Kantine anbieten. Auch dort gibt es normalerweise mehrere Schlangen: vor jeder Essenausgabe, an der Salatbar, an den Kassen.

Ungefähr so:

Oben links kommen die Gäste rein, sie nehmen sich ein Tablett und gehen zu einer Essenausgabe (oben). Manche gehen noch zur Salatbar, dann wird bezahlt, und man setzt sich an einen Tisch (unten). Wir sehen einige Warteschlangen. Wenn Sie wollen, können Sie auch die Tische, an denen gegessen wird, als “Warteschlangen” auffassen. Oder Sie stellen sich das vor als die eigentliche Abarbeitung der Phase “Essen” im “Kantinenprozess”. Wer fertig ist, bringt sein Tablett weg und verlässt die Kantine wieder durch den Ausgang (links in der Mitte).

In Ihrem Software-Lieferprozess entsprechen die Essenausgaben vielleicht einzelnen Entwicklern, der optionale Schritt “Salatbar” könnte so etwas wie Design oder UX sein. Und wahrscheinlich gibt es einen Schritt, den jede Aufgabe absolvieren muss: dem Bezahlen an einer Kasse entspricht dann etwa ein obligatorischer “Code Review”.

Nun können wir über Warteschlangen an einzelnen Arbeitsstationen reden, etwa die drei Leute, die an Ausgabe 3 anstehen. Wir können einzelne Durchlaufzeiten messen: wie lange dauert es vom Anstellen an der Kasse, bis zum Abschluss des Bezahlvorgangs? Und schließlich können wir versuchen, die gesamte Durchlaufzeit (Eingang bis Ausgang) zu verringern, zum Beispiel indem wir uns ansehen, wo die meiste Zeit mit Warten verbracht wird.

Wir können aber auch die gesamte Kantine als eine einzige Warteschlange auffassen, mit Ankunftsrate, Abarbeitungsrate und Work in Process (WIP). Einige Zusammenhänge werden gerade aus dieser stark vereinfachenden Perspektive offensichtlich:

Die Aufgaben kommen links rein, dann passiert etwas mit ihnen, nach einer gewissen Zeit verlassen sie das System (die Kantine, den Software-Lieferprozess) wieder. In dieser Sichtweise ist uns völlig egal, wieviele Phasen es gibt, wo und wieviel gewartet wird, ob eine Aufgabe vordrängelt usw.

Es ist nun keine einfache Schlange, die nach dem Prinzip FIFO (first in first out) abgearbeitet wird. Ein paar fundamentale Wahrheiten gelten aber trotzdem, zum Beispiel die Erkenntnis:

Wenn die Ankunftsrate dauerhaft größer als die Abarbeitungsrate ist, bekommen Sie ein Problem.

Beziehungsweise mehrere Probleme: Lange Durchlaufzeiten, dadurch ständiges Vordrängeln, kaum belastbare Terminzusagen und was sonst noch so zur Überlastung gehört.

Viele Organisationen (und ihre Scrum-Masters) spüren die Symptome der Überlastung, und versuchen, etwas innerhalb der Box oben zu ändern. Können wir unsere Scrum-Zeremonien noch etwas effizienter machen? Wie können wir die Entwickler dazu bekommen, neben ihren Tickets auch noch an grundsätzlichen Verbesserungen zu arbeiten? Können wir sie irgendwie dazu bringen, besser zusammenzuarbeiten, weniger Fehler zu machen, mehr Verantwortung zu übernehmen?

Das bedeutet, man versucht die Abarbeitungsrate zu erhöhen. Das ist nicht grundsätzlich schlecht, wir schreiben hier sogar meistens über Verbesserungen innerhalb des Software-Lieferprozesses. Aber für die erste Intervention in einer Überlastungssituation würde ich immer

den Zufluss an neuer Arbeit steuern.

Das Ziel muss sein, dass die (schwankende) Ankunftsrate dauerhaft unterhalb der (ebenfalls schwankenden) Abarbeitungsrate liegt, weil andernfalls das System mit unerledigter Arbeit volläuft und in die Überlastung rutscht.

Beide Raten lassen sich über ein WIP-Limit aufeinander abstimmen. In unserem Kantinen-Beispiel heißt das: begrenze die Anzahl von Leuten in der Kantine. Wenn das WIP Limit erreicht ist, lass erst jemanden rein, wenn vorher jemand anderes die Kantine verlassen hat. Von überfüllten Clubs kennt man das vielleicht, in der Fertigung heißt das Prinzip CONWIP (constant work in process).

Matthias Berth