Das diesjährige PM-Camp stand unter dem Motto “Menschen sind keine Ressourcen – Im Spannungsfeld von Projekt und Management”. Einige der dort stattgefundenen Sessions wurden unter dem Kontext “Kanban” geführt, wobei in einer Session das Thema “Kanban – Erfolgsfaktoren für den Einsatz” behandelt wurde. Dies haben wir zum Anlass genommen, uns näher mit diesem Vorgehensmodell zu beschäftigen.

Oftmals stellt sich die Frage bei Verbesserungen, auf welche Weise diese angegangen werden können. Agile Vorgehensweisen sind modern und werden gerne als Allheilmittel genannt. Neben Scrum erfreut sich Kanban immer größerer Beliebtheit in der Software Entwicklung. Bei der Auswahl der agilen Methodik gilt es, wie bei deren Einführung, organisatorische und sonstige Rahmenbedingungen zu beachten.

Merkmale von Kanban für die Softwareentwicklung

Im Zentrum des Vorgehensmodells „Kanban“ (was im japanischen soviel wie „Signalkarte“, „Tafel“ oder „Beleg“ bedeutet) steht das „Kanbanboard“. Auf dieser Tafel befinden sich Karten, die der Visualisierung des Workflows dienen. Das Board ist in Spalten unterteilt die in der Basis die Spalten „Eingang“ (ToDo), “In Arbeit” (Doing) sowie „Erledigt“ (Done) enthalten. Diese Spalten sind jedoch nicht fest vorgeschrieben – wichtig ist nur, dass die Karten im Workflow des Kanbanboards stets im Fluss in eine Richtung “wandern”. Über zusätzliche Metriken ist es mit dem Kanbanboard so möglich, Optimierungen am Produktentwicklungsprozess vorzunehmen.

Kanban in der IT-Abteilung

Ein exemplarisches Kanbanboard, wie es bei uns in der NovaTec eingesetzt wird.

Die Arbeit wird in Kanban nach dem „Pull-Prinzip“ verrichtet. Dies bedeutet, dass sich ein Entwickler bei frei werdender Kapazität zum Kanbanboard begibt, sich die am höchsten priorisierte Aufgabe aus der „ToDo“-Spalte nimmt und in die Spalte „Doing“ schiebt. Gleichzeitig limitiert Kanban über das so genannte “Work-In-Progress Limit” („WIP-Limit”) die maximale Anzahl an Aufgaben, die sich in den zwischengelagerten Spalten (innerhalb von ToDo und Done) befinden dürfen. Hierüber wird in Kanban eine Überproduktion vermieden, was in der Softwareentwicklung eine Entlastung der Mitarbeiter darstellt und Engpässe deutlich sichtbar macht.

Die Pflege des Kanbanboards ist, um Verbesserungen des Prozesses bzw. des Arbeitsflusses zu erreichen, von fundamentaler Bedeutung. Vernachlässigt man dessen Pflege, so kann dies dazu führen, dass Entwicklung und Management am Board “vorbei arbeiten” und die Aufgaben zur sofortigen Erledigung dem Entwicklungsteam übertragen werden. Neben dem Effekt, das auf diese Weise gesetzte WIP Limits nicht beachtet werden, ist eine Transparenz des Arbeitsflusses nicht mehr gegeben. Einige Teilnehmer haben während der Sessions des PM-Camps berichtet, das in ihren Organisationen die Vernachlässigung des Kanbanboards dazu führte, dass keine Verbesserungen im Prozess erzielt wurden. Beispielsweise war kaum eine Aufgabe in der korrekten Spalte angeordnet, und da die Entwicklung das Board und dessen Bedeutung und Zweckmäßigkeit nicht anerkannte, tat dies auch das Management nicht. Die Implementation von Kanban war somit gescheitert.

Um mit der Kanban Methode erfolgreich zu sein empfiehlt der „Begründer“ von Kanban in der IT, David J. Anderson, drei fundamentale Prinzipien zu befolgen:

  1. Beginne dort, wo du dich im Moment befindest
  2. Strebe inkrementelle, evolutionäre Veränderungen an
  3. Respektiere den bestehenden Prozess, die existierenden Rollen, Verantwortlichkeiten und Berufsbezeichnungen

Die bestehenden Prozesse bleiben bewahrt und werden inkrementell und evolutionär geändert bzw. verbessert. Hierdurch sollen initiale Ängste gegenüber der Einführung von Kanban abgebaut und eine breitere Unterstützung für die Kanban Initiative eingeholt werden können. Weitere sieben Kerneigenschaften festigen die Prinzipien von Kanban:

  1. Visualisierung des Arbeitsflusses
  2. Limitierung des WIP
  3. Messung und Steuerung des Arbeitsflusses
  4. Explizite Ausweisung der Prozess-Regeln
  5. Verbesserung durch Kollaboration (durch Modelle und wissenschaftliche Methoden)
  6. Unterstützung von Ideen und Förderung von Prozessverbesserungen durch jedes Teammitglied
  7. Implementierung von gesamtorganisatorischem Feedback

In seinem Buch “Kanban – Successful Evolutionary Change for Your Technology Business” geht Anderson näher auf Kanban und seine Kerneigenschaften ein.

Fazit

Kanban optimiert den Durchfluss der Arbeit in einer funktional organisierten Softwareentwicklung unter gleichzeitiger Vermeidung von Überlast. Durch die Visualisierung des Workflows und der Aufgaben hilft Kanban dabei das Projekt besser zu organisieren und die Arbeitseffizienz zu steigern. Auf Grund der wenigen Regeln, die Kanban vorschreibt, ist es auch vermeintlich einfach, damit zu starten. Die wenigen vorhandenen Regeln sollten jedoch gründlichen befolgt werden, da sonst ein Scheitern nicht unwahrscheinlich ist. Um dies zu erreichen, empfiehlt es sich zum einen für den Prozess verantwortlichen Mitarbeiter zu benennen, und zum anderen ist es durchaus sinnvoll, je nach organisatorischem Umfeld Dinge zu regeln, die über die reinen Kanban Vorgaben hinausgehen. Durch eine sorgfältige Analyse der Rahmenbedingungen in der jeweiligen Organisation und den Einsatz eines dafür angepassten Kanban kann dann erhebliches Projekterfolgspotenzial freigesetzt werden.

~ Pascal Naujoks und Harald Müller

Leave a Comment

7 comments

  1. S

    Dazu gibt es auch einen netten Comic, der das veranschaulicht: Ein Tag im Kanban-Land

  2. H

    Sorry … das ist kein Kanban sondern ein schlichtes Scrum-Taskboard…..
    So etwa fehlen die für Kanban essentiellen WIP-Limiten …. und die Puffer zwischen den Arbeitsschritten …

  3. P

    Hallo Hans-Peter, vielen Dank für dein Feedback. Die WIP-Limits sind bekannt aber ich gebe dir recht, dass bei der visuellen Darstellung am Board noch Luft nach oben ist 🙂 Grüße in die Schweiz, Pascal

  4. H

    Wenn die WIP-Limits bekannt sind, dann müssen sie auch oben bei jeder Spalte stehen.

    Puffer sind unabdingbar. So wie bei “Drum-Buffer-Rope”. Anstonsten wird es ein reines und starres “Rope”-System. Das bedeutet dann, dass der GESAMTE Fluss stockt, wenn es in nur einem Arbeitsschritt einen Stau gibt. weil z.B. das WIP-Limit des Folgeschritts erreicht ist.

    Mehr dazu in Abb. 10-3 im Buch Kanban: Evolutionäres Change Management für IT-Organisationen von David J. Anderson (Autor)

    Leider hat sich eingebürgert, weil “Kanban” modern ist, dass jedes schlchte Taskboard zu einem “Kanban” wird….. Gut, dass Taiichi Ohno davon nichts mehr mitbekommt …

    <8-) Hans-Peter

  5. A

    Hallo Hans-Peter, was die Notwendigkeit von Puffern in einer Produktionskette anbetrifft, stimme ich Dir voll und ganz zu. Allerdings bin ich durchaus der Meinung, dass das oben abgebildete Board diese auch vorsieht: Benennt man die Spalte “Durchführung” in “Evaluiert” oder “Zur Umsetzung” und die Spalte “QS” in “Umgesetzt” oder “Zur Abnahme” um, wird eventuell etwas schneller ersichtlich, dass es sich dabei um die von Dir angesprochenen Puffer zwischen den Arbeitsschritten handelt. Zudem formalisierst Du in meinen Augen das Werkzeug “Kanbanboard” über dessen Notwendigkeit hinaus. Die essentiellen Punkte müssen sein, dass es zum einen den Workflow und den Status im Sinne des „WiP“ der einzelnen Work-Items visualisiert, und zum anderen das Pull-Prinzip des Vorgehens unterstützt. Die Angabe der Limits in den Spalten hingegen ist bestenfalls ein Weg, die dem Vorgehen zugrundeliegenden Regeln explizit zu machen, sind aber für die Funktionsfähigkeit des Werkzeugs nach meinem Dafürhalten keine zwingende Voraussetzung.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close