Kanban – was ist das? || Agile Series – Episode 14

In diesem Artikel erklären wir dir was Kanban genau ist. Als erstes klären wir ob es sich dabei um eine Methodik oder ein Framework handelt, dann gehen wir auf die Prinzipien und Praktiken von Kanban ein und natürlich werden wir auch klären, wie ein Kanban Board aussehen kann.

In der letzten Folge haben wir das dritte Prinzip von DevOps (Third way of DevOps) erklärt. Wenn du verstehen willst, was das mit Experimenten, innovativeren Produkten  und Chaos Engineering zu tun hat, dann schau unbedingt hier vorbei.

Kanban – was ist das genau?

Als erstes möchten wir einmal grundlegend darauf eingehen, was Kanban eigentlich macht. Kanban unterstützt uns dabei die Arbeit sinnvoll zu managen, indem man einen holistischen Standpunk einnimmt und auf die eignen Services schaut und versucht diese zu verbessern. Ganz wichtig – verbessern aus der Kundensicht!

Kerngedanke hierbei ist es die, oft unsichtbare, Arbeit (z.B. in der Softwareentwicklung) zu visualisieren mit Hilfe eines Kanban Boards, auf das wir später noch zu sprechen kommen. Diese Visualisierung hilft uns dabei unser Unternehmen effektive zu halten und Risiken einfacher managen zu können, da wir diese so viel einfacher verstehen können.

Mit der Zeit kommt wird dein Unternehmen dadurch immer besser und schneller darin, auf die sich verändernden Kundenwünschen und -erwartungen, zu reagieren. Wie wir alle wissen ist das in dieser aktuellen VUCA Welt auch dringend nötig, um nicht abgehängt zu werden.

Oft wird Kanban nur in Verbindung mit einzelnen Teams gebracht und kann hier schon helfen wieder Kontrolle über die Arbeit zurückzubekommen, aber vor allem wenn man Kanban skaliert und z.B. auf den gesamten Value Stream anwendet, ergebt sich ein noch größerer Mehrwert.

Wir möchten jetzt noch kurz darauf eingehen, ob Kanban jetzt eigentlich eine Vorgehensweise, Methodik oder ein Framework ist.

Bei einer Vorgehensweise, wie der Name schon sagt, ist klar geregelt, wie man vorgehen muss. Daher kann eine Vorgehensweise immer nur spezifisch für eine Domäne funktionieren. Da Kanban aber auf fast jede Domäne angewendet werden kann, fällt das schonmal weg. Ein Framework benötigt noch Anpassung für das spezielle Umfeld und davon braucht Kanban nur sehr wenig, da die Grundprinzipien und -praktiken überall anwendbar sind. Bei Kanban handelt es sich also um eine Methodik und dabei geht es niemals um A oder B, also nie Scrum vs Kanban (und wie gut Scrum und Kanban zusammen funktionieren haben wir schon in diesem Artikel gezeigt 😉 ) oder irgend ein anderes Framework. Kanban ist immer eine Ergänzung zu einer aktuellen Arbeitsweise oder Framework.

Kanban dient also immer dazu zu verbessern was und wie man etwas macht und ersetzt nicht, was man gerade bereits macht!

Kanban kann daher also nicht nur auf Services im IT Sektor angewendet werden, sondern in nahezu allen Bereichen. Wichtig ist aber immer zu verstehen, dass Kanban on top einer bereits implementierten Arbeitsweise anzuwenden ist und diese dadurch verbessert.

Der Ursprung von Kanban:

Kanban kommt ursprünglich aus Lean Manufacturing und übernimmt viele dieser Grundgedanken von Lean, wie z.B. Fokus auf den Fluss der Arbeit, WIP-Limits,… Aber dazu kommen wir weiter unten noch genauer.

Die Kanban Methodik, wie sie hie beschrieben wird basiert auf folgendem Buch:

Einfach auf das Bild klicken* und direkt bestellen. Und das alles inklusive kostenlosem Versand innerhalb Deutschlands (ohne Mindestbestellwert) 😉 .

Die Grundprinzipien von Kanban

Hierbei muss man zwischen den Change Management Prinzipien und den Service Prinzipien unterscheiden.

Die Change Management Prinzipien sind für alle Kanban Implementierungen gleich und lauten:

• Beginn mit dem was du gerade schon anwendest (also der aktuellen Arbeitsweise)
• Verfolgt das gemeinsame Ziel der Verbesserung durch evolutionäre Veränderungen (wichtig ist, dass es nicht eine große Veränderung ist, sondern viel mehr viele kleinere Veränderungen)
• Ermutige Leadership auf allen Hierarchieebenen.

Es geht also auf keinen Fall darum eine, wie man so schön sagt, Big-Bang Veränderung (am besten Top-down angeordnet 🙁 ) durchzuführen, da das, wie die Vergangenheit oft gezeigt hat, nicht funktioniert. Es geht vielmehr darum sich evolutionär zu verbessern und dabei auf den aktuellen Gegebenheit aufzubauen. Wichtig hierfür ist regelmäßiges und offenes Feedback, das auch gehört wird und eine enge Zusammenarbeit auf allen Ebenen und auch über Ebenen hinweg. Nur so kann nachhaltig eine Verbesserung erzielt werden.

Die Erkenntnisse für diese evolutionären Verbesserungen stammen von den Menschen, die innerhalb dieses Kanban Systems arbeiten und Verantwortung und Führung (Leadership) übernehmen, um die aktuelle Arbeitsweise weiter zu verbessern. Unsere Erfahrung zeigt, dass das nur funktioniert, wenn man auch vom Management die entsprechende Unterstützung bekommt solche kleinen Änderungen durchzuführen. Denn man darf nie vergessen, dass die einzige Intension der Mitarbeiter hierbei ist, das Unternehmen zu verbessern und das sollte jedem Manager genauso am Herzen liegen.

Die Service Prinzipien lauten dahingegen:

• Verstehe die Kundenwünsche und –erwartungen und fokussiere dich darauf (extrem wichtig, um Erfolgreich zu sein bzw. zu bleiben)
• Manage the work [not the people]! Dazu gehört, dass sich die Mitarbeiter selbst organisieren dürfen
• Führe regelmäßig Reviews durch bezüglich der Services und Regeln, um die Ergebnisse zu verbessern (hört sich für mich wie „Inspect & Adapt“ an 😉 )

Wem bei „selbst organisieren“, „Review“ und „Inspect & Adapt“ nicht direkt Scrum einfällt, dem können wir nur wärmstens unsere Trainings zu Scrum empfehlen 😉 .

In unserer Arbeit mit Unternehmen merken wir, wie vor allem das erste Prinzip hier extrem wichtig ist (und damit auch die Arbeit eines guten Product Owners z.B.). Dieses Prinzip ist unserer Meinung nach eine Voraussetzung des 2. Prinzips, da man ohne klares Verständnis der Kundenwünsche bzw. –erwartungen gar nicht weiß, was gemacht werden muss und was nicht, wodurch sich häufige Änderungen und Verschwendung (unnötig entwickelte Features,…) ergeben, was zu Frustration führt.

Hat man das erreicht, so kann man sich darum kümmern die Arbeit zu managen/priorisieren, dass die Mitarbeiter sich auf die wichtigsten Themen fokussieren können. Wenn sich die Teams dann noch selbst organisieren können, um möglichst wenig Abhängigkeiten, Hand-offs, etc zu haben sind wir einem innovativen, erfolgreichen Unternehmen schon sehr nahe.

Und natürlich darf auch hier eine kontinuierliche Anpassung nicht fehlen, da sich die Umstände (Kundenwunsch, Teamzusammensetzung, Erfahrung,…) jederzeit verändern können und werden und darauf müssen wir schnell und regelmäßig reagieren können.

Bis man diese Prinzipien richtig anwenden kann, dauert es seine Zeit. Mit erfahrenen Coaches mit dem richtigen Mindset kann dies aber verkürzt werden. So können diese einen dabei unterstützen mehr kundenorientiert zu denken und eine entsprechende Kultur im Unternehmen zu fördern.

Die 6 Kanban Praktiken:

Im Nachfolgenden erklären wir dir die sechs Kanban Praktiken im Detail.

Visualisieren:

Hierbei geht es darum die Arbeit sichtbar darzustellen, z.B. auf einem Kanban Board, da häufig viele Arbeitsschritte versteckt und nicht transparent sind im Unternehmen (z.B. Refactoring, Koordinierungsaufgaben, Bug Fixing,…). Grund dafür ist, dass wir Menschen sehr visuell geprägt sind und diese Visualisierung eine effektive Zusammenarbeit und damit die Identifikation von Verbesserungsmöglichkeiten erst richtig möglich macht.

Ein weiterer Vorteil von Visualisierung ist, dass es die Zusammenarbeit deutlich vereinfacht, da alle das gleiche Bild vor Augen haben. Ich denke, dass jeder schonmal die Situation hatte, dass man eine Diskussion über ein komplexes Problem (z.B. Softwarearchitektur) geführt haben und dann jemand (z.B. der Scrum Master) auf die Idee kommt die Fragestellung bzw. Vorschläge zu visualisieren und man dann gerne sowas hört wie: „Oh. Das hatte ich aber anders verstanden.“, „Ah jetzt verstehe ich wie du das meinst“. Und am Ende sind alle dankbar, dass sich jemand die (meist) geringe Mühe gemacht hat das Thema zu visualisieren.

In Kanban wird hierzu häufig ein Kanban Board genutzt, auf dem die wichtigsten Prinzipien wie WIP-Limits, Richtlinien, etc visualisiert sind.

Kanban Board

Diese Praktiken können auch anhand eines Kanban Majurity Models implementiert werden. Wichtig, wie bei allen Majurity Models, ist zu verstehen, dass diese immer eine Vereinfachung darstellen und:

What you measure is what you get!

Es ist also Vorsicht geboten, bei dem was und wie man die Teams evaluiert und dass man keine falschen Belohnungssysteme dadurch kreiert (Stichwort lokale Optimierung 😉 ).

Work in Progress (WIP) limitieren:

Zuerst einmal müssen wir erklären, was Work in Progress (WiP) bedeutet. Work in Progress beschreibt alle Items, die zu einem bestimmten Zeitpunkt bearbeitet werden. Aber warum muss man die Anzahl an zu bearbeitenden Items pro Zustand (z.B. Entwicklung oder Deployment) limitieren?

Der Grund dafür ist einfach. Wenn alle Entwickler komplett voll beladen sind mit Arbeit, dann gibt es ja gar keinen Spielraum für Unvorhergesehenes bzw. Ungeplantes. Das heißt, dass jedes Item genau so lange dauern muss, wie geplant und dass nichts anderes dazwischen kommen darf (wie z.B. Fehler bei einer Migration, Bugs,…). Das ist in einem komplexen System, wie es jede Softwarentwicklung nunmal ist, eine mehr als unrealistisch Annahme.

Aber lasst uns das doch mit einer Metapher verdeutlichen. Nämlich die Metapher eines Staus auf der Autobahn. Am besten nutzen wir hier direkt das erste Prinzip von Kanban und visualisieren das ganze mit einem Bild, dass wir alle das gleiche vor Augen haben.

Kan-bahn Metapher

Wenn wir bei dieser Situation keine Tempo-Limit (das Äquivalent zu unserem WiP-Limit in Kanban) vor der Engstelle haben, werden die Entwickler, die an der Engstelle arbeiten (z.B. Testing, Deployment) immer mehr überladen und die Arbeit dieser Leute wird zum Flaschenhals. Was dann leider noch viel zu häufig passiert ist, dass dann Aufgaben parallel erledigt werden müssen. Das führt aber zu dem Problem der häufigen Kontextwechsel (Context-Switches), was die Erledigung jeder Aufgabe immer ineffizienter macht, je mehr Aufgaben dazukommen. In unserer Metapher gesprochen bedeutet das quasi, dass man zwischen jedem Spurwechsel 2 Minuten warten müsste.

Diese WiP-Limits sorgen dafür, dass diese Engstellen transparent gemacht werden und dann die Probleme beim Flaschenhals (z.B. zu langsame CI/CD-Toolchain) gelöst werden können.

Ein weiterer Vorteil ist, dass dadurch ein Pull-Sytem entsteht und nicht mehr ein Push-System. Das bedeutet, dass die Entwickler sich neue Arbeit holen, sobald sie die Kapazität dazu haben. Und nein dadurch wird nicht zwischendrin gechillt und Pause gemacht. Zumindest haben wir das noch bei keinem einzigen unserer Teams, die wir gecoacht haben, gesehen. Die genauen Vorteile hiervon und wie man das im Detail umsetzt werden wir auch noch in einem späteren Artikel erklären. Also Newsletter abonnieren nicht vergessen 😉 .

Das dritte Prinzip von Kanban – Den (Arbeits-)Fluss managen:

Das dritte Prinzip von Kanban bedeutet, dass man den Fluss der Arbeit so managen muss, dass die Arbeit so einfach und vorhersagbar wie möglich fertigstellen werden können sollte. Es also keine Wartezeiten, Flaschenhälse, Unklarheiten über Priorisierungen, etc. geben sollte. Das alles sollte unbedingt in einer Geschwindigkeit passieren, die man über lange Zeit aufrechterhalten kann. Wir beschreiben das immer sehr gerne mit folgendem Satz:

Härter Arbeiten skaliert nicht! Ich kann nicht die Geschwindigkeit beim Sprint auf einmal versuchen über die Distanz eines Marathons aufrechtzuerhalten.

Die im zweiten Prinzip dargestellten WiP-Limits sind eine Methode, um diesen Fluss aufrechtzuerhalten.

Mit den richtigen Metriken (wie Durchsatz (engl.: Throughput)) lässt sich das sehr gut handhaben. Ihr ahnt es schon, auch dazu wird es noch einen Artikel geben 😀 . Also gerne den Newsletter abonnieren.

Das vierte Prinzip von Kanban – Richtlinien klar darstellen:

Hierbei geht es darum, dass alle Richtlinien, die wir haben klar dargestellt und von allen gleich verstanden werden müssen. Das hilft uns dabei die zahllosen Entscheidungen, die jeden Tag getroffen werden, richtig zu treffen. Zusätzlich hilft das neuen Mitarbeitern zu verstehen, wie hier eigentlich gearbeitet wird. Dazu gehören z.B.:

• die WiP Limits
• Definitionen, wann eine Aufgabe wirklich abgeschlossen ist (ihr seht hier schon eine klaren Zusammenhang zur Definition of Done von Scrum 😉 )
• Meetingzeiten und Inhalt der Meetings
• Regeln für die Zusammenarbeit
• uvm…

All diese Richtlinien müssen für allen Beteiligten verständlich sein und von allen zugestimmt worden sein. Typischerweise stellt man diese Richtlinien neben dem Kanban Board des Teams dar und macht sie dadurch für alle transparent und passt diese regelmäßig an (das kommt mir irgendwie aus einem anderen agilen Framework bekannt vor 😀 …).

Jede Richtlinie sollte folgende Kriterien erfüllen:

• Einfach
• Klar definiert
• Sichtbar
• Auf das Wesentliche reduziert
• angewendet werden
• Veränderbar

Diese Richtlinien sind dazu da, alle in diesem Kanban-System zur Selbstorganisation (oder wie Scrum seit dem neuen Scrum Guide 2020 sagt „Selbstmanagement“) zu befähigen (engl.: enable). Das bedeutet auch die Verantwortlichkeit wichtige Entscheidungen zu treffen.

Das fünfte Prinzip von Kanban – Feedbackschleifen implementieren:

Auch Kanban benötigt funktionierende und regelmäßige Feedbackschleifen um die Arbeit zu koordinieren und den Service/System immer weiter zu verbessern. (Auch das kommt uns hoffentlich sehr bekannt vor aus DevOps und Scrum 😉 ). Diese Feedbackschleifen ermöglichen es aus unseren Fehlern zu lernen und uns stetig weiter zu verbessern.

Typische Feedbackschleifen von Kanban sind:

• das Kanban Board
• die Kanban Metriken
• Regelmäßige Meetings
• Reviews

Wer noch mehr zu Feedbackschleifen in Scrum oder DevOps verstehen will sollte unbedingt hier und hier vorbeischauen.

Das sechste Prinzip von Kanban – Zusammen besser werden durch Experimente:

Auch Kanban basiert auf kontinuierlicher Verbesserung und Anpassung. Allerdings wird hier noch stärker betont, dass wir diese Verbesserungen gemeinsam durch Experimente erreichen sollten. Hier kommt das fünfte Prinzip von Kanban zu tragen, denn regelmäßiges Feedback und Metriken, mit denen wir das Ergebnis des Experiments bestimmten können, sind hier extrem wichtig.

Diese regelmäßigen Experimente sollten früh passieren und „sicher“ (engl.: safe-to-fail) sein. Das heißt, dass man bei einem Experiment mit negativem Ergebnis schnell wieder zurückrollen (engl.: roll-back) können sollte auf den vorherigen Zustand.

Vielleicht sollten wir auch noch einen Artikel zu DevOps und Kanban schreiben?!… Schreib uns gerne in die Kommentare, wenn dich das interessieren würde 😉 .

Wer diese Grundgedanken von Kanban gerne kompakt in einem Buch nachlesen will, dem können wir folgende Lektüre wärmstens empfehlen.

Einfach auf das Bild klicken* und direkt bestellen. Und das alles inklusive kostenlosem Versand innerhalb Deutschlands (ohne Mindestbestellwert) 😉 .

Die Vorteile

Wir wollen hier nun nochmal die Vorteile von Kanban zusammenfassen.

Der holistische Ansatz von Kanban sorgt für eine Optimierung des gesamten Systems und skaliert mit der Größe des Systems (Team –> Teams –> Abteilungen –>…) und kann dabei immer on top der aktuellen Arbeitsstruktur angewendet werden. Für den maximalen Erfolg muss man die Prinzipien und Praktiken von Kanban verinnerlichen und leben. Dieser Wechsel ist ohne erfahrene Coaches von außen schwer, da man all zu gerne in alte Muster verfällt.

Durch die Visualisierung von Arbeit ergibt sich eine deutlich verbesserte Zusammenarbeit in Teams, zwischen Teams und auch zwischen Hierarchieebnen hinweg und ermöglicht dadurch eine deutlich schnellere Anpassung an sich verändernde Umstände. Dies führt zu innovativeren Produkten und reduzierten Kosten.

Zusammen mit dem klaren Fokus auf die Kundenwünsche und -erwartungen kann durch Kanban die Kundenzufriedenheit deutlich gesteigert werden.

Alles in allem hilft uns Kanban dabei unser Unternehmen effektiv zu führen und Risiken zu managen.

Um diese Vorteile messbar zu machen und um zu verstehen, ob eingeführte Änderungen sich positive oder negativ auswirken benötigen wir Metriken. So wird das ganze auch objektiv betrachtet. Was für Kernmetriken in Kanban wichtig sind werden wir dir noch in einem späteren Artikel genau erklären.

Also melde dich einfach direkt für den Newsletter an, um den Artikel nicht zu verpassen 😉 .

Fazit

Kanban ist eine sehr hilfreiche Methodik, mit vielen Vorteilen, die in einem Unternehmen, das im digitalen Zeitalter erfolgreich sein will, nicht fehlen sollte.

Da Kanban auf dem bestehenden System aufbaut, kann es in nahezu jedem Unternehmen eingeführt werden und es lassen sich dadurch die genannten Vorteile für das Unternehmen und die Mitarbeiter erzielen. Dabei gilt, je mehr Support und Offenheit für Kanban im Unternehmen herrscht, desto mehr Vorteile ergeben sich.

Voraussetzung dafür ist das Verständnis (z.B. durch gute Trainings), auf allen Ebenen im Unternehmen, für die Prinzipien, Praktiken und Metriken von Kanban, sowie eine gut Durchgeführte Transformation (was nicht mal eben in 90 Tagen passiert 😉 )!

Um diese Vorteile für unsere Kunden erreichen zu können, sind die Kanban Praktiken, Prinzipien und Metriken daher auch Teil unserer Digital Age Transformation.

Du willst noch mehr wissen und hast noch Fragen oder bist anderer Meinung?

Schreib uns das auch unbedingt in die Kommentare und wir werden dir gerne und ausführlich antworten!

Da das jetzt alles wieder sehr viel Input auf einmal war, haben wir eine einfache Übersicht über alles was zum Scrum Framework gehört, für dich in einem kostenlosen Poster dargestellt. Du findest es hier:

Damit du all die gelernten Begriffe auch schnell nachschauen kannst, haben wir dir zusätzlich einen kostenlosen Glossar auf Deutsch mit +230 Begriffen zu DevOps, Agile und Lean mit den entsprechenden englischen Fachbegriffen (macht das Googeln meist einfacher, da es noch sehr wenige vollständige deutsche Blogs zu diesen Themen gibt) erstellt.

Und auch der ist komplett kostenlos. Du findest den Glossar hier:

Ausblick

In der nächsten Folge erklären wir dir, was Shifting Left in DevOps bedeutet und wie du das auf dein Unternehmen/Situation anwenden kannst.

Falls du das nicht verpassen willst und ein noch besserer Scrum Master/Agile Coach/Product Owner/Entwickler oder Leader werden willst, melde dich jetzt für unseren kostenlosen Newsletter an:

Unser Podcast

Und falls du unsere Experteninterviews und alle anderen Podcast-Folgen als erster bequem unterwegs hören willst, abonnier einfach unseren Podcast mit folgendem RSS-Feed:

Podcast RSS-Feed

Unser YouTube-Channel

Du stehst auf bewegtes Bild und zusätzliche Grafiken und Visualisierungen? Dann ab auf unseren YouTube-Channel „Agile Coach Academy“.

Abonniere den Channel und verpasse kein Video oder Experteninterview mehr.

Wie immer freuen wir uns auch wenn du diesen Artikel mit deinen Freunden, Kollegen und Bekannten teilst und uns dein ehrliches Feedback in den Kommentaren schickst.

Wir freuen uns auf dich in der nächsten Folge.

Deine Agile Coach Academy Gründer Ben und Alex

Mit * markierte Links sind Affiliate-Links mit denen du uns unterstützt dir weiterhin so guten Content zu liefern.

Vielen Dank für deinen Support 🙂

Note: Wir gehen keine Affiliates mit Amazon ein (auch wenn es hier mehr Möglichkeiten gäbe für uns), da die Mitarbeiter hier nicht fair behandelt werden und wir das nicht unterstützen!