Kanban – So nutzen Sie die Vorteile einer schlanken Produktion für Ihre Software-Entwicklung

Kanban

In vielen Unternehmen kommt heute Kanban für die Optimierung der Produktion zum Einsatz. Die Methodik wurde 1947 vom Automobilhersteller Toyota entwickelte und zielt darauf ab, die Lagerbestände möglichst niedrig zu halten. Ein solches Ziel lässt sich natürlich nur realisieren, wenn die Zwischenerzeugnisse immer an den richtigen Stellen in der benötigten Menge zur Verfügung stehen. Wie Ihnen diese Erkenntnisse bei der Optimierung Ihrer Software-Entwicklung helfen können, zeigen wir Ihnen im folgenden Artikel.

 

Optimierung der Produktion

In einem Unternehmen, das nach Kanban arbeitet, wird stets darauf geachtet, die passende Menge an Ressourcen – sowohl Personen als auch Fertigungsmaterial – zur Verfügung zu haben. Durch diesen Ansatz werden hohe Lagerbestände aber auch Fehlteilelisten ausgeschlossen.

Als erster Schritt in einem solchen Prozess wird eine Fertigungskette definiert. Sinkt das Material bei einem Produktionsschritt unter einen zuvor festlegten Wert, erhält der vorgelagerte Produktionsschritt eine entsprechende Benachrichtigung. Im Unternehmen wird anschließend dieser Schritt gestartet und informiert bei Bedarf wiederum den Vorgänger.

Für die Steuerung dieses Prozesses nutzen die meisten Unternehmen Karten, auf denen als wichtige Kenngrößen, unter anderem der Bedarf und die Menge, vermerkt sind. Aus diesem Vorgehen leitet sich auch der Name „Kanban“ ab, der im japanischen „Karte“ oder „Beleg“ bedeutet.

 

Kanban in der Software-Entwicklung

Aus den Erkenntnissen der Produktion lässt sich mit einigen Anpassungen auch ein Vorgehen für die Software-Entwicklung entwickeln. Die Software-Entwicklung ist zwar in weiten Teilen nicht mit den Herstellprozessen von klar definierten Teilen vergleichbar. Bei der Programmierung ist an vielen Stellen Kreativität gefragt. Auch die Aufwände können Sie nicht wie in der Fertigung eindeutig voraussagen oder von Vergangenem ableiten.

Zwei der Grundprinzipien von Kanban sind jedoch produktionsübergreifend und lassen sich damit hervorragend als Basis für die Software-Entwicklung verwenden:

1.) Die Entwicklung eines Programms durchläuft verschiedene Stadien. Es beginnt bei der  Idee, geht über die Konzeption und die Umsetzung bis hin zum Test sowie der finalen Freigabe. Dies entspricht in Kanban der Idee des „flows“, welcher die Abfolge der Fertigungsschritte festlegt.

2.) Auch das zuvor beschriebene „pull“ Prinzip lässt sich gut auf die Software-Entwicklung adaptieren: hat ein Entwickler ein Arbeitspaket fertiggestellt, wartet das Ergebnis auf die Weiterverarbeitung im nächsten Schritt.

 

Vorteile von Software-Kanban

In vielen Entwicklungsabteilungen herrscht heutzutage ein Zustand der permanenten Überlastung. Entwickler arbeiten in der Regel an vielen Themen gleichzeitig. Dadurch findet keine richtige Priorisierung statt und keiner der Termine kann letzten Endes gehalten werden. An dieser Stelle setzt Kanban an und hilft Ihnen dabei, die Durchlaufzeiten für eine einzelne Entwicklung signifikant zu verkürzen. Durch die Verwendung der Karten kann sich der Verantwortliche erst einmal Transparenz über die Aufgaben der einzelnen Entwickler verschaffen. Daraus lassen sich schnell Ressourcenengpässe erkennen und Gegenmaßnahmen einleiten.

Mit diesem Vorgehen bauen Sie innerhalb von kürzester Zeit die Überlastung der Mitarbeiter ab, da sich jeder Entwickler auf 2 bis 3 Themen konzentrieren kann. Zusätzlich lässt sich nach einer gewissen Eingewöhnungszeit mit dem neuen Arbeitsmodell auch eine verlässliche Aussage über den Fertigstellungstermin treffen.

 

Die Grundprinzipien

Damit dies erreicht werden kann, sind einige zentrale Veränderungen der Arbeitsweise der Entwicklungsabteilung notwendig.

Der Ausgangspunkt aller Aktionen ist das Kanban-Board. Auf diesem bilden Sie den aktuellen Ist-Zustands dar. Alle Entwicklungs-Aufgaben werden mit einer Karte dort angebracht und durchlaufen die Phasen von links nach rechts.

Damit dies funktioniert und die Mitarbeiter nicht wieder in eine Überlastungssituation laufen, dürfen sich in einer Phase nur eine bestimmte Anzahl von Karten und damit Aufgaben befinden.

Die Entwickler steuern mit Hilfe des Kanban-Boards selbst ihre Arbeit. Sobald ein Entwickler ein Aufgabenpaket fertig gestellt hat, holt dieser sich das nächste. Damit wird die Aufgabe von „Push“ auf „Pull“ umgestellt und jeder steuert seine Arbeitsbelastung selbst.

Diese Herangehensweise hat in erster Linie die Durchsatzzeiten im Blick. Wenn sich ein Entwickler auf wenige Themen konzentrieren kann, bringt er diese schneller zum Ende. Dadurch werden die Durchlaufzeiten signifikant verkürzt.

Ein Grundprinzip bei Kanban ist die kontinuierliche Verbesserung („Kaizen“). Auch bei Toyota, welche die Methodik entwickelt haben, findet sich noch immer Optimierungspotential. Dessen sollten Sie sich bei der Einführung von Kanban bewusst sein: der Prozess ist nicht in Stein gemeißelt. Führen Sie Anpassungen durch, wenn Sie entsprechende Potentiale erkennen.

 

Der Weg zu Verbesserungen

Ein wesentlicher Bestandteil von Kanban ist ein kontinuierlicher Austausch. Das Team trifft sich regelmäßig – zu Beginn meist einmal täglich – zu einem „Standup-Meeting“ vor dem Kanban-Board. Dort gibt jedes Team-Mitglied einen Status zu seinen aktuellen Tätigkeiten und berichtet über Schwierigkeiten. Diese werden unter besondere Beobachtung genommen und es wird versucht, eine wirksame Lösung zu finden.

Alle zwei bis drei Monate wird zusätzlich ein Rückblick auf die vergangenen Themen durchgeführt und die Schwierigkeiten analysiert. Diese Erkenntnisse sind die Basis für Korrekturen und Verbesserungen.

Neben der Kommunikation werden auch Messungen für die Ermittlung von Kennzahlen herangezogen. Der erste Fokus liegt dabei auf der Durchlaufzeit eines Tickets. Zusätzlich sollten Sie  aber auch die Fehlerraten, die blockierten Tickets und die Termintreue betrachten.

 

Das Kanban-Board

All diese Werte lassen sich aus dem Kanban-Board und den dort verwendeten Karten ermitteln. Das folgende Beispiel zeigt Ihnen mögliche Phasen, die eine Änderung oder Neuentwicklung zu durchlaufen hat.

Auf einer Karte schreiben Sie zu Beginn die Aufgabe, den Antragsteller sowie den Bearbeiter. Im weiteren Verlauf kommen zusätzliche Informationen, wie die geplante Durchlaufzeit hinzu.

Starten Sie mit allen neuen Anfragen erst einmal ganz links in der Spalte „To Do“. In dieser befinden sich alle Kundenanfragen, welche noch nicht genauer analysiert und bewertet sind.

Damit auch von Entwicklungsseite klar ist, welche Erwartungshaltungen der Beauftragende hat, sollte mit allen Beteiligten ein Gespräch stattfinden. In diesem werden die Anforderungen geprüft und sichergestellt, dass alle das gleiche Verständnis von der Aufgabe haben. Dies führen Sie für alle Tickets in der Spalte „Analyse“ durch. Am Ende haben Sie die Basis für die Entwicklung. Bei größeren Aufgaben kann dies mit einem Feinkonzept untermauert sein.

In der dritten Spalte „Entwicklung“ findet schließlich die Umsetzung der Themen statt.

Anschließend nimmt sich das „Test“ Team die Entwicklung vor und prüft, ob diese korrekt implementiert wurden. Im positiven Fall wandert die Karte in das abschließende Feld „Bereit für Release“. Sind innerhalb der Testphase Probleme entstanden, werden die Tickets farblich markiert und sollten anschließend vom Entwickler nachbearbeitet werden.

 

Auf einem Kanban Board platzieren Sie alle Themen in Form einer Karteikarte.

Für einen solchen Fall macht es Sinn, wenn Sie eine vorgelagerte Warteliste definieren. In diese schieben Sie alle Punkte mit Qualitätsmängeln. Bevor Sie neue Tickets aus der Analysephase herausnehmen, müssen Sie die fehlerbehafteten Aufgaben lösen.

 

Work in Progress

Bis jetzt unterscheidet sich das Modell – außer in der Visualisierung  – nur wenig zum Vorgehen in den meisten Entwicklungsabteilungen. Die Steuerung der Entwickler funktioniert bei Kanban im Wesentlichen über die Limitierung der Ressourcen, dem „Work in Progress“ (WiP). Dies beschreibt die Anzahl der parallel bearbeiteten Tickets je Spalte.

Diese Zahlen sind abhängig von der Anzahl der beteiligten Entwickler, die einen Prozess-Schritt ausführen können. In der Regel sollte ein Entwickler an nicht mehr als zwei bis drei Themen parallel arbeiten. Der Schwerpunkt der Verteilung liegt normalerweise auf dem Bereich „Entwicklung“. Die weiteren Ressourcen verteilen Sie abhängig von den Anforderungen auf die anderen Themenblöcke.

An dieser Stelle sind sicherlich im Laufe der Zeit einige Korrekturen notwendig, denn die Bestimmung des WiP Limits ist stark firmenabhängig.

 

Positive Auswirkung von WiP

Haben Sie jedoch eine optimale Balance erreicht, hat dies positive Auswirkungen auf eine Reihe von Themen. Die Durchlaufzeit eines Tickets ist laut dem stochastischen Gesetz von John Little der Quotient aus der Menge an paralleler Arbeit im Verhältnis zum Durchsatz über diesen Zeitraum.

Erledigt ein Entwicklungsteam 20 Tickets pro Woche und arbeitet parallel an 5 Stück, dann beträgt die Durchlaufzeit pro Ticket 0,25 Wochen.

Hat ein Entwickler nur wenige Themen parallel in der Bearbeitung, kann er eine Aufgabe nach der anderen abarbeiten. Er ist nicht gezwungen sich ständig in neue Themen einarbeiten und diese halb fertig liegenlassen.

Durch einen ständigen Kontextwechsel leidet letzten Endes auch die Qualität. Es dauert gerade bei komplexeren Themen meist länger, bis Sie sich wieder den notwendigen Überblick verschafft haben.

Ein weiterer Faktor, der in der Limitierung berücksichtigt werden sollte, sind personelle Engpässe. Diese können beispielsweise durch Expertenwissen entstehen, das nur ein Entwickler besitzt. Es kann aber auch aus einer eingeschränkten Anzahl von Testern resultieren, welche die Entwicklungen abnehmen.

In solchen Fällen kann es durchaus Sinn machen, wenn Sie weitere Wartebereiche implementieren. Dort werden die Tickets geparkt. Damit kann sich ein Entwickler weiterhin neue Aufgaben nehmen. Die noch nicht komplett abgeschlossen Pakete zählen nicht zur Gesamtzahl dazu.

 

In manchen Fällen, wie bei personellen Engpässen durch Expertenwissen, hilft eine Warteschlange weiter.

 

Rolle des Vorgesetzten

Die Vorgesetzten haben bei dieser Art der Problemlösung lediglich die Aufgabe, die Maschinerie am Laufen zu halten. Störungen werden vom Team schnellstmöglich beseitigt. Dies kann von einem klärenden Gespräch mit der Fachabteilung bis hin zum fehlenden Plug In für die Entwicklungsumgebung gehen.

Darüber hinaus agiert der Vorgesetzte als Ressourcen-Manager und priorisieren die Themen bei Unklarheiten. Ansonsten sollte zumindest diese Aufgabe eigenständig durch die Entwickler gelöst werden.

 

Fazit

Kanban stellt für die Programmierung und die Entwicklung von Produkten eine interessante Alternative dar. Befindet sich ein Unternehmen aktuell in der Umsetzung einer schlanken Produktion, sollte die IT Abteilung die Chance ergreifen und auf diesen Zug aufspringen.

Nutzen Sie die Vorteile von Kanban um die Ressourcen in der Entwicklung besser zu steuern und Engpässe zu erkennen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.