Software-Kanban im Einsatz

Inhaltsverzeichnis

Wer die Softwareentwicklung verbessern möchte und nicht gleich eine unternehmensweite Revolution mit agilen Methoden starten will, findet in Software-Kanban eine gute Alternative. Der Artikel liefert eine Vorgehensweise für eine mögliche Implementierung.

Kanban wurde mit dem Toyota-Produktionssystem (TPS) [1] bekannt, das die Autoproduktion revolutionierte. Das Wort Kanban ist japanisch und bedeutet Signalkarte, und im TPS signalisiert eine Kanban-Karte dem jeweils vorgelagerten Produktionsbereich, was in welchen Mengen produziert werden soll. Das führt zu einer Just-in-time-Produktion, die nur das herstellt, was wirklich gebraucht wird.

David J. Anderson überarbeitete die Grundidee von Kanban wesentlich und passte sie den spezifischen Bedürfnissen der Softwareentwicklung an [2]. Das Resultat ist ein evolutionärer Ansatz zur Verbesserung der Softwareentwicklung. Evolutionär bedeutet in diesem Kontext, dass sich bei der initialen Einführung von Kanban wenig an der gewohnten Arbeitsweise ändert: Etablierte Prozesse sowie die Rollen im Unternehmen beziehungsweise im Team bleiben bestehen, und es werden auch keine neuen Job-Titel erfunden. Das Kanban-Team einigt sich jedoch darauf, permanent kleine Verbesserungen der Arbeitsweise vorzunehmen. Ausgangspunkt der Überarbeitungen ist immer die gegenwärtige Situation und nicht ein definierter Zustand, den man erreichen will; demnach gibt es nicht "den" Kanban-Sollzustand. Vielmehr halten sich Kanban-Teams an folgende grundlegenden Prinzipien [3]:

1. Visualisierung des Arbeitsflusses und der Arbeit
2. Limitierung des WIP (WIP = Work In Progress, in Ausführung befindliche Arbeit)
3. Steuerung und Messung des Arbeitsflusses
4. Prozess-Regeln explizit machen
5. Verbesserung durch bewährte Modelle und wissenschaftliche Methoden

Unter Einhaltung dieser Prinzipien haben sich Vorgehensweisen etabliert, die viele Kanban-Teams teilen und aus denen dieser Artikel eine mögliche Implementierung von Kanban in einem IT-Team ableitet.

Arbeitsfluss und Arbeit im Blick

Alle Schritte, die Arbeiten bis zu ihrer Fertigstellung durchlaufen, visualisiert ein Kanban-Team auf einem Whiteboard – dem Kanban-Board. Ein exemplarischer Arbeitsfluss der Softwareentwicklung könnte aus den Arbeitsschritten Design, Entwicklung und Test bestehen. Bei jedem Schritt werden die Kriterien der Fertigstellung ("definition of done") explizit vermerkt, damit alle Teammitglieder das gleiche Verständnis darüber haben, wann eine Arbeit abgeschlossen ist. Arbeitsaufträge werden auf Tickets erfasst und in die Spalte am Board bewegt, in der sich die Arbeit im Moment befindet. Zusätzlich erhält jedes Ticket einen Avatar der zuständigen Person, damit auf einen Blick ersichtlich ist, wer derzeit welches Ticket behandelt.

Wenn die Arbeit an einem Ticket unterbrochen ist, markiert man das Ticket mit einem roten Sticker als blockiert. Arbeitsblockaden können zum Beispiel durch fehlende Informationen, fehlende Infrastruktur oder Ähnliches verursacht werden. Ein stetiger Arbeitsfluss ist eines der Hauptziele in Kanban und demnach hat das Beheben von Blockaden, die den Arbeitsfluss unterbrechen, hohe Priorität.

In Kanban werden erledigte Arbeiten nicht in den nächsten Arbeitsschritt geschoben (push), sondern der Bearbeiter dieses Arbeitsschritts holt sich die Arbeit (pull) vom Vorgänger, wenn er bereit dafür ist. Erledigte Arbeiten markiert man mit einem grünen Sticker oder durch eine Zweiteilung des Arbeitsschritts in "Do" und "Done".

Wider den Engpass

Kanban beschränkt die Anzahl der gleichzeitigen Arbeiten in jedem Arbeitsschritt (WIP-Limit). Diese Begrenzung geht unter anderem auf die einfache Überlegung zurück, dass es sinnvoller ist, eine Arbeit zu 100 Prozent fertig zu haben als zehn Arbeiten zu 10 Prozent. Je größer die Anzahl der aktiven Arbeiten im System ist, desto höher sind die Durchlaufzeiten.

Die Abbildung 3 zeigt, wie sich drei Arbeiten sequenziell und quasi-parallel abarbeiten lassen. Letzteres bedeutet, dass ein permanenter Aufgabenwechsel zwischen den Arbeiten stattfindet, da Menschen nicht fähig sind, aktive Aufgaben gleichzeitig durchzuführen. Man sieht, dass die sequenziellen Aufgaben in jeweils fünf Zeiteinheiten abgearbeitet werden – die Durchlaufzeit beträgt demnach fünf Zeiteinheiten pro Aufgabe. Bei quasi-paralleler Abarbeitung erhöhen sich die Durchlaufzeiten auf 16, 17 und 18 Zeiteinheiten für die rote, gelbe und blaue Aufgabe. Der ständige Aufgabenwechsel fordert einen zusätzlichen Aufwand, da das Projektmitglied sich andauernd in die Aufgaben wieder einarbeiten muss. Der Zusatzaufwand ist in diesem vereinfachten Beispiel mit einer Zeiteinheit pro Aufgabe quantifiziert.

Zusätzlich werden in einem WIP-limitierten Pull-System Engpässe sichtbar: Der in den Engpass Involvierte kann keine Arbeit vom Vorgänger abholen, weil er noch mit der aktuellen Aufgabe beschäftigt ist. Und da der Vorgänger durch ein WIP-Limit beschränkt ist, kann er sich auch keine Arbeit von seinem Vorgänger abholen. Die Konsequenz ist die Blockade des Arbeitsflusses und Kollegen, die am Weiterarbeiten gehindert werden.

Die WIP-Limits werden durch die Zahlen im jeweiligen Arbeitsschritt gekennzeichnet. Am Board oben hat der Schritt Entwicklung ein WIP-Limit von 2, demnach dürfen sich maximal zwei Tickets in dieser Spalte befinden. Das Board zeigt einen Zustand, in dem ein Entwickler mit der Bearbeitung beider Tickets fertig wurde – er hängt sie in die Spalte Done bei Entwicklung. Im Arbeitsschritt Design steht ein Ticket auf Done. Der Entwickler kann sich dieses Ticket jedoch nicht holen, da er das WIP-Limit von 2 überschreiten würde, wenn er es in die Spalte Entwicklung zieht. In diesem Fall unterstützt der Entwickler den Tester bei seiner Aufgabe, damit das Test-Ticket schneller beendet wird und der Arbeitsfluss wieder hergestellt ist.

Serviceklassen

Steuermann des Arbeitsflusses

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.

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.

Explizite Prozess-Regeln und bewährte Modelle

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.

Implementierung

Eine mögliche Kanban-Implementierung

Zur Übersicht lässt sich die folgende Vorgehensweise festhalten, die die zuvor beschriebenen Punkte zusammenfasst und auf die viele erfolgreiche Kanban-Teams zurückgreifen:

• Das Team visualisiert den Arbeitsfluss auf einem Kanban-Board.
• Arbeitsaufträge sind auf Tickets erfasst und werden über das Kanban-Board bewegt.
• Tickets werden vom nachfolgenden Arbeitsschritt geholt (Pull).
• Blockaden im Arbeitsfluss werden sichtbar gemacht.
• Jeder Arbeitsschritt wird durch ein WIP-Limit beschränkt.
• Durch WIP-Limits verursachte Stehzeiten von Mitarbeitern werden akzeptiert und dafür verwendet, Probleme in der Arbeitsweise zu beseitigen.
• Das Team teilt Arbeiten in Arbeitstypen ein, um den Arbeitsfluss gezielt zu steuern.
• Es teilt Arbeiten basierend auf der Cost-of-delay-Funktion in Serviceklassen ein.
• Service Level Agreements sind etabliert. In ihnen garantiert das Kanban-Team die Fertigstellung von Arbeiten innerhalb eines gewissen Zeitraums.
• Es finden Daily-Standup-Meetings und regelmäßige Queue-Replenishment-Meetings statt.
• Regeln für die Zusammenarbeit im Team und mit den Stakeholdern sind definiert.
• Das Team führt fortwährend Messungen des Arbeitsflusses durch.
• Es ist eine Kaizen-Kultur etabliert, die kontinuierliche Verbesserungen zum Ziel hat.
• Optimierungen basieren auf bewährten Methoden und werden nicht nach Bauchgefühl durchgeführt.
• Um die Berechenbarkeit zu erhöhen, wird die Variabilität im System reduziert.
• Verschwendung wird reduziert – mit dem Wissen, dass ein gewisser Grad an Waste notwendig ist.
• Das Team wendet die fünf Fokussierungsschritte der Engpasstheorie an, um mit Engpässen umzugehen.

Fazit

Obwohl sich Kanban durch den evolutionären Ansatz einfach und ohne große Widerstände in Organisationen einführen lässt, ist die Leistungssteigerung von Kanban-Teams beeindruckend. Eine Erklärung für den großen Erfolg von Kanban ist, dass es Teams dazu veranlasst, ihre eigene, spezielle Arbeitssituation kontinuierlich zu verbessern, und dass nicht "Kochrezepte" verfolgt werden, in der Hoffnung, dass sich eine Verbesserung einstellt. Kanban forciert das Lernen im Unternehmen und nicht, es selbst zu lernen.

Klaus Leopold
ist einer der ersten Kanban-Coaches und Trainer Europas. Er leitet seit 2003 Software-Teams und IT-Projekte im wirtschaftlichen und universitären Umfeld.

Literatur

1. Taiichi Ohno; Das Toyota-Produktionssystem; Campus 1993
2. David J. Anderson; Kanban – Successful Evolutionary Change for your Technology Business; Blue Print Press, 2010; siehe auch Rezension der deutschen Übersetzung
   
3. David J. Anderson; The Principles of the Kanban Method
4. Mary Poppendieck, Tom Poppendieck; Implementing Lean Software Development; Addison-Wesley, 2006
5. Eliyahu M. Goldratt; What is this thing called Theory of Constraints and how should it be implemented?; North River Press, 1990
6. Markus Andrezak, Arne Roock, Henning Wolf; Schützt das Team! Die Überlastung von Entwicklungsteams verhindern mit Kanban; Artikel auf heise Developer
7. Jean Pierre Berchez, Uta Kapp; Brüder im Geiste; Kriterien für eine Entscheidung für Scrum oder Kanban; Artikel auf heise Developer
8. Markus Andrezak, Arne Roock, Henning Wolf; Gedämpfte Schritte; Evolutionäre Entwicklung mit Software-Kanban; iX 6/2010, S. 108

(ane)