Kanban richtig einführen
Kanban klingt vielversprechend, doch der Einsatz der agilen Entwicklungsmethode allein bringt noch keine nachhaltige, qualitative Veränderung. Aber in Kanban steckt auch die Aufforderung an alle Beteiligten, Veränderung und das Lernen aus Fehlern als einen dauerhaften, von Menschen getragenen Prozess zu sehen.
- Klaus Leopold
A fool with a tool is still a fool. Genau so ist es auch mit dem Instrumentarium der agilen Entwicklungsmethode Kanban. Der Einsatz allein bringt noch keine nachhaltige, qualitative Veränderung. Doch wie in jedem Instrument steckt auch in Kanban die Aufforderung an alle Beteiligten, Veränderung und das Lernen aus Fehlern als einen dauerhaften, von Menschen getragenen Prozess zu sehen.
Toyota, wo das Kanban-System ursprünglich 1947 von Taiichi Ohno entwickelt wurde, zeigt seine Produktionsabläufe bereitwillig her, man ist stolz auf die im Unternehmen erfolgreich umgesetzte Entwicklungsphilosophie. Nicht nur potenzielle Kunden, auch Mitbewerber können sich ansehen, wie die Autoproduktion bei Toyota funktioniert. Doch obwohl der jahrzehntelange Weltmarktführer so locker mit seinen Betriebsgeheimnissen umgeht, konnte ihm bis vor kurzem niemand den Platz an der Spitze streitig machen. Zwar hat man vereinzelt die Arbeitsmethoden kopiert, nicht aber die Haltung, wegen der sie funktioniert. Denn das wirkliche Geheimnis von Toyota ist, dass die Menschen selbständig denken und agieren. Sie sehen Fehler als Entwicklungsmöglichkeit und packen Probleme an der Wurzel. Sie stellen sich permanent die Frage, wie sich das System ändern muss, um immer besser zu werden und dadurch besser zu bleiben.
Software-Kanban im EInsatz
Lesen Sie auch: Das etwas andere Kochrezept. Klaus Leopold beschreibt auf heise Developer, wie Kanban in Softwareprojekten umgesetzt wird und sich Engpässe im Arbeitsablauf vermeiden lassen.
Der von David J. Anderson entwickelte Kanban-Ansatz für die Softwareentwicklung übernimmt diesen Weg der ständigen kleinen, evolutionären Schritte. Ebenso wie andere agile Ansätze auch, ist Kanban eben keine Wunderpraktik, die durch ihre bloße Existenz zum Erfolg verhilft. Es ist der Wandel im Denken und Handeln, der dies tut. Wesentlicher Unterschied zu anderen agilen Methoden ist die evolutionäre Veränderung. Oft zeigt sich, dass übergestülpte Veränderungskonzepte in der Software-Entwicklung nicht oder nicht nachhaltig funktionieren. In klassisch gesteuerten Prozessen des Veränderungsmanagements überlegen sich Prozessingenieure abseits der täglichen Arbeit in einem "Big Picture" monatelang, wie die Abläufe neu zu gestalten sind, um ein bestimmtes Ziel zu erreichen. Die betroffenen Mitarbeiter können im besten Fall bis zu einem gewissen Grad ihre Meinungen und Sichtweisen einbringen, müssen dann aber mit den einmal getroffenen Entscheidungen leben und gezwungenermaßen besser werden. Ähnlich verhält es sich bei agilen Methoden wie zum Beispiel Scrum, die häufig mit einem Big Bang eingeführt werden und den Arbeitsalltag der beteiligten Personen komplett ändern, in der Hoffnung dadurch Verbesserungen zu erzielen.
Veränderung nicht am Menschen, sondern durch Menschen
Das Vorgehen in Kanban ist ein anderes: Man setzt auf den Abläufen und Prozessen auf, die zum aktuellen Zeitpunkt zur Verfügung stehen. Es wird kein fern in der Zukunft liegender Soll-Zustand definiert, denn nicht alles ist in einem bestehenden System per se schlecht. Der gedankliche Kern ist es, Mechanismen im System zu installieren, die laufende Veränderung und Verbesserung erlauben. Anders als im klassischen Veränderungsmanagement entsteht hier der Weg also im Gehen. Im Laufe des Prozesses sollen alle Beteiligten selbst erkennen, was sie können, wie sie sich zu helfen haben, wann und wie sie handeln müssen. Um Missverständnissen gleich vorzubeugen: Nur weil die aktuelle Situation der Ausgangspunkt ist, ist Kanban kein Vorwand, den Status quo zu wahren. Veränderung muss ständig passieren. Zwar wirkt Kanban in seinen Instrumenten zunächst einfach, die Schwierigkeit liegt jedoch darin, den Kaizen-Gedanken der kontinuierlichen Verbesserung in die Köpfe der Menschen zu bringen. Veränderung muss nicht am Menschen, sondern durch die Menschen passieren.
Ich kann verändern, was ich sehe
Ziel ist es, mit Kanban einen kontinuierlichen Arbeitsfluss zu etablieren, der am Ende einen Mehrwert beim Kunden generiert. Bei der Fertigung physischer Produkte ist meist offensichtlich, wo es hakt. Anders in der Wissensarbeit: Ob es Probleme gibt und wo sie genau liegen, lässt sich oft schwer sagen, das erschwert Optimierungen und wirkliche Veränderungen. Kanban hilft, die Abläufe der Wissensarbeit – und die hier vorhandenen Probleme, die den Arbeitsfluss behindern – sichtbar zu machen. Die Einführung mengenmäßiger Beschränkungen der Arbeit (WiP-Limits, Begrenzungen des Work in Progress) macht deutlich, was das System ins Stocken bringt und Mitarbeiter daran hindert, Arbeiten abzuschließen.
