Dienstag, 14. Dezember 2010

Visualisierung, Teil 2: Die Tickets

In einem früheren Post zu den Prinzipien von Kanban habe ich geschrieben, dass ein sehr großer Teil der positiven Wirkung von Kanban durch die Visualisierung zustande kommt. Neben dem Kanban-Board sind die Tickets wichtige Artefakte, die zur Visualisierung dienen. Tickets sind in der Regel Karteikarten, Haftnotizen, ausgedruckte Zettel, oder auch virtuelle Tickets in einem elektronischen Tool, auf denen die wichtigsten Informationen zur jeweiligen Aufgabe vermerkt sind. Die Tickets sollten groß genug sein, damit man die wichtigsten Informationen auch aus einigen Metern Entfernung lesen kann. Im Einzelnen sollten diese Informationen auf jeden Fall auf einem Ticket vermerkt sein:
  • Möglichst sprechende Bezeichnung der Aufgabe, z.B. "Validiere Teilnehmer-Mailadresse".
  • Der Name des augenblicklichen Bearbeiters/Pairs/Teams. Bei Fragen weiß so jedes Teammitglied, an wen es sich wenden kann. Und darüber hinaus wird deutlich, welche Teammitglieder an wie vielen Tickets gleichzeitig arbeiten (und wo sich evtt. zu viel Expertentum/Wissensmonopole befindet). Einige Teams verwenden Sticker oder Magnete mit Portraits oder Avataren, die auf die jeweiligen Tickets geklebt werden. So lässt sich schnell herausfinden, welche Kollegen an zu vielen Aufgaben gleichzeitig arbeiten. Wenn man die Anzahl der Sticker/Magnete beschränkt, kann man über diese Visualisierung also auch eine einfache WIP-Limitierung pro Person vornehmen.
  • Das Eingangsdatum (also das Datum, an dem mit der aktiven Arbeit am Ticket begonnen wurde), und nach Erledigung das fertigstellungsdatum (also das Datum, an dem Das Ticket den Bereich der Wertschöpfungskette, den wir kontrollieren, verlassen hat). Das Eingangsdatum ist eine wichtige Information bei den Standup Meetings, weil ein lange zurückliegendes Eingangsdatum auf Probleme hinweisen kann und man dieses Ticket eventuell als blockiert behandeln sollte. Aus der Differenz zwischen Eingangs- und Ausgangsdatum lässt sich dann die Durchlaufzeit errechnen. Je nach Kontext kann es sinnvoll sein, zusätzlich die Daten auf dem Ticket zu vermerken, an denen das Ticket jeweils in einen neuen Prozessschritt gezogen bzw. in eine Queue geschoben wurde. Allerdings kann es verwirrend sein, alle diese Daten auf dem Ticket selbst zu vermerken, so dass es häufiger sinnvoll ist, sie nur in dem Tool festzuhalten, mit dem man auch die Tracking-Diagramme erstellt (Excel, Googel-Spreadsheets usw.)
  • Wenn ein Ticket blockiert ist, sollte dies auf den ersten Blick zu erkennen sein. Die meisten Teams kleben dafür eine rote Haftnotiz auf das entsprechende Ticket.
Zu diesen Basisinformationen können je nach Kontext weitere Elemente hinzukommen, die man auf den Tickets festhalten sollte:
  • Wenn man mit verteilten Teams arbeitet und/oder zusätzlich ein elektronisches Kanban-Tool/Bugtracker verwendet: Eine Ticket-ID, mit der man die Verbindung zum elektronischen Ticket herstellt und auf die man sich bei Telefonkonferenzen, in E-Mails usw. beziehen kann. 
  • Die Serviceklasse der einzelnen Tickets - sofern man mit unterschiedlichen Serviceklassen arbeitet. Dann ist besonders wichtig:
    • Mit welcher Priorität die Tickets behandelt werden sollen. Häufig wird dieser Kennzeichnung über die Farbe der Tickets vorgenommen (z.B. Weiß für besonders eilige Aufgaben (Expedite-Tickets)). Es gibt hierfür allerdings auch andere Möglichkeiten. Henrik Kniberg schlägt beispielsweise vor, einen roten Stern auf ein Ticket zu malen, um hohe Priorität anzuzeigen. Sollte es dann zu einem Notfall werden, wird ein zweiter Stern hinzugefügt (Panik). Dies hat den Vorteil, dass  sich die Serviceklasse leichter ändern lässt.
    • Bei Tickets, die einen fixen Liefertermin haben (d.h., dass extrem hohe Verzugskosten entstehen, wenn das Ticket bis zu diesem Termin nicht erledigt wurde), sollte dieses Datum ebenfalls direkt auf dem Ticket vermerkt werden.

Links und Literatur

Keine Kommentare:

Kommentar veröffentlichen