Kanban-Board

Was Kanban bedeutet

"Kanban" ist ein Begriff aus dem Japanischen und bedeutet "Signal-Karte" japanisch kan = Signal, ban = Karte). Unter Kanban versteht man heute eine Methode zur Produktionsprozesssteuerung. Das ursprüngliche Kanban-System wurde 1947 von Taiichi Ohno in der japanischen Toyota Motor Corporation entwickelt. Ein Grund hierfür war die ungenügende Produktivität des japanischen Unternehmens im Vergleich zu amerikanischen Konkurrenten. Es ist gelungen: das 'Toyota Production System' wurde legendär.

Ohno beschrieb die Idee so: "Es müsste doch möglich sein, den Materialfluss in der Produktion nach dem Supermarkt-Prinzip zu organisieren, das heißt, ein Verbraucher entnimmt aus dem Regal eine Ware; die Lücke wird bemerkt und wieder aufgefüllt"

Wozu ein Kanban-Board?

1. Transparenz
Ein Kanbanboard schafft einen Überblick über alle aktuell oder demnächst abzuarbeitenden Aufgaben.
2. Priorisierung
Das Kanbanboard ermöglicht eine Priorisierung hinsichtlich was vorrangig und nachrangig oder aktuell gar nicht zu bearbeiten ist.
3. Fokussierung
Das Kanbanboard ermöglicht so Fokussierung auf das aktuell Wichtigste und Nutzenstiftendste.
4. Effizienz
Die Begrenzung des WIP schafft Arbeitserleichterung und erzeugt schnelleren Fortschritt in den Dingen die priorisiert sind. Ob man's glaubt oder nicht: 400% Steigerung sind drin und es fühlt sich stressfreier an! Ausschließlich dadurch, dass Verzettelung vermieden wird!
5. Selbstverantwortung
Indem sich die Teammitglieder die Aufgaben selbst definieren und unter der Woche daran eigenständig arbeiten, entsteht eine selbstverantwortliche Kultur.
6. Lernende Kultur
Dadurch, dass das Team regelmäßig über Hindernisse und deren (organisatorische) Lösung spricht, entwickelt sich das Team und die Organisation ständig weiter

Wie ein Kanban-Board aufgebaut ist

Vorgehensweise

1. Sinnvoller Weise sammelt man zunächst alle Themen, Projekte, Initiativen eines Fachbereichs im Backlog. Die agile Welt nennt das "User-Storys" - also aus Kunden/Nutzersicht beschriebene Ergebnisse
2. Der sogenannte 'ProductOwner' (Auftraggeber, der den Kundennutzen vertritt) priorisiert den Backlog. D.h. er definiert, welches Thema als nächstes umgesetzt werden soll - und welches nicht! Priorisierung ist Kernaufgabe des ProductOwners.
3. Der Mitarbeiter/das Projekt-Team definieren die dazu notwendigen Aufgaben. Aufgabenkarten werden so beschrieben, dass sie von einem Mitarbeiter bis zum nächsten Abarbeitungszyklus umsetzbar sind. Im Scrum sind Aufgabenpakete bis max. 8 h definiert. Diese vordefinierten zu erledigenden Aufgaben werden im Planungsmeeting in die Spalte "Redy to do" gesammelt.
4. Während der Woche ziehen sich die Projektmitarbeiter jeweils eine Aufgabenkarte in die Spalte "doing" sobald sie mit dieser Aufgabe beginnen. Die Spalte doing ist mit dem WIP (Work in progress) begrenzt. D.h. es dürfen nur maximal so viele Aufgaben im doing sein, wie das Wip erlaubt. Erst wenn eine Aufgabe ins 'done' als erledigt geht, darf eine neue Aufgabe aus dem 'ready to do' gezogen werden. Das Team zieht nur Aufgaben, die als 'ready' besprochen sind und dem vom ProductOwner priorisierten Backlog entsprechen.
5. Die Größe des Wip muss anfangs ermittelt werden und hängt von den personellen Ressourcen ab. WIP definieren: je größer der WIP, desto mehr Aufgaben werden gleichzeitig bearbeitet. Das bedeutet auch desto mehr halbfertige Produkte oder Projekte binden Kapazität und Material. Durch die Verringerung des WIP entsteht Fokussierung und kann die Effizienz drastisch gesteigert werden. Es gilt die Daumenregel (durch Studien belegt): Pro Projekt in dem ein Mitarbeiter gleichzeitig ist, gehen 20% Effektivität verloren.
6. Wenn eine Aufgabe nicht umgesetzt werden kann und deren Ausführung behindert ist, wandert sie ins 'blocked'. Die blockierten Aufgaben werden gemeinsam besprochen, um die Hindernisse zu entdecken und aus dem Weg zu räumen. Idealer Weise erfolgen organisatorische Verbesserungen, um Hinderungen dauerhaft zu reduzieren. Blockierte Aufgaben zählen zum WIP!
7. Es ist Aufgabe vom ProductOwner sowohl den Wip so zu steuern, dass Fokussierung möglich ist, als auch die Hindernisse in der Organisation dauerhaft zu reduzieren. Dazu sind regelmäßige Planungs- und Reviewtermine mit dem Team vor dem Kanbanboard sinnvoll:
1. Das Team braucht mit dem Projektleiter ein "Daily" für max 15 Minuten Dazu werden drei Fragen beantwortet:
   1. Welche Aufgabe habe ich gestern erfolgreich abgeschlossen (=> Karte ins Done)
   2. Wo sind Hindernisse entstanden (=> Karte ins blocked)
   3. Welche Aufgabe übernehme ich heute um das Sprintziel zu erreichen? (=> Karte vom "ready to do" kommt ins "Doing"
2. Zyklische Review- und Planungstermine mit dem Product Owner max 4 h/Zyklus
   1. Das Team präsentiert die erfolgreich umgesetzten Arbeitsaufträge und erhält dazu Feedback vom ProductOwner (und sogar Kunden)
   2. Für aufgetretene Hindernisse werden organisatorische Lösungen gefunden
   3. Für den nächsten Zyklus (Sprint) wird vom ProductOwner der Backlog neu priorisiert und die dazugehörigen Tasks vom Team erarbeitet und in die "ready to do" Spalte gesetzt

Hinweis:

• Es kann Sinn machen, das Kanbanboard digital zu pflegen. Bei den Meetings (Daily, Planning) müssen aber alle darauf sehen können. Es braucht dann einen Beamer oder einen großen Screen.
• Es kann Sinn machen, das Board mit einer Spalte für die Namen des Kernteams zu ergänzen, um die gebundenen Kapazitäten besser abschätzen zu können. -> ausprobieren!

Agile Rollenbeschreibungen