Bevor man an das Design eines Kanban Boards geht, muss man sich darüber Gedanken machen, was denn da über das Board fließen soll. In der Softwareentwicklung werden in der Regeln Anforderungen über das Board geschoben, die dann verschiedene Prozessstufen durchlaufen. Doch gerade bei Kanban in der Hardware-Entwicklung oder Kanban in der Mechanik-Entwicklung geht mit der Definition der Spalten des Boards automatisch die Frage einher: Was fließt denn da? Und mit dieser Frage geht eine andere Frage einher: Wo sind die Tätigkeiten auf dem Board abgebildet?
Prozess Boards
Die klassischen Software-Boards sind Prozess-Boards. Beim klassischen Kanban Board nach David werden die erforderlichen Tätigkeiten als Prozesschritte in den Spalten des Boards abgebildet. Das sieht dann z.B. so aus:
Bei diesem Setup ist zu klären was auf die einzelnen Karten bzw. Tickets kommt, also was von links nach rechts fließt. Wenn die Tätigkeiten in den Spalten stehen, müssen Aspekte des Produktes fließen, also Anforderungen, Features, Baugruppen, Bauteile, was auch immer in Eurem Kontext Sinn macht. Das ist in der Praxis oft komplizierter als zunächst angenommen, sollte doch die Größe der fließenden Einheiten möglichst klein sein um einen Fluß zu erzeugen. Die Software ist hier im Vorteil, kann einzelne Anforderungen in das Produkt einfließen lassen. Bei Mechanik und Elektronik hingegen gibt es viel mehr Abhängigkeiten zwischen den Anforderungen, aber auch z.B. zwischen Bauteilen. Die Integrationsstufen machen in diesen Disziplinen meist nur Sinn, wenn eine gewisse Anzahl fließender Elemente zusammengekommen ist. Single Piece Flow ist in der Mechanik- und Elektronikentwicklung schwer umzusetzen, aber nicht unmöglich, wie uns das WIKISPEED Projekt zeigt (in der Tat bin ich beim Tippen dieser Zeilen auf dem Scrum Day, auf dem Joe Justice einen Workshop mit dem WIKISPEED durchführt).
Task Boards
Aufgrund der oben beschriebenen Schwierigkeiten in der Hardware- und Mechanikentwicklung setzen viele Organisationen in diesem Kontext auf einfache Task-Boards wie sie in Scrum verwendet werden. Das sieht dann zum Beispiel so aus:
Im Gegensatz zum Board das den Prozess darstellt, sind hier die Tätigkeiten auf den Tickets dargestellt und nicht auf dem Board an sich. Dadurch kann ein Task-Board für alle Arten von Tätigkeiten eingesetzt werden, jedoch geht die Prozess-Sicht verloren. Zeit also, um über die Vor- und Nachteile zu reden:
Diskussion
Nur wenn der Prozess auf dem Board abgebildet ist, kann ich im eigentlichen Sinne von Kanban den Prozess optimieren. Zudem bieten Prozess-Boards eine gute Übersicht über den aktuellen Fertigstellungsgrads bzw. des aktuellen Burndowns aus dem Backlog. Mit Prozessboards können Engpässe lokalisiert und be-puffert werden und über die WIP-Limitierung kann Fluss im erzeugt werden. Die durch die WIP-Limitierung entstehenden Blockaden zeigen Potentiale für die nächsten Verbesserungsschritte auf. Klingt alles gut, oder?
Die Herausforderung ist jedoch, zu identifizieren was über das Board fließen soll und dieses in entsprechend kleine Stücke zu schneiden, so dass auch ein sichtbarer Fluss entstehen kann. Ausserdem müssen Lösungs gefunden werden, was mit Aufgaben geschieht, die ausserhalb des auf dem Board modellierten Prozesses stehen.
Task Boards hingegen sind flexibel und verlockend. Alle Arten von Tätigkeiten können abgebildet werden. Verschiedene Aufgabentypen können z.B. mit verschiedenen Farben modelliert werden. Allerdings gibt ein Task-Board keinen Überblick über den Fluss im Prozess und nur mittelbar einen Eindruck über den aktuellen Abarbeitungsstand.
Fazit
Versucht, wenn irgendwie möglich, auf Prozessboards zu gehen. Die damit entstehenden Schmerzen mit der Definition der Fluss-Items und deren Granularität sind wichtig um die Arbeitsweise zu flexibilisieren und die Grundlagen zur Agilisierung zu legen.
Den Sinn von Task-Boards sehe ich dann, wenn es primär um die Optimierung von Schnittstellen und nicht von Prozessen geht. Darunter verstehe ich sowohl das Ziel, Teams vor der unkontrollierten Einlastung von Tasks zu schützen, wie auch die Abbildung der Zusammenarbeit zwischen verschiedenen Einheiten abzubilden um Latenzzeiten zu minimieren und Priorisierungen transparent zu machen.