Agile Ent­wick­lung – viele denken hierbei direkt an das sehr populäre Scrum, doch diese Methode ist nicht die einzige Art, wie Sie in Ihrem Un­ter­neh­men agiles Pro­jekt­ma­nage­ment anwenden können. Kanban ist eine andere Methode, die schon auf vielen Gebieten ge­winn­brin­gend an­ge­wen­det wurde. Ist Kanban auch für Ihr Un­ter­neh­men oder Projekt sinnvoll? Wir erklären Ihnen, wie die Methode funk­tio­niert.

Ur­sprüng­lich stammt Kanban aus Japan. Toyota hatte das System bereits 1947 für sich ent­wi­ckelt. Hieraus erklärt sich auch der Name: eine Zu­sam­men­set­zung der beiden ja­pa­ni­schen Silben kan und ban, was in etwa „Si­gnal­kar­te“ bedeutet. Damals op­ti­mier­te man mithilfe von Kanban den Ma­te­ri­al­fluss. Toyota wollte Engpässe und gleich­zei­tig einen zu hohen Vorrat von Pro­duk­ti­ons­ma­te­ria­li­en vermeiden. Das Ergebnis dieser Be­mü­hun­gen be­zeich­net man heute auch als Pull-Methode, da Nachschub erst dann an­ge­for­dert wird, wenn sich der Vorrat dem Ende zuneigt.

Davon ausgehend eta­blier­te sich die Methode auch in der Software-Ent­wick­lung. Sowohl bei Microsoft als auch bei Corbis (ein weiteres Un­ter­neh­men von Bill Gates) hat man in den 2000er-Jahren die aus der Au­to­in­dus­trie stammende Idee der schlanken Ent­wick­lung um­ge­deu­tet und für sich adaptiert. Statt um Pro­duk­ti­ons­ma­te­ria­li­en ging es jetzt darum, Aufgaben nach der Pull-Methode anzugehen: Erst wenn ein Team Aufgaben ab­ge­ar­bei­tet hat, werden weitere aus dem Backlog gezogen. Auf diese Weise lässt sich auch in vielen anderen Ein­satz­ge­bie­ten der Workflow ver­bes­sern.

De­fi­ni­ti­on Kanban

Der Begriff Kanban entstammt der ja­pa­ni­schen Sprache und bedeutet übersetzt „Si­gnal­kar­te“. Ur­sprüng­lich wurde Kanban in der Pro­duk­ti­on von Toyota ein­ge­setzt und hat von dort die agile Ent­wick­lung in der IT und in anderen Auf­ga­ben­be­rei­chen be­ein­flusst. Ziel ist es, einen stetigen und ge­ord­ne­ten Workflow zu eta­blie­ren. Es ist zudem möglich, Kanban mit anderen agilen Methoden wie Scrum zu kom­bi­nie­ren.

Was ist Kanban?

Wer Kanban in seinem Team einsetzt, möchte den Workflow ver­bes­sern und damit gleich­zei­tig die Pro­duk­ti­vi­tät und die Qualität des End­pro­dukts steigern. Kanban zählt zu den agilen Methoden und macht als solche die Ar­beits­ab­läu­fe sehr viel flexibler. Aufgaben werden in kleine Schritte geteilt und nach­ein­an­der ab­ge­ar­bei­tet. Dazu kennt man in Kanban auch den passenden Slogan: „Stop starting – start finishing!“ Statt also jede Menge Aufgaben an­zu­fan­gen und in Form von Mul­ti­tas­king mehr oder weniger parallel zu be­ar­bei­ten, soll lieber jeder einzelne Schritt zuerst beendet werden, bevor man sich einem neuen widmet.

Die Um­stel­lung auf das neue System funk­tio­niert dabei sehr leicht. Im Gegensatz zu anderen Methoden lässt sich Kanban einfach in be­stehen­de Abläufe in­te­grie­ren. Das macht es auch so offen: Es ist ohne weiteres möglich, neben Kanban auch andere Methoden wie Scrum ein­zu­set­zen.

Wie funk­tio­niert Kanban?

Zentrum der Methode ist das Kanban-Board und damit die Vi­sua­li­sie­rung der Ar­beits­schrit­te. Auf einem für alle Team­mit­glie­der offen ein­seh­ba­ren Board sind alle Aufgaben dar­ge­stellt. Diese Tafel kann bei­spiels­wei­se ein White­board oder eine Pinnwand sein. Denkbar ist auch eine digitale Version des Kanban-Boards innerhalb einer Pro­jekt­ma­nage­ment-App. Einzelne Aufgaben werden als farbige Karten (z. B. in Form von Post-its oder Kar­tei­kar­ten) an dem Brett an­ge­bracht. Wichtig bei der Ge­stal­tung der Tafel und der Karten ist nur, dass sie über­sicht­lich sein müssen.

Das Board selbst teilt man in mehrere Spalten auf – min­des­tens drei. Ganz links befindet sich der Backlog. Hier sammelt man alle noch an­ste­hen­den Aufgaben. An­schlie­ßend folgt eine Spalte, in der sich alle derzeit be­ar­bei­te­ten Aufgaben befinden. Oftmals wird diese Spalte daher als „Work in Progress“ (WiP) oder auch einfach „In Arbeit“ ge­kenn­zeich­net. Sie kann sich auch in mehrere Spalten aufteilen, wenn eine Aufgabe mehrere Schritte durch­läuft, bis sie endgültig ab­ge­schlos­sen ist. Man kann etwa eine Spalte für Reviews und Testing einbauen. Die Aufträge wandern von links nach rechts, bis sie in der finalen Spalte mit allen ab­ge­ar­bei­te­ten Karten ankommen.

Im Ar­beits­all­tag stellt man al­ler­dings fest, dass es Aufgaben gibt, die wichtiger sind als andere. Um eine solche Prio­ri­sie­rung auch auf dem Kanban-Board deutlich zu machen, lassen sich so­ge­nann­te Swimm­la­nes einfügen. Dabei handelt es sich um ho­ri­zon­ta­le Linien, die den Work-in-Progress-Bereich un­ter­tei­len. Bei­spiels­wei­se kann das Team in einem oberen Bereich (einer Fastlane) alle Aufträge einfügen, die schneller als andere be­ar­bei­tet werden müssen, und weniger zeit­in­ten­si­ve Aufträge weiter unten eintragen. So kann sich jedes Team­mit­glied schnell einen Überblick über die der­zei­ti­gen Prio­ri­tä­ten ver­schaf­fen.

Durch diese Dar­stel­lung erhöht man die Trans­pa­renz der Arbeit auf ganz einfache Weise. Mit Kanban ent­schei­det man sich aber nicht nur für eine hilf­rei­che Vi­sua­li­sie­rung des Workflows, sondern wählt auch eine Methode, die die Aufträge begrenzt: Bevor man beginnt, Kanban in der Pro­duk­ti­on ein­zu­set­zen, legt man fest, wie viele Aufträge gleich­zei­tig be­ar­bei­tet werden dürfen. Während es keine Ein­schrän­kung für die beiden äußeren Spalten gibt, hat jede mittlere Spalte einen eigenen Höchst­wert. So darf ein Team pro Schritt nur zwei Karten gleich­zei­tig be­ar­bei­ten, denn Mul­ti­tas­king führt – laut Ver­fech­tern von Kanban – eher zu Ver­zö­ge­run­gen im Ablauf.

Statt wie oft üblich Aufgaben von einem Schritt zum nächsten zu schieben, verfolgt man bei Kanban die Pull-Methode. Die Aufgabe wird also „gezogen“. Erst wenn das Team wieder Ka­pa­zi­tä­ten in der Spalte frei hat, nehmen sich die Mit­ar­bei­ter eine neue Aufgabe aus der Spalte links von ihrer eigenen. Dies bedeutet auch, dass Spalten oftmals zu­sätz­lich zwei­ge­teilt sind: auf der einen Seite Aufgaben, die gerade be­ar­bei­tet werden, und auf der anderen solche Aufgaben, die an die nächste Station wandern können.

Die Be­gren­zung sorgt zudem dafür, dass Ka­pa­zi­tä­ten ef­fi­zi­en­ter verteilt werden können. Besonders wenn eine Aufgabe mehrere Schritte durch­läuft, bevor sie fer­tig­ge­stellt ist, kann es ansonsten zu Staus kommen. Sollte die erste Station schnell arbeiten, es aber im zweiten Schritt zu einem Problem kommen, dürfen die Mit­ar­bei­ter der ersten Station laut Kanban nicht wei­ter­ar­bei­ten. Statt­des­sen nutzen sie die frei ge­wor­de­nen Ka­pa­zi­tä­ten, um der zweiten Station bei der Lösung des Problems zu helfen.

Neben dem Limit für gleich­zei­ti­ge Aufträge können auch weitere Regeln klar und deutlich am Kanban-Board dar­ge­stellt werden. Dazu gehört etwa, ab wann man einen Auftrag als erledigt und damit bereit für die Übergabe an die nächste Station kenn­zeich­nen darf. Es muss zudem klar sein, dass diese Regeln ver­än­der­lich sind. Zu agilen Prozessen gehört es schließ­lich auch, diese re­gel­mä­ßig zu hin­ter­fra­gen und an­zu­pas­sen.

Um den Ar­beits­ab­lauf lang­fris­tig zu ver­bes­sern, ist es wichtig, Feedback aus­zu­tau­schen. Hierfür sieht Kanban re­gel­mä­ßi­ge Meetings (so­ge­nann­te Kadenzen) vor, gibt aber keine direkten Vorgaben, wann oder wie oft diese auftreten sollen. Statt­des­sen gibt der Kanban-Pionier David J. Anderson einige Vor­schlä­ge: ein tägliches Kanban-Meeting (ähnlich dem Daily Scrum), ver­schie­de­ne the­men­spe­zi­fi­sche Reviews und andere Meetings.

Der Austausch unter den Kollegen passt zum ge­ne­rel­len Ver­ständ­nis von Kanban: Es geht immer darum, den Workflow und das Produkt zu ver­bes­sern. Ausgehend vom Ist-Zustand soll das Team nach und nach neue Ver­bes­se­run­gen einbauen, statt einen großen Umschwung zu or­ga­ni­sie­ren. Vielfach wird diese Her­an­ge­hens­wei­se mit der ja­pa­ni­schen Phi­lo­so­phie Kaizen ver­gli­chen. Die Theorie, die sich in­zwi­schen vor allem in der Un­ter­neh­mens­füh­rung wie­der­fin­det, pro­pa­giert die fort­wäh­ren­de Ver­bes­se­rung (Kaizen = jap. für „Wandel zum Besseren“). Ein Endziel hingegen gibt es nicht. Laut Kaizen kann man immer weitere Ver­än­de­run­gen vornehmen.

Insgesamt lassen sich sechs ver­schie­de­ne Praktiken von Kanban ausmachen:

  1. Vi­sua­li­sie­rung: Das Kanban-Board ist eine Vi­sua­li­sie­rung der Ar­beits­ab­läu­fe. Die Ge­stal­tung selbst bleibt aber relativ offen. Wichtig ist nur, dass Stationen klar sind und für jede Spalte das ent­spre­chen­de Limit angezeigt wird.
  2. Li­mi­tie­rung: Jede Spalte darf nur eine maximale Anzahl an Aufträgen enthalten. Erst wenn eine Auf­trags­kar­te weiter nach rechts wandert, darf sich das Team eine neue Karte von links nehmen. Dies führt zwangs­läu­fig zu einem ef­fi­zi­en­te­ren Workflow.
  3. Ma­nage­ment: Während des Ar­beits­pro­zes­ses kann es zu Blockaden und Engpässen kommen. In solchen Si­tua­tio­nen ist es notwendig, den Fokus des Teams darauf zu legen, diese Störungen aus dem Weg zu schaffen. Außerdem kann die Be­ob­ach­tung des Workflows dafür sorgen, Ka­pa­zi­tä­ten lang­fris­tig korrekt zu verteilen.
  4. Re­gu­lie­rung: Explizite Pro­zess­re­geln sind dafür gedacht, die Ar­beits­ab­läu­fe trans­pa­ren­ter und klarer zu gestalten. Zu solchen Regeln gehört z. B. die Fest­le­gung der Limits, aber auch eine De­fi­ni­ti­on, ab wann eine Aufgabe als erledigt gilt. Pro­zess­re­geln müssen ebenfalls ein sicht­ba­rer und ver­än­der­ba­rer Teil des Kanban-Boards sein.
  5. Feedback: Rück­mel­dun­gen sind ein not­wen­di­ger Teil von Ar­beits­ab­läu­fen, denn nur so lassen sich diese ver­bes­sern. Dafür sind re­gel­mä­ßi­ge Meetings vor­ge­se­hen, so­ge­nann­te Kadenzen. Anders als Scrum gibt Kanban aber kein starres Gerüst für solche Treffen.
  6. Kaizen: Prozesse im Team sollen mit Kanban kon­ti­nu­ier­lich ver­bes­sert werden. Die Theorie geht somit davon aus, dass man kein Optimum erreichen kann, sondern dauerhaft an Ver­bes­se­run­gen arbeitet.

Prak­ti­sche Ein­satz­ge­bie­te von Kanban

Kanban lässt sich ganz einfach in jede Team­struk­tur einbauen – und einige Un­ter­neh­men arbeiten ver­mut­lich sogar schon mit einer (ab­ge­speck­ten) Version von Kanban, ohne dies zu wissen. Die Pull-Methode ist schließ­lich eine sehr ein­leuch­ten­de Technik, doch auch die Vi­sua­li­sie­rung an einem Kanban-Board, die Trans­pa­renz der Vorgänge und die klare Li­mi­tie­rung des Mul­ti­tas­kings sind überaus sinnvoll.

Kanban ist nicht nur wegen seines er­heb­li­chen Nutzens für Teams so beliebt, sondern auch aufgrund der einfachen Im­ple­men­tie­rung der Methode. Die Ein­stiegs­bar­rie­re ist sehr niedrig; ein Team oder Un­ter­neh­men muss nur wenige initiale Ver­än­de­run­gen vornehmen, um Kanban um­zu­set­zen: In erster Linie benötigt es ein Kanban-Board, das nach und nach angepasst werden kann, und die klare Ent­schei­dung für die Pull-Methode. Alle Fein­hei­ten kann und soll das Team nach und nach selbst bestimmen: Welche Pro­zess­re­geln legen wir fest? Welche Limits setzen wir an? In welcher Form rea­li­sie­ren wir unser Kanban-Board?

Außerdem ist Kanban generell ein sehr offenes System, das kaum Regeln vorlegt. Weder gibt es feste Zeitpläne noch spe­zi­fi­sche Rollen, wie man es etwa von Scrum kennt. So lässt sich Kanban nahezu auf jede Situation anwenden. Das gilt für große wie kleine Teams; sogar Ein­zel­per­so­nen können mit Kanban ihren per­sön­li­chen Workflow besser or­ga­ni­sie­ren.

  • Kleine Teams: Kleine Mit­ar­bei­ter­grup­pen or­ga­ni­sie­ren sich ohnehin oftmals nach agilen Vor­stel­lun­gen. Um den Ar­beits­pro­zes­sen mehr Struktur zu geben und so die Ef­fek­ti­vi­tät zu steigern, kann hier ganz un­kom­pli­ziert Kanban in­te­griert werden.
  • Große Un­ter­neh­men: Für große und ein­ge­spiel­te Un­ter­neh­men ist es sehr viel schwie­ri­ger, neue Prozesse ein­zu­pfle­gen. Gerade hier eignet sich Kanban als Einstieg. Die leichte und offene Methode kann nach und nach in­te­griert werden.
  • Ein­zel­per­so­nen: Egal ob man Exis­tenz­grün­der oder Free­lan­cer ist, auch Ein­zel­per­so­nen hilft Kanban bei der Or­ga­ni­sa­ti­on der Aufgaben.

In welcher Grö­ßen­ord­nung man Kanban in einem Un­ter­neh­men einsetzt, kann in so­ge­nann­ten Flight Levels dar­ge­stellt werden. Dr. Klaus Leopold, ein weiterer Kanban-Pionier, ver­deut­licht mit den drei ver­schie­de­nen Stufen, auf welchen Ebenen Kanban die Ar­beits­ab­läu­fe un­ter­stüt­zen kann:

  • Flight Level 1 – Operative Ebene: Auf dieser Flughöhe – der nied­rigs­ten – befindet sich das Team von Spe­zia­lis­ten, das jeden Tag damit be­schäf­tigt ist, das Produkt an­zu­fer­ti­gen oder die Dienst­leis­tung be­reit­zu­stel­len. Oftmals erstellen diese Teams auch nur einen Teil­aspekt eines Ge­samt­pro­dukts. Das heißt im Um­kehr­schluss: Aufgaben kommen bei ihnen nur als Pakete an und müssen dort in kleinere Teil­auf­ga­ben un­ter­glie­dert werden, bevor man diese be­ar­bei­tet. Sollte al­ler­dings nur ein einziges Team im Un­ter­neh­men nach Kanban arbeiten, kann es zu Problemen mit anderen Gruppen kommen, die eine andere, nichta­gi­le Methode wie das Was­ser­fall­mo­dell verfolgen.
  • Flight Level 2 – Ko­or­di­na­ti­on: Auf der zweiten Ebene geht es deshalb um die Ko­or­di­na­ti­on der Teams un­ter­ein­an­der. Mit Kanban stellt man hier sicher, dass alle Teams Aufgaben in der richtigen Rei­hen­fol­ge be­ar­bei­ten und ständig mit Arbeit versorgt werden. So tritt bei einzelnen Teams weder Leerlauf noch Über­for­de­rung auf.
  • Flight Level 3 – Stra­te­gi­sches Portfolio-Ma­nage­ment: Die dritte Ebene erreicht man dann, wenn man nicht nur ein Projekt mit Kanban ko­or­di­niert, sondern das komplette Portfolio mit der agilen Methode or­ga­ni­siert. So kann das Ma­nage­ment ent­schei­den, wann welche Projekte gestartet werden. Dies kann die Abläufe im kom­plet­ten Un­ter­neh­men ver­bes­sern.

Schließ­lich ist Kanban so offen, dass es sich ohne weiteres auch mit anderen Methoden ver­knüp­fen lässt. Sehr beliebt ist eine Kom­bi­na­ti­on von Kanban und Scrum. Scrum selbst ist ein eher re­strik­ti­ves System; das Framework gibt einem Team de­tail­lier­te Vorgaben. Da Kanban al­ler­dings offen gehalten ist, lässt es sich leicht in den re­gel­mä­ßi­gen Scrum-Prozess in­te­grie­ren.

Un­ter­schie­de zwischen beiden Methoden gibt es dennoch: Während bei Scrum das Team im Vor­der­grund steht, legt Kanban den Fokus auf den Fer­ti­gungs­pro­zess und das Ergebnis für den Kunden. In anderen Punkten ergänzen sich beide Systeme: Die hoch­fre­quen­ten und fest in­stal­lier­ten Meetings, die Scrum unter anderem ausmachen, werden in Kanban zwar nicht gefordert, passen aber sehr gut zum Feedback-Gedanken der Methode.

Vor- und Nachteile von Kanban

Vor allem die Vorteile von Kanban sind bei der Be­schrei­bung der Methode bereits her­aus­ge­stellt worden: einfache In­te­gra­ti­on, stetige Ver­bes­se­rung der Ar­beits­ab­läu­fe, erhöhte Trans­pa­renz. Doch es gibt auch Aspekte, die Teams ab­schre­cken. Es ist z. B. zwingend notwendig, dass sich die Arbeit auch tat­säch­lich in Schritte aufteilen lässt. Wenn dies nicht der Fall ist, ergibt das komplette System keinen Sinn.

Ein weiterer Grund, warum die Methode nicht für jedes Team die richtige Wahl ist, ergibt sich aus einem Vorteil des Systems: Die Work-in-Progress-Li­mi­tie­run­gen sorgen dafür, dass Probleme an einer Station schnell sichtbar werden und Ka­pa­zi­tä­ten ver­scho­ben werden können. Das ist al­ler­dings nur möglich, wenn man Ka­pa­zi­tä­ten auch tat­säch­lich ver­schie­ben kann. Team­mit­glie­der müssen in der Lage sein, an ver­schie­de­nen Stationen zu arbeiten. Ansonsten kommt es zu Sack­gas­sen und Über­for­de­rung auf der einen und Leer­läu­fen auf der anderen Seite – genau das Gegenteil von dem, was man mit Kanban erreichen möchte.

Vorteile Nachteile
Offenes Prinzip Bedarf über­grei­fen­der Kom­pe­ten­zen
Mehr Trans­pa­renz Fehlende Zeit­pla­nung kann Probleme bei Deadlines erzeugen
Gleich­mä­ßi­ger Workflow Arbeit muss sich in einzelne Schritte aufteilen lassen
Stetige Ver­bes­se­rung
Lässt sich in vielen Si­tua­tio­nen anwenden
Einfache In­te­gra­ti­on
Zum Hauptmenü