Kanban: Vorteile, Prinzipien und Praktiken des Vorgehensmodells

Was ist Kanban? Eine kompakte Definition

Kanban ist ein Vorgehensmodell zur Steuerung von Arbeitsprozessen und Aufgabenmanagement. Ursprünglich in der Automobilindustrie bei Toyota eingeführt und als System in der Softwareentwicklung weiterentwickelt, hat sich Kanban mittlerweile in verschiedenen Branchen und Arbeitsumgebungen als effektives Modell zur Verbesserung von Arbeitsabläufen etabliert.

Die Idee hinter Kanban ist es, den Arbeitsfluss sichtbar zu machen. Viele Teams und Unternehmen nutzen hierfür ein Kanban-Board, das sich als zentrales Werkzeug des Frameworks etabliert hat. Auf diesem Board visualisieren Teams ihre Aufgaben in Form von Karten oder Post-its. Diese Karten repräsentieren die zu erledigende Arbeit. Sie werden in Spalten auf dem Board platziert, die den verschiedenen Stadien des Arbeitsprozesses entsprechen, im einfachsten Fall z.B.  „To Do“, „In Bearbeitung“ und „Fertig“. Je nach Arbeitsschritt wandern die einzelnen Karten von Spalte zu Spalte, bis sie abgeschlossen sind und in „Fertig“ landen.

Das Ziel von Kanban ist es, den Fluss der Arbeit zu optimieren, indem

• Engpässe identifiziert und beseitigt,
• die Durchlaufzeit verkürzt und
• die Qualität verbessert werden.

Durch die klare Visualisierung des Arbeitsprozesses erkennen die Teammitglieder schnell, wo sich Engpässe oder Blockaden befinden und können entsprechend handeln.

Kanban zeichnet sich durch seine Einfachheit und Flexibilität aus. Das Vorgehensmodell lässt sich leicht an die Bedürfnisse und Anforderungen unterschiedlicher Teams und Projekte anpassen. Mit Kanban arbeiten Teams kontinuierlich an der Verbesserung ihrer Arbeitsprozesse.

Kanban basiert auf dem Pull-Prinzip: Die Teammitglieder „ziehen“ sich ihre Aufgaben und beginnen mit der Arbeit. Aufgaben werden nicht von einer Führungskraft delegiert.

Die Ursprünge von Kanban

Im Oktober 2004 bat Dragos Dumitriu, IT-Manager bei Microsoft, David J. Anderson um Hilfe: Dumitrius Team „XIT Sustaining Engineering“ war eines von acht Microsoft-IT-Teams in Indien – und das mit der schlechtesten Performance. Die Bearbeitungszeit für eine Aufgabe betrug 5 Monate. Das Team konnte so gut wie keine Deadlines einhalten und das Backlog – eine priorisierte Liste anstehender Aufgaben – quoll über mit unerledigten Anfragen.

David J. Anderson arbeitete zu dieser Zeit ebenfalls in der Microsoft-IT. Er entwickelte für XIT Sustaining Engineering das erste Kanban-System für die Softwareentwicklung. Zwar nannte er es damals noch nicht Kanban, das wichtigste Element war jedoch schon vorhanden: Die Arbeit des Teams sollte sichtbar gemacht werden, damit es gemeinsam seine Arbeitsprozesse kennenlernen und verbessern konnten.

So schaffte es das zuvor völlig überlastete Team innerhalb eines Jahres, seinen Workflow so zu optimieren, dass es zeitweise keine Aufgaben mehr im Backlog hatte. Es steigerte seine Produktivität um 155 Prozent, reduzierte die durchschnittliche Durchlaufzeit auf fünf Wochen und erhöhte die Kundenzufriedenheit mit einer Termintreue von 90 Prozent.

Das Team hatte kein zusätzliches Budget, keine weiteren Ressourcen oder neue Kolleg*innen zur Verfügung. Sie arbeiteten auch nicht schneller, machten keine Überstunden oder mehr gleichzeitig. Der Schlüssel war, dass sie ihren Arbeitsfluss transparent und sichtbar gemacht haben. So konnten sie den Prozess optimieren und bessere Ergebnisse erzielen.

David J. Anderson gilt mit seiner Einführung im indischen Microsoft-Team als Begründer des Kanban-Frameworks in der Softwareentwicklung. Er veröffentlichte 2010 sein erstes Buch über das Vorgehensmodell und ist Gründer der David J. Anderson School of Management im spanischen Bilbao sowie der Kanban University in Seattle, USA. Anderson leitete das Kanban-Framework aus dem Toyota-Produktionssystem ab, das bereits in den 1940er-Jahren bei dem japanischen Automobilhersteller zum Einsatz kam und der Vorläufer des heutigen Kanban-Systems ist.

Kanban vs. Scrum

Kanban ist neben Scrum das wahrscheinlich bekannteste agile Framework. Beide Modelle basieren auf ähnlichen Prinzipien und Werten. Es gibt Organisationen, die sie kombinieren und beispielsweise Elemente von Kanban auch in ihren Scrum-Teams einsetzen: Das visuelle Board zur Organisation und Verfolgung von Aufgaben und Arbeitsschritten ist hier wohl das prominenteste Beispiel. Darüber hinaus ist in den letzten Jahren mit Scrumban eine Mischform entstanden, die das Beste aus beiden Frameworks vereint.

Es gibt jedoch einige zentrale Unterschiede: Scrum basiert auf Sprints. Das Team erledigt bestimmte Arbeitsaufgaben innerhalb eines festgelegten Zeitraums. Kanban hingegen ist ein kontinuierlicher Prozess, bei dem das Team die Arbeit fortlaufend in kleinen Schritten durchführt. Mit anderen Worten: Scrum basiert auf einem zeitlich begrenzten Arbeitszyklus, während Kanban einen kontinuierlichen Workflow unterstützt.

Ein weiterer Unterschied besteht in der Rollenverteilung und der Teamstruktur. Bei Scrum gibt es klare Rollen wie Product Owner, Scrum Master und Entwicklungsteam, die bestimmte Aufgaben und Verantwortlichkeiten haben. Kanban hingegen hat keine festen Rollen und das Team ist flexibler in der Zusammenarbeit und Aufgabenverteilung. In der Einführungsphase kann jedoch ein Agile Coach das Kanban-Team unterstützen.

Während Scrum einen Rahmen für die Zusammenarbeit vorgibt, fokussiert Kanban sich mehr auf die Optimierung der Arbeitsprozesse. Scrum stellt den Mehrwert für die Kund*innen in den Vordergrund, während Kanban durch seine Wurzeln im Lean Management eher für eine Optimierung des Workflows sorgt.

Insgesamt ist Kanban dabei weniger formalisiert als Scrum, dessen „Regeln“ im Scrum Guide festgelegt sind. Scrum setzt beispielsweise darauf, dass Teams möglichst täglich zusammenarbeiten oder zumindest ein klares Commitment treffen, wie viel Zeit sie in einem Sprint mitbringen. Das ist bei Kanban nicht nötig.

Die Vorteile von Kanban

Den wahrscheinlichen größten Vorteil hat das Microsoft-Beispiel gezeigt: Durch die Visualisierung der Arbeitsprozesse gewinnt das Team ein tiefes Verständnis über den Arbeitsfluss. So erkennt es schneller Engpässe oder Blockaden und kann diese beheben. Dies trägt dazu bei, die Durchlaufzeit von Aufgaben zu verkürzen und die Effizienz zu steigern.

Ein weiterer Vorteil von Kanban ist seine Flexibilität. Kanban passt sich an unterschiedliche Arbeitsumgebungen und Anforderungen an. Es gibt keine festgelegten Rollen oder Arbeitszyklen. Dies macht Kanban zu einer idealen Option für Teams, die sich auf schnelle Anpassungen und Veränderungen einstellen müssen.

Darüber hinaus ist das Vorgehensmodell einfach zu verstehen und umzusetzen. Es ist ein flexibles Framework, das in vielen Situationen und Arbeitsumgebungen eingesetzt werden kann. Kanban eignet sich nicht nur für die Softwareentwicklung, sondern auch für andere Bereiche wie Marketing, Buchhaltung oder Vertrieb.

Einsatzbereiche von Kanban

Kanban ist ein Framework für evolutionäre Veränderung. So bezeichnet es David J. Anderson in seinem Buch „Kanban: Successful Evolutionary Change for Your Technology Business“. Ziel des Modells ist es, eine Kultur der kontinuierlichen Verbesserung zu etablieren.

Noch einmal zurück zum Microsoft-Beispiel: Es wurden weder neue Teamstrukturen eingeführt noch die Prozesse oder die Zusammenarbeit verändert. Kanban machte die Arbeitsprozesse transparent und half, den Arbeitsfluss zu optimieren.

Die Einführung des Frameworks erfordert keine revolutionären Änderungen in der Organisationsstruktur des Unternehmens oder in der Zusammensetzung des Teams. Bei Kanban konzentriert sich das Team auf den Prozess. Das Modell hilft, Arbeitsabläufe regelmäßig zu hinterfragen und Ressourcenverschwendung zu vermeiden. Dadurch arbeitet das Team wesentlich effizienter. Durch diesen Fokus auf Effizienz ist Kanban streng genommen kein agiles, sondern ein dem “Lean Management” entlehntes Vorgehensmodell. Durch die große Schnittmenge in den Werten setzen es auch agile Teams häufig in ihrer Arbeit ein.

Anwendungsbeispiele aus der Praxis

Kanban hat längst auch außerhalb der IT Einzug gehalten. Das Framework eignet sich vor allem in Bereichen, in denen Aufgaben in immer gleichen Arbeitsschritten bearbeitet werden. Das können beispielsweise Anfragen im Kundenservice, im Vertrieb, in der Organisation des Bewerbermanagements oder Fahrzeuge in der Wartung sein.

Auch die Artikel für das Magazin von Me & Company werden in einem Kanban-Board organisiert. So durchläuft dieser Beitrag vor der Veröffentlichung die Spalten „Recherche/Informationssammlung“, „In Bearbeitung“, „Feedback einholen“, „Feedback einarbeiten“ und „Veröffentlichen“.

Kanban-Varianten: Scrumban, Kanplan und Personal Kanban

Kanban ist als Framework flexibel einsetzbar. Dies hat in den letzten Jahren zu einigen Varianten und Mischformen geführt, die Kanban als Basis für eigenständige Modelle nutzen. Scrumban ist eine dieser Varianten und wurde bereits an anderer Stelle erwähnt. Nachfolgend eine (unvollständige) Auswahl bekannter Kanban-Varianten.

• Scrumban: Scrumban ist eine Kombination aus Scrum und Kanban. Das Framework ermöglicht es Teams, die Flexibilität von Kanban und die Struktur von Scrum zu nutzen. Scrumban eignet sich besonders für Teams, die mit wechselnden Anforderungen und Prioritäten arbeiten.
• Kanplan: Kanplan konzentriert sich auf die Planung. Das Modell basiert auf der Idee, dass die Planung kontinuierlich angepasst werden muss, um den sich ändernden Anforderungen gerecht zu werden. Ähnlich wie Scrumban kombiniert Kanplan Elemente von Scrum und Kanban. Es enthält beispielsweise ein Backlog, arbeitet aber nicht in Sprints.
• Personal Kanban: Wie der Name schon sagt, handelt es sich um eine individuelle Variante von Kanban. Es eignet sich für Einzelpersonen zur Verwaltung persönlicher Themen (Familie, Freizeit, Haushalt).

Werte, Prinzipien, Praktiken: die Grundlagen von Kanban

Als Vorgehensmodell basiert Kanban im Wesentlichen auf drei Säulen: den Werten, den Prinzipien und den Praktiken:

• Werte: Die 9 Werte von Kanban bilden die Grundlage für die erfolgreiche Zusammenarbeit im Team.
• Prinzipien: Die 4 Prinzipien geben den Teams Orientierung und helfen bei der Entscheidungsfindung.
• Praktiken: Die 6 Kernpraktiken von Kanban definieren wichtige Aktivitäten für die Arbeit an und mit dem System.

Die 9 Werte

Wie Scrum basiert auch Kanban auf einer Reihe von Werten, die für die erfolgreiche Anwendung des Modells wichtig sind. Die 9 Kanban-Werte bauen aufeinander auf und bedingen sich gegenseitig. Alle Werte sollten im Unternehmen und im Team gelebt werden:

• Respekt: Kanban setzt den Respekt aller Beteiligten im Unternehmen untereinander voraus. Respekt ist die Basis der Zusammenarbeit und damit die Grundlage für die anderen acht Werte.
• Transparenz: Kanban-Teams machen ihre Arbeit sichtbar und pflegen einen offenen Austausch über alle Themen. So können sie Prozesse reflektieren, analysieren und verbessern.
• Arbeitsfluss: Die Arbeit fließt gleichmäßig und kontinuierlich durch das System, um Blockaden oder Störungen zu vermeiden.
• Verständnis: Veränderungen und Verbesserungen in der Arbeitsweise oder Organisation setzen voraus, dass die Mitarbeitenden und Teams die Situation und die bestehenden Probleme verstehen.
• Kollaboration: Kanban setzt auf eine enge und vertrauensvolle Zusammenarbeit der Beteiligten. Nur so erreichen sie eine Verbesserung der Arbeitsweise und Organisation.
• Balance: Kanban-Teams bringen in ihrer Arbeit die Bedürfnisse und Perspektiven aller Beteiligten in Einklang. Durch diese Balance sichern sie ihre Leistungsfähigkeit.
• Führung: Jedes Teammitglied ergreift die Initiative und entscheidet sich für Veränderungen, wenn es Verbesserungspotenzial erkennt.
• Kundenfokus: Kanban-Teams leben Kundenzentrierung. Mehrwert für Kund*innen zu schaffen, steht im Zentrum allen Handelns.
• Vereinbarung: Alle Beteiligten vereinbaren, die gemeinsamen Ziele zu verfolgen.

Die 4 Prinzipien

David J. Anderson hat vier Prinzipien definiert, die neben den Werten die Arbeit im Kanban-Framework prägen. Auch hier steht der Arbeitsprozess bzw. -ablauf im Mittelpunkt:

1. Beginne mit dem, was du gerade tust: Anstatt eine große Zukunftsvision zu entwerfen, beginnen Teams bei Kanban damit, den aktuellen Status quo zu verbessern.
2. Vereinbare, dass evolutionäre Veränderung verfolgt wird: Kanban legt großen Wert darauf, Prozesse zu verbessern, ohne sie unbrauchbar zu machen. Veränderungen und Verbesserungen werden angestrebt und erfolgen kontinuierlich in kleinen Schritten. Radikale Veränderungen bergen die Gefahr, dass Fehler entstehen, die wesentlich schwieriger zu beheben sind.
3. Respektiere initial bestehende Prozesse, Rollen, Verantwortlichkeiten und Job-Titel: Hier geht es darum, ein umfassendes Bild der Abhängigkeiten für die Veränderung zu erhalten. Kanban-Teams versuchen, andere Perspektiven zu verstehen und ein ganzheitliches Bild der zu lösenden Aufgabe aufzubauen. Das „Tagesgeschäft“ bleibt dabei erhalten. Die Teams erarbeiten jedoch Lösungen, die auf breite Akzeptanz stoßen.
4. Ermutige Menschen aller Ebenen Führung zu übernehmen: Mitarbeitende aller Ebenen des Unternehmens sollen Verantwortung übernehmen und sich an der Verbesserung von Prozessen und Arbeitsabläufen beteiligen.

In folgenden Artikel gibt es weitere Hintergründe und Praxistipps zu den Kanban-Prinzipien: Kanban-Prinzipien: Die 4 Leitplanken des agilen Frameworks

Die 6 Praktiken

Die Kanban-Praktiken ergänzen die Werte und Prinzipien mit operativen Handlungsanweisungen. Mit Hilfe dieser sechs Kernpraktiken gestalten Kanban-Teams ihre tägliche Arbeit effizienter.

1. Mach Arbeit sichtbar: Durch die Visualisierung fällt es den Teammitgliedern leichter, über Abläufe, Hindernisse und Verbesserungen in der Arbeit zu sprechen. Viele Probleme in der Zusammenarbeit lassen sich bereits durch eine bessere Kommunikation lösen.
2. Begrenze die Menge angefangener Arbeit: Mitarbeitende, die voll ausgelastet sind und Multitasking betreiben, arbeiten weniger effektiv. Kanban legt den Fokus auf möglichst schnelle Werterbringung. Teams begrenzen mit Work-in-Progress-Limits die parallel durchgeführten Arbeiten. Das Pull-Prinzip vermeidet Ressourcenverschwendung, in dem es aufgestaute Teilergebnisse im Arbeitsfluss sichtbar macht. Mitarbeitende beschaffen sich Aufgaben selbst, statt sie nach dem Push-Prinzip zugewiesen zu bekommen.
3. Miss und steuere den Arbeitsfluss: Damit sich Teams bei der Verbesserung auf Daten statt auf Meinungen stützen können, messen sie die Dauer und den Durchlauf eines Arbeitsschrittes.
4. Mach Prozess-Regeln explizit: Viele Fehler entstehen durch unterschiedliche Auffassungen und Interpretationen von Sachverhalten. Mit Kanban machen Teams daher Regeln unmissverständlich und im direkten Sichtfeld des jeweiligen Arbeitskontexts sichtbar.
5. Implementiere Lern- und Feedback-Möglichkeiten: Kontinuierliche Verbesserung braucht einen Rahmen. Hierfür nutzen auch Kanban-Teams regelmäßige Termine wie z.B. Daily Standups oder Retrospektiven.
6. Führe gemeinschaftlich Verbesserungen ein: Durch die vereinfachte Darstellung von Abläufen und Zusammenhängen konzentrieren sich die Teammitglieder auf das Wesentliche. Die Gefahr sinkt, sich in Details zu verlieren. Dabei können die Teammitglieder z.B. auf bestehende Modelle oder Methoden zurückgreifen, um kontinuierliche Verbesserungen zu erreichen.

Kanban-Board: zentrales Werkzeug des Frameworks

Viele setzen Kanban mit dem Kanban-Board gleich. Und in der Praxis nutzen die meisten Kanban-Teams auch ein Board oder eine Tafel, um Aufgaben und Arbeitsprozesse für alle sichtbar zu machen. Das Board ist jedoch nur ein Hilfsmittel – wenn auch das zentrale. Kanban baut auf den oben beschriebenen Werten, Prinzipien und Praktiken auf. Das Kanban-Board ist das Werkzeug, um dies in die Praxis umzusetzen.

Kanban-Teams gruppieren ihre Aufgaben in mehrere Spalten auf dem Board, die für die Arbeitsschritte im gesamten Prozess stehen. Welche Schritte das sind, ist von Team zu Team unterschiedlich. Gängige Spalten sind z.B. „Backlog/To Do“, „In Bearbeitung“, „Warten auf Feedback“, „Erledigt/Abgeschlossen“. In der Praxis haben viele Teams sogar mehr als nur eine “In Bearbeitung”-Spalte. Sie splitten die einzelnen Phasen des Bearbeitungsstatus in mehrere Spalten auf, z. B. Recherche, Konzept, Entwicklung, Test.

Das Team schreibt die einzelnen Aufgaben auf Karten, die den gesamten Arbeitsprozess von Spalte zu Spalte durchlaufen. Ziel von Kanban ist es, dass die Karten/Aufgaben möglichst ungehindert durch die Spalten wandern und das Team so schnell Mehrwert für seine Kund*innen liefert.

Die Visualisierung auf der Tafel ermöglicht es dem Team, Engpässe sichtbar zu machen. Wenn eine Aufgabe blockiert ist, wird dies markiert. Eine Blockade entsteht z.B., wenn bestimmte Informationen nicht vorliegen oder Teams auf die Mitarbeit anderer Abteilungen im Unternehmen angewiesen sind.

Kanban-Karten 

Auf dem Board notieren die Teams ihre Aufgaben auf Karten. Die Karten werden z.B. als Post-it auf einem physischen Board oder als digitales Ticket auf einem Digital-Board geschrieben. Auf den Karten steht das jeweilige „Work Item“, also die zu erledigende Arbeit. Es gibt keine Vorgaben, welche genauen Informationen auf den Karten stehen oder in welcher Form sie geschrieben sein sollten. Jedes Team hat hier eine eigene Herangehensweise bzw. Definition. Wichtig ist, dass jedes Teammitglied weiß, was mit dem jeweiligen Eintrag gemeint ist. Auf den Karten können z.B. stehen:

• Requirements/Anforderungen
• User Stories
• Features
• Support-Anfragen
• Nummer/ID aus einem anderen Tool
• URL oder Link zu einem anderen Tool

Viele Teams kennzeichnen Karten separat mit einem Foto oder Aufkleber, um zu zeigen, welches Teammitglied an der Aufgabe arbeitet.

Spalten im Kanban-Board

Das Kanban-Board unterteilt sich in mehrere Spalten, die den Arbeitsprozess des Teams abbilden. Jede Spalte steht hierbei für einen Arbeitsschritt. Die Karten wandern durch diese Spalten und symbolisieren so den Arbeitsfluss. Karten durchlaufen das Board von links nach rechts. Sie starten in der „To Do“-Spalte und landen am Ende in der „Fertig/Abgeschlossen“-Spalte. Einmal unterwegs sollten sie nicht mehr zurück gehängt werden im Prozess.

Jede Spalte/Arbeitsschritt unterteilt sich dabei in zwei Spalten: „In Arbeit“ und „Fertig“. Wie bereits geschrieben basiert Kanban auf dem Pull-Prinzip: Teammitglieder können sich so Aufgaben aus der Fertig-Spalte nehmen und in den nächsten Arbeitsschritt ziehen.

Nicht alle Aufgaben fallen in die gleiche Kategorie. Viele Teams haben unterschiedliche „Arbeitstypen“. Auf dem Kanban-Board machen sie dies mit den sogenannten Swimlanes (Schwimmbahnen) sichtbar. Dabei ordnen sie die verschiedenen Typen auf dem gleichen Board an und trennen sie durch horizontale Linien voneinander. Die Teams können die Swimlanes beispielsweise nutzen, um Aufgaben nach Art oder Dringlichkeit zu unterscheiden. Oder sie gruppieren ihre Karten auf verschiedenen Bahnen, je nach Produkt oder Kunde. Ein klassisches Beispiel für unterschiedliche Arbeitstypen in der Entwicklung sind Features, Change Requests und Bugfixing. In der Praxis organisieren sich häufig auch mehrere Teams mit gleichen Arbeitsschritten auf einem gemeinsamen Board. So verschaffen sich beispielsweise Recruiting-Teams einen ganzheitlichen Blick auf die Bewerbungssituation.

WIP-Limits: Anzahl der Aufgaben begrenzen

Wie bereits an anderer Stelle erwähnt, ist einer der wichtigsten Praktiken von Kanban: „Begrenze die Menge der angefangenen Arbeit“. Auf dem Kanban-Board signalisieren Teams dieses Prinzip mit einer Zahl, die über den einzelnen Spalten steht: Diese steht für das jeweilige WIP-Limit der Spalte.

WIP steht für „Work-in-Progress“, also die Menge der „laufenden Arbeit“. Kanban-Teams begrenzen diese laufenden Arbeiten und vermeiden auf diese Weise Multitasking. WIP-Limits begrenzen die Anzahl der Karten in der jeweiligen Spalte auf die angegebene Zahl. Steht dort eine 2, so dürfen in der Spalte auch nur zwei Karten liegen. Die Zahl bezieht sich auf beide Abschnitte der Spalte und gilt für „In Arbeit“ und „Fertig“ zusammen.

WIP-Limits helfen, die Arbeitsbelastung zu steuern und verhindern, dass sich unerledigte Arbeit ansammelt. Sie unterstützen zudem dabei, Engpässe und Blockaden zu erkennen.

Warum sind WIP-Limits wichtig?

Eine der Grundideen von Kanban ist es, nicht immer mit neuen Aufgaben zu beginnen, sondern bestehende Aufgaben abzuschließen. Eine der Grundweisheiten lautet daher auch: „Stop Starting, Start Finishing“. In der gleichen Zeit an weniger zu arbeiten, führt zu mehr Wert für die Kund*innen. WIP-Limits sorgen nicht dafür, dass „weniger gemacht wird“. Sie helfen Teams dabei, einen Arbeitsfluss herzustellen und sich auf das Fertigstellen zu konzentrieren.

In vielen Unternehmen herrscht allerdings noch immer eine andere Denkweise vor: „Eine volle Auslastung der Teams führt zu höherer Produktivität.“ Also versorgen Führungskräfte ihre Mitarbeitenden mit so viel Arbeit, dass diese an zahlreichen Aufgaben gleichzeitig arbeiten müssen. Die wissenschaftliche Forschung und die Praxis in vielen Organisationen zeigen jedoch: Multitasking und eine höhere Auslastung führen eher dazu, dass weniger Arbeit erledigt wird. Effizienz und Produktivität des Teams sinken.

Wer versucht, mehr in der gleichen Zeit zu erledigen, erreicht das Gegenteil: Er arbeitet unkonzentrierter, produziert mehr Fehler und liefert später ab. Der ständige Wechsel zwischen verschiedenen Kontexten oder Aufgaben kostet kognitive Energie: Die Mitarbeitenden müssen sich erst wieder in die neue Aufgabe einarbeiten und verlieren so Zeit. Schon kurze Unterbrechungen führen zu einem Verlust von bis zu 40 Prozent der produktiven Zeit.

Multitasking verhindert konzentriertes Arbeiten und erhöht die Fehlerwahrscheinlichkeit. Ein hohes Maß an „work in progress“ verlängert die Bearbeitungszeit und beeinträchtigt die Qualität der Arbeitsergebnisse. Daher ist es wichtig, das richtige Maß an gleichzeitiger Arbeit zu definieren und WIP-Limits einzuführen. Auf diese Weise können sich die Teams auf die wichtigen Aufgaben konzentrieren und produktiver arbeiten.

Blockaden und Engpässe sichtbar machen

Kanban hilft, Blockaden und Engpässe in der Arbeit sichtbar zu machen. In der Praxis markieren die Teams die Aufgaben, die gerade blockiert sind, am Board mit einem Aufkleber oder einer Notiz. Typische Blockaden oder Engpässe sind zum Beispiel:

• Abhängigkeit von anderen Teams/Abteilungen
• Warten auf Rückmeldung
• Fehlende Informationen
• Technische Störungen
• Krankheiten oder Ausfälle

Die Blockade einer Aufgabe führt zu einer Unterbrechung des gesamten Arbeitsflusses. Die Spalten des Kanban-Boards bauen aufeinander auf. Wenn alle Aufgaben in Spalte 1 blockiert sind, kann der nächste Arbeitsschritt nicht ausgeführt werden. In diesem Fall wird jedoch keine neue Aufgabe aus dem Backlog in die Spalte gezogen. Wenn das WIP-Limit der Spalte erreicht ist, verbleiben die blockierten Aufgaben dort. Das Team arbeitet daran, das Hindernis zu beseitigen und die Probleme zu lösen.

Manche Teams nutzen jedoch eine zusätzliche “Blocked-Spalte” auf dem Board und schieben die blockierten Karten dorthin. In dem Fall wird ein Platz in der Spalte frei.

Es gibt somit zwei Arten, Blockaden zu visualisieren:

1. Markierte Karten: Dann zählen die WIP-Limits.
2. Eine “Blocked”-Spalte: Dann zählen die WIP-Limits auch, die blockierte Aufgabe macht aber “den Weg frei”.

Teams reden beispielsweise im Daily-Stand-up-Meeting über Hindernisse. Oder sie führen Verbesserungsworkshops durch, um die Blockaden aufzulösen. Auf sogenannten Impediment Boards dokumentieren und visualisieren Teams Hindernisse. Dabei zeigt sich manchmal, dass es wiederkehrende Muster oder immer wieder ähnliche Blockaden gibt, die durch gezielte Maßnahmen beseitigt werden können. Ist z.B. ein Team auf die Zusammenarbeit mit einem anderen Team angewiesen, können durch eine verbesserte Kommunikation Probleme frühzeitig beseitigt oder vermieden werden. Hierzu kann das Team beispielsweise eine*n Vertreter*in aus der anderen Gruppe in sein Daily einladen.

Mit dem Enablement Radar haben wir bei Me & Company zudem ein Werkzeug entwickelt, das hilft, Blockaden in der Zusammenarbeit zu identifizieren und Lösungen zu entwickeln.

Definition of Done: Qualität sicherstellen

Die Qualität ihrer Arbeit sichern Teams durch eine gemeinsam erarbeitete Definition of Done. In dieser definiert es, wann eine Aufgabe aus Sicht der Kund*innen als fertiggestellt gilt. Dazu legt das Team Kriterien fest, um dies zu messen. Das Team formuliert die Definition of Done einmalig. Sie gilt für alle Aufgaben.

Eine Definition of Done kann zum Beispiel ein gemeinsames Dokument oder eine Liste von Kriterien sein. Mögliche Kriterien sind beispielsweise:

• Alle Aufgaben der User Story sind erledigt.
• Funktionalität ist getestet.
• Feedback von mindestens einem Teammitglied ist eingeholt.
• Dokumente sind auf Rechtschreibung und Grammatik geprüft.

Kanban-Meetings: Verbesserung durch Kommunikation

Um eine kontinuierliche Verbesserung zu gewährleisten, Hindernisse zu beseitigen und den Arbeitsfluss zu optimieren, ist Kommunikation in Kanban ein Schlüsselfaktor. Regelmäßige Besprechungen sind bei Kanban zwar nicht vorgeschrieben oder Teil des Rahmenwerks, wie es bei Scrum der Fall ist. Sie sind also nicht zwingend notwendig, um das Vorgehensmodell im Team anzuwenden.

Dennoch haben sich in vielen Kanban-Teams regelmäßige Meetings etabliert, in denen z.B. die Aufnahme neuer Aufgaben oder Blockaden bei laufenden Aktivitäten besprochen werden.

Daily Stand-up

Das Daily Stand-up ist das wahrscheinlich am meisten genutzte Meetingformat in Kanban-Teams. In diesem täglichen Treffen bespricht das Team strategische Probleme und Fragen, die den Arbeitsfluss beeinflussen. Das Stand-up dauert in der Regel 15 Minuten. Ziel ist es, aktuelle Blockaden zu besprechen und Lösungsvorschläge zu diskutieren. Das Team schaut dabei gemeinsam auf das Kanban-Board und bespricht die Situation der aktuellen Aufgaben.

Bei größeren Problemen oder Hindernissen verschieben das Team oder einzelne Mitarbeitende die Erarbeitung der Lösung auf separate Termine oder Workshops. Gegebenenfalls werden weitere Personen hinzugezogen, die für die Lösungsfindung notwendig sind.

Nachschubmeeting

Viele Kanban-Teams halten alle ein bis zwei Wochen ein Nachschubmeeting ab (auch Replenishment Meeting genannt). In diesem Treffen beschäftigt sich das Team mit dem Backlog und den Aufgaben, die als nächstes in Bearbeitung genommen werden sollen.

An dem Meeting nehmen in der Regel auch Stakeholder*innen, also Vertreter*innen aus anderen Bereichen des Unternehmens teil, um ihre Anforderungen in den Arbeitskreislauf des Teams zu bringen. Dabei sollte immer deutlich werden, wie diese neuen Ideen oder Aufgaben zur übergeordneten Produkt- oder Projektvision beitragen. Letztendlich entscheidet das Team, welche Aufgaben es als nächstes in das System aufnimmt.

Das Team nutzt das Nachschubmeeting auch, um das Backlog zu priorisieren und den Aufwand für die Aufgaben zu schätzen. Alles in allem dient das Treffen dazu, für „Nachschub“ zu sorgen. Es stellt sicher, dass das Team nach Abschluss der laufenden Arbeiten neue Aufgaben in Angriff nehmen kann.

Impediment Meeting

Im Impediment Meeting beschäftigt sich das Team mit aktuellen und wiederkehrenden Blockaden und Hindernissen der Arbeit. Viele Kanban-Teams sammeln Informationen über Barrieren in der Zusammenarbeit auf einem Impediment Board. Im Meeting sprechen sie darüber, kategorisieren die Hindernisse und suchen nach Mustern. Sie sprechen darüber, was sie aus vergangenen Blockaden gelernt haben und wie sie aktuelle beseitigen können.

Gerade wenn es sich um wiederkehrende Barrieren handelt, die einem bestimmten Muster folgen, suchen die Teams nach nachhaltigen Lösungen, damit diese in Zukunft nicht mehr auftreten.

Retrospektive

Ähnlich wie bei Scrum nutzen auch Kanban-Teams Retrospektiven, um über die Verbesserung der Zusammenarbeit zu sprechen und konkrete Maßnahmen abzuleiten. Damit diese nachhaltig sind, sollten die Retrospektiven regelmäßig stattfinden und das Team die vereinbarten Verbesserungsmaßnahmen zeitnah umsetzen.

In der Retrospektive bespricht das Team Herausforderungen und Probleme in der operativen Zusammenarbeit und sucht nach Lösungen. Für die Durchführung bieten sich zahlreiche Methoden an. Eine einfache und beliebte Variante ist Keep-Start-Stopp-Retro, bei der sich das Team drei Fragen stellt:

• Keep: Was ist in unserer Zusammenarbeit gut gelaufen und sollte beibehalten werden?
• Start: Womit sollten wir anfangen?
• Stopp: Was sollten wir nicht mehr machen?

Weitere Meetings

Neben den genannten Meetingformaten gibt es noch einige weitere, die in Kanban-Teams zum Einsatz kommen. So nutzen beispielsweise Teams aus der IT und Softwareentwicklung Release Meetings, um den anstehenden Release einer neuen Lösung zu planen. Viele Kanban-Teams führen zudem offene Reviews durch, in denen sie Stakeholder*innen, dem Management oder Kund*innen aktuelle Arbeitsergebnisse präsentieren und Feedback einholen. Mit einem Health Check überprüft das Team, ob es über die systemischen Rahmenbedingungen verfügt, um als Team erfolgreich zu arbeiten.

Kanban-Team: optionale Rollen teilen sich die Verantwortung

Das Kanban-Konzept sieht keine definierten Rollen wie bei Scrum vor. Es gibt weder einen Product Owner noch einen dem Scrum Master ähnlichen Kanban Master. Das gesamte Team ist für die Optimierung der Arbeitsabläufe und die Organisation des Boards verantwortlich. Ganz im Sinne des dritten Kanban-Prinzips: „Respektiere initial bestehende Prozesse, Rollen, Verantwortlichkeiten und Job-Titel“. In der Praxis unterstützt jedoch oft ein Agile Coach die Teams bei der Umsetzung des Vorgehensmodells.

Dieser kommt häufig der Rolle nach, die im ursprünglichen Toyota-Produktionssystem durch eine hierarchische Führungskraft übernommen wurde. Sie war für den Arbeitsfluss und die Entscheidungsfindung zuständig.

Auch wenn sie zu Beginn nicht angedacht waren, haben sich in der heutigen Praxis zwei Rollen herausgebildet. David J. Anderson hat sie um 2010 genauer definiert: der Service Delivery Manager und der Service Request Manager. Diese Rollenbeschreibungen stellen Vorschläge dar. Im Gegensatz zu Scrum sind sie nicht zwingend, wenn Teams Kanban einsetzen wollen. Die Rollen werden von den Teammitgliedern übernommen. Sie können innerhalb des Teams weitergegeben und im Rahmen des kontinuierlichen Verbesserungsprozesses auch verändert werden.

Service Delivery Manager: Verantwortung für den Arbeitsfluss

Der Service Delivery Manager wird in manchen Teams auch “Flow Master” oder “Flow Manager” genannt. Er ist für den Arbeitsfluss verantwortlich. Der Service Delivery Manager stellt sicher, dass regelmäßige Nachschubmeetings abgehalten werden und ist für die Organisation weiterer Meetings verantwortlich. Er moderiert den Daily Stand-up und stellt sicher, dass Blockaden und Hindernisse beseitigt werden, um einen kontinuierlichen Arbeitsfluss zu gewährleisten.

Er ist erster Ansprechpartner für Stakeholder*innen und organisiert die teamübergreifende Zusammenarbeit. Zudem bewertet er regelmäßig Risiken, die im Projekt auftreten könnten.

Service Request Manager: Verantwortung für die Entscheidungsprozesse

Der Service Request Manager ist für die Entscheidungsprozesse im Kanban-Team verantwortlich. Er verantwortet und verbessert den Prozess der Bewertung, Planung, Priorisierung und Auswahl der zu bearbeitenden Aufgaben. In dieser Funktion ist er auch für die Struktur und den Ablauf der Nachschubmeetings zuständig. Darüber hinaus entwickelt der Service Request Manager Mechanismen oder Maßnahmen zur regelmäßigen Überprüfung und Überarbeitung der Strategie und Risikobewertung.

Das bedeutet: Der Service Request Manager trifft nicht alleine die Entscheidungen oder bewertet die Aufgaben hinsichtlich Durchführbarkeit oder Priorisierung. Er schafft die Rahmenbedingungen und Mechanismen, in denen das Team und die Stakeholder gute Entscheidungen treffen können.

Kanban-Metriken: Leistungsfähigkeit und Arbeitsfluss von Teams messen

Kanban-Team beobachten ihren „Work in Progress“ sehr genau. Mit verschiedenen Metriken und Methoden messen sie den Arbeitsfluss. Ziel ist es, die Leistungsfähigkeit zu analysieren und so den Arbeitsfluss fortlaufend zu verbessern.

So beschreibt beispielsweise der Throughput die Anzahl der abgeschlossenen Aufgaben in einem bestimmten Zeitraum. Mit Aging Work in Progress messen Teams, wie lange sich Aufgaben in Bearbeitung sind. Dies ist ein Indikator für aufkommende Probleme oder Blockaden. Weitere Werkzeuge sind beispielsweise der Flow Efficiency Chart, der Cycle Time Scatterplot oder der Due Date Performance Chart. Nave hat auf seiner Webseite eine Übersicht kanban-spezifischer Metriken und Tools veröffentlicht.

Mit dem Cumulative Flow Diagram und dem Cycle Time Histogram stellen wir in den folgenden Abschnitten zwei dieser Kanban-Werkzeuge etwas näher vor.

Cumulative Flow Diagram

Ein Cumulative Flow Diagram (CFD) zeigt die Menge an Work in Progress im Laufe der Zeit. Es hilft den Teams, Engpässe und Veränderungen im Arbeitsfluss zu erkennen. Teams tragen über einen längeren Zeitraum täglich die aktuelle Menge der Aufgaben pro Spalte/Arbeitsschritt in das Diagramm ein. Beispiel: Wie viele Aufgaben befinden sich in der Spalte „To Do“, wie viele in der Spalte „In Arbeit“ und wie viele in der Spalte „Erledigt“. Im Laufe der Zeit bilden sich Linien, aus denen das Team Rückschlüsse ziehen kann: Wenn in allen Spalten immer gleich viele Aufgaben stehen, verlaufen die Linien parallel. In der Regel gibt es jedoch Unterschiede. An diesen erkennt das Team Probleme und sucht nach Verbesserungsmöglichkeiten.

Mit Hilfe des Cumulative Flow Diagrams erkennen Teams, wo sie ihren Prozess verbessern müssen oder wo sie gegebenenfalls Unterstützung benötigen.

Cycle Time Histogram

Mit einem Cycle Time Histogram erfassen Teams die Zeit, die vom Beginn einer Aufgabe bis zu ihrem Abschluss benötigt wird. Das Tool misst die Effizienz des Teams und liefert so Erkenntnisse, um die Arbeitsweise kontinuierlich zu verbessern.

Das Tool misst die Bearbeitungsdauer jeder Aufgabe im Prozess innerhalb eines bestimmten Zeitraums. Der Durchschnitt aller Werte ergibt die Cycle Time (orangefarbene Linie in der Grafik unten). Zusätzlich zur Cycle Time tragen die Teams die einzelnen Zeitwerte pro Aufgabe ein (in der Grafik als Kreise dargestellt). So werden Aufgaben sichtbar, die besonders stark vom Durchschnitt abweichen.

Kanban auf Organisationsebene: Strategie und operative Arbeit verbinden

Kanban wird meist auf der Teamebene eingesetzt, um Arbeitsabläufe zu verbessern und die Produktivität zu steigern. In den letzten Jahren sind darüber hinaus einige Ansätze entstanden, die Kanban auf Managementebene skalieren. Diese Modelle ermöglichen es, die Unternehmensstrategie mit der operativen Arbeit zu verbinden und die Zusammenarbeit der einzelnen Teams zu koordinieren bzw. zu steuern. Die folgenden Abschnitte stellen zwei dieser Modelle vor.

Portfolio Kanban

Portfolio Kanban eignet sich vor allem für Unternehmen, die eine Vielzahl von Projekten oder Initiativen durchführen. Der Ansatz hilft, die verfügbaren Ressourcen zu planen und optimal einzusetzen. Mit Portfolio Kanban stellen Unternehmen sicher, dass sie auf die richtigen Projekte und Initiativen setzen, um ihre Geschäftsziele zu erreichen. Das Modell bietet die Möglichkeit, die Arbeit auf Portfolioebene zu visualisieren und die Verfügbarkeit von Ressourcen und Kapazitäten zu optimieren.

Ein zentraler Aspekt ist dabei die Priorisierung von Projekten und Initiativen, um die begrenzten Ressourcen auf die wichtigsten Projekte zu konzentrieren. Auch die kontinuierliche Analyse und Anpassung der Portfoliostrategie spielt eine wichtige Rolle bei Portfolio Kanban. Anpassungen können notwendig sein, um sicherzustellen, dass das Projektportfolio weiterhin den größtmöglichen Wert für das Unternehmen generiert.

Auch in Portfolio Kanban verwenden Unternehmen häufig Boards, um den Überblick über die verschiedenen Projekte und Initiativen zu behalten. Die Boards sind miteinander verbunden und spiegeln die verschiedenen Ebenen des Unternehmens wider. Sie sind hierarchisch aufgebaut: Auf der obersten Ebene befindet sich in der Regel ein “Strategie-Board”, das die strategischen Ziele und Initiativen des Unternehmens abbildet und die darunter liegenden Projekt- und Team-Boards beeinflusst. Die Kanban-Karten auf dem übergeordneten Strategie-Board sind die “Eltern” der Karten auf den “untergeordneten” Boards. Eine Karte auf dem übergeordneten Board wird also auf den darunter liegenden Boards auf die Projektebene und auf dem Team-Board auf die operative Ebene heruntergebrochen.

Beispiel: Auf der obersten Ebene wird das Ziel formuliert, die Online-Services des Unternehmens zu verbessern. Eine zentrale Initiative ist dabei die Verbesserung der Benutzerfreundlichkeit der Website. Auf Projektebene wird dies in einem UX-Relaunch-Projekt festgehalten. Auf operativer Teamebene könnte eine (von mehreren) Aufgaben die Durchführung von Nutzertests sein.

Kanban Flight Levels

Mit den Kanban Flight Levels hat Klaus Leopold ein Modell entwickelt, das sich auf die Steuerung von Arbeitsabläufen auf den verschiedenen Ebenen der Organisation konzentriert. Es hilft dabei, die Verbindung und Koordination zwischen den Teams zu stärken. Ziel ist es sicherzustellen, dass diese Ebenen effektiv zusammenarbeiten, um die Ziele der Organisation zu erreichen.

Leopold hat das Flight-Level-Konzept aus dem Portfolio Kanban entwickelt, damit auch größere Organisationen Kanban nutzen können. Die Kanban Flight Levels bestehen aus drei Ebenen:

1. Operative Ebene: Flight Level 1 konzentriert sich auf die Optimierung der Zusammenarbeit auf Teamebene – der traditionellen Anwendung des Kanban-Frameworks.

2. Koordinationsebene: Flight Level 2 dient der teamübergreifenden Zusammenarbeit. Diese Boards koordinieren Aufgaben zwischen Teams und sorgen für den ganzheitlichen Arbeitsfluss in einem Unternehmensbereich.

3. Strategieebene: Boards des Flight Levels 3 dienen Führungskräften zur Übersicht des gesamten Portfolios. Diese Ebene legt den Fokus auf die Ausrichtung des Unternehmens an den strategischen Zielen. Sie stellt die Verbindung zwischen der operativen Arbeit in den Teams (Flight Level 1) und der teamübergreifenden Koordination (Flight Level 2) zu den übergeordneten Unternehmenszielen her.

Die unterschiedlichen „Flugebenen“ des Unternehmens helfen dabei, sowohl den Fokus auf die täglichen Arbeitsabläufe zu behalten, als auch die Zusammenarbeit zwischen Teams und die Ausrichtung auf die strategischen Ziele des Unternehmens zu gewährleisten.

Fazit

Kanban ist ein in vielen Bereichen etabliertes Vorgehensmodell. Es ist relativ einfach zu verstehen und kann schnell und ohne großen Aufwand in bestehenden Teams eingeführt werden. Als Framework ist Kanban weniger reguliert als Scrum und konzentriert sich auf die Optimierung der Arbeitsabläufe

Ziel von Kanban ist es, die Effizienz von Teams zu steigern, Engpässe zu vermeiden und eine kontinuierliche Verbesserung des Arbeitsflusses zu ermöglichen. Im Kern besteht das Modell aus Werten, Prinzipien und Praktiken. In der Praxis nutzen viele Teams ein Kanban-Board mit auf ihre Bedürfnisse zugeschnittenen Kanban-Karten, um ihre Arbeit sichtbar zu machen.