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.Need to sell your house in Virginia? Check out https://www.cashhomebuyers.io/virginia/ to get started.
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]
Kanban zeichnet sich im weiteren durch folgende Elemente aus:
- 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]
- 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].
- 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].
- 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
at 19:19
Hallo Fabian,
Du schreibst, dass sich Kanban genau wie SCRUM für kleine bis mittelgroße Projekte eignet. Warum meinst Du, dass sich Kanban oder auch SCRUM nicht für große Projekte eignen?
Gruß Andreas
at 08:37
Im Schlusswort haben wir die These aufgestellt, dass sich Kanban besser für große Projekte eignet als SCRUM. Der Grund dafür ist, dass bei Kanban durch eine Erhöhung der Kapazitäten eine Anpassung an die Anzahl der Mitarbeiter im Projekt stattfinden kann. Bei SCRUM liegt meiner Meinung nach die optimale Anzahl von Projektteilnehmern bei fünf bis zehn. Habe bereits gehört, dass es Firmen gibt, welche sogar in internationalen Projekten mit mehreren hundert Leuten SCRUM einsetzen und auf eine Verschachtelung der Teams zurückgreifen. Wenn ich es richtig verstanden habe werden die Projektteilnehmer in kleinere Teams unterteilt, welche hierarchisch in Form einer Pyramide angeordnet sind. Da dieses Vorgehen das vorhandene Prinzip von SCRUM erweitert und ich noch keine einschlägige Literatur zu dem Thema gefunden habe beziehungsweise keine Erfahrung in dem Bereich gemacht habe stehe ich der Sache sehr kritisch gegenüber. Da jedoch Kanban aus dem Produktionssystem von Toyota abgeleitet wurde und dadurch eigentlich aus großen Projekten stammt, denke ich, dass es einfach wär dieses wieder in diesen Kontext zurückzuführen.
at 10:13
Hallo Fabian,
Was denkst du über elektronische web Kanban-Tools sowie Trello https://trello.com/ oder Kanban Tool http://kanbantool.com/. Hast du schonmal sie ausprobiert?
Gruß Katia
at 08:37
Mit den Tools hat sich mein Co-Autor Axel Schöner beschäftigt, weshalb ich die Frage gerne an ihn weiterleiten würde.