In letzter Zeit habe ich sehr viel über Veränderung und ihre Auswirkungen auf organisatorischer und persönlicher Ebene geschrieben. Heute tauchen wir mal wieder ins Kanban Systemdesign ein. Und zwar mit der Vor-Queue.

Input Queue ist Science Fiction

Die Idee der Vor-Queue entstand das erste Mal vor ungefähr zwei Jahren in einem Systemdesign Workshop bei einem Schweizer Finanzdienstleistungsunternehmen, wie wir über die Input Queue und ihre Größe nachgedacht haben. Wir dachten, ein wöchentliches Queue Replenishment wäre gut und legten somit die Größe der Queue auf 8 fest, da die MitarbeiterInnen die Vermutung anstellten, dass dies die maximale Anzahl an Aufgaben ist, die sie pro Woche erledigen können. Nachdem wir kurz simulierten, wie das Kanban-System sich im realen Betrieb verhalten wird, tauchten gemischte Gefühle bezüglich der Input Queue auf. “Das glaubt ihr wohl selbst nicht, dass sich unsere Stakeholder entscheiden können, welche acht Sachen als nächstes von uns zu bearbeiten sind”, war von einem der beiden Abteilungsleiter zu hören. Ein erfahrener Entwickler argumentierte weiter: “Nicht nur dass sie sich auf die nächsten acht Aufgaben einigen müssen – sie dürfen ihre Meinung ja nicht mal mehr ändern. Sobald etwas in der Input Queue landet, darf es nicht mehr herausgenommen werden. Das klingt ja wie Science Fiction bei unserer derzeitigen Arbeitsweise.”

Eine Testerin ergriff das Wort und entkräftete: “Gestern haben wir noch über unsere Unzufriedenheiten gesprochen”, sie geht zu der gereihten Liste der Verbesserungswünsche und zeigt auf eine konkrete Karte, “und auf Platz zwei unserer Pain Points kann man hier lesen ‘Wir wollen wissen, was als nächstes zu tun ist.’ Das bekommen wir durch die Input Queue. Wenn wir uns Nummer Fünf unserer Verbesserungswünsche ansehen, lese ich ‘Wir wollen, dass sich Prioritäten nicht immer ändern.’ Das können wir mit einer geregelten Input Queue auch adressieren. Sobald eine Aufgabe reingehängt wird, machen wir sie.” Kollektives Nicken stellte sich ein aber so richtig überzeugt waren die Beteiligten noch nicht, dass die Stakeholder dieser Änderung zustimmen würden.

Die Analysten-Sicht

Wir entschieden uns spontan zwei der Stakeholder – Business Analysten – in den Workshop zu holen und mit ihnen das Thema zu besprechen. Das klappte auch wirklich gut, denn wir verstanden nun besser, was ihre Wünsche sind. “Wir müssen vor allem flexibel reagieren können. Es ist nun mal so, dass sich immer wieder Opportunitäten ergeben und wir wollen auf diese reagieren können”, meinte einer der Business Analysten. Ein immer wieder auftauchendes Muster beim Systemdesign: Die Einen wollen sich einen möglichst hohen Handlungsspielraum erhalten und die Anderen wollen konkret Wissen, was als nächstes zu tun ist. Opportunitäten kann man unter anderem auch gut mit Serviceklassen adressieren, was auch von einigen Leuten vorgeschlagen wurde. In dieser speziellen Situation ging es jedoch darum, dass die Stakeholder sich für Standard-Arbeit nicht eine Woche im Voraus festlegen wollten.

Der andere Business Analyst argumentiert weiter: “Ein weiterer wichtiger Punkt ist, dass wir sehen wollen, was in den nächsten zwei bis drei Monaten von euch fertig gestellt wird. Wenn ihr dieses Input Queue Dingsbums wollt, dann müssen wir das Limit auf mindestens 64 setzen – das entspricht eurer Rechnung nach ja zwei Monaten. Aber wie bereits davor schon erwähnt, wir müssen die Reihenfolge permanent ändern können, sonst zementiert ihr unsere notwendige Agilität ein.” Und hier fiel das A-Wort: Agilität. Ich wollte diese große Türe nicht auch noch aufstoßen und biss mir auf die Lippen. Eine Diskussion über Agilität vs. Chaos können wir nicht auch noch gebrauchen. Aber sicher ein schönes Thema für einen späteren Blog-Beitrag.

Groß und klein zugleich

In meiner Rolle des Moderators versuchte ich die Diskussion zusammenzufassen: “Ich habe gehört, dass es den Entwicklern vor allem darum geht, dass sich die Prioritäten nicht immer ändern und dass sie wissen wollen, welche Arbeiten in nächster Zeit auf sie zukommen. Das können wir über eine geregelten Zufluss zu unserem Kanban-System – der Input Queue und dem Queue Replenishment – erreichen. Von den Business Analysten habe ich gehört, dass es für euch wichtig ist, zu sehen, was in einem größeren Zeitfenster alles realisiert wird. Ihr wollt aber die Flexibilität behalten, dass sich die Reihenfolge der Aufgaben ändern darf.” Sehr fein. Zumindest Konsens über das Problem.

Meine Zahnräder im Hirn ratterten: Mehr Flexibilität bzw. Agilität bekommen wir durch eine kleinere Input Queue und häufigeres Replenishment hin. Wir könnten die Input Queue auf 4 reduzieren und zwei mal pro Woche nachfüllen. Dann hätten wir zwar mehr Flexibilität aber die Vorhersehbarkeit von den gewünschten zwei bis drei Monaten haben wir auf eine halbe Woche reduziert. Große und kleine Input Queue gleichzeitig lässt sich nun mal nicht realisieren. Die Lösung muss also außerhalb der Input Queue liegen. Ich machte folgenden Vorschlag: “Was haltet ihr davon, wenn wir vor der Input Queue eine Vor-Queue hin bauen, wo die Stakeholder die Reihenfolge ändern dürfen. Diese Queue kann auch  groß sein, damit ihr die notwendige Vorhersehbarkeit habt. 64 zum Beispiel, was zwei Monaten entspricht. Die Input Queue reduzieren wir dafür auf 4 und und sie wird zwei Mal pro Woche nachgefüllt, was euch höhere Flexibilität bringt.” Nach einiger Diskussion erlangten wir das gleiche Verständnis, was der Vorschlag bringen kann und wir einigten uns darauf, es einfach mal auszuprobieren. Man kann es nicht oft genug erwähnen: Beim Kanban Systemdesign ist Pragmatismus gefragt! Das initiale Board sah dann (schematisch dargestellt) so aus:

Ein paar Wochen später

Als ich einige Wochen später das Unternehmen wieder besuchte, hatte sich einiges getan. Die Vor-Queue wurde auf 20 reduziert, denn es stellte sich sehr schnell heraus, dass die Business Analysten es nicht schafften, 64 Arbeiten im Voraus zu definieren. Die Größe der Input Queue erhöhte sich auf 9 und es wurde nur mehr ein Mal pro Woche nachgefüllt, da durch das Queue Replenishment sehr viel Austausch unter den Stakeholdern stattfand und das permanente Umreihen von Aufgaben nicht mehr notwendig war. Was mich am Meisten freute: die Business-Analysten dachten laut darüber nach, für sich auch ein Kanban-System zu bauen. Mein Vorschlag, dass sie doch das bestehende System um die Business Analyse erweitern sollten, stieß auf sehr wenig Gegenliebe. Die Vorteile würden jedoch auf der Hand liegen: man spart sich Liegezeit von 29 Arbeiten und könnte somit drastisch Agilität erhöhen, Durchlaufzeiten senken und besseren Fluss erzeugen. Mehr dazu auch in einem späteren Blog-Eintrag.

Was spricht für eine Vor-Queue?

Heute macht das Unternehmen noch immer Kanban und die Business Analysten sind Teil des Kanban-Systems. Es hat sich überhaupt vieles getan und ich merke gerade, dass es schön wäre, wenn ich eine Case Study darüber machen könnte… 😉 Was waren meine Learnings? Viele! Ich habe folgende Hauptgründe identifiziert, warum sich Unternehmen häufig für eine Vor-Queue entscheiden:

• Forecasting: Instrument, um zu sehen, was voraussichtlich in einem längeren Zeitraum realisiert wird.
• Hohe Agilität: Input Queue kann klein gehalten werden und somit kann man schneller auf sich ändernde Bedingungen reagieren.
• Geringere Durchlaufzeiten: Input Queue kann klein gehalten werden, wodurch sich die Durchlaufzeit von einzelnen Aufgaben noch mal verkürzt.
• Late Commitment: Die Inhalte der Vor-Queue können sich permanent ändern, was vor allem für Business Analysten sehr wertvoll ist.