Kanban – mehr als nur ein Board

Schon vor 30 Jahren stellte Peter F. Drucker in seinem Artikel „The new Productivity Challenge“ fest, die größte Herausforderung der Zukunft bestehe darin, die Produktivität von Wissensarbeitern zu erhöhen, um wettbewerbsfähig zu bleiben [1]. Nach Verlagerung der Produktivität von den klassischen Produktbereichen hin zu wissensintensiven Branchen, zu denen die Softwareentwicklung gehört, ringen Manager darum, die „Schraube“ zu finden, um wissensintensive Arbeit effizienter und schneller zu erledigen [2]. Denn am Markt ist der vorne, der zuerst liefert. First comes, first serves!

Den Workflow in der IT optimieren

Das ist ein Punkt im Prozess, wo die von Taiichi Ohno und Kiichiro Toyoda bei Toyota im Jahre 1947 entwickelte Arbeitstechnik „Kanban“ ansetzt [2]. Aus der Problematik heraus, viele unterschiedliche Automodelle in kleinen Stückzahlen zu produzieren, legten sie ihren Blickwinkel auf den Fluss eines Produkts im gesamten Produktionsprozess und stellten dabei fest:

1. Das Ziel der „Built-in-Quality“ wird durch das sogenannte „Jidoka“ erreicht. Jidoka meint dabei das sofortige Aufzeigen von Fehlern und Problemen in der Produktion, um eine Verschleppung entlang der Produktionskette zu vermeiden.
2. Weiterhin kam es zur Einführung von Signalkarten, die deutsche Übersetzung der sogenannten „kanbans“. Dieses Kernelement in einer Produktionsablaufsteuerung macht Engpässe und Durchflussprobleme im Prozess sofort sichtbar. Die Chance ist eine schnelle Reaktion und Veränderung auf diesen „Stau“, um alles im „flow“ zu halten.

Auf der Suche nach Verbesserungsmöglichkeiten in der Softwareentwicklung fand David J. Anderson über Umwege zu dem Kanban-Modell in der IT. Im Unterschied zur industriellen Produktion, wo Aufgaben in ihrem Umfang genau definiert werden können, sind die Aufträge im IT-Bereich wesentlich facettenreicher. Das erschwert die Abschätzung nach Aufwand und Zeit und damit die Steuerung beträchtlich. Doch beiden Bereichen ist eins gemeinsam: der Ausführende muss immer die Möglichkeit haben, Schritte sinnvoll abzuschließen bevor er etwas Neues beginnt. Dazu ist es wichtig, die Aufgabe UND das Ziel klar zu definieren. Nur so kann Verschwendung, zum Beispiel durch Aufgaben, die Ressourcen verbrauchen, aber keinen zusätzlichen Wert liefern, vermieden werden.

Das Kanban Board – Stop toiling, start thinking

Um Einblick in den Produktionsprozess zu erlangen und somit mögliche Durchflussprobleme zu erkennen, wird der Ablauf auf einem Kanban Board abgebildet. In die erste Spalte werden die zu erledigenden Aufgaben eingetragen. Am Beispiel Software Development würde man sicherlich Kopfspalten wie „definiert“, „in Realisierung“, „realisiert“ und „abgenommen“ erstellen.

Oberstes Gebot! Die Planung wird gemeinsam und transparent mit dem Team gestaltet.

Denn gute Zusammenarbeit setzt ein gemeinsames Verständnis voraus, von dem was man schaffen möchte. Im Gegensatz zu klassischen Ansätzen möchte man in der Kanban-Kultur ganz ausdrücklich „nachdenkende“ Mitarbeiter haben. Die Teammitglieder sollen den Prozess mitgestalten, ihre Bedenken in täglichen kurzen Meetings (Daily Standups) mitteilen und aktiv an der Verbesserung mitarbeiten.

Ist eine Anforderung „definiert“, kann sie bearbeitet werden und nach Abschluss in die nächste Spalte „in Realisierung“ wandern. Und schon hier setzt eine weitere Neuerung zu anderen Modellen an. Der Mitarbeiter bekommt keine Aufgabe zugetragen (Push-Prinzip). Erst, wenn er mit der aktuellen Aufgabe fertig ist und Kapazität für eine neue hat, holt er sich weitere Arbeit. Durch das Pull-Prinzip (Hol-Prinzip) wird ein kontinuierlicher Arbeitsfluss gewährleistet, der am Ende nicht nur einen Mehrwert beim Kunden zur Folge hat. Eine Aufgabe fertig stellen, dann die nächste Aufgabe holen – diese Arbeitsweise der Lean-Management-Systeme vermeidet Engpässe im Prozess und stellt den sinnvollsten Weg der Flussoptimierung dar. Denn ohne Überlastung und ständig wechselnde Aufgaben, ist der Mitarbeiter entspannter und gleichzeitig auch produktiver.

Klar, nicht nur in der Entwicklung hilft die Visualisierung der Aufgaben. Statt Abbildung der Anforderungen, können Kanban Boards auch dem Support bei der Abarbeitung ihrer Tickets, der Entwicklung beim Beheben von Bugs, oder dem Test Management beim Organisieren ihrer Tests helfen. In dem kommenden Release von objectiF RPM 5.2 ist es möglich, Kanban Boards für unterschiedlichste Ergebnistypen anzulegen, wie:

• Anforderungen,
• User Stories,
• Use Cases,
• Testfälle,
• Bugs,
• Risiken.

Sie legen einfach ein Kanban Board an und entscheiden welcher Elementtyp abgebildet werden soll. Und, geht nicht, gibt’s nicht! Wenn Sie einen speziellen Elementtyp visualisieren wollen, den objectiF RPM nicht kennt, dann können Sie diesen einfach selber definieren. Vom Support Ticket bis hin zum speziellen Arbeitsauftrag, objectiF RPM setzt Ihren Ideen keine Grenzen.

Auswahl der Elementtypen zur Erstellung des Kanban Boards

WiP-Limits setzen – Stop starting, start finishing

Im Kanban Board werden die Zahl der Aufgaben durch Work-in-Progress Limits (WiPs) in Abstimmung mit dem Team begrenzt. Dieser wichtige Schlüsselschritt soll verhindern, dass die Teammitglieder eine Vielzahl von Aufgaben parallel bearbeiten, da es aus ökonomischer Sicht wesentlich sinnvoller ist, eine Aufgabe zu 100% fertig zu stellen als 10 Aufgaben zu lediglich 10 %. Die sogenannte quasi-parallele Arbeit führt zu einer Erhöhung der Durchflusszeit, da sich der Mitarbeiter immer wieder neu in die Aufgabe einarbeiten muss und ein Sicherheitspuffer für das ständige Task Switching benötigt. Weiterhin ist ein unfertiges Produkt gebundenes Kapital und jedes Unternehmen ist bestrebt, die Zahl derartiger Halbfertigprodukte zu minimieren. In einem WiP-limitierten Pull-System werden Probleme im Durchfluss (z.B. Engpässe) schnell sichtbar. Wenn der Mitarbeiter, der sich im Engpass befindet keine weitere Arbeit mehr annehmen kann, ist es dem Mitarbeiter aus dem Vorgängerschritt aufgrund des WiP-Limits nicht möglich neue Arbeit zu beginnen. Daraus folgt eine Blockade des Arbeitsflusses, die sofort erkannt und behoben werden kann.

Ein nächster wichtiger Vorteil ist die Kundenzufriedenheit (customer success). Gerade in der Softwareentwicklung führt der kleine Gefallen nebenbei zu einer hohen Anzahl von quasi-paralleler Arbeit. Dieser Zustand hat oft eine Terminverschiebung zum Nachteil des Kunden zur Folge oder es werden bewusst Abstriche in der Qualität in Kauf genommen. Beide Beeinträchtigungen führen im späteren Verlauf des Prozesses zu unzufriedenen Kunden oder Fehlermeldungen, Beschwerden oder Änderungswünschen. Ziel der Kanban-Kultur ist es, nur Aussagen zu treffen, die man einhalten kann. Und die Einführung der WiP-Limits macht es möglich „Nein“ zu sagen, wenn zusätzliche Arbeit diese Grenze überschreiten würde.

In objectiF RPM 5.2 ist die Definition von WiP-Limits ganz einfach realisierbar. Im Dialog zur Erstellung eines Kanban Boards können Sie das WiP-Limit eines Zustands oder einer Zustandsgruppe einfach eintragen. Das Limit ist im Board in der Kopfspalte rechts zu sehen. Wird die festgelegte Anzahl überschritten, färbt sich das WiP-Limit rot und Sie haben die Möglichkeit zeitnah zu reagieren, um den Engpass zu vermeiden.

Festlegung des Work-in-Progress Limits (WiP) für die Zustände

Kanban-Kultur – Veränderung leben

Ein Board zur Visualisierung, eine Begrenzung der Aufträge (WiP-Limits) zur Aufrechterhaltung eines effektiven Workflows, das sind nur zwei Maßnahmen zur Optimierung eines Produktionsprozesses. Kanban ist mehr, diese Kultur will mit ihren wenigen und einfachen Grundsätzen eine Reformation der Zusammenarbeit erreichen. Der Teamgedanke im Unternehmen ist ein Grundpfeiler für alle Aktivitäten. Deshalb ist es wichtig, die Abläufe transparent zu machen und festgelegte Regeln wie das WiP-Limit gemeinsam im täglichen Meeting (Daily-Standup) zu besprechen. Auch Vorschläge und Anmerkungen zur Verbesserung des Durchsatzes von den Mitarbeitern, werden in Feedback Meetings eingehend untersucht und umgesetzt. Neue Situationen erfordern neue Maßnahmen. Ein Kanban Board ist alles andere als in Stein gemeißelt. Es lebt von der stetigen Veränderung, wird immer wieder angepasst um Stau zu vermeiden und den Durchfluss zu optimieren. Versuch, Beobachtung, Feedback und Neuversuch – diese Schleife sollte immer wieder durchgeführt werden, um auf die Herausforderungen und Änderungen auf dem Markt gewinnbringend zu reagieren.

Aller Anfang ist schwer

Der erste Schritt ist die Visualisierung des Arbeitsablaufs durch das Kanban Board, um Engpässe sichtbar zu machen und entsprechend darauf zu reagieren. Wir möchten Sie bei diesem ersten Schritt unterstützen! Wir laden Sie zu einem kostenlosen Webinar zur Erstellung eines Kanban Boards für die Abbildung eines Arbeitsablaufs ein. In 45 Minuten besprechen wir, welche Gedankenschritte zur Erstellung des Boards notwendig sind und wie das Board in objectiF RPM angelegt wird. Von der Definition der Zustandsgruppen bis hin zur Festlegung des WiP-Limits. Melden Sie sich an und schauen Sie, ob diese Möglichkeit der Prozessoptimierung Ihrem Unternehmen helfen kann.

Kontakt: stefanie.kuke@microtool.de

Quellen:

1) Peter F. Drucker “The new Productivity Challenge” Harvard Business Review, 1991 Nov-Dec;69(6):69-9.

2) K. Leopold, S. Kaltenecker “Kanban in der IT”, 3. Auflage, Carl Hanser Verlag München, 2018