Kanban
Kanban wurde 1947 in Japan von Toyota entwickelt und ist ein sogenanntes Beschaffungsprinzip. Es wird oft auch als Zuruf-, Hol-, oder Pull-Prinzip bezeichnet, das sich als Hilfsmittel für bedarfsgerechte Produktion darstellt[1]. Kanban wird unter anderem in der agilen Softwareentwicklung angewendet und stellt teilweise das Gegenstück zu dem Prinzip Scrum dar. Um die agile Softwareentwicklung im Zusammenhang mit Kanban soll es in diesem Artikel vorrangig gehen.
Nachdem Toyota Kanban 1947 im Zuge des Just-in-Time-Prinzips entwickelt hatte, um die Lagerbestände zu verringern und die sich daraus ergebende Kapitalbindung zu reduzieren, kam Kanban in der Softwareentwicklung im Jahre 2006 erstmals zum Tragen. David Anderson baute Kanban in einen Auftrag ein und formulierte ein Jahr später die fünf hauptsächlichen Merkmale von Kanban.
Er beschrieb Kanban als ein System, das verschiedene Prozesse sichtbar macht und die Menge der angefangenen Arbeiten begrenzt. Zudem lasse sich der Durchsatz, so Anderson, einfacher messen und steuern. Neben den deutlichen Prozessregeln werde durch das Verwenden von Modellen die Möglichkeit geschaffen, Verbesserungen direkt sichtbar zu machen.
Sechs Kernpunkte zeichnen Kanban im wesentlichen aus:
1. Die Visualisierungen
2. Die Limitierung des Working in Progress (WiP)
3. Das Managen des Flows
4. Die genaue Ausführung der Regeln
5. Das Einrichten von Feedback-Schleifen
6. Das Verbessern des Teams und die Weiterentwicklung der Arbeit durch Experimente[2].
Allgemeine Informationen zum Thema
Die Unterschiede zwischen Kanban und Scrum werden weiter unten berührt, beide Methoden werden aber in der agilen Softwareentwicklung angewendet. Kanban wird als evolutionäres Change Management angesehen, das seinen Ursprung ebenfalls in Japan hat. Im Kern beschreibt das Verfahren ein Prozess der kleinen Schritte, sodass Prozesse auf diesem Wege mit möglichst wenig Aufwand optimiert werden können. Bei Kanban wie auch beim übergeordneten Change Management geht es um die Minimierung von Risiken, indem viele kleine Änderungen statt weniger großer durchgeführt werden. Da Kanban eine, bezogen auf die Mitarbeiter, eher sanfte Methode ist, stößt sie meist in Mitarbeiterteams auf Gegenliebe.
Kanban wird mit dem Vorteil beschrieben, dass es – neben der einfachen Einführung und der meist verbreiteten Akzeptanz im Team – zu kürzeren Durchlaufzeiten und Arbeitspaketen führt. Es schafft zudem eine schnelle und übersichtliche Transparenz hinsichtlich der Projektfortschritte und möglicher Fehler oder Störungen. Zudem ist es in vielen Bereichen einsetzbar, lässt sich also im Vertrieb verwenden, im Marketing, der Wartung oder der Systemadministration[3].
Wesentliche Unterschiede zwischen Scrum und Kanban
Grundsätzlich kann man sagen, dass Kanban freier aufgebaut ist als Scrum. Das führt zu Vorteilen, aber auch zu Einschränkungen, beispielsweise der, dass sich Kanban eher bei kleineren Projekten einsetzen lässt und an größeren meist scheitert. Die hauptsächlichen Unterschiede zwischen Kanban und Scrum lassen sich wie folgt zusammenfassen:
| Scrum | Kanban |
| Der WiP wird indirekt durch sogenannte Sprints festgelegt. | Der WiP wird direkt pro Zustand im Arbeitsablauf festgelegt. |
| Das Scrum Board wird immer wieder neu eingesetzt. | Das Kanban Board bleibt konstant bestehen. |
| Das Scrum Board wird nur von einem Team benutzt. | Das Kanban Board kann von unterschiedlichen Teams benutzt werden. |
Im Anwendungsbereich zeigen sich folgende Unterschiede, die deutlich machen, dass Scrum und Kanban verschiedene Ansätze und Ziele verfolgen:
| Scrum; | Kanban |
| Scrum kommt zum Einsatz, wenn die zu realisierenden Projekte eine große Komplexität aufweisen. | Kanban wird angewendet, wenn die Projekte überschaubar sind. |
| Bei Scrum können vier oder auch deutlich mehr Entwickler beteiligt sein. | Kanban funktioniert am besten mit drei bis vier Entwicklern. |
| Die Geschwindigkeit (auch als Velocity bezeichnet) ist ein wesentlicher Faktor bei Scrum. | Bei Kanban spielt die Geschwindigkeit eine untergeordnete Rolle. |
| Scrum eignet sich für große Projekte, die sehr genau strukturiert werden müssen. | Bei Kanban wird das Festlegen von Regeln eher als Zeitverschwendung betrachtet. |
Vorteile und Nachteile von Kanban
Wie bereits weiter oben angedeutet, eignet sich Kanban nicht für jedes Projekt, und insbesondere nicht für jede Projektgröße. Die Vor- und Nachteile lassen sich wie folgt zusammenfassen:
| Vorteile | Nachteile |
| Probleme werden sehr schnell sichtbar gemacht. | Kanban setzt eine räumliche Gebundenheit voraus und schränkt damit die Möglichkeiten ein. |
| Kanban kann auf jeden Entwicklungsprozess aufgesetzt werden. | Kanban ist nicht beliebig skalierbar und somit für größere und große Projekte ungeeignet. |
| Negatives Multitasking wird vermieden. | Die Teamgröße muss auf nur wenige Mitglieder reduziert bleiben, da sonst Unübersichtlichkeit auftritt. |
| Die Beschreibung der Tasks enthält nur das Wesentliche. |
Insbesondere die Unübersichtlichkeit wird schnell zum Problem, wenn zu viele Teammitglieder an einem Projekt mitarbeiten[4].
Bedeutung für das Development
Ob Kanban oder Scrum die bessere Methode für das eigene Projekt ist, lässt sich nur sagen, wenn man die Rahmenbedingungen genau analysiert hat. Die Größe des Projekts spielt dabei ebenso eine Rolle wie die Erfahrungen, die bereits vorhanden sind. Auch die Frage, ob mehr oder weniger Freiheit bei der Entwicklungsarbeit gewährt werden soll, nimmt Einfluss auf die Entscheidung über Scrum oder Kanban. In der agilen Softwareentwicklung haben sich beide Methoden im Laufe der Zeit durchsetzen können, ein objektives „Besser“ oder „Schlechter“ kann es nicht geben, allenfalls ein „Passender“ oder „Weniger passend“.
Einzelnachweise
- ↑ Das Kanban-Prinzip rechnungswesen-verstehen.de. Abgerufen am 18.01.2018
- ↑ Kanban: Extrem lean und hoch effektiv de.agdice.com. Abgerufen am 18.01.2018
- ↑ Einstieg und Überblick: Das Kanban Prinzip it-agile.de. Abgerufen am 18.01.2018
- ↑ Scrum Kanban cosy.sbg.ac.at.de. Abgerufen am 18.01.2018