Kanban-Board
Share ZU:
9 June 2020 @ Bertil Muth

Kanban und was es für die agile Entwicklung bedeutet

Kanban wurde in der japanischen Automobilindustrie in der ersten Hälfte des 20. Jahrhunderts erfunden. Inspiriert davon, wie Supermärkte ihre Regale nachfrageorientiert bestücken, war es das Ziel von Toyota, die Lagerbestände zu reduzieren und den Flow im gesamten Produktionssystem zu verbessern.

In seinem Buch Kanban: Successful Evolutionary Change for Your Technology Business beschrieb David Anderson, wie man die Kanban-Prinzipien auf die Software-Entwicklung anwendet. Diese Prinzipien sind:

  • Beginnen Sie mit dem, was Sie jetzt tun.
  • Vereinbaren Sie inkrementelle, evolutionäre Veränderungen.
  • Respektieren Sie den aktuellen Prozess, Rollen, Verantwortlichkeiten und Titel.

Was bedeutet das für die agile Entwicklung?

In meinen Kursen frage ich die Teilnehmer, was sie bereits über agile Entwicklung wissen. Häufige Antworten sind: “In Sprints arbeiten”, “Es gibt einen Product Owner”, ” User Stories in einem Backlog verwalten”. Die Teilnehmer sind von dem heute wohl populärsten agilen Framework, Scrum, geprägt.

Scrum kommt mit seinen eigenen vordefinierten Rollen, Ereignissen und Artefakten. Scrum verlangt, dass Sie die im Scrum Guide definierten Regeln befolgen, wenn Sie das, was Sie tun, Scrum nennen wollen. Kanban ist anders.

Kanban beginnt mit dem Prozess, den Sie jetzt in Ihrem Unternehmen anwenden. Visualisieren Sie die Schritte auf einem Kanban-Board. Sie können alles beinhalten, was Sie tun, von der Idee bis zum Release.
Jeder Schritt wird zum Titel einer Spalte auf dem Board.

Um Ihre alltägliche Arbeit zu verfolgen, ist es am besten, sie in kleine Elemente zu zerlegen. Vielleicht User Stories, die in höchstens 2 Tagen implementiert werden können. Schreiben Sie jedes Element auf ein Post-It und hängen Sie es an das Board. Sie können die vertikale Reihenfolge auf dem Board zur Priorisierung verwenden.

Die Karten bewegen sich von links nach rechts. Die Personen, die die Arbeit erledigen, ziehen Elemente, die durch den vorherigen Prozessschritt beendet wurden, in ihre Spalte. Wenn sie Zeit haben, dies zu tun. Die Entwickler im Beispiel ziehen also die Bild-Hochladen-Karte in die Entwicklung-Spalte, wenn sie die Zeit haben, sie zu implementieren.

Schrittweiser, evolutionärer Wandel

Sie haben also ein Kanban-Board erstellt, das Ihren Prozess zeigt? Sie machen Ihre Arbeit sichtbar, das ist ein guter Anfang!

Um die Vorteile von Kanban nutzen zu können, müssen Sie noch einige weitere Dinge tun:

  • Unfertige Arbeit und Warteschlangen begrenzen
  • Den Flow beobachten und verbessern
  • Effektiv zusammenarbeiten

Unfertige Arbeit und Warteschlangen begrenzen

Unfertige Arbeit begrenzen bedeutet: Sie legen ein Maximum für die Anzahl der von Ihnen bearbeiteten Elemente fest. Dies wird als Work-in-Process-Limit oder kurz WiP-Limit bezeichnet. Hier sehen Sie das Kanban-Board mit einem WiP-Limit für einige Prozessschritte.

Die Entwickler können an 5 Elementen gleichzeitig arbeiten. Höchstens. Wenn ihre Spalte 5 Elemente enthält, ist es ihnen nicht mehr erlaubt, Elemente zu ziehen. Dies hat zwei Konsequenzen.

Zunächst einmal: Es ermutigt die Menschen, ihre Arbeit abzuschließen, anstatt mehr Arbeit anzufangen. Angefangene Arbeit, die nicht beendet wird, birgt Risiken. Wie glücklich werden Ihre Kunden sein, wenn Sie Ihre Software nicht wie geplant ausliefern können? Weil Sie angefangen haben, an all diesen großartigen Ideen zu arbeiten, sie aber nicht zu Ende geführt haben?

Die zweite Folge der Begrenzung von Work-in-Process: Engpässe werden sichtbar. Wenn ein Prozessschritt Arbeit beginnt, die er nicht abschließen kann, werden die Menschen dies sofort spüren. Denn der nächste Prozessschritt wird nicht in der Lage sein, Elemente zu ziehen.

Neben der Begrenzung der unfertigen Arbeit sollten Sie auch die Größe der Warteschlangen begrenzen. In der obigen Tafel sind sie als gestrichelte Linien zwischen den Spalten dargestellt. Dies funktioniert auf dieselbe Weise wie die Begrenzung der unfertigen Arbeit.

Zusammengefasst: Stop Starting, Start Finishing ist das Motto. Vom Konzept bis zur Auslieferung in möglichst kurzer Zeit.

Den Flow beobachten und verbessern

Engpässe zu bemerken kann unangenehm sein. Aber zumindest wissen Sie dann, wo in Ihrem Prozess die Hauptprobleme liegen. Und Kanban ermutigt Sie, den Flow durch die Beseitigung des Engpasses zu verbessern. Ein konsistenter Flow ermöglicht es Ihnen, zuverlässiger zu liefern, und das ist gut für alle Beteiligten, einschließlich der Entwickler.

Um den Flow zu beobachten, erfassen Sie den Zeitpunkt, zu dem eine Karte in einen Prozessschritt eintritt. Und den Zeitpunkt, zu dem Sie den Prozessschritt abschließen. So wissen Sie, wie viel Zeit die Karte in jedem Schritt und in jeder Warteschlange zwischen den Schritten verbringt.

Auf der Grundlage der Daten können Sie Metriken erstellen, die Ihnen helfen, den Flow zu verbessern. Zu den gängigen Metriken gehören:

  • Cycle time: die Zeit, die eine Karte vom Beginn der Arbeit eines Teams an ihr (d.h. Entwicklung) bis zur Auslieferung (d.h. Release) benötigt. Die Verbesserung dieser Metrik kann Ihnen helfen, Ihre Time-to-Market zu verkürzen.
  • Durchsatz: die Anzahl der Karten, die sich in einer bestimmten Zeit durch das System bewegen. Die Verbesserung dieser Kennzahl kann Ihnen helfen, die Leistung Ihrer Entwicklungsorganisation zu verbessern.

Eine übliche Methode, sich einen Überblick darüber zu verschaffen, wie viele Karten sich in welchem Prozessschritt im Laufe der Zeit befinden, ist ein kumulatives Flussdiagramm. Im Idealfall bleibt die Anzahl der Karten in jedem Schritt bis auf die letzte Karte im Laufe der Zeit ungefähr gleich. Die Anzahl der ausgelieferten Karten sollte steigen. Wenn das Diagramm davon abweicht, kann es zu einem Engpass kommen.

Cumulative Flow Diagram

Effektiv zusammenarbeiten

Die Kanban-Metriken sind ein leistungsstarkes Werkzeug zur Analyse und Verbesserung Ihrer Arbeit. Aber sie sind wertlos ohne die Menschen, die die Arbeit tun. Jeder, der an den Prozessschritten beteiligt ist, sollte offen sein für die Transparenz, die Kanban schafft.

Die Menschen sollten konstruktiv zusammenarbeiten, um Engpässe zu beseitigen, anstatt Einzelpersonen die Schuld zu geben. Schauen Sie sich regelmäßig den aktuellen Stand an. Gibt es irgendwelche Engpässe? Steht für einen bestimmten Prozessschritt zu viel oder zu wenig Arbeit zur Verfügung? Ist der Durchsatz ausreichend? Gibt es andere Quellen der Unzufriedenheit? Was muss verbessert werden?

Vereinbaren Sie Experimente, die kleine Änderungen am System ausprobieren. Nehmen Sie die Änderungen vor. Schauen Sie später, ob die Experimente wie erwartet funktioniert haben. Um die Änderungen umsetzen zu können, ist die Unterstützung durch das Management oft entscheidend.

Wann sollte Kanban verwendet werden?

Kanban ist sehr flexibel. Es kann in Kombination mit Scrum verwendet werden, was als Scrumban bezeichnet wird. Es kann auch außerhalb der Produktentwicklung eingesetzt werden. Sie können es sogar verwenden, um eine Reise zu planen oder zu organisieren, was Sie in Ihrer Freizeit tun.

Ich fand Kanban besonders dann hilfreich, wenn die Arbeit in Scrum Sprints nicht möglich oder schwierig ist. Beispiel: zwei Unternehmen, bei denen das eine Kunde und das andere Lieferant ist, und eine Übergabe unvermeidlich ist. Ein anderes Beispiel ist, wenn Sie an einem Produkt arbeiten, das sowohl Software als auch Hardware umfasst, und mehrere Engineering-Disziplinen beteiligt sind.

Kanban kann auch innerhalb Ihres Unternehmens eingesetzt werden, wenn die Entwicklung agil verläuft, aber nicht der gesamte Rest des Unternehmens. Es kann verwendet werden, um die Zusammenarbeit zwischen strategischer Planung und Softwareentwicklung zu erleichtern.

Glauben Sie nicht, dass es keine Möglichkeit gibt, agiler zu werden, nur weil Sie Probleme bei der Implementierung von Scrum haben. Kanban beginnt mit dem, was Sie jetzt tun. Und wenn Sie es ernst nehmen, wird es Ihnen helfen, sich zu verbessern. Ein kleiner Schritt nach dem anderen.

Bertil Muth

Kontaktieren Sie Bertil Muth

Bertil Muth arbeitet als Agiler Coach, Scrum Master und Trainer. Mit Leidenschaft setzt er sich für konstruktive Zusammenarbeit, dezentralisierte Entscheidungsfindung und technische Exzellenz in der Produktentwicklung ein.