Das perfekte Kanban-Board …

… gibt es natürlich nicht. Aufbau und Anwendung eines Kanban-Boards müssen immer auf die spezifischen Arbeitsflüsse oder Anwendungszwecke im Unternehmen abgestimmt werden. Was ich hier vorstellen möchte, ist mein eigenes Kanban-Board, ein sogenanntes Personal-Kanban also, das sich für die Arbeit in einer Kommunalverwaltung gut eignet.

Mein Kanban-Board

Mit dem Kanban-Board habe ich alle vorigen Systeme abgelöst. Also lose Zettelchen, Listen, PostIts am Monitorrand. Auch die Aufgabenlisten und Erinnerungen im Mailsystem verwende ich nicht mehr.

Mein neues Morgen-Ritual

Seit der Umstellung gibt es morgends ein kleines Ritual: PC anwerfen, den Kollegen nebenan begrüßen, einen Kaffee rauslassen und dann E-Mails und Papiereingang checken. Mit diesem Ablauf dürfte ich mich in guter Gesellschaft befinden. Oder?

Jetzt aber kommt das Board ins Spiel. Alles, was ich nicht sofort erledigen kann, notiere ich auf einem PostIt und gehe damit ans Board. Die neuen Tickets werden zusammen mit den vorhandenen Tickets im Aufgabenspeicher jeden Tag neu priorisiert. Aus der Prio-1-Spalte stelle ich das Programm für den Tag zusammen.

Was im Laufe des Tages telefonisch, per Zuruf, Mail oder sonst wie dazukommt, wird ebenfalls notiert und landet in der Regel erst einmal im Aufgabenspeicher. Es sei denn, es kommt direkt vom Bürgermeister 😉 .

Ein bisschen Theorie

Was mit dem Board abgebildet wird, ist die Bearbeitung von Vorgängen oder Projektaufgaben, genauer die Statusinformationen der Vorgänge.

Die Unterscheidung nach „Der nächste Arbeitsschritt liegt bei mir“ und „Der nächste Arbeitsschritt erfolgt durch eine andere Person/Stelle“ (das erläutere ich weiter unten genauer) fasst alle Arbeitsschritte einer Swimlane (Zuständigkeit) im Prozess oder Workflow zusammen, ohne sie detailliert darzustellen.

Was ich bei meinem Board nicht mache, ist eine explizite Abschätzung des Aufwands (Storypoints). Auch habe ich kein Work-in-Progress-Limit (WiP) gesetzt. Für meine Zwecke genügt es, den Arbeitsfluss zu visualisieren und alle Aufgaben zentral an einer Stelle zu verwalten.

Personal-Kanban und Teamboards

Was mir noch Probleme macht, ist das Zusammenspiel von meinem Personal-Kanban mit anderen Boards (Teamboards). Bei den Projekten kommen nämlich Teamboards, analog oder elektronisch, zum Einsatz. Um meine Aufgaben zentral im Blick zu haben, müsste ich die mir zugewiesenen Tickets auf den Teamboards duplizieren und auf mein Personal-Kanban übertragen, was ich wegen des Aufwands nicht mache. Für dieses Problem habe ich noch keine gescheite Lösung gefunden.

Die Aufteilung

Die Aufteilung des Boards ist das Ergebnis mehrfachen Herumprobierens. Diese Änderungen waren leicht durchzuführen, weil die Linien auf dem Board aufgepinnt, also flexibel sind. Wie man ein solches Board selber baut, könnt ihr in meinem Blog-Artikel Teamboard im Eigenbau nachlesen.

Wie bei allen Kanban-Boards, visualisiert die Aufteilung den Fluss der Arbeit:

1. Liste der Linien-Aufgaben und Projekte (optional)
2. Aufgaben,
3. In Bearbeitung,
4. Wartet auf und
5. Erledigt

Spalte „Linie / Projekte“

Zu meinen Aufgaben gehören sowohl Linienaufgaben, das sind die Aufgaben, für die ich nach meiner Arbeitsplatzbeschreibung zuständig bin, und Projekte beziehungsweise projekthafte Aufgaben, also Aufgaben, die jeweils neu formuliert und übertragen werden, zum Beispiel durch einen Projektauftrag. Diese zwei Aufgabentypen habe ich zur Übersicht ganz links gepinnt.

Was ich schon einmal überlegt, aber noch nicht ausprobiert habe ist, für die Aufgaben Farbcodes zu hinterlegen, so dass die abgeleiteten Tickets/ Vorgänge/ Arbeitspakete auf PostIts in der jeweiligen Projektfarbe notiert werden.

Spalte „Aufgaben“

Die Spalte Aufgaben ist unterteilt in drei Kolonnen zur Priorisierung und zwar von

• „Kann noch warten“ (Prio 3), über
• „Denmnächst zu erledigen“ (Prio 2) bis
• „Steht als nächstes an“ (Prio 1).

Aus der Spalte mit den Prio-1-Aufgaben entnehme ich die Tickets zur Bearbeitung.

Spalte „In Bearbeitung“

Das Kriterium für diese Spalte ist: „Was erledige ich heute“. Die Betonung liegt auf „ich“ und auf „heute.

Mit dem Heute-Kriterium verhindere ich, dass Tickets ewig in dieser Spalte hängenbleiben. Bei der täglichen Priosierung schaue ich einfach, was eventuell vom Vortag übrig geblieben ist und beziehe das in die neue Priorisierung ein. Mit der Zeit hat sich eine gewisse Übung eingestellt, wie viele Tickets ich mir am Tag zur Bearbeitung vornehmen kann.

Das Ich-Kriterium, genauer „Den nächsten Arbeitsschritt kann/muss ich machen“ heißt, der Beginn der Bearbeitung hängt nur von meinen Kapazitäten (ehrlich gesagt, manchmal auch von meiner Lust) ab oder, anders gesagt, vom Ticketabfluss zum Status „Erledigt“.

Spalte „Wartet auf“

Aufteilung

Diese Spalte ist eine Besonderheit. Das Kriterium ist „Der nächste Arbeitsschritt muss von einer anderen Persone/Stelle gemacht werden“ .

Anders als bei üblichen Kanban-Boards, ist das keine eigene Spalte, sondern die untere Hälfte der In-Bearbeitung-Spalte. „Wartet auf“ bildet bei mir keine Blockaden ab, sondern die verwaltungstypische Wiedervorlage. Der hierarchische Aufbau und die fein ziselierten Zuständigkeiten und Befugnisse einer Verwaltung führen dazu, dass bei der Vorgangsbearbeitung häufig Zuarbeit von anderen Stellen oder Entscheidungen höherer Hierarchieebenen notwendig werden, bevor die Bearbeitung abgeschlossen werden kann. Während diese Arbeiten erledigt werden, wird die Vorgangsbearbeitung der sachbearbeitenden Stelle meistens unterbrochen und erst wieder aufgenommen, wenn diese Zuarbeiten erledigt sind.

Ticketfluss

Die vertikale Notation bewirkt, dass die Tickets nicht hin-, zurück und dann über die Wartet-auf-Spalte hinweg auf „Erledigt“ springen, sondern Schleifen machen.

Die Tickets auf dem Kanban-Board wandern normalerweise von links nach rechts (Bild 1). Wenn Tickets nicht abgeschlossen werden, fällt das optisch auf, weil sie längere Zeit in der Spalte stehen bleiben. Wenn die Spalte „Wartet auf“ Blockaden zeigt, funktioniert der Ticketflow.

Anders ist es, wenn die Spalte „Wartet auf“ wie oben beschrieben die Wiedervorlage abbildet. Auf dem Board müssten die Tickets bei üblicher Spalten-Anordnung zuerst zurück und dann über eine Spalte hinweg auf „Erledigt“ wandern.

Die vertikale Unterteilung der Spalte „In Bearbeitung“ bildet die in der Verwaltung übliche Vorgangsbearbeitung mit Wiedervorlagen eleganter ab (Bild 3). Der Ticketfluss ist bei dieser Anordnung wieder von links nach rechts.

Arbeitsschritte

Im Bild 3 ist noch ein kleines Gimmick zu erkennen. Bei manchen Tickets notiere ich mir die Arbeitsschritte, indem ich diese auf kleinere PostIts notiere und auf das Hauptticket klebe. Das ist bei umfangreicheren Vorgängen sehr hilfreich.

Spalte „Erledigt“

„Erledigt“ heißt auf meinem Board: „Mein Arbeitsanteil am Vorgang ist erledigt“. Das bedeutet, dass noch weitere Prozess- oder Workflowschritte folgen können – eigenlich ist das sogar die Regel, nur dass der Vorgang, anders als bei der Wiedervorlage, nicht mehr zu mir zurückkommt.

Wenn Vorgänge erledigt sind, könnte man die Tickets eigentlich wegwerfen. Ich habe die Spalte trotzdem. Warum sollte ich mir das Vergnügen nehmen, abgearbeitete Tickets in die Erledigt-Spalte umzuhängen? Es ist einfach ein gutes Gefühl zu sehen, wie sich diese Spalte füllt.