Wie funktioniert Scrum und Kanban zusammen? || Agile Series – Episode 13

In diesem Artikel erklären wir dir die wichtigsten Elemente von Kanban und von Scrum sind und wie diese zusammen funktionieren und was für Vorteile dadurch entstehen.

In der letzten Folge haben wir das 2. Prinzip von DevOps genau erklärt. Dabei geht es darum, dass man Feedbackschleifen aufbaut und so kurz wie möglich hält. Wenn du darüber mehr erfahren willst schau unbedingt hier vorbei falls du darüber mehr lernen willst.

Die 6 Grundprinzipien von Kanban

Kanban hat sechs Grundprinzipien, die dafür sorgen, dass die Umsetzung von Kanban möglichst erfolgreich ist.

Zusätzlich gibt es noch drei Change-Management Prinzipien und drei sogenannte Service-Delivery Prinzipien, auf die wir hier nicht eingehen werden, sondern in einem späteren Artikel. Also unbedingt den Newsletter abonnieren 😉 .

Das erst Prinzip von Kanban – Visualisieren:

Das erste Prinzip von Kanban heißt „Visualiseren„. Das klingt sehr einfach, ist aber essenziell um Erfolg zu haben, da Informationen, die keiner benutzt oder benutzen kann (weil sie viel zu kompliziert dargestellt sind oder niemand weiß wo die Informationen abgelegt sind) sind nunmal nutzlos. Vor allem in der Softwareentwicklung ist dieses Prinzip extrem wichtig, da Software an sich und ihr Zustand nunmal nichts physisches ist und daher nur schwer sichtbar ist, im Vergleich z.B. zur Fertigung eines Autos. Hier kann ich ja jederzeit sehen wo und wie weit ist das Auto, für das ich mich interessiere.

Kerngedanke hierbei ist es aber nicht nur die Arbeit, sondern auch den Fluss (Flow) der Arbeit darzustellen. Also von welchem Zustand (State) geht die Arbeit in welchen Zustand über. Dies ist sehr gut in folgender Darstellung zu sehen.

Beispiel Kanban Board

Ein weiterer Punkt der hier dazugehört ist es auch die Risiken zu visualisieren. Ich benutze dafür gerne in unseren Kanban Boards nicht nur die oben dargestellten Spalten sondern noch eine weitere Spalte mit dem Titel „At Risk“, also „gefährdet“. So können die Teams klar darstellen wo wir z.B. das Sprint Goal (für Scrum) oder die Service Level Expectations (SLE; für Kanban) nicht halten werden können. Diese Information ist dann klar und einfach verständlich für z.B. den Product Owner einzusehen und es können entsprechend Anpassungen vorgenommen werden.

Das zweite Prinzip von Kanban – Limit Work in Progress:

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

Wie funktioniert Scrum und Kanban zusammen?

Wer sich gut mit Scrum auskennt und die offensichtlichen Hinweise gesehen hat, dem sollte klar sein, dass es zwischen Scrum und Kanban sehr viele Gemeinsamkeiten gibt. Wer sich noch nicht so gut mit Scrum auskennt, dem kann ich nur unsere Trainings wärmstens ans Herz legen 😉 .

Aber wir wollen hier ja alle abholen und ein möglichst großes Verständnis für all diese Frameworks schaffen und stellen deshalb hier klar dar, wie Scrum und Kanban zusammen funktionieren.

Zu Kanban gehört die Definition des Workflows, die gewisse Ähnlichkeiten zur Definition of Done aus Scrum ist. Diese sollte während der Retrospektive betrachtet und entsprechend angepasst werden. Zu dieser Definition of Workflow gehören:

• Visualisierungsrichtlinien, wie wir das oben in dem Kanban-Board beispielhaft dargestellt haben. Hier erkennt man die deutliche Ähnlichkeit zum Scrum-Board, nur dass hier noch die WiP-Limits und zusätzliche Zustände (wie z.B. Entwicklung abgeschlossen) für noch mehr Transparenz sorgen.
• Arbeitsrichtlinien, die direkt Impediments (z.B. aus der Scrum Retrospektive) angehen. Z.B. die Änderung der WiP Limits oder der Service Level Expectations (SLEs).

Das Gute wenn man Scrum und Kanban kombiniert ist, dass man kein einziges zusätzliches Meeting benötigt. Das ist immer der Moment für den alle Entwickler sehr dankbar sind und erleichtert aufatmen in den Trainings und Workshops 😀 .

Während des Sprints:

Teams die Scrum und Kanban benutzen nutzen den Sprintzyklus (in Kanban oft als Kadenz bezeichnet), um die Definition des Workflows und die entsprechenden Metriken gemeinsam anzupassen.

Während des Sprint-Plannings:

Während des Sprint-Plannings helfen uns die Metriken aus Kanban den Sprint Backlog zu erstellen. So kann zum Beispiel der vergangene Durchsatz verwendet werden, um die Kapazität der Teams für den nächsten Sprint besser abschätzen zu können.

Während des Daily Scrum:

Hier wird das Daily um den Gedanken der Flussoptimierung und -konstanz ergänzt. Dazu wird natürlich nicht ein Scrum-Board und ein Kanban-Board verwendet, sondern eigentlich immer nur das Kanban-Board, da dieses mehr Informationen enthält (es wird also kein zusätzliches Scrum Board benötigt). Man fokussiert sich also darauf, wo der Fluss noch nicht perfekt ist und was man dagegen tun kann. Potentielle Fragen während des Dailies können sein:

• Welche Items sind blockiert und was können wir dagegen tun?
• Welche Items kommen langsamer voran als gedacht?
• Haben wir in der Zwischenzeit (seit dem Planning oder dem letzten Daily) etwas gelernt, das eine Änderung des Plans/Priorisierung nötig macht?

Während des Sprint-Reviews:

Es können sehr hilfreiche Diskussionen ergeben, wenn man im Review die Kanban Metriken genauer anschaut. So können wir z.B. anhand des Durchsatzes potenzielle Auslieferungstermine berechnen (Vorsicht: Das ist nur eine Vorhersage und keine Deadline!), die wir an die Stakeholder oder Nutzer weitergeben können.

Während des Sprint-Retrospektive:

Hier werden zusätzlich noch die Kanban Metriken betrachtet, um weitere Verbesserungsmöglichkeiten zu finden. Wie auch die Definition of Done sollte auch die Definition of Workflow spätestens hier betrachtet und gegebenenfalls angepasst werden.

Das Inkrement:

Ziel ist es natürlich weiterhin spätestens am Ende eines jeden Sprints ein nutzbares, wertschaffendes Inkrement zu haben. Kanban hilft hierbei den Fluss und Feedback noch besser zu managen, sodass das Team Flaschenhälse, andere Einschränkungen oder Impediments früher findet und damit auch schneller und kontinuierlicher Wert liefern kann.

Vorteile, wenn man Scrum und Kanban kombiniert:

Einer der großen Vorteile, wenn man Scrum mit Kanban kombiniert (gerne als Scrumban bezeichnet) ist, dass durch die Erweiterung des Scrum Frameworks um den Gedanken des Flow-based Arbeitens weitere Probleme im System/Unternehmen früher aufgedeckt und schneller, einfacher gelöst werden können.

Wenn man also das Scrum Framework um die Kanban-Prinzipien erweitert, bekommt man noch einen klareren Fokus auf über den Fluss der Arbeit durch das gesamte System und optimiert dabei auch noch die Transparenz, Verantwortlichkeiten der Mitarbeiter und Kollegen sowohl für das Produkt als auch den Prozesse.

Kurzgesagt:

Die Flow-Based Perspektive und Metriken von Kanban ergänzen Scrum perfekt und verstärken sogar noch den Gedanken der Empirie von Scrum.

Um diese Vorteile nutzen zu können braucht man natürlich Mitarbeiter, die in den entsprechenden Frameworks trainiert sind und die Gründe für die Prinzipien verstanden haben oder natürlich erfahren Coaches, die einem dabei helfen können 😉 .

Fazit

Wie du sicher klar gesehen hast, hat die Kombination von Scrum und Kanban viele Vorteile, ohne dabei groß neue Meetings und damit Komplexität einzuführen. Hierbei ist das Konzept des Flusses (Flow) eine super Ergänzung für die Umsetzung von Scrum. Aber wie auch bei Scrum ist es bei Kanban und vor allem bei der Kombination aus beiden sehr wichtig, ein Verständnis für die Prinzipien zu haben und warum diese wann eingesetzt werden. Denn es gibt auch hier genug Fallstricke wie in Scrum auch.

Voraussetzung dafür ist aber wieder ein Verständnis, auf allen Ebenen im Unternehmen, für die Prinzipien von sowohl Kanban als auch Scrum!

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 Rahmenwerk 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 das dritte Prinzip von DevOps ist und was es bedeutet kontinuierlich zu lernen und sich zu verbessern.

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