Als Einstieg in dieses Thema bietet sich somit folgende Literatur an:

• Scrum Detailbetrachtung: Scrum Rollen
• Scrum Detailbetrachtung: Scrum Artefakte
• Scrum Detailbetrachtung: Scrum Meetings
• Scrum Detailbetrachtung: Scrum Kennzahlen
• Kanban in der IT
• Brüder im Geiste – Kriterien für eine Entscheidung für Scrum oder Kanban
• Scrum vs. Kanban: Ziel und Weg

Die Softwareentwicklungsmethode Kanban

Die Softwareentwicklungsmethode Kanban (jap. „kan“=Signal; „ban“=Karte) ist eine Technik, angelehnt an das Produktionssystem von Toyota, mit der ein gleichmäßiger Fluss durch die verschiedenen IT-Prozessphasen, kombiniert mit Theorien aus dem klassischem Projektmanagement (Theory-of-Constraints), hergestellt wird.

Im Zentrum des Kanban der Softwareentwicklung steht das Kanban-Board, mit dem der aktuelle Projektstand mit Hilfe von Kärtchen für jede Aufgabe / Work-Item dargestellt wird. Jedes Kärtchen durchläuft hierbei jede Spalte, bis die Arbeit abgeschlossen ist.

Ziel der Methode ist die Optimierung des Prozessdurchflusses, indem eine Begrenzung der Work-Items, die sich zur gleichen Zeit in einem gewissen Status befinden dürfen, pro Spalte erfasst wird. (Work-Items in Progress: WIP)

Diese Visualisierung zeigt auf einen Blick wie schnell Aufgaben bearbeiten werden können, zeigt aber auch wo „Staus“, „Engpässe“ oder freie Kapazitäten entstehen.

Anhand eines kontinuierlichen Verbesserungsprozesses werden die Limits pro Spalte angepasst (z.B. durch Puffer, weitere Ressourcen, usw.), um einen gleichmäßigen Fluss durch alle Projektphasen zu erreichen.

Innerhalb dieses Prozessmodells werden keine Vorschriften bezüglich Anforderungen, Commitments, Schätzungen, Sprints (time-boxing) oder cross-funktionale Teams gemacht. Neue Anforderungen können zu jedem Zeitpunkt an das Team gegeben werden, falls Kapazitäten frei sind.

Scrum vs. Kanban

Das Ziel von Scrum und Kanban ist die Verbesserung der Team-Arbeitsweise. Hierbei kommt es nicht darauf an, welche Prozessmethode gewählt wird, bzw. wie die gewählte Prozessmethode genau heißt, solange das gewünschte Ziel erreicht wird.

Wie jede Softwareentwicklungsmethode ist weder Scrum noch Kanban perfekt für den eigenen Einsatz geeignet oder bietet eine Komplettlösung zur effizienten Softwarenentwicklung. Scrum und Kanban bieten hingegen Methoden, die vom Team angepasst und schrittweise optimiert werden müssen, um zu einem effizienten System zu kommen.

Das Auswahlkriterium: „Scrum oder Kanban“ liegt somit auf dem Team/ Teamgröße und der Projektkomplexität bzw. dem Projektumfeld. Es ist daher von Vorteil beide Methoden zu kennen:

• Für Projekte mit hoher Projektkomplexität und 5 plus minus zwei Projektmitarbeitern kann Scrum ein gutes Entwicklungsmodell darstellen.
• Für Projekte mit kleineren Projektteams, ohne feste Sprintlängen, kann Kanban eine Option sein.

Im Hinblick auf einen Toolsupport im Microsoft-Umfeld existiert mit dem Team Foundation Server in Kombination mit dem Scrum Prozesstemplate eine sehr gute Tool-/ Prozessunterstützung (Scrum for Team System von EMC Consulting bzw. Microsoft Visual Studio Scrum 1.0). Für den Bereich Kanban ist mir aktuell kein TFS Prozesstemplate bekannt. Das Tool „Visual WIP“ von Hakan Forss bietet hierbei, obwohl erst in als Beta 1 Version vorhanden, ein mögliches Tool zur Visualisierung. Ein durchgängiges Application Lifecycle Management-Produkt, wie mit dem TFS und Visual Studio von Microsoft gegeben, ersetzt dies leider nicht.

Generell gilt für die Auswahl einer Softwareentwicklungsmethode: Eine Methode hilft dem Team, führt aber nicht automatisch zu einen erfolgreichen Projekt.

Eine ausführliche Gegenüberstellung beider Entwicklungsmethoden findet sich unter dem Titel Scrum-Minibook „Kanban and Scrum – making the most of both“ von Henrik Kniberg und Mattias Skarin auf der Internetseite von InfoQ. Entweder als PDF-Download (Anmeldung erforderlich) oder als kostenpflichtige gedruckte Version.