Einleitung

Bei Kanban handelt es sich um eine schlanke Form der Softwareentwicklung (Lean Software Development), welches ursprünglich von Ohno Taiichi für das Produktionssystem des Automobilherstellers Toyota entwickelt wurde und 2007 von David J. Anderson als agiles Managementsystem für IT-Projekte vorgestellt wurde. Der Begriff „Lean Development“ bezeichnet ein Vorgehensmodell der Softwareentwicklung bei dem ein wesentlich kleinerer bürokratischer Aufwand herrscht. Auf viele klassische Methoden, wie die Führung eines Pflichtenheft wird verzichtet was zu einem schlankeren Projektfluss führt. Entgegen dem „Lean Development“ stehen schwere Vorgehensmodelle, welche dem klassischen Management entsprungen sind.
Ziel dieses Beitrags ist die Eignung von Kanban für den Einsatz in IT-Projekten zu untersuchen. Es soll einen Überblick über die Verbreitung, die Grundeigenschaften, mögliche Schulungen und die Abgrenzung zu Scrum geben. Im Fazit soll zudem Auskunft darüber gegeben werden für welche Art von Projekten sich der Einsatz von Kanban eignet.

Verbreitung

Kanban wurde bei Microsoft bereits im Jahr 2004, vor seiner Veröffentlichung durch David J. Anderson, bei IT-Projekten angewendet und befindet sich bei deutschen Unternehmen, wie der it-agile GmbH und Cologne Intelligence GmbH, in der Praxis [1].

Grundeigenschaften

David J. Anderson [2] benennt bei Kanban fünf Kerneigenschaften:

  • Visualisiere den Workflow.
  • Begrenze den Work in Progress.
  • Führe Messungen zum Fluss durch und kontrolliere ihn.
  • Mache die Regeln des Prozess explizit.
  • Verwende Modelle, um Chancen für Verbesserung zu erkennen.

Die Visualisierung erfolgt durch ein Kanban-Board (Abbildung 1.1), welches in „Backlog“, „Selected“, „Develop“, „Deploy“ und „Live!“ unterteilt wird. Jedem Teil wird ein Maximum an Tasks zugeteilt, welche nicht im jeweiligen Prozess überschritten werden darf. Die Aufgaben werden nach Freigabe einer Instanz nicht weitergereicht, sondern von der nächsten Instanz abgeholt sobald diese mit ihrer aktuellen Aufgabe fertig ist. Dies gewährleistet, dass alle Work in Progress vollständig beendet sind und sich keine größere Menge an nicht vollständig abgeschlossenen Tasks anhäuft [1], welche sich im mittleren Bereich des Kanban Boards befinden. [2]

Ein Kanban Board

Abbildung 1.1: Foto eines Kanban Boards.

Kanban zeichnet sich im weiteren durch folgende Elemente aus:

  1. Arbeit wird genommen nicht vergeben: Dies bedeutet einerseits, dass Aufgaben nicht innerhalb von Phasen der Wertschöpfungskette verschoben werden, sondern von Personen/Teams innerhalb einer bestimmten Phase ausgewählt werden. Weiterhin ermöglicht dies, dass ein gezieltes Auswählen der Aufgaben nach den eigenen Fähigkeiten erfolgen kann. Jeder Person kann zwischen Arbeitsaufgaben sein Wissen erweitern. Es vermindert den Overhead des Task Switching, da eine neue Aufgabe erst dann angenommen wird wenn die vorangehende abgeschlossen wurde.[1]
  2. Mengen(Aufgaben) werden limitiert: Innerhalb jeder Phase existiert ein Limit von Aufgaben. Dies soll zur Vermeidung von Überlastungen einzelner Personen/Teams dienen. Weiterhin vermidert es die Anzahl der in Bearbeitung befindlichen Prozesse und beschleunigt die „average completion time“ und verringert so die Durchlaufzeit der einzelnen Phasen[1].
  3. Informationen werden veröffentlicht: Damit Arbeiten selbstorganisiert/eigenverantworlich durchgeführt werden können bestehen folgende Voraussetzungen: Phasen des Wertschöpfungsprozess zu jeder Aufgabe muss bekannt sein. Die Personen welche die Aufgaben bearbeiten. Limitierungszahlen und Projektkennzahlen(Fortschritt…)[1].
  4. Arbeitsabläufe werden kontinuierlich verbessert: Auf diesen Prozess haben alle Mitwirkenden Einfluss. Es dient dazu neu erworbenes Wissen und Techniken einzuführen, bestehende Techniken zu hinterfragen und gegebenenfalls aufzugeben[1].

Schulungen

Neben dem international aktiven Unternehmen von David J. Anderson werden auch im deutschen Bereich Kurse und Zertifizierung zu Kanban angeboten. Die Kurse von David J. Anderson & Associates finden weltweit statt. Das deutsche Unternehmen it-agile GmbH bietet den Kurs „Kanban für Projektmanager“ und „Kanban in Action“ an.

Über diese Kurse hinaus findet man auf der Webseite der limitedwipsociety Material und Support zu Fragen rund um die Thematik. Hinter limitedwipsociety verbirgt sich hierbei eine Community von Mitgliedern der Kanban-Szene mit dem Slogan „Yes We Kanban“, einer Anlehnung an den Slogan von US-Präsident Barack Obama während seiner ersten Amtskandidatur.

Im vergangen Oktober fand die „Lean Kanban Central Europe“ in Wien statt, welche ein jährlicher Kongress von Vertretern der Kanban-Szene ist. Markus Andrezak schrieb in einem Artikel bei Heise, dass die Kanban-Szene in Europa zunehmend reifer werde. Grund dafür sei, dass die Themen dieser Veranstaltung zu der im Vorjahr wesentlich tiefgreifender sind und nicht mehr über die richtige Einführung und Techniken am Kanban Board sondern wurden lange bestehende Paradigmen hinterfragt, neue Denkanstöße gemacht und weiterführende Modelle, welche zur Verbesserung genutzt werden können, vorgestellt[7].

Abgrenzung zu SCRUM

Scrum greift wie Kanban die Grundgedanken des agilen Management auf und setzt hierbei ebenfalls auf Daily Standup-Meetings und die Verwendung eines Kanban Board. Im Gegensatz zu Scrum werden die traditionellen Rollen der Teammitglieder beibehalten. Es wird auf die Einführung spezieller Rollen wie Product Owner und eines Scrum Masters verzichtet und auf Rollen wie Projektmanager, Requirement Engineer, Entwickler und Qualitätsmanager zurückgegriffen.

Fazit

Kanban eignet sich wie Scrum als agiles Management System für kleine bis mittelgroße Projekte und kann sich als ebenbürtiger Kontrahent behaupten. Es wird jedoch vor falscher Einführung gewarnt, da Prozesse und Regeln von Unternehmen missinterpretiert oder nicht eingehalten werden [4]. Auf teure Schulungen kann unserer Meinung zunächst verzichtet werden, da eine gute Einarbeitung mittels Literatur möglich ist.

Empfehlenswert ist es für Projektmanager, welche eine Alternative zu Scrum suchen, aber trotzdem nicht auf ein agiles und schlankes System verzichten wollen und ihre Prozesse optimieren wollen und die Entwicklung von Software verbessern wollen.

Da wir leider keine Informationen zur Einarbeitungszeit für Kanban finden können wir nur eine These für weitere Untersuchungen aufstellen. Da bei Kanban alle Rollen und Prozesse eines Unternehmens bestehen bleiben und nur der Ablauf verändert wird gehen wir davon aus, dass die Einarbeitung schneller verläuft als bei Scrum, welche schätzungsweise bei zwei Wochen liegt. Grund hierfür ist, dass auf Einführung neuer Rollen wie den Scrum Master und Anwendung neuer Methoden wie Sprints verzichtet wird.

Zum Schluss möchten wir eine weitere These aufstellen, dass sich Kanban für große Projekte besser eignet als Scrum. Scrum verschachtelt bei größeren Projekten ihr eigenes System über mehrere Ebenen. Kanban könnte hierbei durch die Erhöhung der WiP?-Limits einen einfacheren Weg zeigen.

Quellen

[1] Kanban für die Softwareentwicklung, Thomas Epping, Springer, 1. Auflage, 2011
[2] Kanban: Successful Evolutionary Change for Your Technology Business, David J. Anderson, Blue Hole Press, 2010
[3] http://www.heise.de/developer/artikel/Software-Kanban-im-Einsatz-1235465.html
[4] http://www.heise.de/developer/artikel/Kanban-richtig-einfuehren-1344554.html
[5] http://www.it-agile.de/kanban-schulung.html
[6] http://agilemanagement.net/index.php/site/advanced_kanban_masterclass_karlsruhe_germany_nov_21-23/
[7] http://www.heise.de/developer/artikel/developer_artikel_1744042.html

Autor: Fabian Nitsch, Axel Schöner