Jahrhunderts zu weltweiter Bekanntheit. Seitdem wächst die Kanban-Anhängerschaft kontinuierlich. Für David J. Anderson stand schon 2013 fest, dass es “das nächste große Ding auf dem Softwareprozess-Markt” sein wird.
Das mag nach einer Übertreibung klingen, aber Anderson wusste, wovon er spricht. Schließlich ist er einer der Pioniere, die Kanban auf den Softwarebereich übertragen haben.
Auch dein Unternehmen wird in der Regel von Kanban profitieren. Das Gute daran: das Kanban-Verfahren verlangt nicht, deinen aktuellen Managementstil oder alle deine Prozesse komplett auf den Kopf zu stellen. Vielmehr fügt es sich nahtlos in die unterschiedlichsten Unternehmensstrukturen ein.
GitLab bietet mit seinen Issue-Boards die Möglichkeit, den Software-Entwicklungsprozess mit Kanban zu optimieren. Bevor wir allerdings näher darauf eingehen, sehen wir uns an, worum es bei Kanban ganz genau geht.
Was ist ein Kanban-Board?
Heute assoziieren wir mit dem Wort “Kanban” vor allem die Darstellung der Arbeitsschritte in einem sogenannten “Board”.
Ein Kanban-Board ist eine visuelle Repräsentation der anfallenden Aufgaben eines Projekts in einer klar strukturierten zeitlichen Abfolge. Aufgaben werden als Kärtchen in diesem Board dargestellt. So kannst du anhand dieser Übersicht erkennen, in welchem Stadium sich ein Task befindet. Egal, ob der Task beispielsweise kurz vor der Vollendung steht oder sich noch in Bearbeitung befindet.
Auch zeigt ein Board alle Aufgaben an, die noch nicht bearbeitet wurden, aber noch anstehen. So erfasst du auf einen einzigen Blick den Stand der zukünftigen Arbeitslast. Daraus ergeben sich konkrete Anforderungen an deine Planung.
Wie funktioniert das Kanban-System?
Kanban ist eine Methode der agilen Planung. Auf einem Kanban-Board wandern die Aufgabenkärtchen von links, dem Ort der To-do-Liste, nach rechts, in Richtung des fertigen Produkts. Sobald die auf einer Karte vorgeschriebene Aufgabe bearbeitet wurde, verschwindet sie vom Board und macht den Weg frei für neue Karten.
In seiner einfachsten Form hat ein Kanban-Board somit drei Spalten: “Zu erledigen”, “In Bearbeitung” und “Erledigt”.
Beispiele für Kanban-Boards
Grundsätzlich gibt es zwei verschiedene Varianten eines Kanban-Boards: Physische und virtuelle.
Physische Kanban-Boards waren in der Frühphase des Konzepts der Standard. Sie bestehen im Wesentlichen aus einem Whiteboard oder einer Pinnwand, die, wie oben beschrieben, in Spalten aufgeteilt wird und an denen Karteikarten oder auch größere Papierblätter befestigt werden.
Sobald sich eine Änderung im Prozess ergibt, passen Mitarbeiter:innen die Karte auf dem Board an und machen die Veränderung damit für das gesamte Team sichtbar.
In modernen visuellen Boards findet die Darstellung innerhalb einer Softwareumgebung statt. GitLab zum Beispiel bietet im Rahmen seiner Issue-Boards eine Funktionalität an, Kanban in DevOps-Prozesse einzubinden.
Interessanterweise finden physische Boards auch heute noch Anwendung und daher empfehlen viele Expert(inn)en und Kanban-Coaches Unternehmen, bei der Umsetzung von Kanban mit einem solchen materiellen Brett zu beginnen. So schreibt das Fachmagazin IT-Agile in einem groß angelegten Spezial:
“Physische Boards machen vieles einfacher und transparenter. Elektronische Tools führen oft zusätzliche Komplexität ein, die von den eigentlichen Problemen ablenkt.”
Die Kanban-Methode als Veränderungs- und Verbesserungs-management
Mit Kanban zu arbeiten bedeutet, ein Kanban-Board zu verwenden und es fortlaufend zu aktualisieren. Dennoch entwickelte Ohno die Grundzüge von Kanban interessanterweise ohne ein Board. Das bedeutet:
Die Anwesenheit eines Boards deutet zwar in der Regel auf einen Kanban-Ansatz hin. Aber das Kanban-Verfahren ist, was die Theorie betrifft, auch ohne Board denkbar.
Ohno wollte Toyotas Organisation nicht radikal verändern, sondern sie vielmehr sanft und unter enger Mitarbeit aller Beteiligten erneuern. Dies spiegelt sich wider in einem Zitat von David J. Anderson:
“Kanban ist keine Ingenieursmethode oder Management-Methode. Es ist eine Technik, mit Veränderungen umzugehen. Es geht darum, Veränderungen zu provozieren und eine Kultur der ständigen Verbesserung zu erreichen.”
Diese Auffassung erklärt auch, warum Kanban mit einer Vielzahl verschiedener Philosophien kombiniert werden kann: Es diktiert nicht so sehr, wie ein Unternehmen geführt werden sollen. Es legt sich vielmehr über bereits bestehende Abläufe und macht sichtbar, wo Optimierungen möglich oder sogar erforderlich sind.
Worum geht es bei der Kanban-Methode?
Wer einmal in einer auf Kanban ausgerichteten Organisation mitgewirkt hat, wird den Flow-Charakter, der auf dem Board visualisiert wird, bemerkt haben: Teams benötigen hier kaum ein Einwirken von oben, organisieren sich innerhalb vorgegebener Einschränkungen selbst und kommen eigenständig zu Ergebnissen und Lösungen.
Diese Optimierung der Flow-Effizienz war auch genau der Punkt, der Taiichi Ohno am Herzen lag, als er für Toyota nach dem Zweiten Weltkrieg sein System entwickelte, um der japanischen Automobilindustrie den Anschluss an die westlichen Hersteller zu ermöglichen.
Damals wurden Prozesse oftmals zentral exakt vorgeplant, gerieten aber immer wieder aufgrund praktischer Probleme ins Stocken. Bei umfangreicheren Anpassungen mussten die Computer umprogrammiert werden, was bis zu zwei Wochen in Anspruch nehmen konnte.
Kanban war eine Methode, Prozesse am Laufen zu halten und “Work in Progress”, also unfertige Zwischenprodukte auf ein Minimum zu beschränken.
Prinzipien und Grundsätze: Wie funktioniert das Kanban-System?
Kanban sorgt für Ordnung, ist aber ungemein flexibel. Es hat einen sehr einfachen Aufbau, kann aber auch in großen, komplexen Unternehmen verwendet werden.
Trotzdem hat es nicht an Versuchen gemangelt, Kanban ein wenig genauer zu gliedern. So gibt es, je nach Autor(in), 6 „Kanban-Praktiken“, 4 „Kanban-Prinzipien“, 3 „Kanban-Agenden“ und 2 „Kanban-Regeln“.
Man braucht gewiss nicht alle zu kennen, um Kanban erfolgreich anwenden zu können. Die drei wichtigsten grundlegenden Prinzipien aus den genannten Grundsätzen lauten:
-
Visualisiere die Arbeit. Der Blick aus der Vogelperspektive lässt Strukturen erkennen. Er zeigt das, was Taiichi Ohno als “Verschwendung” bezeichnete, die im laufenden Betrieb, also bei der Arbeit, nicht erkennbar ist. Ohno bezog sich darauf mit seiner Anweisung, “das Verborgene sichtbar zu machen”. Erst die Visualisierung auf einem Kanban-Board sorgt für die Automatisierung der Prozesse, welche zu einem verbesserten Flow und erhöhter Effizienz führt.
-
Reduziere unfertige Zwischenprodukte auf ein Minimum. Bei Toyota in den 40ern bedeutete dies, erst dann mit der Arbeit an einem neuen Wagen zu beginnen, sobald eine bestimmte Anzahl von ihnen komplett abgeschlossen und bereit für den Verkauf waren. Zwischenprodukte halten den Flow auf und sorgen oftmals für hohe Kosten.
-
Bevor du alternative Konzepte ausprobierst oder Produkte änderst, fange mit deiner aktuellen Praxis an. Erst sobald du diese verbessert hast, wende dich neuen Ufern zu.
Kanban: Agile oder Lean?
Heute wird die Kanban-Methode oft durch die Linse der agilen Entwicklung betrachtet. Das ist verständlich, denn tatsächlich war es das agile Manifest aus dem Jahr 2001, das den Weg für den breiten Einsatz von Kanban in DevOps bereitete.
Doch ist Kanban bereits weitaus früher entstanden, weit früher auch als Konzepte wie das Wasserfallmodell, welches heute bereits als überholt gilt. Und in den Prinzipien und Regeln die Taiichi Ohno für Toyota aufstellte, spiegeln sich auch viele Grundsätze des Lean-Managements wider.
So ist es sicherlich richtig, Kanban als Teil beider Ansätze zu sehen. Der Just-in-Time-Ansatz rückt Kanban etwas näher an die agile Methodologie, der Grundsatz der sorgsamen Ressourcen-Nutzung eher in Richtung der Konzepte der Lean-Managements.
Man könnte auch sagen, dass Kanban einen Ausgleich zwischen den beiden Konzepten herstellt. Während Lean nämlich Perfektion und vollständige Informationen anstrebt, ist es bei Agile wichtiger, Dinge auch bei unvollständiger Datenlage zu tun und entstehende Schwierigkeiten durch Improvisation und Lösungen aus der Praxis heraus zu korrigieren.
Kanban erlaubt es, die Zwischenräume zwischen diesen Polen auszuloten und dabei zu individuellen Ansätzen zu gelangen.
Scrum vs. Kanban: Übersicht
Vielleicht fragst du dich nach dem, was du bis jetzt gelesen hast, ob eher Kanban oder Scrum für dein Unternehmen die richtige Wahl ist.
Diese Frage ist aber letzten Endes in dieser Form nicht zielführend. Denn sowohl Scrum als auch die Kanban-Methode schließen sich nicht gegenseitig aus und werden in der Praxis oft miteinander kombiniert.
Bei Scrum handelt es sich um einen Projektmanagement-Ansatz, bei dem Wissen (in der Form von Daten aus der Planung und dem Prozess) genutzt wird, um iterativ und über möglichst viele testbare Produkte den Kundennutzen zu maximieren.
Vergleichen wir Scrum vs Kanban, fällt schnell auf, dass die beiden nicht deckungsgleich sind. Die vier Prinzipien von Scrum sind „Transparenz“, „Inspektion“, „Adaptation“ und “Vertrauen”. Dem stehen die von David J. Anderson vorgegebenen Kanban-Werte der „Transparenz“, „Balance“ (Vermeiden von Ungleichgewichten) und „Kollaboration“ gegenüber.
Daraus wird direkt ersichtlich, dass Scrum mehr Wert auf Daten und Prozesse legt, während Kanban in erster Linie auf menschliche Zusammenarbeit setzt. Dennoch können die beiden Ansätze einander hervorragend ergänzen.
Scrum vs. Kanban: Unterschiede
Was ist der Unterschied zwischen Scrum und Kanban? Ein Kernunterschied besteht darin, dass du bei Kanban Prozesse tendenziell nicht terminierst. Der Flow soll zwar optimiert werden, doch die Fließgeschwindigkeit ergibt sich aus der Arbeitspraxis. Fixe zweiwöchige Sprints und ein eindeutiges Enddatum laufen dieser Idee zuwider.
Auch verlangt Scrum zwangsweise, dass Abläufe ein festes Raster haben. Sprints müssen nicht zwangsläufig einem Zwei-Wochen-Rhythmus folgen. Aber eine Vorgabe regelmäßiger Ziele ist sehr wohl erforderlich. Die Treffen dienen dabei sowohl dem Informationsaustausch im Team, als auch dazu, den Grad der Zielerreichung stets wieder aufs Neue zu determinieren.
Dennoch ist ein “Scrumban” möglich. Denn auch ein Scrum-Prozess lässt sich über ein Kanban-Board recht bequem abbilden. Werden die Spalten passend definiert, ist es sogar kaum von “konventionellen” Board zu unterscheiden.
Mit seiner Betonung empirischer Daten füttert Scrum das Kanban-Board mit wertvollem Feedback, welches hilft, den Flow weiter zu optimieren. Und dank seiner Reduzierung von Engpässen und Work in Progress sorgt Kanban für eine Organisation, in der Scrum optimal umgesetzt werden kann.
Scrumban erweist sich in der Praxis oftmals als schwierig. Aber das Gleiche gilt auch für Scrum, das sich durchaus nicht immer intuitiv in die meisten Organisationsstrukturen einfügt. Letzten Endes kommt alles auf die Umsetzung an.
Wann funktioniert Kanban nicht?
Wenn du darüber nachdenkst, was das Kanban-System ist, ist es leicht ersichtlich, dass es in jedem Unternehmen Anwendung finden kann. Aber nicht jedes Unternehmen ist bereit für Kanban.
Im direkten Vergleich zu Scrum fällt die Realisierung aber sicherlich weitaus leichter aus. Hier sind drei typische Gründe, warum die Implementierung von Kanban eventuell dennoch nicht funktioniert:
- Das Kanban-Projektmanagement ist für selbstorganisierende Teams entwickelt worden. Das bedeutet, dass die Mitarbeiter(innen) im Rahmen von Vorgaben operieren, die ihnen gestellt werden. Wenn diese Vorgaben nicht ausreichend genau ausfallen oder sogar unerwünschte Anreize vorgeben, kann sich Kanban nicht entfalten.
- Die Prozesse, die über die Kanban-Methode laufen, sollten immer wieder hinterfragt werden. Das gelingt beispielsweise mit einem externen Kanban-Coach, der/die mit seinen/ihren Impulsen Umsetzungsschwierigkeiten minimiert. Fehlt eine solche Bezugsperson, kommt es unter Umständen zu Kompetenzfragen, Zuordnungsproblemen oder einem Stocken des Flusses.
- Softwareentwicklung ist sehr dynamisch und die Bedingungen ändern sich nahezu täglich. In einem solchen Umfeld wird die Aktualisierung des Kanban-Boards zu einer Aufgabe, die eine Menge Ressourcen verlangt. Rob Williams hat dies folgendermaßen auf den Punkt gebracht: “Das größte Problem mit Kanban besteht darin, dass es für eine Welt entworfen wurde, in der Produkte nur ein einziges Mal den Prozess durchlaufen, wie beispielsweise bei einem Automobilhersteller. In der Software-Branche ist dies nahezu niemals der Fall.”
Gelegentlich sind die Erwartungen an die Kanban-Methode zu hoch. Wenn sich keine schnellen Erfolge in der Form von Kosteneinsparungen, höherer Innovation oder gesteigerten Umsätzen einstellen, liegt oft die Versuchung nahe, zu alten Gewohnheiten zurückzukehren.
Wie gliedere ich mein Kanban-Board?
Wie bereits erwähnt, besteht das klassische Kanban-Board aus nur drei Spalten: „To-do“, „In Bearbeitung“ und „Erledigt“.
Allerdings erlauben es alle gängigen Kanban-Boards, darunter auch die Issue-Boards von GitLab, die Spalten nicht nur anders zu benennen, sondern auch noch zusätzliche hinzuzufügen.
Frage dich dazu folgendes:
Ist das Hauptkriterium der zeitliche Ablauf?
Dann bist du mit einem klassischen Kanban-Board bestens beraten.
Für eine genauere Analyse des Status Quo kannst du diese Spalten nun genauer unterteilen. So ist es denkbar, zu bearbeitende Tasks danach zu gliedern, welche bereits begonnen wurden, aber aktuell nicht umgesetzt werden können (beispielsweise aufgrund von Lieferengpässen).
Du kannst das Board ebenfalls um eine Spalte mit freiem Brainstorming ergänzen. Nur die besten Ansätze werden in den To-do-Teil übernommen.
Arbeitest du auf eine Reihe von Events hin?
Dann hast du zwei Optionen. Lege entweder für jedes Event ein eigenes Board an.
Oder, wenn die Events eng miteinander verbunden sind, lege diese in ein geteiltes Board, in dem jedem Event eine eigene Spalte zugeteilt ist, die wiederum in verschiedene Unterspalten aufgeteilt ist.
So behältst du auch in der Gesamtplanung stets die Übersicht.
Liegt dein Schwerpunkt in der Softwareentwicklung?
In der Softwareentwicklung durchlaufen Produkte eine Reihe zusätzlicher Stadien. Hier kann es von Vorteil sein, diese festen Abläufe in Kanban abzubilden. Die Beraterin Danielle Berg nennt beispielsweise die folgenden Spalten:
- (Code-) Review
- Test (in unterschiedlichen Abstufungen)
- On-Hold (Projekte, die begonnen wurden, aber an denen aktuell nicht weitergearbeitet werden kann.)
Die Spalte “Test” kann sogar noch weiter untergliedert werden in:
- interne Prüfung,
- Prüfung beim/bei der Kunden(in),
- akzeptiert vom/von der Kunden(in).
In anderen Branchen können entsprechend Spalten wie “Konzept/Entwicklung” oder auch “Beschaffung” (entweder in der Form von Wartezeiten wegen Lieferengpässen oder, weil ein Produkt speziell angefertigt werden muss) sinnvoll sein.
GitLab-Issue-Boards und Kanban Projekt-Management
GitLab wurde zwar nicht als Kanban-Tool konzipiert. Aber aufgrund der engen Verwandtschaft zwischen DevOps und der Kanban-Methode bestand zwischen ihnen stets eine Verbindung. Gerade in der Softwareentwicklung kommen Kanban-Boards hervorragend zur Geltung.
Um von diesen Vorteilen auch in GitLab profitieren zu können, stehen dir unsere Issue-Boards zur Verfügung. Issue-Tracker ähneln in ihrem Aufbau Kanban-Boards, sind aber weniger auf den gesamten Workflow eines Projekts ausgerichtet, sondern zielen mehr auf die Lösung ganz konkreter Probleme und Bugs ab.
Die Überschneidungen aber sind offensichtlich. Daher wurden die GitLab-Issue-Boards um Features wie Roadmap Building erweitert, um eine volle Kanban-Funktionalität zu bieten.
Wie nutze ich GitLab-Issue-Boards für mein Kanban?
Um Kanban in GitLab zu nutzen, lege einfach in dem Issue-Tracker ein Board im Kanban-Stil an.
Dazu wählst du so viele Listen aus, wie du Spalten in deinem Kanban-Board wünschst. Das bedeutet in der einfachsten Variante die drei Spalten “To Do”, “In Bearbeitung” und “Erledigt”. Alternativ ist ein ebenfalls empfehlenswerter Aufbau die Vierteilung in “Backlog”, “In Bearbeitung”, “Wartet auf” und “Erledigt”.
Einzelne “Issues” (Aufgaben) entsprechen nun den Karten in einem Kanban-System. Sie können von den Anwender(inne)n oder Teams, die mit der Bearbeitung beauftragt sind, aus dem Backlog in die Bearbeitung gezogen und nach Beendigung in die “Erledigt”-Liste abgelegt werden.
Die Integration von Kanban in die GitLab-Issue-Boards wird ständig um neue Funktionen erweitert. So steht dieses Feature spezialisierten Kanban-Tools im Wesentlichen um nichts mehr nach.
Entwickelt von Entwickler(innen) für Entwickler(innen) liegt sein großer Vorteil darin, Development, Anforderungen, Dokumentation und CI/CD an einem Ort zu bündeln.
Ausführliche Informationen dazu findest du in unserem GitLab-Handbuch.
