Kanban Basics

Kanban

Kanban ist ein japanisches Wort und bedeutet so viel wie Karte, Tafel oder Beleg. Es stellt eine Methode zur Produktionsablaufsteuerung dar. 1947 entwickelte Taiichi Ohno in der japanischen Toyota Motor Corporation diesen Produktionssteuerungsansatz. Die ungenügende Produktivität des Unternehmens im Vergleich zu amerikanischen Konkurrenten war damals der Auslöser für diese Entwicklungsmaßnahme. Ferner wurden die Kosten für Zwischenlager in Japan immer teurer, da auf den japanischen Inseln das Raumangebot limitiert ist. Es galt also, einen Steuerungsansatz zu finden, welcher

  1. präzise ohne komplexe Berechnungen Produktionsabläufe steuert
  2. dabei hilft, Optimierungspotenziale im Produktionsprozess ohne aufwendige Analysen zu erkennen
  3. geeignet ist, den Bedarf an Lagerflächen zu reduzieren

Ohno holte sich seine Motivation für Kanban aus dem Supermarktprinzip: Der Kunde nimmt sich das gewünschte Produkt aus dem Supermarktregal. Die herausgenommene Menge stellt hierbei ein Signal dar, Ersatz zu produzieren, um die entstandene Lücke wieder zu schließen (Abb. 3).

Abb. 3: Das Kanban-Prinzip

Zentraler Bestandteil dieses Ansatzes ist das Zurufprinzip, das in der Fachwelt auch „Pull-Prinzip“ genannt wird. Kanban orientiert sich demnach ausschließlich am tatsächlichen Verbrauch von Materialien am Bereitstellungs- und Verbau-Ort. Dieser Ansatz erlaubt somit eine Reduzierung von Lagerbeständen bezüglich Produkten, Bauteilen oder Rohstoffen, die in der Produktion benötigt werden. Somit werden in der Produktion Kosten aufgrund reduzierter Kapitalbindung durch kleinere Zwischenlager optimiert. In der IT wird unter dem Namen Kanban eine bestimmte Methode verstanden, die zwar Prinzipien aus dem ursprünglichen Kanban übernimmt, sich aber in vielen Punkten stark von diesem unterscheidet. Dies liegt eigentlich auf der Hand: In der Softwareentwicklung stehen Artefakte im Produktionsfokus, welche immateriell sind und damit nicht den gleichen Gesetzmäßigkeiten unterliegen, wie sie auf einer Produktionsstraße – wie zum Beispiel im Automobilbau – oder in deren Produktionsergebnissen vorzufinden sind. So spricht man hier auch gerne von „Software-Kanban“ oder „IT-Kanban“, um diesen Unterschied deutlich zu machen. Es lassen sich auch nicht einzelne Kanban-Techniken aus der Produktionswelt in die IT-Welt ohne Anpassungen und Modifizierungen übernehmen. Software-Kanban beinhaltet auch weitere Prinzipien aus der Lean Production (Schlanke Produktion), dem Lean Development (Schlanker Entwicklung), der Theory of Constraints (Engpass-Theorie) und dem Risikomanagement. Es mag nun die Frage aufkommen, ob die Bezeichnung Kanban für diesen Ansatz noch gerechtfertigt sei. Ich denke schon, da trotz der vielen Anpassungen die Methode als Kanban-Derivat zum ursprünglichen Kanban noch gut zu erkennen ist (Kasten: „Warum Kanban?“).

2007 stellte David Anderson Software-Kanban erstmalig vor und führte die Methode erfolgreich bei Microsoft ein. Seit dieser Zeit steigt das Interesse an diesem Ansatz, der folgende Vorteile hat:

  1. Software-Kanban schafft schnell eine hohe Transparenz über Projektfortschritt und akute Probleme.
  2. Der Ansatz geht über die reine Softwareentwicklung hinaus und beleuchtet auch Bereiche wie die Qualitätssicherung, Wartung und Systemadministration.
  3. Er ist gut geeignet für Organisationen mit starker Arbeitsteilung und Spezialisierung.
  4. Der Ansatz lässt sich behutsam in bestehende, sequenzorientierte oder agile Prozesslandschaften integrieren und schrittweise anpassen.
  5. Kanban fördert eine gleichmäßige und nachhaltige Geschwindigkeit (Sustainable Pace).
Warum Kanban?

Welche Gründe kann es für Unternehmen geben, Software-Kanban einzuführen? Die nachfolgende Rangliste enthält die zehn am häufigsten genannten Antworten:

  1. „Empowerment“ der betreffenden Teams
  2. Verbesserung des agilen Momentums in dem betreffenden Bereich
  3. Reduktion der Verwaltungs- und Steuerungsaufwände
  4. Verbesserung der Realisierungsleistung/schnellerer „Burndown“
  5. Limitierung der parallel durchführbaren Arbeitspakete
  6. Umsetzung des Pull-Ansatzes
  7. Rasche Problemerkennung und Lösung
  8. Realisierung einer besseren Prozesstransparenz
  9. Reduzierung von Überstunden innerhalb der Teams
  10. Reduzierung des Bedarfes an externer Unterstützung (Insourcing)

Die Grundidee von Software-Kanban besteht in zwei Dingen:

  1. Die Wertschöpfungskette, der Kanban-Stream, mit ihren verschiedenen Prozessschritten – wie z. B. Anforderungsdefinition, Programmierung, Dokumentation, Softwaretest und Inbetriebnahme – wird gut sichtbar für alle Beteiligten visualisiert. Dafür wird ein Kanban-Board verwendet, auf dem die unterschiedlichen Stationen als Spalten dargestellt werden. Die einzelnen Anforderungen (wie Tasks, Features, User Storys usw.) werden auf Karteikarten festgehalten und durchwandern mit der Zeit als Tickets das Kanban-Board von links nach rechts.
  2. Die Anzahl der Tickets (Work in Progress – WiP), die gleichzeitig an einer Station bearbeitet werden dürfen, ist der Work in Progress (WIP), welcher für jede Station limitiert ist. Wenn beispielsweise die Anforderungsdefinition gerade drei Tickets bearbeitet und das Limit für diese Station ebenfalls drei beträgt, darf sie kein viertes Ticket annehmen, auch wenn weitere Aufgaben vorhanden sind. Hierdurch entsteht ein Pull-System, bei dem sich jede Station ihre Arbeit bei der Vorgängerstation abholt, anstatt fertige Arbeit einfach an die nächste Station zu übergeben. Dies bedeutet auch, dass die Anforderungsdefinition sich keine neue Aufgabe holen kann, wenn bereits eines der drei besagten Tickets fertig ist, die Programmierung aber nicht in der Lage ist, das Ticket abzuholen.

Abb. 4: Beispiel eines Kanban-Board

Die Visualisierung und die Begrenzung des WiP bieten einige Vorteile:

  • Es ist rasch sichtbar, wie schnell die Tickets die verschiedenen Stationen durchlaufen und wo sich Tickets stauen (Kasten: „Ticketstau im Kanban-Stream“). Die Stationen, an deren Eingängen sich Tickets häufen, werden oft auch „Bottlenecks“ genannt. Einfache Analysen des Kanban-Boards lassen diese Bottlenecks schnell erkennen, und so können zeitnah Gegenmaßnahmen ergriffen werden, um einen gleichmäßigen Fluss (Flow) zu erreichen. Denn ein gleichmäßiger Durchfluss erzeugt einen nachhaltigen Stream, wobei das Verhältnis Ressourceneinsatz zu Durchlaufzeit der Tickets über alle Stationen in der Regel optimal im Vergleich zu einem ungleichmäßigen Fluss ist.
  • Die WiP-Limitierung hilft den Mitarbeitern an den Stationen, sich auf die aktuelle Arbeit zu konzentrieren. Ferner wird sehr schnell sichtbar, wenn das Team überlastet ist, d. h., wenn das WiP-Limit viel zu hoch angesetzt wurde. Permanente Staus wären die Folge, sodass letztlich der gesamte Kanban-Stream stoppen würde.
Ticketstau im Kanban-Stream

Bei Software-Kanban kann es zu Ticketstaus kommen. Diese gilt es rasch zu beseitigen, um den Flow aufrecht zu erhalten oder wieder anlaufen zu lassen. Gründe für derartige Staus können zum Beispiel sein:

  • Kurzfristiger Ausfall von Mitarbeitern (Krankheit)
  • Unerwartete Probleme bei der Aufgabendurchführung
  • Unklare Aufgabenbeschreibung
Geeignete Gegenmaßnahmen

Es gibt eine Reihe möglicher Gegenmaßnahmen, um den Stau rasch zu beseitigen. Zur exakten Ursachenbestimmung und bei der Prozessoptimierung unterstützt das ISHIKAWA-Modell wie auch der Kaizen-Ansatz. Die Gegenmaßnahmen sind der Ursache entsprechend auszuwählen, um möglichst rasch und effektiv den Stau zu beseitigen:

  • Erhöhung der WIP-Limits einer Station
  • Zuordnung weiterer Mitarbeiter zu einer Station (temporär oder permanent)
  • Optimierung der begleitenden Dokumentation im Sinne von Kaizen
  • Optimierung der Eingangsprüfung
Scrum und Software-Kanban im Vergleich

Scrum und Software-Kanban haben viele Gemeinsamkeiten. Beide Ansätze lassen sich den agilen Entwicklungsmethoden zuordnen und unterstützen Lean-Ansätze. Es wird der Ansatz verfolgt, große Aufgabenpakete in kleine, überschaubare und leicht handhabbare Arbeitspakete zu unterteilen. Ihr Aufwand bezüglich der Projektsteuerung ist gering, da beide Ansätze auf einfachen Regelwerken beruhen. Beide Methoden legen Wert auf hohe Prozesstransparenz. Neue Erkenntnisse und Erfahrungen aus den Projekten können zeitnah in Form von Optimierungen oder Anpassungen eingebracht werden. Beide Methoden lassen sich gut mit Kaizen kombinieren, beziehungsweise ein kontinuierlicher Verbesserungsprozess lässt sich leicht integrieren.

Zusätzlich steht das Team im Mittelpunkt: Die Teams organisieren sich selbst, sie bestimmen und verantworten alle Entscheidungen. Beide Systeme gehen davon aus, dass – aus Unkenntnis über wichtige Details – nicht ein Management-Board die richtige Option bei konkreten Fragestellungen der Projektsteuerung findet, sondern nur das betreffende Team selbst in der Lage ist, die beste Wahl aus allen Alternativen zu treffen. Beide Ansätze unterstützen zudem eine häufige und frühe Lieferung der Projektergebnisse an Kunden zur Begutachtung, um mögliche Abweichungen bezüglich Projektziele und Fehlentwicklungen früh zu erkennen und mit vergleichsweise geringem Änderungsaufwand zu korrigieren.

Es gibt aber auch deutliche Unterschiede zwischen beiden Ansätzen. Scrum ist bezogen auf die möglichen Aufgabenstrukturen sehr flexibel. Dies geht sicherlich mit Software-Kanban ebenso, jedoch spielt diese Methode ihre Stärken insbesondere dann aus, wenn die zu bearbeitenden Aufgaben über ähnliche Strukturen verfügen. Zum Beispiel könnte diese Voraussetzung vorliegen, wenn ein Bereich aus mehreren Teams die Aufgabe hat, für ein produktives System Change Requests mit ähnlicher Komplexität von der Definition über die Realisierung und Übergabe in die Produktion zu bearbeiten. Durch die Gleichförmigkeit der Arbeitspakete kann sich der kontinuierliche Fluss im Kanban-Stream besser entwickeln als bei ständig wechselnden Aufgabenpakten. Tabelle 1 gibt eine Übersicht über die weiteren Unterschiede.

Tabelle 1: Scrum und Software-Kanban im Vergleich

Software-Kanban Scrum
Iterationen können bei Kanban optional eingeführt werden. Es kann sogar unterschiedliche Takte für die verschiedenen Bereiche, wie Programmierung, Qualitätssicherung oder beispielsweise Dokumentation, geben. In Scrum sind Iterationen mit gleicher Zeitdauer vorgeschrieben.
Kanban benötigt keine Committments. Sie können aber eingeführt werden. Das Team vereinbart eine bestimmte Menge an Arbeit in der nächsten Iteration zu erledigen. In der Scrum-Philosophie nehmen Committments eine zentrale Bedeutung ein.
Die Durchlaufzeit wird in Kanban als Basismetrik für die Planung und Prozessverbesserung verwendet. Innerhalb von Scrum ist Teamgeschwindigkeit die Basismetrik für die Planung und Prozessverbesserung.
Kanban kennt in der Regel keine cross-funktionalen Teams. In Kanban arbeiten so genannte „Expertenteams“ zusammen. Jedoch können optional auch cross-funktionale Teams eingeführt werden. Cross-funktionale Teams sind in Scrum vorgeschrieben.
Kanban limitiert nicht die Größe von Anforderungen. In Scrum dürfen die Anforderungen nur so groß sein, wie diese auch in einer Iteration umsetzbar sind. In diesem Sinne zu große Anforderungen können in einer Iteration nicht bearbeitet und müssen unterteilt werden.
Kanban schreibt keine Diagrammtypen vor. Die Burn-Down-Charts sind in Scrum das zentrale Element zur Darstellung der Ergebnisse innerhalb einer Iteration.
Bei Kanban wird der WiP pro Arbeitsstatus festgelegt. Der WiP wird in Scrum limitiert, indem die Anforderungen festgelegt werden, die in einer Iteration bzw. einem Sprint realisiert werden können. Allerdings ist die Steuerung des WiPs in Scrum schwieriger als in Kanban.
Kanban kennt normalerweise keine Schätzungen. In Scrum sind Schätzungen vorgeschrieben.
Neue Anforderungen können in Kanban zu jedem Zeitpunkt an das Team zur Bearbeitung weitergeben werden, wenn entsprechende Kapazitäten frei sind (bezogen auf WiP-Limit). Während laufender Sprints können in Scrum keine weiteren Anforderungen an das Team zur Bearbeitung weitergegeben werden.
Kanban selbst gibt keine Rollen vor. In Scrum gibt es drei Rollen, die es zu etablieren gilt: Product Owner, Scrum Master und das Team.
Ein Kanban-Board kann von mehreren Teams oder Einzelpersonen benutzt werden. Jedes Scrum-Team besitzt sein eigenes Scrum-Board.
Ein Kanban-Board wird kontinuierlich weitergepflegt. Ein Scrum-Board wird nach jedem Sprint bzw. nach jeder Iteration gelöscht und neu aufgesetzt.
Eine Priorisierung der Aufträge oder Arbeitspakete in Kanban ist optional. Scrum schreibt vor, dass die Einträge im Product Backlog, die einzelnen Aufträgen entsprechen, priorisiert sein müssen.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.