Software-Kanban im Einsatz

Serviceklassen

Software-Kanban zielt darauf ab, einen schnellen, vorhersehbaren und stetigen Arbeitsfluss zu etablieren. Um das zu unterstützen, werden Arbeiten in Arbeitstypen wie Feature-Programmierung, Wartungsaufgaben und Änderungsanforderungen eingeteilt und mit Stickern auf den Tickets oder mit sogenannten Swim-Lanes am Kanban-Board visualisiert.

Swim-Lanes für verschiedene Arbeitstypen (Abb. 5)

In der Abbildung 5 sind die Arbeitstypen Features, Changes und Bugs zu sehen. Die Zahlen neben den Arbeitstypen repräsentieren ein WIP-Limit für den jeweiligen Arbeitstyp. Auf diesem Board dürfen sich zum Beispiel für den Arbeitstyp Features maximal sechs Tickets in den Arbeitsschritten Design, Entwicklung und Test befinden. Mit WIP-Limits bei Arbeitstypen lässt sich der Arbeitsfluss noch gezielter steuern. Im Beispiel sieht man, dass das Hauptaugenmerk auf neuen Features liegt. Wenn man etwa das WIP-Limit beim Arbeitstyp Bugs erhöht und dafür bei Features senkt, legt man den Fokus des Arbeitsflusses auf die Stabilisierung der Software.

Ein weiterer wichtiger Punkt zur Steuerung des Arbeitsflusses sind Serviceklassen. Ähnlich wie Paketdienste unterschiedliche Behandlungen von Paketen anbieten (Standardversand, Expressversand etc.), werden Tickets in Kanban differenziert behandelt. Serviceklassen beruhen auf der sogenannten Cost-of-Delay-Funktion. Das heißt, dass die Auswirkungen auf das Geschäft ausschlaggebend für die Zuteilung einer Arbeit in eine Serviceklasse sind. Diese Klassen visualisiert man durch verschiedenfarbige Tickets am Kanban-Board.

Gängige Serviceklassen sind "beschleunigt", "fester Liefertermin", "Standard" und "unbestimmbare Kosten". Arbeiten, die unmittelbar hohe Kosten verursachen, wie ein Serverausfall bei einem Webprodukt, erfasst das Kanban-Team auf "Beschleunigt"-Tickets und behandelt sie mit höchster Priorität; sie dürfen temporär auch das WIP-Limit überschreiten. Tickets mit festem Liefertermin verwendet man für Arbeiten, die hohe Kosten verursachen, wenn sie nicht an einem definierten Termin fertiggestellt sind. Ein Beispiel ist das Adaptieren einer Software aufgrund gesetzlicher Rahmenbedingungen, die zu einem bestimmten Zeitpunkt in Kraft treten. Wenn die Änderungen nicht zeitgerecht erfolgen, könnte dies hohe Strafzahlungen oder sogar Geschäftsunfähigkeit zur Folge haben.

In die Klasse "unbestimmbare Kosten" fallen Arbeiten, die erst mal beinahe unbedeutend sind, aber in unbestimmter Zeit große Auswirkungen haben können. Ein Beispiel ist ein Versions-Upgrade einer Softwarekomponente: Anfangs mag das eher unbedeutend sein, da die Software noch einwandfrei mit dem Gesamtsystem funktioniert. Sobald jedoch abhängige Softwarekomponenten nicht mehr mit der alten Version kompatibel sind, hat dies große Auswirkungen auf das Gesamtsystem. In der Standard-Arbeitsklasse erfasst man Arbeiten des Alltagsgeschäfts. Die Wichtigkeit der richtigen Zuteilung von Arbeiten in Serviceklassen wird in Kanban durch zusätzliche Limitierungen Nachdruck verliehen: Es dürfen sich zum Beispiel maximal 5 Prozent "Beschleunigt"- und 10 Prozent Tickets mit "festem Liefertermin" im System befinden.

Arbeitstypen und Serviceklassen bilden die Grundlage für Service Level Agreements (SLAs). In diesen garantiert das Kanban-Team die Fertigstellung der Arbeiten einer gewissen Serviceklasse beziehungsweise eines gewissen Arbeitstyps innerhalb eines definierten Zeitraums. Das gibt den Stakeholdern eine hohe Planungssicherheit, da Kanban-Teams meist eine SLA-Zuverlässigkeit von über 90 Prozent aufweisen.

Ein weiterer wichtiger Punkt zur Steuerung des Arbeitsflusses sind periodische Besprechungen. In Kanban-Teams werden sogenannte Daily-Standup-Meetings durchgeführt, in denen das Team die Arbeiten am Board bespricht. Ihr Ziel ist es, die Arbeiten zu koordinieren und den Arbeitsfluss aufrechtzuerhalten. Dabei werden die einzelnen Tickets am Kanban-Board von rechts nach links besprochen: Rechts stehen die Arbeiten, die kurz vor der Fertigstellung sind, weswegen ihnen erhöhte Aufmerksamkeit zukommt. Die meisten Kanban-Teams besprechen nur Problem-Tickets beziehungsweise solche, bei denen in naher Zukunft Probleme auftreten könnten. Das ist effektiv, und es gibt Kanban-Teams von mehr als 40 Personen, die Daily-Standup-Meetings innerhalb von nur zehn Minuten durchführen. Außerdem gibt es sogenannte Queue-Replenishment-Meetings, bei denen Personen, die in einer Arbeitsbeziehung mit dem Kanban-Team stehen, die Abarbeitungsreihenfolge der Tickets festlegen.

Kanban-Teams definieren konkrete Prozessregeln und machen diese für alle Beteiligten transparent. Das führt bei Problemen zur Diskussion über bestehende, greifbare Regeln und lässt kein subjektives, emotionales und mit Anekdoten übersätes Streitgespräch zu. Objektiv geführte Diskussionen bei Streitthemen erhöhen die Wahrscheinlichkeit konsensbezogener Entscheidungen erheblich.

Eines der Hauptziele von Kanban-Teams ist das Streben nach kontinuierlicher Verbesserung – der Etablierung einer Kaizen-Kultur. Als Basis der Optimierungen führen Teams laufend Messungen der Arbeit durch, zum Beispiel zur Durchlaufzeit, zum Durchsatz und zur Flusseffizienz. Durch sie gelangt man zu Informationen, durch die sich zielgerichtete Optimierungen wie die Reduktion von Variabilität durchführen lassen. Variabilität ist eine Abweichung vom Standard-Arbeitsfluss und hat demnach Auswirkungen auf die Berechenbarkeit der Arbeit. Sie können etwa durch zu hohe WIP-Limits, unterschiedliche Komplexität von Aufgaben, hohe Anzahl an Blockaden und zu viele Bugs verursacht werden. Ein weiterer Punkt, auf den sich Kanban-Teams beim Verbessern konzentrieren, ist die Reduktion von Verschwendung (Waste) [4]. Es handelt sich um Aktionen, die keinen Mehrwert für den Kunden generieren. Aktionen, die keinen Mehrwert generieren, jedoch bei Nicht-Durchführung die Leistung des Team negativ beeinflussen, werden dabei nicht beseitigt.

Eine wichtige Methode, die Kanban-Teams für Optimierungen des Arbeitsflusses verwenden, ist die Engpasstheorie [5]. Sie geht von der Erkenntnis der Systemtheorie aus, dass der Durchsatz eines Systems ausschließlich von einem begrenzenden Faktor bestimmt wird. Wenn zum Beispiel in unserem Arbeitsfluss von oben das Testen am längsten dauert, bestimmt dieser Arbeitsschritt den Durchsatz des Gesamtsystems. Mit den fünf Fokussierungsschritten der Engpasstheorie lassen sich Engpässe beseitigen:

  • Schritt 1: Den Engpass identifizieren. Mit der Visualisierung des Arbeitsflusses und der WIP-Limits werden Engpässe leicht sichtbar.
  • Schritt 2: Ausschöpfen des Engpasses. Man stellt sicher, dass die beschränkende Ressource immer Arbeit hat. Zusätzlich wird der Engpass entlastet, indem jemand anderes Arbeiten, die nicht unbedingt im Engpass durchzuführen sind, übernimmt.
  • Schritt 3: Alles dem Engpass unterordnen. Es wird dafür gesorgt, dass im Engpass optimal gearbeitet werden kann und dass nur so viel Arbeit im Gesamtsystem vorhanden ist, wie der Engpass verarbeiten kann.
  • Schritt 4: Engpass beheben. Der Engpass bekommt mehr Ressourcen. Dieser Schritt passiert ausdrücklich erst an vierter Stelle, da mehr Ressourcen mit zusätzlichen Kosten und Overhead verbunden sind.
  • Schritt 5: Wieder bei Schritt 1 beginnen. Durch die Beseitigung eines Engpasses tritt immer ein neuer Engpass im System auf.