Kanban in der IT

 

kanban-pipe
Kanban Pipe: Kobald Agile Expert & IT-Projects, 2017

Für mich als Kanban-Experte sind Ausschreibungen bei denen Scrum und Kanaban in ein und dem selben Softwareprojekt als Skill-Anforderungen genannt werden, sehr kritisch zu hinterfragen. Genauso wie für alle agilen Methoden auch, gilt besonders für Kanban in der IT „ein bisschen Kanban“ geht de facto nicht. Kanban für die IT ist keine Rocket Science, aber auch nichts, das man so „nebenbei mal“ betreiben kann. Kanban ist ein Modell mit speziellen  Restriktionen, Limits und  agilem Verständnis und lässt sich nicht mit anderen Ansätzen „vermanschen“. Soweit ich sehe, ist es ein weit verbreiteter Irrtum, wenn behauptet wird, dass Kanban beispielsweise nur für DevOps, aber nicht für einen software development process (SDLC), oder als ERP Methode angewandt werden kann. So arbeitet etwa SAP mit Kanban und bietet bekanntermaßen ein Produkt dazu an (PP – KANBAN), welches sich mit Logistikprozessen beschäftigt –  dies als Alternative zu ERP!

kanbancadences-anderson-2015
Kanban Cadences: David J. Anderson, 2015

Werden die Grundvoraussetzungen (Regeln) von Kanban eingehalten, dann erhält man ein Steuerungsinstrument mit sehr hohem Praxisbezug, welches es ermöglicht die Arbeitsflüsse (Prozesse) optimierend zu steuern. Ein zentraler Unterschied zu den meisten anderen agilen Methoden ist, dass Kanban „doesn’t optimize teams“ und kein spezielles Rollenmodell voraussetzt. Im Gegenteil werden die im Unternehmen angewandten Rollen und Hierachien beibehalten. Vorteile eines Kanban-Boards sind sicher die notwendigen inkrementiellen Feedbackloops über die festgelegten Kanban-Meetings. Verwendet man digitale Boards kann man, wenn die WIP Limits der jeweiligen Aufgabe entsprechend festgelegt sind, Echtzeit Reports ziehen. Aber natürlich werden bei manuellen Boards ebenfalls Reports erstellt. Persönlich bevorzuge ich manuelle Boards und Reports, da diese die Team-Kollerobation m. M. nach besser unterstützen und die Herstellung mit wenigen Hilfsmitteln möglich ist – immer und überall.

Spektralanalyse mittels Kanbanmethode, oder das Prinzip des stetigen Wandels

Der deutsche Physiker Gustav Robert Kirchhoff legte als der Entdecker der Spektralanaylse fest:

Jedes chemische Element nämlich sendet, durch Hitze oder sonstwie angeregt, eine Mixtur sehr reiner Lichtfarben aus oder verschluckt diese, je nach Umstand. Wird ein solcher Lichtstrahl von einem Prisma in die Einzelfarben zerlegt, entsteht auf einem Bildschirm dahinter ein Muster, ein Spektrum, dessen Analyse die sichere Bestimmung der beteiligten Elemente ermöglicht

Die Spektralanalyse ermittelt eine Verteilungsfunktion, um das Spektrum (physikalische Größe) von Energie, Frequenz, Masse, usf. festzulegen. Die Funktion gibt Informationen über den Zustand der betrachteten Größe, etwa der Anzahl, der Häufigkeit, der Rate, des Durchflusses, oder der Intensität eines bestimmten Objektes in Größenwerten ausgedrückt. Die wesentliche Frage ist die „Wie-Viel-Frage“, bezogen auf ein Spektrum.

Genauso funktioniert die Kanban-Spektralanalyse. Hat man das Spektrum der WIP Limits und insbesondere jene der Serviceklassen festgelegt, lässt sich die Effizienz, Durchflussmenge der Kanban-Pipe analysieren. Gleichzeitig kann man daraus schließen, welche (informellen) Prozesse oder organisatorischer Einflüsse auf die Kanban-Pipe wirken. Warum? Die Serviceklassen zum Beispiel beziehen sich auf Auswirkungen und Risiken und sollten zu einer nachvollziehbaren Vorhersebarkeit (Es handelt sich um keine Prognose!) etwa von Lieferterminen führen.

Natürlich hält sich Kanban ebenfalls an das Prinzip durch kurze Entwicklungszyklen, Feedbackloops und exakter Messung (Kanban-Metriken) laufend Verbesserungspotential zu finden. Gleichzeitig wird danach gesucht, ob die Verbesserungen überhaupt greifen.  Wenn wir etwas optimieren schlägt sich das häufig in Euro nieder, worüber Sie sich als Kunde natürlich freuen. Dazu müssen Basismessungen durchgeführt werden – wichtig sind Durchlaufzeit, Durchsatz und Flusseffizienz eines Prozesses. Gängige Metriken dafür sind das Cumula­tive Flow Diagramm sowie das Tracking und Spektralanalysen von Lead- und Durchlaufzeiten (Cycle Times).

People ask me: What is the difference between lean and kanban? Answer: lean is a destination; kanban is means to get there.
(David J. Anderson)

klaus-leopold
Kanbanboard: Klaus Leopold, 2017

Gegenüber zahlenbasierter Priorisierung wie beispielsweise beim Planning Poker haben Serviceklassen den Vort
eil, dass sie mehr „weiche“ Risikoinformationen beinhalten. Deren Ursprung – z.B. die Projektleitung wird vom Kunden bedrängt ein Zugeständnis zu machen – nicht abstrahiert wird, sondern auf den Serviceklassenkärtchen vermerkt wird.  Jede Serviceklasse definiert sich natürlich über Regeln. Diese Regelen müssen zwingend eingehalten werden. Sie weisen eine eigene Kategorie der Cost of Delay auf, die entstehen
würden, sollte die Entwicklung verspätet oder gar nicht fertig werden. Klaus Leopold, neben David Anderson einer der renommiertesten Interpreten von Kanban für die IT,  spricht von „flight levels„. Ein flight level ist zum Beispiel der value stream in einem Entwicklungsprojekt. Wie alle agilen Methoden ist das oberste Prinzip AVOID WASTE! Zur Elimination von Verschwendung meint Anderson:

Value trumps flow, flow trumps waste elimination, eliminate waste to improve efficiency.
– David J. Anderson

Bei der Anwendung von Kanban ist für mich das besonders faszinierende, dass man mit dem startet was man gerade macht. Damit ist gemeint, dass man beispielsweise eine Entwicklungsprozess sofort kanabanisieren kann.

Die Wichtigkeit der Cycle Time, oder die andere Sichtweise auf Durchlaufzeit

Noch ein Wort zu den Metriken und WIP Limits. Ich halte mich an Andreson und Leopold und versuche fixe Endtermine zu planen und einzuhalten, nur nicht für alles und jenes. Constraints wie neue gesetzliche Rahmenbedingungen, Securityänderungen, u. ä. versehe ich jedoch immer mit Deadlines. Bei einer Softwareentwicklung für einen Kunden zählt der Abgabetermin, während der Entwicklung erfolgt die Steuerung allerdings über die Serviceklassen, Kanbanmeetings und Limits. So kann dann die Anzhal der gelieferten Tickets innerhalb eines bestimmten Zeitraums gemessen werden. Natürlich aber auch die absolute Anzahl von problembehafteten oder blockierten Tickets. Ebenso lässt sich die Anzahl der Bugs (Qualitätskategorie) pro Feature sehr einfach feststellen.

 

Die Cycle Time gibt uns Informationen darüber, wie lange eine Capability von Start bis zur Fertigstellung (100% fertig = einsatzfähig!). Wird die Formel umgeformt, wird deutlich, dass die CT verringert wird, wenn die WIP’s gesenkt oder der TH erhöht wird (CT = WIP / TH). Hier finden wir das eherne Gesetz der agilen Methode manifestiert: Einzig der Scope (Product Backlog) kann geändert werden, niemals die Zeit, Ressourcen, Qualität ode Kosten. So wie Scrum, BDD, FDD, XP oder Pair Testing zählt das Pull-Prinzip und nicht die Systemabhängigkeit zur Organisation. Mit Pull-Prinzip ist ein Nachfrageorientiertes Produktionssystem gemeint. Es zählt vor allem der Informationsfluss als wichtiger Trigger für die Fertigung und nicht so sehr die Produktionsschritte. Gleichzeitig wird über die Vorhersehbarkeit eine genauere Estimation für den Fertigstellungstermin eines Softwareprodukts ermöglicht.

Für mich liegen die Vorteile eines Kanban-Produktions-Prozesses klar auf der Hand: Kanban kann ich sofort einsetzen, ich benötige keine tiefgehenden Prozessdokumentationen dafür, habe einen messbaren Prozess, der die Entwicklungsrealität in Echtzeit abbildet und verschwende kaum Zeit für Administration, des administrieren willens – diese Zeit kann in die Velocity investiert werden!

Sie haben weitere Fragen? Ich kann Sie bei einer Problemlösung unterstützen? Dann kontaktieren Sie mich bitte!