Einer der häufigsten Kritikpunkte an Kanban von Leuten, die schon lange (und meist auch sehr erfolgreich) agil vorgehen und Scrum oder XP einsetzen, lautet: "Was auf den meisten Kanban-Boards zu sehen ist, sieht aus wie Wasserfall vom Feinsten!" Und das stimmt auf den ersten Blick auch, denn häufig sind auf den Boards die Prozessschritte in der Reihenfolge Backlog, Analyse, Entwicklung, Test, Deployment o.ä. abgebildet. Wie Johannes Link, Agilist der erste Stunde, in diesem Chat mit Henning Wolf und mir vollkommen richtig angemerkt hat, ist es in der Regel keine besonders gute Idee, die Aufgabe mit dem größten Risiko, also die Tests, erst so spät durchzuführen. Das stimmt! Im Idealfall sollten die Tests möglichst weit am Anfang der Wertschöpfungskete stehen und vielleicht sogar in Form von testgetriebener Entwicklung nicht nur vor Fehlern schützen, sondern auch das Design der Software leiten. Aber so sieht die Realität im größten Teil der Software-Industrie leider nicht aus. Die wenigsten Teams könnten wohl von sich behaupten, sie würden wirklich konsequent nach TDD (oder ATTD) vorgehen. Stattdessen wird faktisch in vielen größeren Organisationen nach einem Wasserfall-ähnlichen Prozeß vorgegangen - ob es einem nun gefällt oder nicht. Wenn Kanban-Boards nach Wasserfall aussehen, dann also nicht, weil Kanban Wasserfall nahelegen oder sogar vorschreiben würde. Vielmehr macht Kanban transparent, wie der Prozess momentan aussieht. In einer Kanban-Schulung mit David Anderson sollten die Teilnehmer den Entwicklungsprozess ihres aktuellen Projektes auf einer Moderationswand modellieren und dann kurz der Gruppe vorstellen. Ein Teilnehmer präsentierte sein Ergebnis mit den Worten "Wir entwickeln nach Scrum". Nach einigen Rückfragen aus der Gruppe wurde jedoch schnell klar, dass das Ganze nicht viel mit Scrum zu tun hat, sondern starke Ähnlichkeit mit Wasserfall aufwies. Kanban kann also Wasserfall sichtbar machen - auch dann, wenn es sich als Scrum tarnt.
Was die Beteiligten dann mit dieser Transparenz anfangen, bleibt ihnen überlassen. Vielleicht sind sie mit ihrem Prozess ja zufrieden, und er funktioniert für sie. Warum sollten sie ihn dann verändern? In der Regel ist dies aber nicht der Fall, und Organisationen möchten (oder müssen) sich verändern. Hierfür liefert Kanban einen guten Startpunkt (aber keine Komplettlösung mit Erfolgsgarantie). Fatal wird es dann, wenn Teams/Organisationen nach dem reinen Visualisieren ihres Prozesses Halt machen - was leider regelmäßig vorkommt. Richtig verstandenes Kanban enthält immer kontinuierliche Verbesserung als eine Kerneigenschaft, so dass das Team zu Verbesserungen getrieben wird - auch wenn diese in sehr kleinen Schritten vor sich gehen mögen. Im Wasserfall-Beispiel wird man wahrscheinlich nicht gleich am Anfang die Reihenfolge der Prozessschritte verändern und die Tests nach vorne ziehen. Aber allein durch die Betrachtung der Durchlaufzeit, die ja in Kanban die Haupt-Messgröße darstellt, in Kombination mit Little's Law wird das Team vermutlich ziemlich schnell überlegen, dass es eine gute Idee ist, nicht alle Anforderungen gleichzeitig zu bearbeiten (was eine maximale Losgröße (Batch Size) für die Anforderungen bedeutet). Wenn dann statt der maximalen 30 Anforderungen ein WIP-Limit von 15 eimgeführt wird, dann stellt dies schon einen erheblichen Fortschritt dar, weil die Durchlaufzeit sich damit deutlich verkürzt haben sollte und man viel früher Feedback über Fehler, Design, Erfüllen von Kundenbedürfnissen usw. erhält.
Diese kontinuierliche Verbesserung stellt aber zweifellos eine große Herausforderung an Teams/Organisationen dar, insbesondere, weil es in Kanban keine klaren Vorschriften gibt, wohin genau die Reise gehen soll. Hier sind eigene Überlegungen und kleine, kontrollierte Experimente nötig, um den besten individuellen Weg herauszufinden.