Leseprobe

Software-Kanban – eine Einführung

von Arne Roock

Um konkurrenzfähig zu bleiben, ist eine stetige Optimierung der Arbeitsprozesse notwendig. In der Software-Entwicklung gibt es dafür mit Software-Kanban eine einfache Methode, um den bestehenden Arbeitsprozess für das Team transparent darzustellen und so Verbesserungsansätze aufzuspüren. Arne Roock stellt in diesem Beitrag Software-Kanban sowie dessen Prinzipien vor und zeigt an einem konkreten Beispiel, wie sich die Methode einsetzen lässt. Der Grundgedanke von Software-Kanban kann aber auch auf andere Bereiche übertragen werden.

Viele von uns waren schon an groß angekündigten Änderungsvorhaben beteiligt – und haben auch erlebt, wie diese gescheitert sind. Große, revolutionäre Veränderungen zum Erfolg zu führen, ist schwierig und scheitert oft an der mangelnden Akzeptanz der Betroffenen. In der Software-Entwicklung und -Wartung bietet "Software-Kanban" für Change-Projekte einen interessanten Ansatz: Denn hier wird der Ist-Zustand des Arbeitsprozesses als Ausgangspunkt betrachtet und darauf aufbauend Änderungen in kleinen Schritten vorgenommen. Dabei werden einige Elemente aus dem Lean Thinking mit Ideen der Engpasstheorie und der flussbasierten Produktentwicklung kombiniert.

Dieser Artikel stellt das Prinzip "Software-Kanban" anhand eines Beispiels vor und diskutiert dessen Stärken und Schwächen. Der Beitrag richtet sich vornehmlich an Führungskräfte und Projektmanager aus der IT-Branche; der Grundgedanke, der dahinter steckt, lässt sich aber auch auf andere Industriezweige anwenden.

Herr Paulsen probiert was aus...

Herr Paulsen ist Entwicklungsleiter eines renommierten Software-Hauses, das eine Warenwirtschaftssoftware für mittelständische Unternehmen entwickelt. Obwohl die Zahlen noch recht gut aussehen, bahnen sich immer mehr Probleme an: Die Konkurrenz hat gerade eine neue Version ihres Produkts mit einigen wirklich innovativen Features auf den Markt gebracht, wodurch ein deutlicher Verlust an Kunden droht. Gleichzeitig war das letzte eigene Release kein großer Erfolg, denn es enthielt eine Menge Fehler, so dass jetzt die Support-Hotlines heiß laufen und die Entwicklungsteams überwiegend mit Wartungsarbeiten beschäftigt sind. Es muss sich also etwas ändern. Aber was?

Die nächstliegende Lösung bestünde wohl darin, mehr Entwickler einzustellen. Das hatte Herr Paulsen jedoch schon vor einem Jahr getan und erstaunlicherweise hatte sich dadurch kaum etwas verbessert. Außerdem würde sein Chef Neueinstellungen kaum zustimmen. Vielleicht sollte er eine groß angelegte Qualitätsoffensive starten, mit motivierenden Postern an den Wänden? Er könnte auch die aktuell verwendeten Tools und Frameworks prüfen, ob diese überhaupt noch zeitgemäß sind? Doch bei all diesen Überlegungen beschleicht ihn das ungute Gefühl, damit auch nicht die gewünschten Veränderungen herbeizuführen – zu oft schon sind ähnliche Aktionen ohne Erfolg geblieben.

Da fällt ihm ein, dass er vor einiger Zeit von Software-Kanban gelesen hat, einem Ansatz, mit dem sich kontinuierlich Verbesserungen in kleinen Schritten verwirklichen lassen. Er informiert sich mehr über Software-Kanban und beschließt, dieses Prinzip in seiner Abteilung auszuprobieren.

Was ist Kanban?

Kanban in der Fertigung

Ursprünglich stammt Kanban aus der Fertigung und stellt neben "Jidoka" (intelligente Automatisierung des Produktionsprozesses) eine der beiden Säulen des Toyota Production Systems dar. Bei Kanban geht es darum, Lagerbestände zu reduzieren und zu gewährleisten, dass Zwischenerzeugnisse sich stets in der richtigen Anzahl zur richtigen Zeit am richtigen Ort befinden und dadurch weder Überproduktion noch Mangel entsteht.

Das Mittel dafür ist sehr einfach: Sobald der Bestand eines bestimmten Zwischenerzeugnisses unter eine definierte Anzahl sinkt (aber erst dann), wird dem vorgelagerten Produktionsschritt signalisiert, dass er nachproduzieren soll. Dafür werden Karten verwendet (der Begriff "Kanban" bedeutet ursprünglich "Signalkarte") auf denen die Art des Zwischenerzeugnisses, die benötigte Menge und einige weitere Informationen vermerkt sind (in vielen Bereichen wurden die Karten inzwischen durch vollständig elektronische Systeme abgelöst).

Software-Kanban

In der Automobilindustrie und in anderen Bereichen der Fertigung, wie z.B. dem Werkzeugbau, ist Kanban seit Jahrzehnten im Einsatz. Allerdings lässt sich diese Technik nicht einfach eins zu eins auf die Software-Entwicklung (bzw. -Wartung und -Betrieb) übertragen – denn diese ist keine Fließbandproduktion. Features für ein neues Software-System sind keine Einzelteile, die einfach nur nachbestellt und in der richtigen Reihenfolge zusammengefügt werden müssen. Vielmehr zeichnet sich Software-Entwicklung durch ein hohes Maß an Kreativität, Ungewissheit und somit auch Variabilität aus: Einige Anforderungen lassen sich in wenigen Stunden umsetzen, andere dauern Wochen, Fachexperten und Spezialisten sind ungleichmäßig verfügbar usw.

Dennoch lassen sich für die Software-Entwicklung sehr wohl einige allgemeine Kanban-Prinzipien aus der Fertigung übernehmen. Dies ist zum einen das Pull-Prinzip (genaue Erklärung siehe unten) und zum anderen die Vorstellung von "Flow": Die Arbeit soll möglichst gleichmäßig die einzelnen Prozessschritte durchlaufen und dabei möglichst wenig Wartezeiten aufweisen.

Wenn wir heute in der IT von Kanban sprechen, meinen wir nicht das eben beschriebene Produktions-Kanban, sondern sprechen von Software-Kanban. Dabei handelt es sich um eine Methode des "Evolutionären Change Managements", die von David Anderson entwickelt wurde. "Evolutionär" ist Kanban aus zwei Gründen:

  1. Ausgangspunkt ist der Ist-Zustand, der schrittweise verbessert werden soll; einen definierten Endzustand gibt es nicht. Ebenso wie die Evolution niemals endet, ist auch in Software-Kanban eine ständige Weiterentwicklung vorgesehen.
  2. Änderungen werden stets in kleinen Schritten vorgenommen, während große, einschneidende Verbesserungen nicht vorgesehen sind. So entstehen Systeme, die einzigartig und für den jeweiligen Kontext optimiert sind.

Anmerkung: Wenn nachfolgend in diesem Artikel von Kanban die Rede ist, ist ausschließlich Software-Kanban und nicht das Kanban aus der Fertigung gemeint.

Was bringt Software-Kanban

Kanban macht Probleme verschiedener Art im Arbeitsablauf schnell sichtbar und regt zu Diskussionen über mögliche Lösungen und Verbesserungsvorschläge an. Wie sich immer wieder zeigt, lassen sich mit Hilfe von Kanban insbesondere die folgenden Probleme erkennen und beheben:

  • zu lange Durchlaufzeiten verkürzen
  • Engpässe erkennen und beseitigen, so dass ein gleichmäßiger Fluss der Arbeit entsteht
  • Überlastung einzelner Mitarbeiter oder ganzer Teams abbauen, sodass ein nachhaltiges Arbeitstempo entsteht
  • Die Vorhersagbarkeit des Prozesses verbessern und somit die Kundenzufriedenheit erhöhen. So ermöglicht es Kanban mit der Zeit, die Bearbeitungsdauer für neue Aufgaben gut einschätzen zu können.
  • Akzeptanz der Beteiligten für Änderungen am Prozess erhöhen

Prinzipien von Software-Kanban

Die Funktionsweise von Kanban zeichnet sich im Kern durch vier Prinzipien aus:

  1. Visualisiere den Ist-Zustand auf einem "Kanban-Board"
    Diese Visualisierung sollte möglichst einfach und für alle Teammitglieder gut sichtbar sein. Für jeden einzelnen Arbeitsschritt (also z.B. "Analyse" oder "Entwicklung") wird auf einem Board eine Spalte angelegt. Die Aufgaben werden auf Karteikarten oder Haftnotizen geschrieben und durchlaufen als "Tickets" die Prozessschritte von links nach rechts (genaue Erklärung des Kanban-Boards siehe unten). Wichtig ist, dass man keinen Wunschzustand modelliert, sondern den Workflow, wie er aktuell tatsächlich besteht. Das Board kann dabei ebenso gut ein Whiteboard sein wie auch eine Trennwand, Glasscheibe o.ä.
  2. Limitiere die Arbeit auf die Kapazität, die das System tatsächlich abarbeiten kann
    Hierbei hat es sich als sinnvoll erwiesen, die Zahl der Tickets pro Prozessschritt zu begrenzen, um sichtbar zu machen, wo sich Arbeit immer wieder aufstaut (Engpass). Diese "Limits" werden dann als Zahlen über die jeweiligen Spaltenüberschriften am Board geschrieben. Die Menge an begonnenen Aufgaben wird als WIP bezeichnet ("Work in Progress"). Besitzt ein Arbeitsschritt z.B. den WIP gleich drei, dürfen also in diesem Arbeitsschritt immer nur drei Aufgaben gleichzeitig bearbeitet werden.
  3. Führe ein "Pull-System" ein
    Aufgaben werden nicht mehr zugewiesen, sondern eigenverantwortlich von den Teammitgliedern "gezogen", also von selbst eingeholt, sobald im System die nötigen Kapazitäten frei sind. Dadurch lässt sich Überproduktion vermeiden und die Qualität erhöhen. Dabei gibt die Führungsebene keine Zeitlimits vor, bis wann die Aufgabe erledigt sein soll, sondern räumt den Mitarbeitern ausreichend Zeit für die Bearbeitung der Aufgabe ein. Die Führungskräfte müssen hier also ihren Mitarbeitern vertrauen – ein wichtiger Grundgedanke in Kanban. Darüber hinaus ermöglicht Pull, kombiniert mit WIP-Limits, eine nachhaltige Entwicklungsgeschwindigkeit.
  4. Denke systemisch
    Nicht Auslastung ist die entscheidende Größe, sondern der Durchsatz, also die Fertigstellung möglichst vieler Aufgaben mit hoher Qualität, die einen Wert für den Kunden bedeuten. Dafür muss immer das gesamte System im Auge behalten werden. Lokale Optimierungen sollte man also vermeiden, z.B. wenn die Entwicklungsabteilung ihre lokale Durchlaufzeit dadurch verbessert, dass sie Code in schlechterer Qualität abliefert. Dies verschlechtert mittelfristig die Leistung des Gesamtsystems, weil immer mehr Nacharbeiten notwendig sind.

Kontinuierliche Verbesserungen

Zu diesen Prinzipien kommt ein weiterer entscheidender Punkt, der leider häufig nicht richtig ernst genommen wird und wodurch jede Kanban-Einführung zum Scheitern verurteilt ist: Die kontinuierliche Verbesserung (auch "Kaizen" genannt). Da in Kanban immer wieder kleine Anpassungen des Prozesses vorgenommen werden, stellen sich große Verbesserungen nicht von heute auf morgen ein. Aus diesem Grund ist auch viel Geduld gefragt. Außerdem sind kontinuierliche Verbesserungen auch deshalb nötig, weil wir uns in der Software-Entwicklung in einem hochgradig flexiblen Umfeld bewegen. Es gibt verschiedene Möglichkeiten, um Verbesserungen anzustoßen, wobei die beiden wichtigsten "Feedback-Meetings" und "Messungen" sind:

Feedback-Meetings

Kanban-Teams treffen sich täglich zu einem kurzen "Standup Meeting" vor dem Board (das Meeting findet im Stehen statt, damit es möglichst kurz gehalten wird). Bei diesem Meeting geht das Team gemeinsam die Tickets auf dem Board durch, damit jedem Teammitglied der aktuelle Status klar ist. Und Tickets, die blockiert sind (z.B. weil Zuarbeiten aus einer anderen Abteilung nötig sind), werden besonders in den Fokus genommen, um diese Blockaden zu lösen. In größeren Abständen (z.B. einen Tag im Monat) werden außerdem Retrospektiven durchgeführt, in denen sich das Team eine längere Auszeit nimmt, um den aktuellen Arbeitsprozess zu reflektieren, Problemen auf den Grund zu gehen und Verbesserungsmöglichkeiten zu diskutieren.

Messungen

Mit Messungen ist in erster Linie gemeint, die durchschnittliche Durchlaufzeit eines Tickets zu ermitteln. Im Sinne der kontinuierlichen Verbesserung ist es wichtig, sich immer wieder die Frage zu stellen: "Was können wir tun, um die Durchlaufzeit noch weiter zu verkürzen?" Die Erfahrung zeigt jedoch, dass sich viele Probleme (z.B. schlechte Qualität oder mangelhafte interne Abstimmung) offenbaren, sobald man die Durchlaufzeit verringert. Solche Probleme haben häufig auf den ersten Blick nichts mit der Geschwindigkeit zu tun, müssen aber bei einer Verkürzung der Durchlaufzeit identifiziert und sofort angegangen werden.

Neben der Durchlaufzeit werden für die Messung häufig weitere Kennzahlen erfasst, wie die Menge an WIP, Fehlerraten oder die Termintreue. Auch die Anzahl der Blockaden lässt sich als Messung verwenden, also die Frage, an wie vielen Tickets momentan nicht weitergearbeitet werden kann, weil sie durch Probleme blockiert sind. Generell gilt, dass man sich nur auf die Messungen konzentrieren sollte, von denen man sich einen wirklichen Erkenntnisgewinn für weitere Verbesserungen verspricht. Die Messungen sollten möglichst einfach sein, sich schnell aktualisieren lassen und die Ergebnisse für jeden gut zugänglich sein.

Einführung von Software-Kanban

Wie kann nun eine Kanban-Einführung aussehen, und welche Effekte können dabei auftreten? Um uns dies zu verdeutlichen, kehren wir zu Herrn Paulsen und seinem Team zurück:

Herr Paulsen befestigt ein riesiges Whiteboard direkt neben der Kaffeemaschine an der Wand. Dann zeichnet er auf das Board die vier Spalten "To Do", "Analyse", "Entwicklung" und "Erledigt", die den aktuellen Arbeitsprozess widerspiegeln sollen. Mit kleinen Magneten heftet er in die unterschiedlichen Spalten Karteikarten. Jede Karteikarte steht für eine Aufgabe, an der das Team gerade arbeitet. Mit kurzen Worten ist eine möglichst sprechende Bezeichnung der Aufgabe auf die Karte geschrieben, z.B. "Der Benutzer kann die Liste offener Bestellungen nach Artikelnummer sortieren". Das Whiteboard sieht dann in etwa aus wie in Bild 1.

Bild 1: Initiales Kanban-Board, auf dem der "offizielle" Stand der Aufgaben abgebildet ist.

Nun schreibt Herr Paulsen an alle 15 Mitarbeiter eine E-Mail, in der er um ein kurzes Treffen Donnerstagmorgen bittet. Auf dem Treffen erzählt er seinem Team, dass ihm das elektronische Projektmanagement-Tool zu unübersichtlich geworden ist und dass es doch viel besser wäre, wenn auch "live" im Büro für jedermann sichtbar ist, an welchen Aufgaben gerade gearbeitet wird. Daher also dieses Board. Um zwei Kleinigkeiten bittet er die Kollegen noch: Wenn sie eine Aufgabe abgeschlossen haben, sollen sie bitte die entsprechende Karteikarte in die nächste Spalte hängen. Und das gesamte Team möge sich jeden Morgen um 9.00 Uhr für 10 bis 15 Minuten vor dem Board versammeln, um sich gegenseitig auf den neuesten Stand zu bringen.

Eigentlich möchte Herr Paulsen die Runde jetzt auflösen, aber er merkt, dass den Kollegen noch etwas unter den Nägeln brennt. Als er nachfragt, erhält er die Antwort, dass da wohl noch einige Aufgaben am Board fehlen. Also bittet er jeden, sich Zettel und Stift zu nehmen und das Board zu vervollständigen. Nach einigen Minuten wird der Blick auf das Board wieder frei, und es tritt eine merkwürdige Stille ein: Mehr als doppelt so viele Karten wie zuvor hängen jetzt am Board! Da ist offensichtlich ein großes Problem zutage getreten, das Herr Paulsen erst einmal verdauen muss. Er dankt allen Mitarbeitern und verabschiedet sich. Vorher bittet er noch darum, dass jeder sein Kürzel auf diejenigen Karten schreibt, an denen er arbeitet.

Als Herr Paulsen sich zwei Stunden später einen neuen Kaffee holt, sieht er sich das Board noch einmal genauer an. Besonders zwei Dinge erstaunen ihn: Zum einen hängen dort jede Menge Karten, die laut Tracking-Tool schon lange erledigt sein sollten. Dazu befragt er einen Entwickler, der sich auch gerade einen Kaffee holen möchte und vor dem Board steht. Dieser antwortet ihm: "Die zusätzlichen Karten waren tatsächlich schon fertig. Aber nur scheinbar, denn bei jeder einzelnen Aufgabe wurden Fehler von der Qualitätssicherung gefunden, so dass sie nachbearbeitet werden müssen. In unserem elektronischen Tool ist es sehr umständlich, ein abgeschlossenes Ticket wieder zu öffnen, also erledigen wir solche Wartungsaufgaben in der Regel nebenbei." Diesen Umstand möchte Herr Paulsen auch visualisiert haben, also klebt er auf alle Wartungsaufgaben einen roten Punkt.

Der andere merkwürdige Aspekt betrifft die Kürzel auf den Karten: Offensichtlich arbeiten die drei "alten Hasen" in seinem Team fokussiert an wenigen Aufgaben, während die neueren Kollegen sich verzetteln und etliche Karten gleichzeitig bearbeiten. Aber die Antwort des Entwicklers widerlegt diese Vermutung: "Normalerweise arbeitet jeder Entwickler so lange an einer Aufgabe, bis sie erledigt ist. Außer er kommt allein nicht weiter. Dann braucht er in der Regel Hilfe von einem erfahrenen Entwickler. Weil diese aber gleichzeitig auch bei sehr vielen anderen Aufgaben helfen müssen, bekommt man die Hilfe nicht sofort. Um in dieser Zeit nicht untätig herumzusitzen, fängt man dann schon mal die nächste Aufgabe an." Das führt dann dazu, dass die meisten Entwickler an mehreren Aufgaben parallel arbeiten.

Es werden also durch die Visualisierung am Kanban-Board immer neue Probleme sichtbar. Aber jetzt möchte Herr Paulsen wirklich das ganze Ausmaß transparent haben. Also holt er die drei Entwickler ans Board, die schon seit über zehn Jahren am System arbeiten und auch den letzten Winkel kennen. Diese bittet er, ihr Kürzel auch auf die Karten zu schreiben, bei denen sie "nur ganz kurz mal mithelfen". Nach fünf Minuten hat sich die Befürchtung von Herrn Paulsen bestätigt: Fast jede Karte trägt nun das Kürzel eines der drei Entwickler!

Visualisierung

Was der Entwicklungsleiter in unserem Beispiel bisher getan hat, ist trivial, hat aber eine enorme Wirkung: Er hat für Transparenz über den tatsächlichen Zustand in der Entwicklung gesorgt. Für die Visualisierung reichen ein Whiteboard und ein paar Karteikarten plus Magnete aus. Was Herr Paulsen nun zu sehen bekommt, gefällt ihm nicht – aber so sieht die Realität leider aus. Was er mit dieser unangenehmen Realität anfängt, liegt an ihm. Wenn er die eben gewonnene Transparenz möglichst schnell wieder zerstören möchte, sollte er jetzt vor versammelter Mannschaft nach Schuldigen suchen und das Team auffordern, dass es endlich seine Arbeit vernünftig verrichten soll. Dann kann er sicher sein, dass Probleme ab sofort garantiert unter den Teppich gekehrt werden! Möchte er hingegen wirkliche Verbesserungen erreichen, dann sollte er versuchen, das Team mit ins Boot zu holen und gemeinsam nach Verbesserungsmaßnahmen zu suchen.

Am nächsten Morgen trifft sich das gesamte Team vor dem Board. Herr Paulsen stellt nun eine offene Frage an alle: "Es ist ganz offensichtlich, dass wir uns Wissensinseln aufgebaut haben. Dadurch verhindern wir, Aufgaben so schnell wie möglich zu erledigen, weil sie nur von einer bestimmten Person bearbeitet werden können. Und was passiert, wenn einer unserer "alten Hasen" einmal länger ausfällt, möchte ich mir gar nicht vorstellen. Was können wir tun, um das Wissen im gesamten Team zu verteilen?" Nach einer Weile kommt ein Vorschlag aus der Runde: "Wir sollten vereinbaren, dass an jedem Ticket immer ein alter Hase zusammen mit einigen nicht so erfahrenen Entwicklern arbeiten muss. So lange, bis sich das Wissen einigermaßen gleichmäßig im Team verteilt hat."

Limitierung

Das hört sich zunächst einmal verrückt an; denn es würde bedeuten, dass das gesamte Team maximal an drei Aufgaben gleichzeitig arbeiten könnte. Auf der anderen Seite: Fakt ist bereits jetzt, dass die erfahrenen Entwickler an jeder Aufgabe beteiligt sind – nur dass sie momentan ihr Wissen nicht gezielt an die Kollegen weitergeben. Also sollten sie es ausprobieren. Neben dem Whiteboard wird ein Flipchart aufgehängt, auf dem die neue Regel festgehalten wird: "Jedes Ticket wird gemeinsam von einem erfahrenen und mehreren 'neuen' Entwicklern bearbeitet."

Auf dem Board wird über die Spalte "Entwicklung" eine "3" geschrieben – dies ist das WIP-Limit, das angibt, wie viele Aufgaben gleichzeitig bearbeitet werden dürfen. Erst wenn eine Aufgabe erledigt ist, darf sich ein Team um einen erfahrenen Entwickler auf ein neues Ticket stürzen. Jetzt stellt sich natürlich die Frage, was mit den restlichen Tickets geschieht, die ja vorerst nicht bearbeitet werden dürfen. Das Team diskutiert verschiedene Möglichkeiten und entscheidet sich dann dafür, sich auf die drei wichtigsten Aufgaben zu konzentrieren und alle anderen erst einmal in einer eigenen Spalte zu "parken". Für die geparkten Aufgaben wird "First in First out Queuing" vereinbart – die ältesten Tickets werden also zuerst abgearbeitet. Nun hat sich das Board schon wesentlich verändert (Bild 2).

Bild 2: Das Kanban-Board hat sich weiterentwickelt: Die Anzahl der Tickets in der Entwicklung wurde limitiert, und rote Punkte zeigen an, dass Karten in die Entwicklung zurückgegeben wurden, weil die Qualitätssicherung Fehler gefunden hat.

Das ist sicherlich noch nicht ideal, und das Board wird sich in den nächsten Monaten garantiert noch mehrmals verändern. Aber schon jetzt wird auf einen Blick deutlich, dass es einen riesigen Stau vor der Entwicklung gibt, der erst einmal aufgelöst werden muss, bevor neue Aufgaben angegangen werden können. Weiterhin gibt es offensichtlich ein Qualitätsproblem, wie die roten Punkte auf den Karten zeigen.

Gründe für die Limitierung

Das Team hat sich dazu entschlossen, die Menge an paralleler Arbeit zu begrenzen, um Wissensinseln abzubauen. Das ist eine sinnvolle Maßnahme, die mit großer Wahrscheinlichkeit zum Erfolg führen wird. Dieser Vorteil wird vermutlich mit einem vorübergehenden Performance-Rückgang erkauft werden. Dies liegt daran, dass die meisten Aufgaben zwar gut zu zweit bearbeitet werden können, dass sich aber bei weiteren Beteiligten die Abstimmungsaufwände stark erhöhen werden.

Auf der anderen Seite sind diese Einbußen oft bei weitem nicht so groß wie befürchtet. Denn was das Team durch die erhöhten Abstimmungsaufwände (anfangs) verliert, kann es (mindestens zum Teil) durch höhere Qualität und dadurch weniger Nacharbeiten wieder gutmachen. Langfristig wird sich die Gesamt-Geschwindigkeit des Teams in jedem Fall erhöhen, weil es weniger Expertentum gibt und sich somit die Arbeit gleichmäßiger im Team verteilt.

In unserem Beispiel steht die Verteilung von Wissen im Fokus, und diese wird durch ein sehr strenges WIP-Limit und die zugehörige Teamregel forciert. Darüber hinaus gibt es aber weitere, gewichtige Gründe, für eine Begrenzung paralleler Arbeit:

  1. Geschwindigkeit: Nach dem stochastischen Gesetz "Little's Law" (benannt nach dem amerikanischen Professor John Little, s. auch Reinertsen 2009) errechnet sich die Durchlaufzeit ("Lead Time") als Quotient aus dem WIP und dem Durchsatz (Bild 3). Wenn das Team also Aufgaben schneller erledigen soll, kann der Teamleiter entweder den Durchsatz erhöhen (was in der Regel sehr schwierig ist) oder den WIP reduzieren (was in der Regel sehr einfach ist)

    Angenommen, ein Team erledigt 10 Tickets pro Woche (Durchsatz = 10) und arbeitet an allen 10 Tickets gleichzeitig (WIP = 10). Dann beträgt die durchschnittliche Durchlaufzeit für ein Ticket eine Woche (10/10 = 1). Halbiert man jetzt den WIP, so verkürzt sich die Durchlaufzeit für ein Ticket durchschnittlich auf eine halbe Woche (5/10 = 0,5). Allerdings muss man bei einer weiteren Reduzierung des WIP berücksichtigen, dass ab einem bestimmten Zeitpunkt die Kosten relevant ansteigen, wenn z.B. drei bis vier Entwickler gleichzeitig an einer Aufgabe arbeiten. Es gibt also für jeden Bereich und jedes Team ein Optimum an WIP

    Bild 3: Nach Little's Law lässt sich die Durchlaufzeit leicht verkürzen, indem die Anzahl begonnener Aufgaben reduziert wird.

  2. Kontextwechsel vermeiden: Jeder weiß aus eigener Erfahrung, wie viel Zeit wir benötigen, um uns in andere Kontexte einzuarbeiten. Oft reicht schon ein Telefonanruf, um uns komplett aus einer Aufgabe herauszureißen. Die Zeit, die für einen Kontextwechsel benötigt wird, ist häufig verschwendet.
  3. Qualität: Ein geringerer WIP führt zu weniger Fehlern, was im Wesentlichen an den schädlichen Auswirkungen von Multitasking liegt: Jeder weiß aus eigener Erfahrung, dass es nicht nur sehr lange dauert, sich wieder in eine Aufgabe hineinzudenken, wenn wir durch einen Telefonanruf unterbrochen werden, sondern auch dass wir durch solche Kontextwechsel mehr Fehler machen.
  4. Überlastung vermeiden: Zu viele parallele Aufgaben führen zu Stress und unnötigen Fehlern. Sinnvoll gesetzte WIP-Limits ermöglichen eine Entwicklungsgeschwindigkeit, die das Team dauerhaft einhalten kann. Die richtige Zahl an WIP-Limits für seine individuellen Bedürfnisse lässt sich am besten durch Ausprobieren und den gegenseitigen Austausch im Team ermitteln (s. auch Andrezak et al., "Schützt das Team!", 2010).
  5. Engpässe vermeiden: Die Engpasstheorie lehrt uns, dass die Gesamtleistung eines Systems immer durch die Leistung am Engpass limitiert ist. In unserem Fall stellen die erfahrenen Entwickler den Engpass dar. Es ist vollkommen sinnlos, dass die anderen Entwickler immer weitere Aufgaben beginnen und sie dann oben auf den großen Berg legen, den die erfahrenen Kollegen abarbeiten müssen.

Leerlaufzeiten sinnvoll nutzen

In unserem Beispiel ist ein (sehr enges) WIP-Limit für den Arbeitsschritt "Entwicklung" definiert. Dadurch bildet sich schnell ein Stau vor diesem Engpass, und die unerfahrenen Kollegen dürfen keine neuen Aufgaben mehr beginnen. Das ist schlecht für die Auslastung. Aber gut für das System! Denn nun entstehen bei einigen Entwicklern Leerlaufzeiten – und das ist nicht negativ, sondern positiv zu bewerten.

Denn was tun die Entwickler mit diesen freien Zeiten? Auch wenn wir es oft nicht glauben: Sie werden sie sinnvoll nutzen! Dazu haben sie viele Möglichkeiten: Sie können ein lange liegengebliebenes Refactoring durchführen. Oder sich endlich einmal mit dem neuen Framework beschäftigen, was sie schon lange einmal tun wollten. Oder anfangen, den Build-Prozess zu automatisieren. Oder ein paar Fachartikel lesen. Oder sie machen sich Gedanken darüber, wie sie die Kollegen am Engpass unterstützen können und wie sich der Prozess generell verbessern lässt. Und sobald sie wissen, dass sie mit ihren Aufgaben keine Eile haben, werden sie (wahrscheinlich) mehr Zeit in Qualität investieren. Wohl gemerkt: Das alles kann zusätzlich geschehen, und der Gesamtdurchsatz bleibt trotzdem gleich (und erhöht sich mittelfristig sogar durch die erarbeiteten Verbesserungsmaßnahmen).

WIP-Limits festlegen

Wie legt man die initialen WIP-Limits für einen Prozessschritt fest? Hierfür gibt es leider keine allgemeingültige Formel, sondern das Team muss nach seiner spezifischen Situation entscheiden und die Limits dann immer wieder mit Bedacht anpassen. Häufig empfiehlt es sich, mit eher großzügigen Limits zu beginnen und diese dann schrittweise zu reduzieren. Wenn Entwickler einzeln an Aufgaben arbeiten, ist es sinnvoll, die Anzahl der Entwickler plus eine Reserve von zwei oder drei Aufgaben als WIP-Limit festzulegen, damit das System nicht sofort ins Stocken gerät, sobald eine Aufgabe blockiert ist. Will man allerdings den Abbau von Wissensinseln (so wie in unserem Beispiel) erzwingen oder liegt die oberste Priorität auf einer deutlichen Verbesserung der Qualität, so können auch sehr strikte Limits sinnvoll sein.

Das Zulassen von Leerlaufzeiten erfordert ein Umdenken. Denn das klassische Management lehrt uns, dass wir die Auslastung einzelner Mitarbeiter optimieren sollen. Lean Thinking strebt hingegen an, die Durchlaufzeiten für einzelne Aufgaben zu optimieren, qualitativ hochwertige Arbeitsergebnisse zu erhalten und somit den Wert für den Kunden zu erhöhen. Dafür spielt es keine Rolle, ob einzelne Mitarbeiter ausgelastet sind oder nicht. Aber was tun Manager in der Regel, sobald deutlich wird, dass es Leerlaufzeiten gibt? Sie stecken die betroffenen Mitarbeiter in weitere Projekte. Dadurch belasten sie sich nicht nur mit den schädlichen Auswirkungen des Multitaskings (längere Durchlaufzeiten, Fehler durch Kontextwechsel), sondern sie berauben sich auch der Verbesserungspotenziale, die Mitarbeiter durch die Leerlaufzeiten entwickeln können. Aus diesem Grund muss auch das Top-Management hinter Software-Kanban stehen. Es muss die Prinzipien und die Vorgehensweise von Kanban verstehen und akzeptieren, da ansonsten Kanban nicht funktionieren kann.

Das Pull-Prinzip

Toyota hat es vorgemacht, und inzwischen zeigen etliche Beispiele, dass dieselben Prinzipien auch für die Softwareentwicklung funktionieren: Um wirklich kundenorientiert zu arbeiten, Probleme frühzeitig zu erkennen und uns kontinuierlich zu verbessern, sollten wir von "Push" auf "Pull" umstellen. Push bedeutet, dass jeder Mitarbeiter so viele Aufgaben erledigt, wie er nur schaffen kann. Und um sicherzustellen, dass er auch wirklich immer ausgelastet ist, bekommt er die Aufgaben von seinem Vorgesetzten zugeteilt, am besten mit einer Deadline versehen: "Herr Meier, erledigen Sie diese Aufgabe bis Montag früh 8.00 Uhr!"

Dem gegenüber steht Pull: Die Mitarbeiter "ziehen" sich neue Aufgaben nur dann, wenn sie selbst und die nachgelagerten Prozessschritte ausreichend Kapazitäten haben. Denn es sollte einsichtig sein, dass jedes System nur eine bestimmte Menge an Aufgaben in einem bestimmten Zeitraum verarbeiten kann. Wenn man über diese Menge hinaus weitere Aufgaben in das System gibt, entstehen Warteschlangen, und das System "überhitzt", was sich in mehr Fehlern und ausgebrannten Mitarbeitern äußert.

Vertrauen als wichtiges Kriterium

WIP-Limits sind ein einfaches Mittel, um die Überlastung des Systems zu verhindern. Aber wie können wir sicher gehen, dass die Mitarbeiter sich auch tatsächlich neue Aufgaben ziehen und nicht stattdessen lieber im Internet surfen oder Kaffee trinken? Die Antwort lautet: "Wir vertrauen darauf, dass wir gute, motivierte Mitarbeiter haben, die stets ihr Bestes geben und ein Interesse daran haben, selbstbestimmt zu arbeiten und gute Ergebnisse abzuliefern." Pull bedeutet also Vertrauen und Schluss mit Mikromanagement, also der ständigen Kontrolle von Einzelheiten! Dies ist eine große Herausforderung – aber die Ergebnisse sind oft beeindruckend (siehe dazu auch Andrezak, 2010).

Zudem bewirkt das Pull-Prinzip, dass Führungskräfte nicht mehr spontan an einzelne Mitarbeiter oder Teams Aufgaben delegieren können, die mit einer Deadline versehen sind. Auf eine zeitnahe Bearbeitung von Aufgaben können sie hingegen Einfluss nehmen, indem sie z.B. Aufgaben priorisieren. Kommen solche "eiligen" Anforderungen ab und zu mal vor, ist zu überlegen, dafür eine eigene Serviceklasse einzuführen, z.B. rote Tickets, die mit Vorfahrt durch das System geschleust werden. Allerdings muss allen Beteiligten klar sein, dass bei einem solchen Vorgehen immer andere Aufgaben warten müssen und dass das System schlechter vorhersagbar wird, wenn man bestimmte Aufgaben ausnahmsweise "beschleunigt".

Kanban verändert die Arbeit

Durch die neue Arbeitsweise ist vieles in der Entwicklungsabteilung von Herrn Paulsen anders geworden. Nicht nur die Entwickler haben ihre Arbeitsweise geändert, sondern auch Herr Paulsen musste umdenken. Weil die WIP-Limits erschöpft sind, kann er dem Team keine neuen Aufgaben mehr zuweisen. Das ist ungewohnt. Und er muss sich stark zurückhalten, um nicht ständig nach Zwischenergebnissen zu fragen. Dafür bekommt er beim Standup Meeting vor dem Board ein tägliches Update, in welchem Zustand sich welche Aufgabe befindet. Und dort erfährt er auch, bei welchen Aufgaben es Probleme gibt. Wenn diese Probleme nicht technischer Natur sind, kümmert meistens er sich darum.

Das war zuerst sehr ungewohnt. Gehörte es wirklich zu seinen Aufgaben als Entwicklungsleiter, sich um größere Monitore und neue Büromöbel zu kümmern (weil die alten sich schlecht für gemeinsames Arbeiten am selben Schreibtisch eigneten)? Ursprünglich nicht! Aber jetzt hat er erkannt, dass es nicht entscheidend ist, ob eine Aufgabe zu seiner Jobbeschreibung passt. Viel wichtiger ist es, dass sein Team in kurzer Zeit Software in vernünftiger Qualität liefert. Und wenn er zu diesem Ziel am besten beitragen kann, indem er Probleme aus dem Weg räumt, dann sollte er dies tun. Natürlich gibt es auch viele Aufgaben, die Herr Paulsen nach wie vor erledigen muss, z.B. das Tracking und Reporting für das obere Management. Die Hauptkennzahlen dafür sind die durchschnittliche Durchlaufzeit und der Gesamt-Durchsatz (also die Anzahl gelieferter Features pro Woche oder Monat).

Die Durchlaufzeit dient auch dazu, dass sein Team sich selbst und den Prozess immer weiter verbessert. Dazu finden regelmäßige Treffen statt, auf denen alle gemeinsam sich die Frage stellen: "Was können wir tun, um die Durchlaufzeit zu verkürzen?" Dabei kommen dann ungewohnte Vorschläge wie: "Wir müssen die Qualität erhöhen, weil die größten Zeitfresser die ständigen Bugfixes sind", oder "Wir müssen enger mit den Business-Analysten zusammenarbeiten, weil es ständig Missverständnisse wegen unklarer Anforderungen gibt, die uns aufhalten. Vielleicht sollten wir unser Board erweitern und sie auch zu unseren Meetings einladen." Solche Änderungen sind nicht von heute auf morgen erledigt – aber es sind lohnende Ziele, die das Team unter Leitung von Herrn Paulsen nun angehen möchte.

Systemisches Denken

Ein großes Problem in vielen Organisationen sind lokale Optimierungen: Jeder Einzelne möchte seine Aufgaben möglichst effizient erledigen. Die Entwicklungsabteilung soll möglichst produktiv arbeiten. Die Tester sehen nur die Bugs, interessieren sich aber nicht für die Ursachen (sondern halten die Entwickler für inkompetent) usw. Dies alles führt schnell zu Problemen im gegenseitigen Umgang, z.B. wenn sich regelrechte Fronten zwischen Entwicklern und Testern aufbauen.

Das Gegenteil von lokalen Optimierungen ist systemisches Denken: Wie schaffen wir es als Gesamt-System, unseren Kunden (die auch interne Kunden sein können), möglichst oft Ergebnisse mit möglichst viel Wert auszuliefern? Wir haben schon gesehen, dass eine hohe Auslastung nicht unbedingt förderlich für dieses Ziel ist. Stattdessen ist es in den meisten Fällen eine gute Idee, Grenzen aufzuweichen oder sogar abzuschaffen (z.B. wenn Entwickler und Tester gemeinsam im selben Team arbeiten). Systemisches Denken bedeutet auch eine andere Art des Managements. So wie Herr Paulsen es in unserem Beispiel vormacht, sollten Manager aufhören, über Mitarbeiter zu bestimmen, und stattdessen anfangen, das System zu verbessern, sodass die Teams optimale Leistung bringen können.

Was kann Kanban leisten?

Das Beispiel von Herrn Paulsen und seinem Team hat gezeigt, was Kanban leisten kann:

  • In kurzer Zeit und mit einfachen Mitteln wird Transparenz über den aktuellen Zustand der Aufgaben, die Verteilung der Arbeit und akute Probleme geschaffen.
  • Die Limitierung des WIP führt zu kürzeren Durchlaufzeiten, weniger Fehlern und kann auch (wie in unserem Beispiel) zum Abbau von Wissensinseln beitragen.
  • Die regelmäßigen Abstimmungsmeetings und der Fokus auf die Durchlaufzeit regen immer wieder Diskussionen im Team an, den Prozess stetig zu verbessern und führen häufig zu einer verbesserten Zusammenarbeit entlang der gesamten Wertschöpfungskette.
  • Kanban hält einfache Möglichkeiten bereit, um die Arbeit gleichmäßig über die verschiedenen Prozessschritte zu verteilen und für die einzelnen Mitarbeiter eine nachhaltige Geschwindigkeit zu gewährleisten.

Auf der anderen Seite ist Kanban natürlich kein Wundermittel, das alle unsere Probleme löst. In erster Linie werden die Probleme nur deutlich – wie Team und Management dann damit umgehen, bleibt ihnen selbst überlassen. So lassen sich viele Probleme nicht von heute auf morgen lösen – man denke nur an riesige Mengen Legacy-Code (also historisch gewachsener Code z.B. einer individuellen Unternehmens-Software, der schwer änder- und erweiterbar ist, für den sich niemand zuständig fühlt und der dafür sorgt, dass die Kosten für Änderungen am System mit der Zeit exponentiell ansteigen), die viele Teams allzu gut kennen. Diesen Code zu refaktorisieren, stellt eine mühsame Arbeit dar. Allerdings macht Kanban solche Hürden im System sichtbar und legt immer wieder den Finger auf die wunden Punkte, sodass das Team immer wieder angeregt wird, die notwendigen Diskussionen zu führen, um sich kontinuierlich zu verbessern.

Mittel- bis langfristig sollen Kanban-Systeme sich dahin entwickeln, dass die Arbeit selbstorganisiert von den Teammitgliedern gezogen wird, Probleme eigenständig erkannt und behoben werden und immer wieder Verbesserungsvorschläge von den Mitarbeitern eingebracht und dann im Team umgesetzt werden. Es wäre allerdings utopisch zu denken, eine solche "Kaizen-Kultur" würde sich einstellen, sobald ein Kanban-Board an der Wand hängt. Auch hier gilt das Prinzip der kleinen Schritte. Um den Finger immer wieder auf die wunden Punkte zu legen und das Team zur kontinuierlichen Verbesserung anzuregen, braucht man eine Person, die sich dafür zuständig fühlt, diese Veränderungen auch voranzutreiben. Sie muss dafür sorgen, dass immer wieder unangenehme Fragen diskutiert und Selbstverständlichkeiten in Frage gestellt werden, ohne dem Team dabei fertige Lösungen vorzusetzen.

Was ist Software-Kanban nicht?

Ein häufiges Missverständnis besteht darin, dass Software-Kanban für eine Entwicklungsmethode gehalten wird. Dies ist allerdings keineswegs der Fall. Kanban sagt rein gar nichts darüber aus, wie Software entwickelt werden sollte. Es sagt noch nicht mal etwas darüber aus, wie Software-Projekte geplant und durchgeführt werden sollten. Deshalb ist Software-Kanban auch kein Management-Framework, wie z.B. Scrum. Stattdessen besteht der Zweck von Software-Kanban darin, den eigenen Arbeitsprozess (ganz gleich, wie dieser im Moment aussehen mag), beständig zu verbessern.

Wenn dies verstanden ist, dann wird auch klar, warum Kanban keine Konkurrenz zu Vorgehensmodellen wie Wasserfall, V-Modell, eXtreme Programming oder Feature Driven Development darstellt. Auf jede der Methoden lässt sich Kanban aufsetzen, um Verbesserungen voranzutreiben. Allerdings wird die Ausgangsmethode sich nach einer Weile sehr wahrscheinlich deutlich verändert haben, so dass sie dann besser zu den jeweiligen Bedürfnissen des Teams bzw. der Organisation passt.

Häufige Fehler bei der Umsetzung

Die Eleganz von Software-Kanban besteht in seiner Einfachheit. Deshalb lässt sich Kanban auch in den unterschiedlichsten Kontexten einsetzen: Von der Entwicklung, der Wartung und dem Betrieb von Software über Portfolio-Management bis hin zum persönlichen Zeitmanagement. Damit Kanban erfolgreich sein kann, müssen drei Grundvoraussetzungen erfüllt sein:

  • Es müssen wiederkehrende Prozessschritte vorhanden sein (auch wenn nicht immer alle Aufgaben alle diese Schritte durchlaufen müssen),
  • es muss die Bereitschaft bei den Beteiligten geben, selbst den Arbeitsprozess schrittweise verbessern zu wollen und
  • die nötige Zeit für langsame Veränderungen muss vorhanden sein.

Die erste Bedingung ist häufig in Abteilungen nicht erfüllt, in denen es keinen festen Arbeitsablauf für die Aufgaben gibt, z.B. in der Forschung. Hier bestehen viele verschiedene Möglichkeiten, die Aufgaben zu bearbeiten, wobei auch ein hohes Maß an Kreativität für die Gestaltung des Arbeitsablaufs gefragt ist.

Die Erfüllung der zweiten Bedingung wird dann zum Problem, wenn Veränderungen – wie z.B. die Einführung von Kanban – "von oben" verordnet werden, ohne dabei die Beteiligten mit einzubeziehen. Das bedeutet keineswegs, dass die Einführung von Software-Kanban basisdemokratisch von allen im Konsens beschlossen werden muss. Aber es bedeutet sehr wohl, alle Beteiligten auf die Veränderungen einzustimmen und hervorzuheben, dass Ihre aktive Beteiligung wesentlich für den Erfolg ist und jeder mit seinen Meinungen und Verbesserungsvorschlägen willkommen ist.

Die dritte Bedingung ist immer dann nicht erfüllt, wenn eine Organisation mit dem "Rücken zur Wand" steht, z.B. weil ein überlebenswichtiges Projekt kurz vor dem Scheitern steht oder die Konkurrenz übermächtig zu werden droht. In diesem Fall dauert die langsame Art der Veränderung, wie sie Kanban vorsieht, zu lange. Dann kann es sinnvoller sein, einen eher revolutionären Ansatz für Veränderungen zu wählen, wie er z.B. in Scrum vorgesehen ist.

Kaizen wird häufig vernachlässigt

Wie bereits erwähnt, besteht der häufigste Fehler bei der Einführung von Software-Kanban darin, dass zwar ein Kanban-Board gepflegt wird, dass WIP-Limits vorhanden sind und auch tägliche Standup Meetings durchgeführt werden – eine kontinuierliche Verbesserung findet hingegen nicht statt. Kaizen ist aber kein optionaler Bestandteil von Kanban, sondern ein unverzichtbares Element!

Tatsächlich lässt sich immer wieder beobachten, dass Teams und Organisationen sich eine "Kanban-Fassade" aufbauen, um sich den Anschein von Veränderungen zu geben. Nach ihren Veränderungsbemühungen gefragt, verweisen sie dann auf ihr Kanban-Board und die Standup Meetings. Aber das Board macht Probleme nur sichtbar, ohne sie zu lösen. Und Standup Meetings dienen ebenfalls dazu, Verbesserungen zu diskutieren – wenn daraus aber keine konkreten Maßnahmen abgeleitet werden, wird ihr Potenzial verschenkt.

Problem "Tooleritis"

Ein weiteres Problem kann man treffend als "Tooleritis" bezeichnen. Gerade in der IT-Branche, in der wir nicht nur täglich mit einer Reihe elektronischer Tools arbeiten, sondern auch selbst Software-Systeme entwickeln, liegt die Idee nahe, als allererstes eines der vielen vorhandenen elektronischen Kanban-Tools einzuführen – oder selbst zu programmieren. Davon sei dringend abgeraten! Zwar gibt es durchaus Konstellationen, in denen der Einsatz solcher elektronischer Tools sinnvoll ist, z.B. wenn wir es mit Teams zu tun haben, die über drei oder noch mehr Standorte verteilt sind. Aber man sollte so lange wie möglich versuchen, mit "Low-Tech-Tools" wie Whiteboard, Karteikarten, Filzstiften usw. auszukommen (und dies ist in der Regel länger, als man am Anfang denkt).

Dafür gibt es verschiedene Gründe: Zum einen ist selbst das flexibelste elektronische Tool niemals so flexibel wie ein Whiteboard, kombiniert mit einigen Zetteln und Stiften. Dort lassen sich in kürzester Zeit Spalten am Board zusammenlegen oder trennen, WIP-Limits verändern, zusätzliche Informationen auf Tickets vermerken, Tickets gruppieren und trennen (oder mit an seinen Arbeitsplatz nehmen), die verschiedensten Formen von Visualisierungen vornehmen usw. Kurzum: Low-Tech-Tools sind hervorragend geeignet, um spontan kreativ zu werden und Innovationen vorzunehmen, während elektronische Tools eine Tendenz haben, um Innovationen zu behindern. Ganz im Gegenteil: Häufig führt der Einsatz solcher Tools dazu, dass der Prozess dem Tool angepasst wird, und nicht anders herum!

Ein weiteres wichtiges Argument gegen elektronische Tools ist, dass diese eigentlich immer eine höhere Hemmschwelle aufweisen. Selbst wenn es nur einige wenige Klicks bedeutet, das elektronische Tool zu öffnen, um etwas nachzusehen oder den Status eines Tickets zu aktualisieren, wird dies oft nicht sofort getan. Auf der anderen Seite lässt sich gut beobachten, dass Teammitglieder gern an einem realen Board arbeiten, um z.B. ein Ticket zu verschieben.

Schließlich ist die schiere Größe und die starke Präsenz eines realen Boards ein entscheidender Faktor: Wenn ich täglich etliche Male am Board vorbeigehe und mich darüber hinaus jeden Morgen vor diesem Board treffe, kann ich die Probleme einfach nicht ignorieren, die mir das Board zeigt. Bei einem elektronischen Board hingegen fällt es mir sehr leicht. Darüber hinaus lässt sich in eigentlich allen Kanban-Teams (genauso übrigens wie in Scrum-Teams) beobachten, dass sich regelmäßig kleine Grüppchen von Teammitgliedern vor dem Board bilden, um sich zu synchronisieren, Probleme zu diskutieren und sich natürlich auch gegenseitig auf die Schulter zu klopfen.

Zusammenfassung

Software-Kanban ist eine Methode des Evolutionären Change Managements. Die Prinzipien und Techniken von Kanban sind sehr einfach: Der aktuelle Workflow wird visualisiert, z.B. in Form von Karteikarten auf einem Whiteboard. Danach wird die Menge an begonnener Arbeit limitiert und ein Pull-System eingeführt. Aufgaben werden also nicht mehr an einzelne Mitarbeiter zugewiesen, sondern von Mitarbeitern gezogen und eigenverantwortlich bearbeitet. Regelmäßige Abstimmungs-Meetings und Messungen (vor allem der Durchlaufzeiten) dienen als Anhaltspunkte für Vorschläge zur kontinuierlichen Verbesserung, so dass das Kanban-System für den jeweiligen Kontext immer weiter optimiert wird.

Die Einfachheit von Kanban führt in der Regel zu einer hohen Akzeptanz bei allen Beteiligten. Schwierig wird der Einsatz von Kanban hingegen, wenn kein wiederkehrender Arbeitsablauf zur Bearbeitung der Aufgaben besteht oder der Organisation die Zeit für langsame Veränderungen fehlt.

Literatur

  • Anderson, David J.: Kanban. Evolutionäres Change-Management für IT-Organisationen, dpunkt Verlag, 2011
  • Andrezak, Markus: Wer WIP sagt, muss auch Pull sagen, Javamagazin 11/2010 (Download unter it-republik.de)
  • Andrezak, Markus; Roock, Arne; Wolf, Henning: Gedämpfte Schritte. Evolutionäre Entwicklung durch Software-Kanban, ix-Magazin für professionelle Informationstechnik, Juni 2010
  • Andrezak, Markus; Roock, Arne; Wolf, Henning: Schützt das Team! Die Überlastung von Entwicklungsteams verhindern mit Kanban, Heise Developer Channel, 2010 (Download unter www.heise.de)
  • Goldratt, Eliyahu M.; Cox, Jeff: Das Ziel: Ein Roman über Prozessoptimierung, 4. Auflage, Campus Verlag, 2008
  • Reinertsen, Donald G.: The Principles of Product Development Flow. Second Generation Lean Product Development, Celeritas Publishing 2009
  • Womack, James P.; Jones, Daniel T.: Lean Thinking: Ballast abwerfen, Unternehmensgewinn steigern, Campus Verlag, 2004




 
 
Tech Link