Was Kanban nicht kann
Agil, Scrum, Kanban … Schlagworte der Informatik heute. Scrum und Kanban lassen sich erst noch kombinieren, daraus entsteht dann Scrumban.
Scrum ist vermutlich den meisten ein Begriff, Kanban vielleicht weniger. Dazu gibt es ein kostenloses Buch, das eine schnelle Einführung in Kanban gibt: Kanban Scrum Minibook.
Wer schon an einer Scrum Schulung oder Einführung war, weiss, da steht ein begeisterter Trainer vor einem und füttert einen mit Schlagworten darüber, was der Prozess alles kann. Das Ganze ähnelt einem Verkaufsgespräch. Das macht durchaus Sinn, denn bei Scrum wie Kanban ist es wichtig, dass der Prozess gelebt wird, damit er funktioniert und das lässt sich wiederum am besten über Begeisterung bewerkstelligen.
Ich will gar nicht viele Worte über das Prinzip von Kanban verlieren. Kanban stammt ursprünglich aus der Automobilindustrie und wurde bei Toyota fürs Fliessband entwickelt. Was hat jetzt Software mit Fliessband zu tun? Ein Verkäufer hat darauf sicher eine Antwort.
Kanban verwendet analog zu Scrum ein Board, um Transparenz zu schaffen. Die bestehenden Firmenprozesse werden auf das Board in mehrere Phasen bzw. Spalten abgebildet. Bspw. Input-Queue, Analyse, Entwicklung, Abnahme, Live-Schaltung. Der Prozess will Engpunkte in den bestehenden Prozessen aufdecken und diese verbessern. Er arbeitet mit dem, was da ist und zwingt das Team nicht, einen neuen Prozess zu lernen wie bei Scrum. Soweit so gut.
Sprints gibt es nicht, dafür WIP (work in progress), der minimiert werden soll. Der Gedanke dahinter ist, dass sich der Entwickler immer auf eine Aufgabe konzentriert und diese zu Ende bringt, anstatt ständig zwischen unterschiedlichen Aufgaben wechseln zu müssen. Denn dieser Wechsel kostet Zeit! Eine VM muss runter-, die nächste hochgefahren werden, der Kopf muss sich erst in die neue Aufgabe hinein denken. Soweit einleuchtend.
Damit das Team sich auch daran hält, erhält jede Spalte eine Limite als Kontrollgrösse. Wenn die Entwicklungsphase eine Limite von drei besitzt und das Team aus drei Entwicklern besteht, kann sich jeder auf eine Aufgabe konzentrieren. Wenn Pairprogramming erwünscht ist, schraubt man die Limite auf zwei runter. Ändert das Team und wird aufgestockt auf vier, kann die Limite angehoben werden. Für gewöhnlich beginnt das Team mit einer höheren Limite und versucht, diese nach unten zu schrauben, um den Durchfluss der Arbeit zu erhöhen. Soweit sinnvoll.
Wenn ein Entwickler aufgrund der Limite keine neue Arbeit in Angriff nehmen kann (weil bspw. der Tester nicht nachkommt mit der Abnahme), zieht er die rote Leine. Die ganze Produktion stoppt, das Problem wird behoben (wie dass der Entwickler im Testing aus- oder bei einem anderen Entwickler mithilft), damit alle weiterarbeiten können. Soweit die Konsequenz.
Der Kern und zugleich Knackpunkt von Kanban ist die Schaffung einer angstfreien Kultur. Der Prozess fusst darauf, dass Teammitglieder Probleme melden, um den Prozess zu optimieren. Der Prozess muss nicht nur im Team, sondern auch beim Auftraggeber, ja beim ganzen Umfeld verankert sein und gelebt werden. Damit der Entwickler sich auf eine Aufgabe fokussieren kann, müssen die Anforderungen klar sein, müssen die Zulieferer mitziehen. Dahinter versteckt sich, östliches Gedankengut im Westen zu leben. Genau da steckt meiner persönlichen Meinung nach der Wurm drin. So sehr wir uns für alles Östliche begeistern (auch ich mache Yoga), muss das Gedankengut meist auf uns zugeschnitten werden.
Eine rote Leine zu ziehen wirkt abschreckend (allein schon die Farbe, rot!). Bei uns im Team ist die rote Leine eine Hupe, dh. dass tatsächlich das ganze Umfeld mitbekommt, wenn die Produktion stoppt. Wenn gehupt wird, werden alle in ihrer Arbeit gestört. Denn die anderen müssen alles stehen und liegen lassen und ans Board hechten, um das Problem des einen zu beheben. Wir haben im Team festgestellt, dass wir uns alle über das Hupen genervt haben. Dabei wurde nicht wie vom Prozess vorgesehen vier Mal die Woche sondern gerade einmal alle zwei Wochen gehupt!
Der Durchfluss der Arbeit sollte durch Kanban automatisch erhöht werden, was in der Praxis nicht unbedingt der Fall ist. Denn dazu muss der Einzelne daran interessiert sein, seine Arbeit so schnell wie möglich zu erledigen. Die Stimmung im Team war eher entspannt. Endlich hatte jeder Zeit, seine Arbeit gründlich zu tun. Sich erst einzulesen, eine VM ganz neu aufzusetzen. Keine Termine, kein Abgabedruck, kein Sprint, kein Stress. Damit will ich keinesfalls sagen, dass irgendein Teammitglied schlechte Arbeit abgeliefert hat oder das vorsätzlich wollte. Das ist nie der Fall. Wir wollen alle gute Arbeit leisten. Aber den einen oder anderen Entwickler muss man manchmal bremsen, sonst vergoldet er bis zum Sanktnimmerleinstag.
Wenigstens der Auftraggeber ist daran interessiert, dass seine gestellte Aufgabe schnell erledigt wird? Weit gefehlt! Das ist er natürlich schon. Aber bei der Abnahme fällt dies und jenes auf. Das hätte er doch lieber anders, beim nächsten Abnahmezyklus fällt ihm noch eine Verbesserung ein und so dreht die Aufgabe ihre Kreise auf dem Board und wird nicht fertig.
Transparenz über das Board ist nur gegeben, wenn der Prozess und das Board vom Umfeld auch verstanden wurde. Der subjektive Eindruck, dass die Arbeit nicht vorangeht, entsteht immer noch. Das Board ist lediglich ein Abdruck der aktuellen Arbeitssituation. Wenn die geleistete Arbeit aus der letzten Spalte herausrutscht, weil sie produktiv ist, ist sie am Board nicht mehr zu sehen, jedoch über Auswertungsgrafiken (bspw. über ein kumulatives Flächendiagramm) ersichtlich. Diese hängen bei uns neben dem Board, müssen aber auch erst Beachtung finden.
Ich bin der Meinung, dass der Sprint einer der Gründe ist, warum Scrum für den Westen besser geeignet ist als Kanban. Abgabetermine sind für uns verbindlich und wir sind stets bemüht, diese einzuhalten. Ein Abgabetermin baut den nötigen Druck auf, die Arbeit schnell zu erledigen und falls nötig Abstriche zu machen. Beim Entwickler wie beim Auftraggeber. Für Support- und Wartungsarbeiten sind Sprints allerdings weniger geeignet. Bei einem Notfall kann nicht erst der nächste Sprint abgewartet werden.
Die Idee das Team zu entlasten und zu schützen, die hinter Kanban steht, ist auf jeden Fall schützenswert! Wenn wir Entwickler uns auf unsere Arbeit fokussieren können, arbeiten wir am besten. Ich wäre jedoch für eine westliche Variante von Kanban zu begeistern. Vielleicht finden wir die noch. Ganz im Sinne von Kanban: Der Prozess verbessert sich selbst durch diejenigen, die ihn leben!
