Schöne Sache das Networked Kanban wie es Jurgen Appelo in seinem Blogbeitrag beschreibt - nur was ist denn daran wirklich neu? Jeder nicht triviale Produktionsprozess ist mehr als eine "Eimerkette". Und jeder Produktionsschritt arbeitet immer aus einer Warteschlange. Die ringelt sich auf dem Schreibtisch in Form einer Inbox, die besteht aus Post-It Notes am Monitor oder die zischelt in Excel oder einem anderen Tool im Intranet.
Die "Erfindung" von Kanban kann also nicht in Warteschlangen bestehen. Und wenn Kanban die Softwareproduktion als "Eimerkette" sieht, dann ist das eine sehr vereinfachende Sichtweise.
Aber zum Glück bietet Kanban mehr. Es geht darum, die ohnehin immer existierenden Warteschlangen zur Steuerung zu nutzen. Der bewusste Umgang mit Warteschlangen ist der Trick bei Kanban. Weg von der lokalen ad-hoc Optimierung hin zu einer globalen Optimierung.
Guter Ansatz - nur fehlt mir immer wieder dabei etwas. Daran rührt Jurgen Appelo, finde ich. Es fehlt die Frage, wie denn überhaupt der Produktionsprozess aussieht?
Die Kanban-Boards, die ich bisher gesehen habe, sind aus meiner Sicht so einfach, dass sie der Realität des Softwareproduktionsprozesses nicht wirklich gerecht werden, finde ich. Man freut sich, dass man ein Board aufhängt und nun Warteschlangen beobachtet. Das Vorhandensein eines Terrariums auf dem Gang wird als Meilenstein betrachtet.
Doch was ist es, das man dort beobachtet? Ist das wirklich genug? Ist das die Realität oder nur eine mühelose Abstraktion?
Jurgen Appelo kommt der Wirklichkeit näher mit dem Netzwerk. So kann Kanban skalieren. (Ob Kanban dafür dann ein guter Name ist, lasse ich mal dahingestellt. Er ist zumindest eingebürgert.)
In Jurgens Beitrag kann man ahnen, dass Softwareproduktion erstens ein Netzwerk von Produktionsschritten ist und zweitens auch noch eine Holarchie: jeder Produktionsschritt auf einer Abstraktionsebene kann potenziell wieder ein Produktionsprozess bestehend aus mehreren Schritten sein. Ich fühle mich erinnert an Staged Event Driven Architecture, SEDA:
Die Masterfrage jedoch lässt auch Jurgen offen: Wie sieht denn überhaupt der Produktionsprozess im Ganzen aus? Wieviele Ebenen hat er, aus welchen Schritten besteht er?
Board-Beispiele wie dies
finde ich viel zu starr. Das Leben und die Produktion von Software finden nicht im Schwimmbad auf klaren Bahnen statt.
Indem Kanban aber immer wieder nur so beschrieben wird, macht man es Teams schwer, ihre Realität wirklich zu finden - und zu optimieren. Denn es kann ja nicht nur darum gehen, einen simplifizierten Prozess zu optimieren. Auch das führt nur zu Reibungen - über die man sich wundert, weil man doch lokal alles optimal gemacht zu haben meint.
Jurgens Beitrag sollte daher ein Appell sein, sich mehr Gedanken über den Produktionsprozess von Software zu machen. Wenn dabei dann erstmal soetwas herauskommt ist das auch ok:
So ist halt das Leben. Gut, dass man das weiß. Dann kann man an die Sache wirklich bewusst herangehen. (Im Bild ist zum Beispiel zu sehen, dass nicht die Softwareentwicklung das Problem ist. Die mit Kanban zu optimieren, brächte nichts. Das Problem steckt in den Schritten davor (rot).)
Kanban-Kärtchen schieben, ist auch wieder keine Silberkugel für die Softwareentwicklung. Genauso wenig wie jeden morgen 15 Minuten Standup-Meeting und alle 3 Wochen ein Release rausschieben nach Scrum.
Die Realität ist unordentlicher und schmutziger. Sie muss zuerst erkannt werden. Teams müssen sich das IST bewusst machen, bevor sie auf den einen oder anderen Zug aufspringen. Das, würde ich sagen, hat auch Jurgen in gewisser Weise gemerkt. Sein Beitrag hilft damit, realistischer in eine Veränderung des Vorgehens bei der Softwareentwicklung einzusteigen. Analyse und Nachdenken helfen halt doch.
Am Ende zählt nicht, ob man Scrum oder Kanban “nach dem Buch macht”. Es zählt, dass die Softwareproduktion besser ist als vorher.