Kanban Reloaded

In meinem letzten Blogeintrag habe ich die agile Methode „Kanban“ bereits vorgestellt. Ich konnte zeigen, was Kanban ist und wie wir Kanban in einem Wartungsteam eingeführt haben. Der Blog endete mit einem Ausblick auf den vor uns liegenden Weg und die Umsetzung der noch offenen Punkte.
An dieser Stelle möchte ich nun anknüpfen und den Erfahrungsbericht fortsetzen.

Kanban Board 2.0

In der Einführungsphase sind wir recht schnell zu einem Boardaufbau gekommen, der die wesentlichen Bestandteile unseres Prozesses abdeckte:

Abbildung 1: Die erste Version des Kanban Boards

Die erste Änderung, die wir durchführten, war die Einführung von WiP-Limits (Work in Progress). Je nach Phase, setzen wir diese unterschiedlich (2-3 Karten pro Teammitglied). Außerdem begrenzten wir die maximale Anzahl an Karten, die ein Teammitglied auf dem Board verteilen kann. Hier wählten wir ein Limit von 9, um jedem die Möglichkeit zu geben auch dann weiter zu arbeiten, wenn einzelne Aufgaben blockiert sind. Insbesondere der Buildprozess kann zu einer Blockade führen. Nämlich immer dann, wenn einzelne Aufgaben zwar bereits umgesetzt sind,  aber ein einchecken noch nicht erfolgen darf z.B. Codefreeze in Rework-Phasen.
Dieses Board weite Limit haben wir auch sichtbar gemacht, jedes Teammitglied hat Stecknadeln in einer bestimmten Farbe. Sind diese aufgebraucht, ist das Teammitglied voll ausgelastet.

Um auch im Eingangspuffer eine Vorabzuordnung von Aufgaben zu Bearbeitern vornehmen zu können, verwenden wir kleinere Stecknadeln in der Farbe des vorgeschlagenen Bearbeiters. Diese Zuweisung ist jedoch nicht fest, so dass prinzipiell jedes Teammitglied die Aufgabe übernehmen kann. Die kleinen Stecknadeln sind nicht durch ein Limit begrenzt, allerdings sorgt das Pull Prinzip von Kanban dafür, dass kein Mitarbeiter schon an dieser Stelle überlastet wird. Die kleinen Stecknadeln sind nur eine Empfehlung der Projektleitung. Die Stecknadeln werden entsprechend den bekannten Aufgabengebieten der Teammitglieder gesetzt. Jedes andere Teammitglied kann und soll die Aufgabe aber auch übernehmen können.

Die Einführung der Limits funktionierte sehr gut. Es zeigte sich jedoch schnell, dass unsere Boardaufteilung weiter angepasst werden muss. Wir entschieden uns dafür Zwischenpuffer einzuführen, für die außer dem globalen Boardlimit kein weiteres Limit gilt. Ein Beispiel für diesen Puffer, ist die Spalte „Bereit für Build“. Gerade in Übergangsphasen zwischen Releases zeigte sich nämlich, dass an diesen Stellen ein WiP Limit nicht sinnvoll ist.
Außerdem merkten wir schnell, dass die „Erledigt“ Spalte in der Analysephase kaum genutzt wurde. Die Karten wurden immer sofort von der Analysephase in die Umsetzungsphase gehängt. Deshalb entfernten wir sie und führten stattdessen am Ende des Boards eine neue Spalte „Warten auf Feedback“ ein, für die kein WiP Limit gilt. Diese Spalte ist für die Aufgaben, die noch „beobachtet“ werden sollen.
Das war für uns sinnvoll, da Aufgaben teilweise nur analysiert und dann ggf. an andere Bereiche weitergereicht werden. Bei Vorbereitungen von Abstimmungs- oder Statuslisten, können diese Aufgaben nochmal kurz überprüft werden um sie z.B. in Telefonkonferenzen anzusprechen.
Erst wenn Aufgaben für unser Team definitiv als abgeschlossen gelten, wandern sie in die Spalte „Abgeschlossen“, in der sie regemäßig vom Projektmanagement geprüft und dann entfernt werden.

Serviceklassen

Wie bereits im ersten Blogeintrag angesprochen, muss in der Wartung immer mit einem Prio-1 Problem gerechnet werden. Um diese kenntlich zu machen, nutzen wir eine rote Markierung an der Aufgabenkarte. Dadurch fällt diese auf und auch Außenstehende sehen sofort, wie es mit der Bearbeitung steht bzw. wer gerade daran arbeitet. Für derart gekennzeichnete Tickets gilt kein WiP-Limit. Es darf jedoch nur eines davon geben.

Da sich diese Markierung als sehr praktisch erwies, führten wir noch eine zweite Serviceklasse mit einer gelben Markierung ein. Diese ist für Aufgaben die blockiert sind oder aus verschiedenen Gründen genauer im Auge behalten werden müssen. Für diese Klasse gelten die WiP-Limits.

Priorisierung

Die Retrospektive ist im „Agilen Prozess“ eine wichtige Methode zur stetigen Verbesserung des Prozesses. Das stellten wir schnell fest, denn die meisten Vorschläge zur Verbesserung des Boards und des Prozesses kamen innerhalb dieser Teammeetings. Einige wurden diskutiert und verworfen, andere stießen auf breite Unterstützung und wurden eingeführt.

Dies trifft auch auf die Priorisierung innerhalb des Eingangspuffers zu. Die Notwendigkeit kommt aus der Art der anzutreffenden Aufgaben innerhalb der Wartung. Es gibt Aufgaben, die schnellstmöglich umgesetzt werden müssen (Priorität A), Aufgaben des normalen Alltagsgeschäftes (Priorität B) und Aufgaben die erledigt werden können, wenn keine höher priorisierten Aufgaben anstehen (Priorität C).
Natürlich könnte das noch weiter detailliert werden, allerdings erschien uns der Mehraufwand einer detaillierteren Priorisierung in Hinsicht auf den Nutzen als zu gering. Deshalb beschränken wir uns auf die genannten drei Priorisierung und sortieren nur innerhalb der einzelnen Bereiche nochmals grob, d.h die etwas wichtigeren stehen weiter oben.

 

kanbanboard2.jpg

Abbildung 2: Kanban Board 2.0 mit Priorisierungen und WiP Limits


Die Aufgabenkarten

Was bisher kaum Erwähnung fand, ist der Aufbau der Aufgabenkarten. Diese änderten wir seit Beginn der Einführung kaum ab. Außer Angaben zur Aufgabe (ggf. Ticketnummer) und dem Eingangs- / Ausgangsdatum werden bei uns nicht mehr Informationen zur Verfolgung der Aufgabe benötigt.

Wir sind Agil – Und nun?

Sicher ließe sich an dieser Stelle lange darüber diskutieren, ob wir jetzt an einem Punkt angelangt sind, an dem uns Kanban geholfen hat, die Bearbeitung der Aufgaben zu beschleunigen. Diese Aussage läßt sich jedoch nicht immer so einfach treffen.
Die Bearbeitung war auch vor der Einführung von Kanban nicht langsam. Kanban hat uns viel mehr dazu gedient, eine bessere Strukturierung und Visualisierung der Aufgaben und Tätigkeiten vorzunehmen. Kein Teammitglied sollte unbemerkt in zu viel Arbeit untergehen.

Die sehr gute Visualisierung und Strukturierung, sowie ein ausgewogenes „Loadbalancing“ unter den Teammitgliedern haben wir erreicht. Dies zeigt sich in den mindestens zweitägig durchgeführten Statusbesprechungen des Teams. Aktuelle Aufgaben werden in diesen „Stand-Ups“ kurz durchgesprochen und eine Überlastung Einzelner durch frühzeitige Umverteilung oder zusätzliche Unterstützung vermieden.

Die Einführung von Kanban hat bei uns sehr gut funktioniert und wir mussten die vorhandenen Prozesse wenig anpassen, um unmittelbar einen Nutzen daraus ziehen zu können. Ich kann also jedem mit einem ähnlichen Projekthintergrund nur empfehlen, Kanban auszuprobieren.