Kanban: Wer will schon ein Bottleneck sein?

In einem Kanban-Projekt habe ich ein interessantes zwischenmenschliches Problem. In Kanban versuchen wir, sinnvoll mit den Bottlenecks umzugehen, um die Durchlaufzeiten zu reduzieren.

Im Rahmen der Theory of Constraints gibt es sogar ein standardisiertes Verfahren zum Umgang mit Bottlenecks:

  1. Identify. Identify the bottleneck of the system.
  2. Exploit. Exploit this bottleneck, making its throughput efficient by changing processes, equipment maintenance procedures, training, policies, etc.
  3. Subordinate: Subordinate the throughput of all other work centers to this work center.
  4. Elevate. Invest in this work center to increase its throughput – add equipment, manpower, etc.
  5. Inertia. Start the process over on the line to determine the new bottleneck.

Das ganze kommt aus einer allgemeinen Systemtheorie und ist natürlich in der Produktion sehr wichtig und auch nützlich. Kanban für die Softwareentwicklung möchte die Theory of Constraints für die Softwareentwicklung auch anwenden. Und da lauert eine Fußangel, die ich auch nicht vorhergesehen habe.

Bei Kanban für die Softwareentwicklung bilden meistens Menschen das Bottleneck. Und wenn wir jetzt beginnen, diese als Bottleneck zu bezeichnen, fühlen sie sich häufig angegriffen. “Ich bin doch kein Bottleneck. Ich tue doch mein Möglichstes.” etc. Auch wenn niemand diese Menschen angreifen wollte, sind sie nun zunächst in einer Verteidigungshaltung. Und das ist die denkbar schlechteste Voraussetzung dafür, mit diesen Menschen Veränderungen im Prozess und in den Arbeitsweisen herbeizuführen.

Ich habe dafür bisher keine Patentlösung. Der erste wichtige Schritt ist sicherlich, sich dieses Problems bewusst zu sein.

Kanban ohne Stress?

Ich begleite jetzt schon eine Weile ein Kanban-Team bei einem Kunden und mache dort ganz interessante Erfahrungen.
Eine “Falle” bei Scrum ist das Commitment auf das Sprint-Ziel. Es kann so missverstanden werden, als wäre es eine Garantie des Teams. So passiert es leider immer wieder, dass Teams über einen längeren Zeitraum Überstunden ohne Ende schieben mit den bekannten Ergebnissen: miese Qualität, schlechte Arbeitsmoral, Burnout, etc.
Wenn das Commitment zu solchen Problemen führt, handelt es sich meiner Meinung nach um einen Fehler bei der Scrum-Implementierung. Aber trotzdem tritt dieser Fehler relativ häufig auf.

Kanban hat dieses Problem nicht. Es gibt keine Sprints/Iterationen und auch kein Commitment auf Sprint-Ziele.

Allerdings: Vor kurzem musste ich ein Teammitglied vertreten. Bei dem Kunden gibt es gleich zu Anfang auf dem Kanban-Board eine Spalte, in der die Tickets landen, wenn es einen technischen Lösungsvorschlag der Entwickler gibt. Wenn dieser akzeptiert wird, wird das Ticket in die nächste Spalte verschoben und die Entwicklung kann beginnen.
Ich war nun für die Freigabe der Tickets vorantwortlich und natürlich brauchte ich dafür viel länger als das Teammitglied, das ich vertreten habe. Ich wurde also zum Bottleneck im System. Und da war ich ganz plötzlich doch im Stress. Ich wusste, dass 10 Leute oder mehr ohne Arbeit dastehen, wenn ich nicht möglichst schnell die Tickets freigebe. Und ich würde auch bis spät in die Nacht arbeiten, um meine Teamkollegen mit ausreichend Arbeit zu versorgen.

Ähnlich wie bei den Scrum-Commitments handelt es sich hier um eine fehlerhafte Implementierung von Kanban. Tatsächlich ist die Existenz des Bottlenecks ein organisatorisches Problem. Dass meine Teamkollegen keine Arbeit mehr haben, ist gewollt. Es soll das eigentliche Problem deutlich zeigen und dann sollen wir als Team eine Lösung dafür finden und das Bottleneck beseitigen.

Hier scheint mir kein relevanter Unterschied zwischen Scrum und Kanban zu existieren: Beides kann missverstanden werden und so ein Missverständnis kann in Überlastung einzelner oder aller Teammitglieder enden.

Flow, Pair Programming, Teams und das Unerwartete

Ich bin jetzt endlich dazu gekommen, einen Artikel zu lesen, der schon eine Weile bei mir rumlag: “Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience” (PDF).

Auch wenn der Artikel nicht mehr ganz frisch ist, ist er dennoch sehr erfrischend. Er untersucht die Auswirkungen verschiedener Team-Organisationsformen in agilen Projekten. Zuerst belegt er die Annahme, dass Teams, die sich selbst Tasks nehmen, die effektivste Form der Arbeitsorganisation ist. Gefolgt von Teams, denen die Aufgaben zugewiesen werden, gefolgt von Individuen, die sich die Arbeit selbst nehmen, gefolgt von Individuen, die Arbeit zugewiesen bekommen. Damit ist die klassische Form der Arbeitszuweisung am wenigsten effektiv. Interessanterweise geht FDD mit seinem Class-Ownership-Konzept aber auch in diese (ineffektive) Richtung.

Richtig interessant wird der Artikel aber bei der Frage des Pair-Programming. Die Autoren haben bei sich festgestellt, dass die Enwicklung dann mit Abstand am Effektivsten war, wenn alle 90 (!) Minuten die Pair-Partner getauscht wurden. Bei wachsender Teamgröße (11 Personen) war 120 Minuten die ideale Zeitspanne, bis die Paare wieder wechseln sollten.
Das ist wirklich erstaunlich. Normalerweise geht man davon aus, dass man für hochproduktives Arbeiten im Flow arbeiten muss. Der Flow-Zustand hat aber auch Nachteile: Man braucht lange, um in den Flow-Zustand zu gelangen und wenn man drin ist, ist der Zustand fragil. Durch Unterbrechungen kann er schnell zerstört werden. Nun sagen die Ergebnisse des Papers, dass man auch ohne Flow-Zustand extrem produktiv sein kann – schließlich institutionalisiert das extrem häufige Wechseln des Pair-Partners ja gerade die Unterbrechungen. Dadurch geht man immer wieder mit einer neuen Perspektive an die Aufgabe heran (“Beginners Mind”) und kommt so auf die besten Ideen. Und das ist offenbar sehr produktiv.

Und an dieser Stelle finde ich den Artikel auf einer Meta-Ebene sehr interessant: Die Autoren haben ein “Naturgesetz” in Frage gestellt – nämlich dass hochproduktives Arbeiten nur im Flow möglich ist. Und so konnten sie etwas wirklich Neues entdecken. Respekt!