Kanban

Agile Softwareentwicklungsteams nutzen heute dieselben JIT-Grundsätze, indem sie die Anzahl der laufenden Arbeiten an die Kapazität des Teams angleichen. So kann das Team flexibler planen, Aufgaben schneller erledigen, sich auf kontinuierliche Verbesserung fokussieren und für Transparenz im gesamten Entwicklungszyklus sorgen.

Die Kernprinzipien des Kanban-Frameworks sind zwar zeitlos und können in nahezu jeder Branche angewandt werden, jedoch verzeichnen insbesondere Softwareentwicklungsteams mit der agilen Methode große Erfolge. 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 Aufgabenkarten – und selbst diese können virtuell sein.

Die Arbeit von Kanban-Teams dreht sich um ein Kanban-Board, ein Tool, das verwendet wird, um den Workflow teamübergreifend zu visualisieren und zu optimieren. Physische Boards sind zwar bei einigen Teams beliebt, jedoch sind virtuelle Boards aufgrund ihrer Rückverfolgbarkeit, Zusammenarbeitsmöglichkeiten und Barrierefreiheit von mehreren Standorten aus in jedem agilen Softwareentwicklungstool unverzichtbar.

Unabhängig davon, ob ein Team ein digitales oder physisches Kanban-Board verwendet, stellt es sicher, dass das Team seine Arbeit visualisiert, seinen Workflow standardisiert und etwaige Blockaden und Abhängigkeiten umgehend identifiziert und löst. Ein einfaches Kanban-Board beinhaltet einen dreiphasigen Workflow: Zu erledigen, In Bearbeitung und Erledigt. Abhängig von der Größe, Struktur und den Zielen von Teams kann der Workflow jedoch so abbildet werden, dass er ihren individuellen Prozessen entspricht.

Die Kanban-Methode basiert auf völliger Transparenz der Aufgaben und Mitteilung der Kapazitäten in Echtzeit. Deshalb dient das Kanban-Board als die zentrale Informationsquelle für die Arbeit des Teams.

Die wörtliche Übersetzung von Kanban aus dem Japanischen ist „visuelles Signal“. Kanban-Teams stellen jedes Arbeitselement als separate Karte auf dem Board dar. Die Darstellung 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 enthalten wichtige Informationen zu Projektaufgaben und geben Teams einen Überblick darüber, wer für welche Aufgaben verantwortlich ist, sowie eine kurze Beschreibung der Aufgabe und wie lange Aufgaben voraussichtlich dauern werden. Karten auf virtuellen Kanban-Boards sind zudem häufig mit Screenshots und anderen technischen Details versehen, die für die zugewiesene Person hilfreich sind.

Dadurch, dass Teammitglieder jederzeit den Status jeder Aufgabe sowie relevante Details einsehen können, wird eine erhöhte Konzentration, eine umfassende Rückverfolgbarkeit und eine schnelle Identifizierung von Blockaden und Abhängigkeiten gefördert.

Kanban ist eine der beliebtesten Softwareentwicklungsmethoden, die agile Teams heute verwenden. Kanban bietet zusätzliche Vorteile in Bezug auf die Aufgabenplanung und den Durchsatz für Teams jeder Größe.

Ein Kanban-Team konzentriert sich nur auf die Arbeit, die aktiv ausgeführt wird. Sobald das Team eine Aufgabe abgeschlossen hat, wählt es die nächste Aufgabe aus dem Backlog aus. Der Produktinhaber kann die Priorität von Aufgaben im Backlog beliebig neu festlegen, ohne das Team zu unterbrechen, da sich alle Änderungen, die nicht das aktuelle Aufgabenelement betreffen, nicht auf das Team auswirken.

Solange der Produktinhaber dafür sorgt, dass die wichtigsten Aufgabenelemente oben im Backlog stehen, kann das Entwicklerteam dem Unternehmen den größtmöglichen Wert liefern.

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 Best Practices wie Code-Reviews und Mentoring, um ihr Wissen zu teilen. Geteilte Kompetenzen bedeuten, dass Teammitglieder heterogene Aufgaben übernehmen und damit die Durchlaufzeit weiter optimieren können.

Darüber hinaus ermöglicht dieser Ansatz dem gesamten Team, Arbeitsengpässe gemeinsam anzugehen, was eine schnelle Lösung ermöglicht und einen reibungslosen Workflow gewährleistet. Zum Beispiel erstreckt sich die Verantwortung für Tests nicht nur auf die Qualitätssicherung, sondern auch auf Entwickler, wodurch zusammen an der Gewährleistung von Effizienz gearbeitet wird. In einem Kanban-System sorgt das gesamte Team dafür, dass die Arbeit den Prozess reibungslos durchläuft.

Multitasking erstickt Effizienz. Je höher die Arbeitsbelastung zu einem bestimmten Zeitpunkt, desto häufiger treten Kontextwechsel auf, was den Abschluss von Aufgaben behindert. Deshalb ist ein wichtiger Grundsatz des Kanban-Prozesses, Grenzen für laufende Arbeit zu setzen. Grenzen für laufende Arbeit heben Engpässe im Teamprozess hervor, die auf mangelnde Konzentration, fehlende Mitarbeiter oder Fähigkeiten zurückzuführen sind.

Ein typisches Softwareteam hat möglicherweise vier Workflow-Status festgelegt: „Zu erledigen“, „In Bearbeitung“, „Code-Review“ und „Erledigt“. Das Team kann die WIP-Grenze für den Code-Review-Status auf 2 festlegen. Das mag wie eine niedrige Grenze erscheinen, aber dafür gibt es einen guten Grund.

Entwickler ziehen es oft vor, neuen Code zu schreiben, anstatt Zeit damit zu verbringen, die Arbeit von jemand anderem zu überprüfen. Eine niedrige Grenze ermutigt das Team, Problemen im Review-Status besondere Aufmerksamkeit zu widmen und die Arbeit anderer zu überprüfen, bevor sie ihre Code-Reviews einleiten, wodurch letztlich die Gesamtzykluszeit reduziert wird.

Ein kumulatives Flussdiagramm zeigt die Anzahl der Vorgänge pro Status. Das Team kann Blockaden leicht erkennen, wenn die Anzahl der Vorgänge in einem bestimmten Status zunimmt. Vorgänge in Zwischenstatus wie „In Bearbeitung“ oder „In Überprüfung“ werden noch nicht an Kunden geliefert, und eine Blockaden in diesen Status kann die Wahrscheinlichkeit massiver Integrationskonflikte bei der späteren Zusammenführung erhöhen.

Bei Continuous Delivery (CD) geht es darum, Kunden häufige Releases bereitzustellen. Bei Continuous Integration (CI) werden im Verlauf eines Tages automatisch inkrementell Builds erstellt und Code-Tests durchlaufen. Zusammen bilden sie eine CI/CD-Pipeline, die für DevOps-Teams unerlässlich ist, um Software schneller und in hoher Qualität ausliefern zu können.

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. Kanban-Teams konzentrieren sich auf genau das: die Optimierung der Übergabe von Arbeit an Kunden.

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

Einige Teams vereinen die Ideale der Kanban-Methode und Scrum zu „Scrumban“. Sie kombinieren Sprints mit fester Länge und Rollen aus Scrum mit der Fokussierung auf WIP-Grenzen und Durchlaufzeiten von Kanban.

Teams, die agile Methoden gerade erst einführen, sollten sich jedoch unbedingt für eine Methode entscheiden und diese eine Weile beibehalten. Ist dein Team bereit für die Kanban-Methode? Dann verwende noch heute unsere kostenlose Kanban-Board-Vorlage!