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.
8 Kommentare:
Hallo Ralf,
das ist ja genau die Stärke von Kanban. Es hilft das Chaos zu ordnen bzw. gibt Denkanstöße, über den eigenen Prozess nachzudenken. Dabei gilt je einfacher desto besser, ansonsten verlieren sich die Leute im Detail. Der Prozess dient den Entwicklern und nicht umgekehrt (das ist das was ich an Prince2 und Rational Unified Process unter anderem zu bemängeln habe). Das Kanban Board muss ja auch nicht den gesamten Prozess abdecken sondern den, in dem wir primär arbeiten. Für unterschiedliche Abläufe sind auch unterschiedliche Boards denkbar. Natürlich ist Kanban nur ein Teil der Lösung, siehe David Anderson's Buch http://www.amazon.de/Kanban-David-J-Anderson/dp/098452140
Kanban ist aber für mich momentan die beste Methode der Software Entwicklung.
Keep up the good work
Johannes
Einer der weiteren Stärken: Viel fundamentaler als den Prozess zu visualisieren ist, die "Work in Progress" zu limitieren. Ob das jetzt mit Kanban passiert (auf Basis von input queues und expliziten work limits) oder wie bei Scrum zeitlich in Form von Sprints ist dabei zweitranging. Ganz getreu dem Motto "Stop starting and start finishing". Ich stimme dir zu, dass Kanban nicht den ganzen Prozess abbildet sondern kleinere Prozesse (die dann leichter optimiert bzw verändert werden können). Aber ist etwas anderes wirklich erstrebenswert? Das schöne an Kanban ist doch auch dass es sich auch im "kleinen" einführen lässt und die Veränderung nach und nach stattfinden kann.
@Johannes: Das Schöne an Kanban ist, dass es so leichtgewichtig ist. Das Nachteilige an Kanban ist, dass es so leichtgewichtig ist ;-)
Darum geht es mir: Kanban fehlen Antworten auf wichtige Fragen. Kanban ist ein "leeres Tool" wie Scrum. Kanban hat nichts speziell mit Softwareentwicklung zu tun - auch wenn Softwareentwicklung von Kanban profitieren kann.
Die Darstellung ist aber anders. Deshalb glaubt man schnell, dass 3 Wochen Iterationen die Rettung sind. Deshalb glaubt man, dass ein Kanban Board im Flur und ein paar Warteschlangen die Rettung sind.
Der Cargo Cult lauert überall, wo Richtiges gut sichtbare Artefakte produziert.
Um den Cargo Cult weniger leicht entstehen zu lassen, finde ich es wichtig, das bigger picture in den Blick zu nehmen. Eben nicht einfach lokal optimieren. Jedenfalls nicht als erstes. Wenn sich sonst keiner Gedanken über das big picture macht, dann eben die Entwickler. Auch egal. Und wenn sie es gesehen haben und wissen, wo der Engpass ist, und dann entscheiden, dass sie nur für sich Kanban einführen (auch wenn die Entwicklung womöglich nicht der Engpass ist), dann auch ok.
"Wir machen jetzt endlich auch Kanban!" sagt nichts, außer vielleicht, dass sich da Leute um Verbesserung bemühen. Das ist schön. Wie deren Bewusstsein für ihre Bude aber ist... das kann man daran nicht ablesen.
(Davon mal abgesehen, dass mir in Kanban der Zug (Pull) fehlt. Davon wird immer wieder gesprochen, da wird auf die Kanban-Kärtchen verwiesen - nur sehe ich ihn am Kanban Board nicht. Ich sehe immer nur Druck (Push), dem manchmal widerstanden wird, wenn eine Queue voll ist. Der systemische Kern von Kanban in der Vervielfältigung ist damit für mich noch gar nicht am Start.)
Hallo Ralf,
das "Pull"-Prinzip sollte von dem Kanban-Board modelliert werden. Bei deinem Beispiel ist es definitiv nicht vorhanden. Normalerweise besteht jede Spalte aus zwei Unterspalten ("in progress" und "ready") das Worklimit würde dann über die Gesamtspalte wirken. "Gepullt" wird dann von der "Ready"-Spalte. Klar sollte man das "Big Picture" im Auge behalten, aber nachhaltige Veränderung beginnt im Kleinen und nicht mit einem Putsch-Versuch a la Scrum. Wenn das Team plötzlich pünktlich funktionierenden Code abliefert, kommen vielleicht andere Leute auf die Idee ähnlich zu arbeiten. Des Weiteren ist die Visualisierung mit dem Board hilfreich, wenn man gegenüber dem Management argumentieren muss. Wie nun die Kanban-Realisierung konkret aussieht, ist abhängig vom Kontext des Projekts. Wie du bereits sagtest: es ist leichtgewichtig :), aber ganz sicher nicht "leer". Aber wie mit jeder Methodik ist auch Kanban kein Garant für Erfolg. Es soll ja auch erfolgreiche Waterfall-Projekte gegeben haben :P
Ich würde dir wirklich David Andersons Kanban Buch ans Herz legen, für mich so oder so ein muss.
@Johannes: Lass mich aus "Kanban" von Anderson zitieren: "Kanban [setzt voraus], dass bereits ein Prozess vorhanden ist [...]" (s. 20 der dpunkt Ausgabe).
Und genau das ist mein Punkt: Ich sehe nicht, dass sich Teams über ihren Prozess wirklich Gedanken machen. Wenn ein Team heute "Hurra, Kanban!" ruft, dann hat es sehr wahrscheinlich vorher keinen expliziten Prozess. Irgendwie tut es natürlich etwas und kommt auch zu Ergebnissen - aber warum und wie? Das Flipchart-Foto in meinem Beitrag spricht Bände. So sieht Prozessrealität heute aus - nur war die dem Team vorher nicht bewusst.
Dann kommt Kanban - und was dann? Dann schaut man in ein Kanban Buch und sieht hübsche Kanban Boards und sagt sich: die Spalten übernehmen wir.
Und Kanban sagt dazu nichts. Klar. Denn Anderson sagt: "Kanban ist keine Softwareentwicklungsmethode und auch kein Projektmanagementansatz." (ebd.).
Das ist natürlich total unattraktiv, wenn man händeringend nach Verbesserung sucht. Da will man nicht lange analysieren, sondern einen zackigen Ansatz. Man hatte bisher keinen bewussten Prozess, man hatte bisher keine Softwareentwicklungsmethode - na, dann soll Kanban das mal rausreißen.
Tut es nur nicht. Kann es nicht. Will es nicht. Steht von Anderson geschrieben. Kommt aber als Feinheit - wie soviele Feinheiten - nicht gut beim Publikum an.
Selbst bei Jurgen Appelo nicht, denn sonst wäre sein Blogbeitrag nicht so ausgefallen. Darin schwingt nämlich ein Ton von Überraschung mit und eine Wunsch, sie für diese "Abweichung" zu erklären.
Dabei weicht Appelo von nichts ab. Wie denn auch? Kanban macht keine Aussage darüber, wie ein Softwareproduktionsprozess in Schritten aussehen sollte. Oder überhaupt die Schritte irgendeines Prozesses. Das meine ich damit, dass Kanban leer ist. (Nicht hohl oder dumm, sondern eben leer. Ohne Meinung zur Domäne irgendeines Produktionsprozesses.)
Und nochmal zu pull: Die Zahl der Spalten ist egal. Es gibt kein Pull in Software-Kanban. Pull ist hineingeheimst. Nochmal Anderson himself: "[...] fungieren diese Karten tatsächlich nicht als Signal, um Arbeit zu ziehen. Stattdessen repräsentieren sie Aufgaben." (s. 15 ebd.)
Aufgaben werden nun - anders habe ich es noch nicht gesehen - vorne "reingesteckt" (push), damit sie erledigt werden. Und wenn das nicht flutscht, dann wird Druck ausgeübt.
Software-Kanban mag diesen Druck herausnehmen. Das ist ne gute Sache. Aber es bleibt dabei, dass eben nicht wirklich gezogen wird.
"Das Signal zum Ziehen neuer Aufgaben folgt aus der sichtbaren Menge der begonnen Arbeit [...]" (ebd.) Auch wenn Anderson hier den Begriff "Ziehen" benutzt, ist das - sonst würde er es nicht betonen - anders als im physischen Kanban. Ich halte diesen Unterschied für beachtenswert, weil ein virtueller Zug, der nur durch Interpretation entsteht, immer schwächer als ein physischer Zug ist.
Ein physischer Zug - besser wohl Sog - ist unwiderstehlich. Ihm muss man sich anpassen. Natura abhoret vacuum. Er führt systemisch zu Veränderungen.
Hallo Ralf,
als Grundlage einen schon vorhandenes Board zu nehmen ist grundsätzlich nicht verwerflich. Ob der Prozess passt oder nicht merkt man sehr schnell, ebenfalls was man ändern sollte. Und ich sehe dein "Push" nach wie vor nicht. Klar kommt irgendwie ein Backlog zustande wo Sachen reingepusht werden (Aber das ist nun einmal immer so egal welcher Ansatz, schließlich will irgendjemand ein Feature haben und probiert es zu pushen). Die Bearbeitung erfolgt aber erst mit Hilfe eines freien Slots ... was zu einem "pull" führt. Anderson betont ebenfalls, das Kanban nichts bringt wenn die Entwickler kein Qualitätsbewusstsein / -wissen haben. Wenn man grundsätzliches QA voraussetzt, ergeben sich ähnliche Prozesse. Ich stimme mit dir überein, dass Kanban kein Allheilmittel ist und schon gar nicht "Out-Of-The-Box". Ich habe jetzt einige Jahre Erfahrung mit Scrum gesammelt und Kanban ist einfach eingängiger. Bei uns hat der Übergang von Kein Prozess zu Scrum und nun zu Kanban stattgefunden. Es funktioniert, schon allein weil es die Schwachstellen visualisiert (für jeden sichtbar). Natürlich steht und fällt das ganze mit den Leuten, die es anwenden bzw. deren Resistenz gegen die "Push"-Mentalität von Managern/Stakeholdern ... man muss eben auch nein sagen können.
@Johannes: Verwerflich ist hier gar nichts. Es geht ja nicht um die Kategorie Moral.
Mit einem Board aus dem Buch zu starten, ist also ok - nur muss die Frage erlaubt sein, ob das ein geeigneter Start ist. Oder wird da eine Chance auf Reflexion verschenkt? Das ist mein Eindruck.
Alles mögliche kann man nach dem Motto "Ach, fangen wir mal an" beginnen. Nur wird dann ein Ergebnis womöglich langsamer als möglich erreicht. Das ist genauso bei TDD. "Ach, fangen wir einfach mit einem Test an..." Dann wird refaktorisiert und refaktorisiert - und am Ende steht man dort, wo man gleich hätte stehen können. Verschenkte Zeit.
Wenn Kanban lt. Anderson keine Aussage zu Softwareentwicklung macht, dann stellt ein Team solch wichtigen Fragen kaum selbst. Das halte ich für eine Falle. Die gibt es seit Scrum. Man liefert dann immer noch Zeug aus, das schnell unwartbar wird - nur tut man das nun ganz geschmeidig :-)
Deshalb ist mir Kanban zuwenig. Kanban wird eben nicht der Besonderheit von Softwareentwicklung wirklich gerecht. Kanban bleibt leer.
...
...
Nochmal zum Pull: Stell dir den Produktionsprozess doch mal anders vor. Zäumen wir ihn von hinten auf.
Der Kunde zieht. An wem? An der Qualitätssicherung. (Dass es eine gibt, muss man natürlich wissen ;-) Kanban sagt dazu nichts.) Der QS sagt der Kunde, "Ich möchte X, aber zackig."
Die QS überlegt dann, ob sie dem Kunden X geben kann. Kann sie nicht, weil noch kein Release Candidate da ist. Also überlegt sie, woher sie den bekommt. Außerdem braucht sie Akzeptanzkriterien. Sie zieht deshalb an der Softwareentwicklung und an der Anforderungsdefinition. Beide müssen sie nun beliefern. Aber zackig.
Die Anforderungsdef muss sich die Anforderungen genau überlegen und Akzeptanzkriterien liefern. Die Entwicklung versteht auch nicht, was der Kunde da will. Also wendet sie sich auch an die Anforderungsdef. Von der will sie Features. Aber zackig.
Die Anforderungsdef wendet sich an den Kunden (der steht also am Ende, da zieht er, und am Anfang, da wird an ihm gezogen).
Das ist ein vereinfachter Prozess. Aber der ist anders, weil er von vornherein nicht produziert, wenn nicht einer zur Abnahme bereitsteht. Daran (!) mangelt es nämlich in den meisten Projekten. Nicht der Backlog steht am Anfang, nicht die Burndown-Rate ist im Fokus - sondern einzig interessant ist, was abgenommen wird.
Die Abnahme ist der Motor der Softwareentwicklung. Sie muss nur in der Rate produzieren, wie abgenommen wird. Alles andere richtet sich danach aus. Der erste Engpass in den meisten Projekten ist sozusagen der Markt, die Abnahme.
Das muss man nicht lange herausfinden durch Wochen der Kanban Board Kontemplation. Dazu reicht ne simple Frage: "Wann ist der Kunde denn bereit, wieder mal was abzunehmen?" Antwort: "Keine Ahnung. Nächste Woche vielleicht oder übernächste?" oder "Der will uns erst in 3 Monaten sehen, wenn das Modul komplett fertig ist."
Bingo. Es wird nicht gezogen. Und das machen die freien Warteschlangenplätze bei Kanban nicht wett.
Scrum hat das irgendwie begriffen und die Iterationen klein gemacht mit einer institutionalisierten Abnahme am Sprintende. Aber auch das ist nur halbgar, finde ich. Denn die Rolle des PO in Scrum ist vor allem die eines Drückers: Backlog füllen!
Für wirklich systemische Veränderungen braucht es aber einen Zieher.
Den gibt es beim Spinning. Ganz radikal. Da steht die Lieferung zur Abnahme ganz oben. Jeder Tag ist Releasetag. Jeden Tag will einer abnehmen. Alles andere ist zweitrangig. Alles andere ergibt sich.
Wenn man diesen Zug nur befriedigen kann, indem man den Produktionsprozess mit Kanban organisiert, dann ist das völlig ok. Aber Spinning hat eine sehr konkrete Idee, wie der aussieht. Vielleicht braucht man Kanban aber auch nicht :-) Denn beim Spinning ist alles einfacher. Jeden Tag kann man sich eh nur um 1 Sache kümmern. Und morgen kann schon wieder etwas ganz anderes dran sein. Es gibt keine halbfertigen Aufgaben, die in Warteschlangen rumliegen könnten. Jeden Tag ist die angefangene Arbeit am Abend fertig und auslieferbereit.
Kommentar veröffentlichen