Theorie "Agile Methode Kanban"

Kanban ist eine Methode zur Produktionsablaufsteuerung, die ihren Ursprung im Toyota-Produktionssystem (TPS) hat. Ursprünglich wurde Kanban für die Lean Production entwickelt, es wurde aber später für den Einsatz in (IT-)Projekten angepasst. Der Begriff "Kanban" stammt aus dem Japanischen und bedeutet Signalkarte. Im Projektmanagement kann es dabei helfen, die Arbeit zu veranschaulichen und ein besseres Verständnis für den Workflow (Arbeitsfluss) zu bekommen. Dazu werden die anfallenden Aufgaben auf einer Kanban-Karte notiert und auf einem Kanban-Board zur Visualisierung angebracht.

Eine Kanban-Karte beinhaltet alle für die Mitarbeitenden notwendigen Informationen. Diese sind im wesentlichen Kanbanart, Kanban-ID, Karten-Anzahl, Artikelnummer, Artikel-Text, Menge, Lieferant, Lagerort (Quelle), Lagerort (Ziel), Empfänger, Barcodes und Produktbild.

Die Kanban-Methode kann auf unterschiedlichen Ebenen eingesetzt werden:

Teamebene
Die Darstellung eines Projektes mit dem Kanban-Board kann zu einem besseren Verständnis des Arbeitsablaufs führen. Es erleichtert Ihnen die Organisation und Verwaltung Ihrer Arbeit und ermöglicht es Ihrem Team und den Projektmitgliedern, den Überblick über jede Aufgabe zu behalten.

Portfolioebene
Wenn Ihre strategischen Ziele auf einem separaten Kanban-Board visualisiert werden, können Sie leicht erkennen, welche davon begonnen oder abgeschlossen wurden. Gleichzeitig wird es für Sie einfacher, durch die Verwendung den Überblick über jedes einzelne Projekt zu behalten, welches im Unternehmen sattfindet.

Grundsätze und Praktiken¶

In Kanban existieren vier Prinzipien (Principles) und sechs Praktiken (Practices).

Die 4 Prinzipien:¶

• Prinzip 1: Beginnen Sie mit dem, was Sie gegenwärtig tun.
• Prinzip 2: Verpflichte Sie sich, inkrementelle und evolutionäre Veränderungen anzustreben.
• Prinzip 3: Respektieren Sie die bestehenden Prozesse, Rollen und Verantwortlichkeiten.
• Prinzip 4: Ermutigen Sie dazu, auf allen Ebenen der Organisation Führung zu übernehmen.

Die 6 Praktiken:¶

• Praktik 1: Arbeitsabläufe visualisieren.
• Praktik 2: Laufende Arbeiten einschränken.
• Praktik 3: Aufgabenlast verwalten.
• Praktik 4: Prozessrichtlinien explizit machen.
• Praktik 5: Feedback-Schleifen implementieren.
• Praktik 6: Gemeinschaftlich verbessern und empirisch weiterentwickeln.

Ziele von Kanban¶

Ziele der Kanban-Methode im Produktionsprozess sind die Verbesserung der Produktivität, der Qualität und die Optimierung der Flexibilität.

Diese Ziele sollen durch die Vermeidung von Verschwendung und Fehlern erreicht werden. Verschwendung bedeutet hierbei Arbeit, die dem Produkt keinen Wertzuwachs bringt, Überlastung von Mitarbeitenden und Maschinen sowie Unregelmäßigkeiten von Prozessen. Überproduktion gilt ebenfalls als Verschwendung und sollten Sie vermeiden. Mit Verschwendung ist hier gemeint, dass die produzierten, aber aktuell nicht benötigten Produkte Lagerplatz beanspruchen und Kapital binden, das dem Unternehmen somit nicht für andere - möglicherweise wichtigere - Aufgaben zur Verfügung steht.

Die Kanban-Methode beschreibt im Wesentlichen die Vorgehensweise der Versorgung der einzelnen Produktionsschritte mit den benötigten Materialien und deren Beschaffung. Es enthält alle Informationen, die benötigt werden, um die Versorgung mit den benötigten Gütern anzustoßen. Dabei wandert die Kanban-Karte zwischen Lieferanten- und Kundenprozess hin und her.

Deshalb wird die Kanban-Methode auch als Pull-Prinzip (Hol-Prinzip) bezeichnet. Das Pull-Prinzip ist ein System zur Steuerung von Prozessabläufen, bei dem die Aufträge durch die Fertigung "durchgezogen" werden. Der Impuls zur Durchführung eines Auftrags geht vom Ende der logistischen Kette aus, es ist also eine nachfrageorientierte Produktionssteuerung.

Kanban in IT-Projekten¶

Anwendung von Lean Production, Lean Development und der Theory of Constraints¶

Die Prinzipien von IT-Kanban entstammen, wie oben beschrieben, dem Produktionsprozess und der Lagerverwaltung und wurden angepasst. Dabei finden sich auch die Prinzipien aus Lean Production, Lean Development und der Theory of Constraints.

Lean Production (schlanke Fertigung) ist Bestandteil des Lean Managementkonzepts. Darunter versteht man den sparsamen und zeiteffizienten Einsatz von Produktionsfaktoren (Mensch, Maschine, etc.).

Lean Development (schlanke Entwicklung) überträgt das Managementkonzept der Lean Production und des Lean Managements auf den Bereich der Softwareentwicklung.

Theory of Constraints (Engpasstheorie) geht davon aus, dass die Leistungsfähigkeit eines Systems ausschließlich von einem Faktor, dem Engpass, begrenzt wird. Eine Verbesserung der Leistungsfähigkeit kann nur erfolgen, wenn das Gesamtsystem ausgehend vom Engpass angepasst wird.

Wenn in einem Projekt ein Arbeitsschritt den Engpass darstellt - zum Beispiel, weil nur ein Kollege in der Abteilung diese spezifische Arbeit erledigen kann - dann ist ein häufiger Reflex, dort mehr Kollegen, etwa aus anderen Abteilungen einzusetzen. Einerseits kann das gefährlich sein, da die Teamgröße gerade in agil arbeitenden Teams neben anderen Faktoren nicht verändert werden soll. Ferner kann das dazu führen, dass der Engpass als Resultat an einer anderen Stelle auftritt. Aus diesen Gründen werden zwei Anpassungen vorgenommen:

• Die Anzahl der Vorgänge pro Station wird auf eine maximale Anzahl begrenzt.

• Es wird ein Pull-Prinzip etabliert. Das heißt, Developer "ziehen" sich Aufgaben aus dem Task-Backlog zur Weiterbearbeitung. Dies kann nur geschehen, wenn sie andere Einträge bearbeitet haben und diese vom nachfolgenden Kollegen gezogen wurden.

Wenn dennoch ein Stau entsteht, wenn zum Beispiel bei einer Station Probleme auftreten, etwa beim Testing, dann können diejenigen Kollegen anderer Stationen dazukommen und gemeinsam an einer Lösung arbeiten, da sie selbst aufgrund der begrenzten Anzahl an Einträgen in ihrer Station keine neuen Aufgaben ziehen können. Also könnten beispielsweise die Entwickler mit dem Tester gemeinsam an Lösungsmöglichkeiten arbeiten. Der Vorteil eines fachübergreifenden Teams ist also, dass Entwickler mehr Einblick in das Testing bekommen - und umgekehrt. Man lernt also voneinander.

Kanban kennt keine Iterationen, sondern setzt auf einen kontinuierlichen Bearbeitungsfluss. Dazu wird die Wertschöpfungskette visualisiert und der Work-in-Progress (WIP) begrenzt.

Visualisierung der Wertschöpfungskette¶

Das Kanban-Board¶

Die Wertschöpfungskette wird für die Beteiligten mit Hilfe eines Kanban-Boards (z. B. großes Whiteboard, Kanban-Software) dargestellt. Das Kanban-Board kann entweder einem Team oder mehreren Teams gemeinsam "gehören".

Das Board listet die einzelnen Prozessschritte (z. B. Requirement, Design, Implementation, Test etc.) in Spaltenform auf. Die einzelnen Aufgaben (Tasks) werden auf Karteikarten oder Post-its notiert und zeilenweise auf das Board geklebt (bzw. über entsprechende Symbole in der elektronischen Kanban-Anwendung dargestellt). Häufig kommen auch Kombinationen zum Einsatz, bei dem das Kanban-Board mit einer Kamera auf Veränderungen hin beobachtet wird.

Entsprechend dem Pull-Prinzip der Lean Production holt der Bearbeiter für den jeweils nachfolgenden Arbeitsschritt die abgeschlossene Aufgabe des vorhergehenden Arbeitsschritts.

Durch diese Art der Bearbeitung wandern Karteikarten bzw. Post-its auf dem Kanban-Board von links nach rechts, bis die einzelnen Tasks abgeschlossen sind. Für die Gestaltung des Kanban-Boards gibt es keine Vorschriften, d. h. es kann frei an die individuellen Teambedürfnisse angepasst werden.

Begrenzung des Work-in-Progress (WIP)¶

Der Umgang mit Engpässen¶

Das Kanban-Board schafft Transparenz und ermöglicht das rasche Identifizieren von Engpässen.

Im Beispiel ist der Engpass die Implementierung (Einbindung), da die vom Design abgeschlossenen Themen nicht mit der gleichen Geschwindigkeit umgesetzt werden können. Dadurch ist ein gleichmäßiger Bearbeitungsfluss nicht mehr gegeben. Abhilfe kann die Limitierung des Work-in-Progress der Spalte "Design" schaffen. Eine Begrenzung des WIP im Bereich des Designs auf vier würde bedeuten, dass in der Spalte "Design" insgesamt nur vier Karten angebracht werden dürfen. Damit soll sichergestellt werden, dass in einem Bearbeitungsschritt nicht mehr Ergebnisse entstehen, als weiterverarbeitet werden können. Nach einiger Zeit werden die Tasks dann abgearbeitet und der Engpass löst sich.

Metriken¶

Die Lead- und Cycle Time¶

Nachfolgend sind die Metriken dargestellt, welche bei der Kanban-Methode Anwendung finden.

Lead Time (Durchlaufzeit):
Die sogenannte Lead Time ist die Zeit, die Sie benötigen, um eine Aufgabe seit ihrem Bekanntwerden fertig zu stellen. Dies kann beispielsweise der Zeitraum sein, in welchem ein Kunde seinen Auftrag kommuniziert, bis zu dem Auslieferungszeitpunkt des fertiggestellten Produktes.

Cycle Time (Zykluszeit):
Die Cycle Time ist die Zeit, die vom Beginn bis zur Fertigstellung einer Aufgabe benötigt wird. In anderen Worten die komplette Zeit, die Sie benötigen, um eine Aufgabe zu erledigen. Bei einem Call Center wäre das der Zeitraum, der dann anfängt, wenn das Team aktiv mit der Bearbeitung begonnen hat, bis hin zur Erledigung. Sie schließt auch eventuelle Unterbrechungen, Pausen oder Wartezeiten zwischen den einzelnen Prozessschritten mit ein.

Cumulative-Flow-Diagram (CFD)¶

Zur Kontrolle des Projektfortschrittes kann ein kumulatives Flussdiagramm (Cumulative-Flow-Diagramm) verwendet werden.

Cumulative-Flow-Diagram:
Dieses Diagramm visualisiert, wie viele Aufgaben oder Tickets sich an einem bestimmten Tag in welchem Bearbeitungsstand befinden. Über die Beobachtung der Lead- oder Cycle Time kann dann genau ermittelt werden, wie die Aufgaben erledigt werden.

Anhand des Cumulative-Flow-Diagramms lassen sich folgende Metriken ablesen:

• Backlog (offene Punkte)
• Cycle Time (Zeit, die für das Design aufgewendet wird)
• Lead Time (horizontaler Abstand zwischen den Requirements und der Implementierung)
• Work in Progress (vertikaler Abstand zwischen den Geraden Requirements und Implementation)
• Done (abgeschlossenen Aufgaben)
• Durchsatz (Steigung im Diagramm)

Scrum vs. Kanban¶

Gemeinsamkeiten¶

Scrum und Kanban setzen beide auf:

• Transparenz und Visualisierung
• agiles Vorgehen
• häufige und frühzeitige Auslieferung von release-fähigen Komponenten
• Verwendung eines Pull-Prinzips
• Begrenzung der gleichzeitigen Bearbeitung von Themen (Work-in-Progress)
• das Zerlegen von Anforderungen in detaillierte Einzelschritte
• wenige Regeln

Unterschiede¶