Thursday, December 9, 2010

Visualisierung, Teil 1: Das Board

In einem früheren Blogpost habe ich geschrieben, dass Visualisierung eines der Grundprinzipien von Kanban darstellt und dass häufig schon eine recht simple Visualisierung einen riesigen Erkenntnisgewinn bringt und Veränderungen anstoßen kann. Grund genug, etwas mehr zu Visualisierung zu schreiben. In diesem Post geht es um das Kanban-Board, später wird es noch je einen Post zu Tickets und weiteren Elementen geben, die es zu visualisieren lohnt.
Das Kanban-Board ist das zentrale Planungs- und Steuerungstool jedes Kanban-Teams. Die Standup Meetings sollten vor dem Board abgehalten werden, ebenso wie die Retrospektiven/Operations Reviews. Darüber hinaus lässt sich anhand des Boards besser über Probleme bei der täglichen Arbeit diskutieren. Und nicht zuletzt erlaubt das Board nicht nur dem Team Einsichten über den Prozess und den Zustand einzelner Aufgaben, sondern auch Stakeholdern und Mitgliedern aus anderen Teams. All diese Punkte machen zwei Dinge deutlich: 1) Das Board sollte so groß wie möglich sein, damit möglichst viele Details vom Arbeitsplatz aus erkennbar sind. 2) Das Board sollte so platziert werden, dass es von möglichst vielen Teammitgliedern mit dem kleinst möglichen Aufwand eingesehen und aktualisiert werden kann. Selbst wenn man nur kurz von seinem Arbeitsplatz aufstehen und einmal um die Ecke gehen muss, stellt dies oft schon eine Hemmschwelle dar, das Board so oft zu verwenden, wie es hilfreich wäre. Elektronische Tools haben übrigens immer so eine "Ecke" eingebaut: Selbst wenn es nur zwei Klicks dauert, das elektronische Board zu öffnen, stellt dies eine kleine Hemmschwelle dar. Auch wenn es logisch kaum zu erklären ist, führt dies oft dazu, dann nicht im Tool nachzusehen oder eine kleine Ergänzung vorzunehmen. Wenn man allerdings nur kurz den Kopf heben und etwas drehen muss, um die nötigen Informationen zu erlangen, so führt dies zu einer regeren Nutzung. Aus diesem Grund empfiehlt es sich, auch dann ein physikalischen board zu verwenden, wenn man parallel dazu auch ein elektronisches Tool einsetzt.

Welche Informationen sollten auf dem Board erkennbar sein? Obwohl die Details ja nach Kontext abweichen können, gibt es einige Punkte, die wohl generell für jedes Board gelten:
  • Der Workflow, also die Reihenfolge der Prozessschritte, die eine Aufgabe (normalerweise) durchläuft.
  • Die Anzahl der Aufgaben, die sich gerade im System befinden. Allein die tatsächliche Menge an Aufgaben am Board zu sehen, hat häufig einen enormen Effekt. Auch wenn man schon vorher irgendwie wusste, dass man an zu vielen Dingen gleichzeitig arbeitet.
  • Der jeweilige Prozessschritt, in dem sich eine Aufgabe befindet (in Entwicklung, beim Test usw.)
  • Der jeweilige Zustand jedes einzelnen Tickets: | In Arbeit | wartet darauf, in den nächsten Schritt gezogen zu werden | blockiert | fertig |. Der Zustand bietet einen wichtigen Anhaltspunkt, um über Verbesserungsmaßnahmen zu diskutieren, beispielsweise wenn über die Ursachen von Blockaden gesprochen wird.
  • Die Work-in-Progress-Limits für die einzelnen Prozessschritte
  • Die Reihenfolge, in der neue Tickets gezogen werden. Dieser Punkt wird in der Regel nicht allein durch das Board visualisiert, sondern durch eine Kombination aus der Anordnung der Tickets am Board, der Art der Tickets (Serviceklasse) und vereinbarten Teamregeln.
  • Der Mitarbeiter (bzw. das Pair oder das Team), der gerade an der Aufgabe arbeitet. Dies ist zum einen deshalb wichtig, damit jeder weiß, an wen er sich wenden kann, wenn er eine Frage zu einem Ticket hat. Zum anderem macht diese Kennzeichnung deutlich, wenn einzelne Teammitglieder an sehr vielen Tickets gleichzeitig arbeiten, was häufig auf Wissensmonopole hindeutet.
Das Board soll auf einen Blick die Verteilung der Aufgaben zeigen und Probleme sichtbar machen.


Zum Weiterlesen:

No comments:

Post a Comment