Seite 2: Schutzmechanismus

Inhaltsverzeichnis

Schutz vor Verschleiß in Kanban

Auch wenn zu Beginn der Einführung eines Kanban-Systems die WiP-Limits (Work in Progress Limits = Begrenzung paralleler Arbeit im gesamten System und pro "Arbeitsstation") noch nicht optimiert sind und das erst im Laufe der Zeit durch Retrospektiven geschieht, beschränken die WiP-Limits parallele Arbeit. Das geschieht, um die Koordinations- und die Transaktionskosten sowie gleichzeitig die Durchlaufzeit des Systems zu optimieren. Im Hinblick auf die Belastung der Entwickler sind die Koordinationskosten besonders interessant. Diese werden in Kanban deswegen reduziert, weil wenige Arbeitsaufträge einfacher zu koordinieren sind als viele. Für jeden einzelnen Entwickler bedeutet das weniger Kontextwechsel, weniger lose Enden, die im Kopf zu behalten sind, et cetera – letztlich ein einfacheres Arbeitsumfeld. Die Physiologie scheint die Beobachtungen zu untermauern: Sie geht von der Annahme aus, dass der Mensch Multitasking nicht gut beherrscht und es ihn unnötig belastet.

Noch wichtiger für den Schutz des Teams und des einzelnen Entwicklers ist in dem Zusammenhang das Pull-Prinzip. Es besagt, dass niemals Arbeit auf den Arbeitstisch gelegt wird (auch wenn das WiP-Limit momentan noch nicht erreicht ist), sondern dass der Entwickler selbst neue Arbeit von einem (möglichst niedrigen) Stapel holt, sobald er dafür bereit ist. Das verdeutlicht der Vergleich der Situation eines Systems mit WiP-Limits und Push-Prinzip mit der eines mit WiP-Limit und Pull-Prinzip. Wenn der Entwickler in einem Push-System seine WiP-Limits unterschreitet, ist für den ihm vorgelagerten Prozess die Versuchung groß, fertig gewordene Arbeit einfach auf seinen Schreibtisch abzulegen, egal wie stark er gerade ausgelastet ist.

Das kann gut klappen, es kann aber auch gründlich in die Hose gehen. Denn hierdurch wird der Flow des Entwicklers unterbrochen, die zusätzliche Annahme der Arbeit kann ihn verwirren, der Kontextwechsel ihn belasten et cetera. Es kann ihm zudem alles einfach zu viel sein. Im Pull-System kann das nicht geschehen. Hier ist der Entwickler "Herr der Arbeitslage". Er darf nur neue Arbeit ziehen, wenn er das WiP-Limit noch nicht überschritten hat und bereit ist, innerhalb des Flows eine neue Aufgabe zu beginnen. Ist der Entwickler aus irgendeinem Grund nicht in der Lage oder bereit dazu, sollte er keine neue Arbeit ziehen. Das zu beurteilen ist allein seine Aufgabe und darf nicht von außen beeinflusst werden.

Ein weiterer Punkt, der einen großen, wenn auch eher indirekten Einfluss auf die Arbeitsbelastung hat, betrifft die Qualität der Software. In Kanban ist klar geregelt, dass der Entwickler für die Qualität innerhalb seines Prozessschrittes zuständig ist. Erst wenn er mit der Qualität seiner Arbeit zufrieden bin, zieht er sich eine neue Aufgabe. Das gilt für jeden einzelnen Schritt, und weil jeder Schritt einen klar abgegrenzten Auftrag hat, kann die Gesamtqualität nicht besser sein als die schlechteste Qualität innerhalb der Kette.

In Umgebungen ohne Pull-System werden Entwickler häufig angewiesen, es erst mal nicht so genau mit der Qualität zu nehmen, weil gerade akuter Zeitdruck besteht. Übersehen wird aber, dass man immer unter Zeitdruck leidet (es gibt ja viele gute Ideen für zukünftige Produkte) und dass schlechte Qualität langfristig immer die Entwicklungsgeschwindigkeit drosselt. Zum einen lässt sich eine schlechte Code-Basis nur mit stetig wachsendem Aufwand weiterentwickeln. Zum anderen führt schlechte Qualität dazu, dass Arbeit, die schon abgeschlossen war, wieder zurückkommt. Das erneute Hineindenken und Anfassen dauert immer länger, als hohe Qualität gleich beim ersten Mal einzubauen. Ganzheitlich betrachtet ist Druck kontraproduktiv, und das Pull-Prinzip hilft, den Druck vom Team fernzuhalten.

Fazit

Nun stellt das eben Geschilderte den Soll-Zustand dar, den es erst einmal zu erreichen gilt. Es sei nicht verhehlt, dass in der Praxis viele hoch priorisierte Karten in der Input-Queue eines Kanban-Systems einen gewissen mentalen Druck ausüben können, doch wieder Überstunden zu machen und Qualität zugunsten von kurzfristiger Geschwindigkeit zu opfern.

Unerfahrene Teams müssen lernen, diesem Druck standzuhalten, auch wenn dadurch das Projekt in Schieflage zu geraten droht. Statt persönlichen Heldentums ist das Problem darzulegen und dauerhaft zu beheben. Dafür sieht Kanban tägliche Standup-Meetings, Retrospektiven und Selbstorganisation vor. Deswegen sind auch bei Kanban eine ganzheitliche Sichtweise, ein gemeinsamer Standpunkt des Unternehmens, eine gute Ausbildung und das Vertrauen in die Fähigkeiten und Entscheidungen des Teams wichtig. Auch in Kanban läuft nicht alles automatisch gut, aber die beschriebenen Prinzipien helfen, das Ziel einer durchhaltbaren Entwicklungsgeschwindigkeit zu erreichen.

Markus Andrezak
leitet "Architektur und Prozesse" bei mobile.de, wo er maßgeblich an der Einführung von Scrum und Kanban beteiligt war.

Arne Roock
arbeitet bei der it-agile GmbH. Er beschäftigt sich dort mit den Themen Kanban, Lean Thinking, Arbeitsorganisation und Zeitmanagement in der IT.

Henning Wolf
ist Geschäftsführer der it-agile GmbH. Er ist Autor der Bücher "Software entwickeln mit eXtreme Programming" und "Agile Softwareentwicklung".

Literatur

1. Jean Pierre Berchez, Uta Kapp; Brüder im Geiste; Kriterien für eine Entscheidung für Scrum oder Kanban; Artikel auf heise Developer
2. Markus Andrezak, Arne Roock, Henning Wolf; Gedämpfte Schritte; Evolutionäre Entwicklung mit Software-Kanban; iX 6/2010, S. 108
3. David Anderson; Kanban; Successful Evolutionary Change for Your Technology Business; Blue Hole Press, 2010
4. Henrik Kniberg; Mattias Skarin; Kanban and Scrum – making the most of both

(ane)