# Kanban

## Vor dem eigentlichen Thema... Workshop! 

## Lernziele

* Grundlegende Konzepte hinter Kanban **kennen lernen**
* Unterschiede (Vor- und Nachteile) gegenüber anderen agilen Ansätzen **verstehen**
* **Verstehen** wann Kanban vorzugsweise eingesetzt werden kann

## Kanban Ursprung

* Jap. *kan* 看 (sichtbar) und *ban*  板 (Karte o.d Brett)
* Konzepte entstammen dem Toyota Production System (TSP)
* Konkret: Just-in-Time Scheduling System
  * Nur »machen« was benötigt wird
  * Nur »machen« wenn es benötigt wird
  * Nur »machen« wieviel benötigt wird

Kanban System wurde sowohl für die Produktion als die Software Entwicklung adaptiert.

## Toyota Kanban

> The kanban, a tool that describes **which and how many parts are used where and when, made just-in-time production possible**. The new kanban management system was adopted at all plants in 1963. By producing parts in accordance with the instructions on the kanban, **parts are delivered among the different plants only in the volumes needed, and inventories within each process can be eliminated**. As kanban came into widespread use, problems such as standardization of work and transport management were resolved one after another and production lines operated smoothly.

Quelle: [Toyota](https://www.toyota-global.com/company/history_of_toyota/75years/text/entering_the_automotive_business/chapter1/section4/item4.html)

## Drei Prinzipien

* Visualize
* Limit Work in Progress
* Manage Flow

## Visualisieren - Dass Kanban Board

* **Information Fridge**
  * Muss immer wieder geöffnet werden, um nachzuschauen ob „etwas Neues drin ist“
  * Klassische Ticket-Systeme, digitale Boards etc.
* **Information Radiator**

  * Große sichtbare Displays
  * Für das eigene Team und alle Interessierten
  * Aktualisierungen möglichst einfach halten
  * So groß wie möglich!!!
  * »Use it or lose it!«

  <figure><img src="https://1352029815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FobQn6v8Z1iiTuGdkOJUH%2Fuploads%2FeDpNn2rf9cDrDTYboje8%2Fdevops.04.board.jpg?alt=media&#x26;token=49b66f74-f7a1-4ce9-9134-23fd373d64ec" alt=""><figcaption><p>Rakuten Inc., <a href="https://commons.wikimedia.org/wiki/File:Lean_Kanban.jpg">https://commons.wikimedia.org/wiki/File:Lean_Kanban.jpg</a>, CC BY-SA 3.0 (<a href="https://creativecommons.org/licenses/by-sa/3.0">https://creativecommons.org/licenses/by-sa/3.0</a>)</p></figcaption></figure>

## Kanban Board - Tipps

* Große Boards verwenden (s. Information Radiator)
* Digitale und physische Boards haben beide Vor- und Nachteile
* Bei ungeübten Teams möglichst physische Boards nutzen
* Regelmäßige Stand-Ups (Daily Stand-Up)
* Den Workflow anpassen, das Board reflektiert den aktuellen Workflow im Team
* Der Workflow kommt nicht vom Management, sondern vom Team
* Nicht zu viele Gedanken machen, Änderungen willkommen heißen

## Kanban Board - Beispielaufbau

<figure><img src="https://1352029815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FobQn6v8Z1iiTuGdkOJUH%2Fuploads%2FsyRzaUtbqP5v6jrvCt6q%2Fdevops.04.board_aufbau.png?alt=media&#x26;token=e4c20ac5-44c6-456b-8433-2e976c6fb8e6" alt=""><figcaption><p>Kanban Board - Beispielaufbau</p></figcaption></figure>

## Enter & Exit Critera

<figure><img src="https://1352029815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FobQn6v8Z1iiTuGdkOJUH%2Fuploads%2FWuTdZIcJ7sNADEdiVD8m%2Fdevops.04.enter_exit_criteria.png?alt=media&#x26;token=684bd433-71ab-44df-90b1-e78ce0039898" alt=""><figcaption><p>Enter &#x26; Exit Criteria</p></figcaption></figure>

## Priorisierung

* Anders als in Scrum:
  * Priorisierung kann fortwährend erfolgen täglich, u.U. auch wöchentlich oder zwei-wöchentlich
* Reihenfolge der Tickets am Board spiegelt die Priorität wider:
  * Es wird immer das am höchsten priorisiertes Ticket gezogen
  * No-Go: Ticket ziehen, das einem am meisten Spaß macht

## Work in Progress

* Abk.: WiP
* Beinhaltet alle begonnen aber noch nicht abgeschlossenen Aufgaben
  * Auch alle Aufgaben, an denen gerade nicht gearbeitet wird
  * Auch alle Aufgaben, für die gerade auf Zuarbeit geartet wird
* WiP-Limit
  * Anzahl an gerade in Bearbeitung befindlicher Aufgaben limitieren
  * Anzahl der Tickets
  * Typischerweise pro Spalte (in Bearbeitung, Test, Abnahme etc.)
* <br>

## Little's Law

* Ursprung: John D.C. Little
  * In den 1950ern einfach angenommen
  * Erst Ende der 1960er bewiesen
* Bedeutung: Je mehr gleichzeitig bearbeitet wird, desto länger dauert die Fertigstellung aller »Work Items«

<figure><img src="https://1352029815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FobQn6v8Z1iiTuGdkOJUH%2Fuploads%2F9Mhm7i7Iy4HYFA7huLFi%2Fdevops.04.littleslaw.png?alt=media&#x26;token=acbf05da-58b8-47d3-abbf-2130c403138f" alt=""><figcaption></figcaption></figure>

## Auswirkung von Parallelität

<br>

<figure><img src="https://1352029815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FobQn6v8Z1iiTuGdkOJUH%2Fuploads%2FlB9V0j4bUSAwJaAxEeBh%2Fdevops.04.parallelitaet.png?alt=media&#x26;token=b246927c-c94b-4fb0-a1cf-c94c4cac49a3" alt=""><figcaption></figcaption></figure>

## Auswirkung von WiP-Limits

<figure><img src="https://1352029815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FobQn6v8Z1iiTuGdkOJUH%2Fuploads%2FyESHF4j5uRcYhbsRc4RB%2Fdevops.04.sequentiel.png?alt=media&#x26;token=b33cb45d-3ec3-464d-9997-a5920a3667b9" alt=""><figcaption></figcaption></figure>

## WiP-Limit Wisdoms

* Es gibt keine »goldene Regel«
* Beobachten und anpassen
* Guter Ansatz: »Stop starting, start finishing «
* Beispiel 1: Um Pairing zu forcieren kann ein WiP-Limit von *Teamgröße−1* gewählt werden
* Beispiel 2: Existieren z.B. externe Abhängigkeiten (=Wartezeiten) kann ein WiP-Limit von *Teamgröße\*2* gewählt werden um Wartezeiten (engl. idle time) zu vermeiden
* Beispiel 3: …

## Praxis Tipps

* Durchsatz erhöhen
* Verschwendung (jap. *muda* 無駄) z.B. durch Wartezeiten oder Blocker vermeiden
* Probleme schnell lösen
* Kanban ermöglicht häufig Priorisierung (signifikanter Unterschied zu Scrum)
* Geeignet für kleine und bekannte Arbeitseinheiten (z.B. im Ops-Umfeld)
* Schlechter für Entwicklung, da Aufgaben geschätzt werden müssen
* WiP-Limits einhalten

<br>

<br>

\
\ <br>