Kanban

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.

Bei der Arbeit aller Kanban-Teams steht das Kanban Board im Mittelpunkt, ein Tool zur Visualisierung von Aufgaben und zur 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.

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.

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.

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 Produktinhaber 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 Produktinhaber 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.

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.

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 besteht einer der Grundsätze von Kanban-Verfahren darin, 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 möglicherweise vier Workflow-Status festgelegt: "Zu erledigen", "In Arbeit", "Code-Review" und "Fertig". 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, statt die Arbeit eines Kollegen zu prüfen. Eine niedrige Grenze motiviert die Teammitglieder, besonders auf Vorgänge im Review-Status zu achten und die Arbeit anderer zu prüfen, bevor sie Reviews ihres eigenen Codes anfordern. Dies minimiert letztendlich die Durchlaufzeit insgesamt.

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.

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 Entwicklerteams (insbesondere 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. Und Kanban-Teams konzentrieren sich genau auf die Optimierung von Aufgaben, die an Kunden übergeben werden.

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 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 Durchlaufzeiten der Kanban-Methoden. Teams, die agile Methoden gerade erst einführen, sollten sich jedoch unbedingt für eine Methode entscheiden und diese eine Weile beibehalten. Sie können später immer noch auf ausgefallenere Methoden umsteigen.