Warum wir uns mit einem Thema wie Kanban beschäftigen? Weil wir auf der ewigen Suche nach höherer Produktivität sind. Diese Suche betreiben wir Menschen schon sehr, sehr lange.

Doch was genau bedeutet Produktivität? Laut Wikipedia ist Produktivität eine »wirtschaftswissenschaftliche Kennzahl, die das Verhältnis zwischen produzierten Gütern/Dienstleistungen und den dafür benötigten Produktionsfaktoren beschreibt«. Ein großer Schritt , der dieses Verhältnisses verbesserte, war zum Beispiel die Erfindung der Fließbandproduktion.

Aber welche Produktivitätsfaktoren sind heute in der Softwareentwicklung ausschlaggebend? Wir haben kein Produkt, das wir in hoher Stückzahl immer wieder herstellen. Wir entwickeln hingegen ein Softwareprodukt permanent weiter und veröffentlichen immer wieder einzelne Version davon für unsere Kunden. Wir betreiben also permanente Prototypenentwicklung. Betrachtet man die Mitarbeiter, sind beispielsweise Wissen und Kreativität Produktionsfaktoren. 

Softwareentwicklung ist Wissensarbeit. Und Kreativität brauchen wir unter anderem, um Probleme zu lösen. Aber auch unser Produkt selbst ist ein Produktionsfaktor, da es immer weiterentwickelt wird. Je höher die Codequalität unseres aktuellen Produktes ist, desto höher ist die Produktivität der nächsten Release-Zyklen bei Wartbarkeit und Erweiterbarkeit.

Wissen, Kreativität, Wartbarkeit und Erweiterbarkeit fördern – in einem Umfeld, in dem mehr oder weniger per Definition immer zu viel zu tun ist. Wie soll das funktionieren? Hier setzt Kanban an.

Ursprung

Kanban wurde ursprünglich von Toyota erfunden. Das Unternehmen wollte unter anderem zu hohe Lagerkapazitäten verringern und schneller auf geänderte Kundenanforderungen reagieren. Ein Baustein dieser Bemühungen ist Kanban. Kan-Ban steht für »Signalkarte«. Diese Signalkarten aus der Toyota-Produktion kennen wir heute in der IT als Karten an unseren Kanban-Boards.

Grundprinzipien und Kernpraktiken

Im Jahr 2007 hat David Anderson das Kanban-Prinzip zum ersten Mal für die Softwareentwicklung dokumentiert.
Er definiert vier Grundprinzipien (GP) und sechs Kernpraktiken (KP).

GP1: Beginne mit dem, was du gerade tust

Hinter dem Satz verstecken sich zwei Dinge. Zum einen ist es sehr einfach Kanban zu etablieren, weil man mit dem beginnt, das man gerade eh schon tut. 2009 haben wir uns zum ersten Mal mit dem Thema Kanban beschäftigt und uns dazu entschieden, dies als Grundphilosophie unserer Arbeitsorganisation in der IT zu verwenden. Das damals noch kleine Entwicklerteam wollte anderen Abteilungen und der Geschäftsleitung zeigen, was gerade in Planung und in Arbeit war. Unser erstes Kanban-Board hat uns hier enorm geholfen.

Zum anderen versteckt sich in diesem Satz die Aussage, die in den Kernpraktiken noch einmal aufgegriffen wird. »Beginne mit dem, was du gerade tust« bedeutet anders ausgedrückt »mach erst das zu Ende, was du gerade tust, bevor du etwas Neues anfängst«. Dieser Fokus vermeidet unter anderem unfertige Softwareanpassungen.

GP2: Vereinbare, dass evolutionäre Veränderung verfolgt wird

Das schöne an IT-Teams ist, dass sich die meisten ITler sehr bewusst für diesen Berufsbereich entschieden haben, da man immer wieder Neues lernt. Das Interesse ständig dazuzulernen und sich weiterzubilden ist bei den meisten vorhanden und muss nicht extra gefördert werden.

In diesem Grundprinzip ist vor allem das Verb vereinbaren extrem wichtig.  Eine Vereinbarung wird immer von mehreren Personen getroffen – und das ist so wichtig daran. Diese evolutionäre Veränderung kann nicht aus den Teamleiter-Positionen heraus vorgegeben werden, da jeder Mitarbeiter mit sich selbst vereinbaren muss, was in seinem eigenen Arbeitsbereich verbessert und weiterentwickelt werden kann.

GP3: Respektiere initial bestehende Rollen, Prozesse und Verantwortungen

Auch dieses Prinzip ist sehr einfach einzuhalten. Als wir uns 2009 für Kanban entschieden haben, war unser IT-Team noch sehr klein. Ich selbst habe in dem Jahr die Leitung für den Bereich Softwareentwicklung übernommen. Über die Jahre haben sich neue Rollen entwickelt. Heute bestehen wir aus mehreren Teams mit Junior, Professional und Senior-Developer und verschiedenen Level für Team-Manager. Auch wenn das Grundprinzip explizit »initial« bestehende Rollen anspricht, folgt Kanban den Freiheiten, wie man die Grundprinzipien/Kernpraktiken umsetzt. In diesem Fall sind das Rollen oder Hierarchie-Ebenen, die man haben möchte.

GP4: Ermutige dazu, Führung auf jeder Ebene des Unternehmens zu zeigen

Was bedeutet Führung? Nach Prof. John P. Kotter ist Führung (Leadership) »ein Verhalten, das Menschen Zukunftsvisionen zeigt und sie dazu inspiriert, diese entgegen aller möglichen Widerstände zu verfolgen«.

Mitdenkende Mitarbeiter halte ich in der Softwareentwicklung für das wichtigste Erfolgskriterium. Wir arbeiten zwar nicht mehr am Fließband, trotzdem sind wir Wissensarbeiter, die permanent Prototypen weiterentwickeln. Prototypen werden erfolgreich, wenn die Mitarbeiter, die daran arbeiten, ihre eigenen Zukunftsvisionen entwickeln und in das Produkt einfließen lassen.

Vom Produktmanagement erstellte Anforderungsdokumente werden bei uns immer von einem Softwaretester und einem Entwickler geprüft und dokumentiert, bevor wir die entsprechende Anpassung umsetzen. Neben der Machbarkeitsprüfung erhalten Tester und Entwickler bewusst die Möglichkeit, Ideen an den Produktmanager weiterzugeben.

Wir haben ein Tec-Team in der Softwareentwicklung, das für die technische Weiterentwicklung und das Refactoring zuständig ist. Das Team organisiert sich selbst, legt Prioritäten fest und entwickelt eigene Zukunftsvisionen.

Zu verschiedenen Themen starten wir immer wieder Diskussionsgruppen, um unsere Arbeit allgemein voranzubringen. Es werden der Einsatz neuer Entwicklungstools, anderer Prozesse oder auch die Weiterentwicklung bestimmter Bibliotheken diskutiert.

Über alle diese kleinen Bausteine möchten wir Führung auf allen Ebenen der IT-Mitarbeiter fördern.

Kanbanboard mit Menschen
Kanbanboard mit Menschen

KP1: Visualisiere

Das Board ist wohl das erste, das jemandem einfällt, wenn man über Kanban spricht. Auch für uns war dies der erste Berührungspunkt. Kanban-Boards gab und gibt es bei uns in der Firma in unterschiedlicher Form, zum Teil noch mit Karten, ausgedruckten Zetteln oder auch komplett digital in unserer eigenen CRM-Software onOffice enterprise.

KP2: Limitiere die Menge paralleler Arbeit

Die Limitierung paralleler Arbeit war das zweite große Argument für den Einsatz von Kanban. Ein Mensch kann immer nur eine Sache erledigen. Geben wir einem Softwareentwickler zwei Projekte parallel, dauern beide länger. Für Entscheidungsträger kann es beruhigend sein zu wissen, dass an beiden wichtigen Themen gearbeitet wird, es macht trotzdem keinen Sinn. Genau diese parallel laufenden Projekte oder Arbeitspakete verschwenden Arbeitszeit in der Softwareentwicklung.

KP3: Manage den Arbeitsfluss

Ist die Arbeit visualisiert und sind gute wip-Limits (work in progress) festgelegt, wird der Arbeitsfluss sehr gut organisiert. Standup-Meetings am Kanban-Board sind ein gutes Mittel. In unseren Teams für die Systemadministration und die Durchführung der Datenimporte machen wir jeweils ein wöchentliches Standup-Meeting, in dem jeder etwas zum Stand seiner aktuellen Projekte sagt.

Die Phasen, in denen die Arbeitspakete der einzelnen IT-Teams wandern, können wir über die Software definieren und so auch die Durchlaufzeiten messen. Dazu gehören Durchlaufzeiten insgesamt, Durchlaufzeiten für bestimmte Phasen oder die Verweildauer in Input Queues. Auch das Sammeln und Auswerten dieser Kennzahlen gehört zum Managen des Arbeitsflusses.

KP4: Mache Prozessregeln explizit

Es wirkt oft bürokratisch, wenn man Prozessregeln dokumentiert und festhält. Man gewinnt durch diesen Weg aber entspannte Diskussionen, nämlich Diskussionen ohne Emotionen, in denen eher über Prozessregeln diskutiert wird, als über Fehler oder Schuldzuweisungen.

KP5: Implementiere Feedback-Zyklen

Hier kommt die Kaizen-Philosophie wieder hervor. In regelmäßigen Abständen sollte man sich bewusst damit beschäftigen, wie die Arbeit aktuell funktioniert oder sich bewusst machen, was der größte Flaschenhals ist. Durch eine klare Vorgabe geschieht dies bereits in der täglichen Arbeit und trotzdem kommen in den regelmäßigen Feedbackgesprächen immer wieder spannende neue Ideen auf, die uns über die Jahre immer weiter verbessert haben.

KP6: Führe Verbesserungen kontinuierlich basierend auf Methoden und Modellen durch

Jeder, der einen Job in der IT wählt, weiß, dass man sich in der Umgebung ständig weiterentwickeln und verbessern muss. Im zweiten Teil der Kernpraktik wird darauf hingewiesen, dass man dies »basierend auf Methoden und Modellen« tun soll. Es schadet nie, über den Tellerrand zu schauen und zu prüfen, ob schon jemand das Problem gelöst hat, mit dem man sich gerade beschäftigt. Kanban selbst ist da ein gutes Beispiel. Hier wurde ein System aus der Automobilindustrie adaptiert, um die Arbeit von IT-Teams zu organisieren.

Fazit

Wir haben uns schon 2009 für Kanban als Grundphilosophie entschieden. Die verschiedenen Grundprinzipien und Kernpraktiken haben uns über die Jahre immer wieder einen guten Rahmen gegeben, um die Arbeit in unseren IT-Teams zu organisieren und vor allem weiterzuentwickeln.

Quellen

  • Kanban in der IT – David Anderson
  • Kanban Verstehen, einführen, anwenden – Mike Burrows
  • Kanban in der IT – Eine Kultur der kontinuierlichen Verbesserung schaffen – Klaus Leopold / Siegfried Kaltenecker
  • Wikipedia-Artikel Kanban (Softwareentwicklung)