Was ist Kanban?

Kanban is a popular framework used to implement agile software development. It requires real-time communication of capacity and full transparency of work. Work items are represented visually on a kanban board, allowing team members to see the state of every piece of work at any time. 

It is enormously prominent among today's agile software teams, but the kanban methodology of work dates back more than 50 years. In the late 1940s Toyota began optimizing its engineering processes based on the same model that supermarkets were using to stock their shelves. Supermarkets stock just enough product to meet consumer demand, a practice that optimizes the flow between the supermarket and the consumer. Because inventory levels match consumption patterns, the supermarket gains significant efficiency in inventory management by decreasing the amount of excess stock it must hold at any given team. Meanwhile, the supermarket can still ensure that the given product a consumer needs is always in stock.

Als Toyota dieses System in seinen Fertigungshallen einführte, war das Ziel, die enormen Lagerbestände besser am tatsächlichen Materialverbrauch auszurichten. Zur Mitteilung von Kapazitäten in Echtzeit innerhalb der Fertigungshalle (und an Zulieferer) reichten die Arbeiter Karten, die sogenannten "Kanban", zwischen den Teams weiter. Wenn die Materialien an einer Produktionslinie zu Ende gingen, wurde eine Kanban an das Lager weitergereicht, auf der u. a. vermerkt war, welche Materialien in welcher Menge benötigt wurden. Die im Lager bereitgehaltenen Materialien wurden nach Erhalt der Kanban an die Fertigungshalle geliefert. Daraufhin übermittelte das Lager eine Kanban an den Zulieferer. Der Zulieferer hielt ebenfalls eine gewisse Menge dieser Materialien bereit und lieferte die angeforderte Menge an das Lager aus. Auch wenn sich die bei diesem Prozess genutzte Technologie seit den 1940er Jahren weiterentwickelt hat, ist dieses System immer noch der Kern der heutigen "Just in Time"-Fertigung (JIT).

>> Try this tutorial to create a kanban project with Jira 

Kanban für Softwareteams

Agile Softwareentwicklungsteams nutzen heute dieselben JIT-Grundsätze, indem sie die Anzahl der Work-in-Progress-Aufgaben der Kapazität des Teams zuordnen. So kann das Team flexibler planen, Aufgaben schneller erledigen, eine klare Fokussierung erreichen und für Transparenz im gesamten Entwicklungszyklus sorgen.

Während die Kernprinzipien des Framework zeitlos sind und in nahezu jeder Branche angewandt werden können, verzeichnen insbesondere Softwareentwicklungsteams großen Erfolg mit der agilen Methode. Dies liegt zum Teil daran, dass Softwareteams sie ohne großen Aufwand umsetzen können, sobald sie die grundsätzlichen Prinzipien verstanden haben. Im Gegensatz zu der Einführung von Kanban in einer Fertigungshalle, wo dies zu Veränderungen physischer Prozesse und zu einer beträchtlichen Menge an zusätzlichen Materialien führen würde, benötigen Softwareteams als einziges physisches Material ein Board und Karten – und selbst diese können virtuell sein.

Kanbanboards

Bei der Arbeit aller Kanban-Teams steht das Kanban Board im Mittelpunkt, ein Tool zur Visualisierung von Aufgaben und der Optimierung des Workflows im Team. Manche Teams arbeiten gerne mit physischen Boards, doch virtuelle Boards sind ein entscheidender Bestandteil jedes agilen Softwareentwicklungstools für die Nachverfolgbarkeit, eine einfachere Zusammenarbeit und Zugänglichkeit von verschiedenen Standorten aus.

Unabhängig davon, ob das Board eines Teams physisch oder digital ist – seine Funktion ist die Visualisierung der Aufgaben, die Standardisierung des Workflows und die Ermittlung und Beseitigung aller Hindernisse und Probleme durch Abhängigkeiten. Ein einfaches Kanban Board ist in einen Workflow in drei Schritten unterteilt: ToDo, in Bearbeitung, erledigt. Je nach Größe, Struktur und Zielen eines Teams kann der Workflow jedoch an die spezifischen Prozesse jedes beliebigen Teams angepasst werden.

Die Kanban-Methode basiert auf völliger Transparenz der Aufgaben und Mitteilung der Kapazitäten in Echtzeit. Deshalb sollte das Kanban Board eine Stellung als die zentrale Informationsquelle zu den Aufgaben des Teams einnehmen.

Kanban-Karten

Die wörtliche Übersetzung von Kanban aus dem Japanischen ist "visuelles Signal". In Kanban-Teams wird jedes Aufgabenelement als eine separate Karte auf dem Board dargestellt.

Die Repräsentation von Aufgaben als Karten auf dem Kanban Board soll zuallererst die Verfolgung des Arbeitsfortschritts entlang des Workflows durch eine klare visuelle Darstellung ermöglichen. Kanban-Karten stellen kritische Informationen zu dem jeweiligen Aufgabenelement in den Vordergrund, sodass das gesamte Team völlige Transparenz darüber erhält, wer für das Aufgabenelement zuständig ist, worum es sich bei der Aufgabe handelt, wie lange die Bearbeitung schätzungsweise dauern wird usw. Karten auf virtuellen Kanban-Boards sind zudem häufig mit Screenshots und anderen technischen Details versehen, die für die zugeordnete Person hilfreich sind. Dadurch, dass die Teammitglieder den Status jedes Aufgabenelements sowie die zugehörigen Details zu jeder Zeit einsehen können, wird eine stärkere Fokussierung, völlige Nachverfolgbarkeit und eine schnelle Ermittlung von Hindernissen und Abhängigkeiten sichergestellt.

Die Vorteile von Kanban

Kanban ist eine der beliebtesten Methoden bei der Softwareentwicklung, die heute von agilen Teams übernommen wird. Kanban bietet verschiedene zusätzliche Vorteile bezüglich Aufgabenplanung und Durchsatz bei Teams jeder Größe.

Flexibilität bei der Planung

Ein Kanban-Team konzentriert sich nur auf die Arbeit, die aktiv ausgeführt wird. Sobald das Team ein Aufgabenelement abgeschlossen hat, wird das nächste Aufgabenelement aus dem obersten Bereich des Backlogs entnommen. Der Product Owner kann Prioritäten für Aufgaben im Backlog beliebig neu festlegen, ohne das Team zu unterbrechen, da sich alle Änderungen, die das aktuelle Aufgabenelement nicht betreffen, nicht auf das Team auswirken. Solange der Product Owner dafür sorgt, dass die wichtigsten Aufgabenelemente oben im Backlog stehen, kann das Entwicklerteam dem Unternehmen den größtmöglichen Wert bereitstellen. Die für Scrum typischen Iterationen mit fester Länge sind hier also nicht erforderlich.

Profitipp: Erfahrene Product Owner beziehen das Entwicklerteam immer mit ein, wenn sie Änderungen am Backlog in Betracht ziehen. Wenn sich beispielsweise die User Storys 1 bis 6 im Backlog befinden, basiert die Schätzung für User Story 6 möglicherweise auf dem geplanten Abschluss der User Storys 1 bis 5. Änderungen sollten immer mit dem Entwicklerteam besprochen werden, damit es keine Überraschungen gibt. 

Kürzere Durchlaufzeit (Cycle Time)

Die Durchlaufzeit ist für Kanban-Teams eine wichtige Metrik. Die Durchlaufzeit ist die Zeit, die eine Arbeitseinheit benötigt, um den Workflow des Teams zu durchlaufen – von dem Moment, an dem die Aufgabe gestartet wird, bis zu dem Moment, an dem sie ausgeliefert wird. Durch eine Optimierung der Durchlaufzeit kann das Team die Bereitstellung geplanter Aufgaben zuverlässig prognostizieren.

Die Überschneidung von Kompetenzen sorgt für kürzere Durchlaufzeiten. Wenn nur eine Person über eine bestimmte Kompetenz verfügt, kann diese Person einen Engpass im Workflow darstellen. Deshalb nutzen Teams grundlegende Best Practices wie Code-Reviews und Mentoring, um ihr Wissen zu verteilen. Geteilte Kompetenzen bedeuten, dass Teammitglieder heterogene Aufgaben übernehmen und damit die Durchlaufzeit weiter verbessern können. Das bedeutet auch, dass bei einem Aufgabenstau das gesamte Team einspringen kann, um den Prozess wieder reibungslos laufen zu lassen. So wird beispielsweise das Testen nicht nur von QA-Technikern ausgeführt, sondern auch Entwickler können einspringen.

In einem Kanban-Framework ist das gesamte Team für einen reibungslosen Ablauf der Arbeit im gesamten Prozess verantwortlich.

Weniger Engpässe

Multitasking erstickt die Effizienz. Je mehr Aufgabenelemente zu einem bestimmten Zeitpunkt bearbeitet werden, umso mehr Kontextwechsel finden statt. Und diese behindern den Abschluss der Aufgaben. Darum ist eines der Hauptmerkmale von Kanban-Verfahren, die Menge der Work-in-Progress (WIP) einzugrenzen. Work-in-Progress-Grenzen heben Engpässe und Staus im Teamprozess durch fehlende Fokussierung sowie fehlende Mitarbeiter oder Kompetenzen hervor.

Ein typisches Softwareteam hat z. B. möglicherweise vier Workflow-Status festgelegt: ToDo, in Bearbeitung, Code-Review und erledigt. Das Team kann die WIP-Grenze für den Code-Review-Status auf 2 festlegen. Das mag niedrig erscheinen, hat aber einen guten Grund: Entwickler schreiben oft lieber neuen Code, als dass sie die Arbeit eines Kollegen reviewen. Eine niedrige Grenze ermuntert die Teammitglieder, besonders auf Vorgänge im Review-Status zu achten und die Arbeit anderer zu reviewen, bevor sie Reviews ihres eigenen Codes anfordern. Dies minimiert letztendlich die gesamte Durchlaufzeit.

Visuelle Darstellung von Metriken

Zu den zentralen Werten zählt ein starker Fokus auf eine stetige Verbesserung der Teameffizienz und -effektivität bei jeder Wiederholung einer Aufgabe. Diagramme können Teams als visuelle Mechanismen dienen, um sicherzustellen, dass sie sich weiter verbessern. Wenn das Team Daten sehen kann, können Engpässe im Prozess einfacher erkannt (und aus diesem entfernt) werden. Kanban-Teams nutzen dafür hauptsächlich Kontrollcharts und kumulative Flussdiagramme.

In einem Kontrollchart werden die Durchlaufzeit für jeden Vorgang und ein fortlaufender Durchschnitt für das Team dargestellt.

Profitipp: Das Team verfolgt das Ziel, die erforderliche Zeit zu verkürzen, in der ein Vorgang den gesamten Prozess durchläuft. Eine erfolgreiche Durchführung lässt sich daran ablesen, dass die durchschnittliche Durchlaufzeit im Kontrollchart fällt. 

In einem kumulativen Flussdiagramm wird die Anzahl der Vorgänge dargestellt, die sich in einem bestimmten Status befinden. Das Team kann schnell Blockaden erkennen, indem es die Anzahl der Vorgänge in einem bestimmten Status beobachtet. Vorgänge in Zwischenstadien, wie z. B. "In Progress" (in Bearbeitung) oder "In Review" (in der Review-Phase) werden noch nicht an Kunden ausgeliefert und eine Blockade in diesen Stadien erhöht die Wahrscheinlichkeit enormer Integrationskonflikte, wenn ein Upstream-Merging der Aufgaben erfolgt. 

Continuous Delivery

Wir wissen, dass Continuous Integration – das Verfahren, mit dem im Verlauf eines Tages automatisch inkrementel Builds erstellt und Tests durchlaufen werden – ein entscheidender Faktor für die Qualität des Codes ist. Sehen wir uns jetzt Continuous Delivery (CD) an. Bei CD geht es darum, Kunden häufige Releases bereitzustellen – oft täglich oder sogar stündlich. Kanban und CD ergänzen einander auf nahezu perfekte Weise, da bei beiden der Schwerpunkt auf der Just-in-time-Wertbereitstellung (mit jeweils einem Wert) liegt.

Je schneller ein Team dem Markt Innovationen liefern kann, umso wettbewerbsfähiger ist das Produkt. Und Kanban-Teams konzentrieren sich genau auf die Optimierung von Aufgaben, die an Kunden übergeben werden.

Scrum im Vergleich zu Kanban

Kanban und Scrum basieren teilweise auf gemeinsamen Konzepten, der Ansatz ist jedoch jeweils unterschiedlich. Die Verfahren sollten nicht miteinander verwechselt werden. 

  Scrum Kanban
Rhythmus Regelmäßige Sprints mit fester Länge (d. h. 2 Wochen) Kontinuierlicher Fluss
Release-Methoden Am Ende jedes Sprints, wenn vom Product Owner genehmigt Continuous Delivery oder nach Ermessen des Teams
Rollen Product Owner, Scrum Master, Entwicklerteam Keine vorhandenen Rollen. Einige Teams nehmen die Hilfe eines Agile Coach in Anspruch.
Zentrale Metriken Velocity Durchlaufzeit
Änderungsphilosophie Teams sollten während des Sprints keine Änderungen an der Sprintprognose vornehmen, da dies die Lernlektionen aus der Schätzung beeinträchtigt. Es kann jederzeit zu Änderungen kommen.

Einige Teams vereinen die Ideale von Kanban und Scrum zu "'Scrumban." Sie kombinieren Sprints mit fester Länge und Rollen aus Scrum-Verfahren mit der Fokussierung auf Work-in-Progress-Grenzen und der Durchlaufzeit der Kanban-Methoden. Teams, die agile Methoden gerade einführen, sollten sich jedoch unbedingt für die eine oder andere Methode entscheiden und diese eine Weile beibehalten. Sie können immer noch später auf ausgefallenere Methoden umsteigen. 

Dargestelltes Produkt
Projekt- und Vorgangsnachverfolgung