Kanban in der IT (Part 1 – Systemhaus)

Seit zwei Monaten kann ich erste praktische Erfahrungen im Einsatz von KANBAN Prinzipien in der IT sammeln. Sowohl in der Softwareentwicklung als auch im klassischen Systemhausbereich der Firma ABIAN GmbH in Hannover habe ich ein KANBAN Board eingeführt.
Begonnen haben wir im Systemhausbereich.
Die Firma ABIAN ist als Systemhaus vornehmlich im Servicegeschäft aktiv. Dies bedeutet:

• regelmäßige Vor-Ort Termine beim Kunden
• Projektgeschäft im Wesentlichen für Servicepasskunden
• Hotline und Telefonsupport für Servicepasskunden
• RZ Betrieb und Hosting für die Projekte aus dem Bereich Softwareentwicklung

KANBAN habe ich hier nicht in der reinen Form eingeführt, weil das Technikerteam zu heterogen aufgestellt ist. Zwei Techniker sind 70% der Zeit außer Haus unterwegs, ein Kollege betreut die Hotline und zwei weitere Kollegen sind als Systemadministratoren für die RZ-Infrastruktur der ABIAN und eines weitere Kunden zuständig. Darüber hinaus ist das Team in eine „LINUX“ und eine „Windows“ Gruppe unterteilt, sodass nicht alle Kollegen alle anfallenden Tasks übernehmen können. Das hatte zur Folge, dass das KANBAN Board pro Mitarbeiter eine Queue abbildet. Weiterhin bildet das KANBAN Board immer nur die Aufgabenplanung für die laufende Arbeitswoche ab. Längerfristig zu planende Tasks werden in der Tasksammlung (vergleichbar mit einem „physischen“ Product Backlog) erfasst.

Als Prozessschritte am KANBAN Board gibt es:

• Next: Hier stellen die Kundenbetreuer (Vertrieb) die nächsten anstehen Tasks für die Woche ein
• Eingeplant: Hier plant der Techniker in Absprache mit dem Kundenbetreuer seine kommenden Tasks des Tages (max. 3)
• Umsetzung: Hier stehen die aktuell in Arbeit befindlichen Tasks des Technikers (max. 2)
• Qualitätssicherung: Hier stehen die Tasks die live gehen sollen und geprüft werden müssen (max. 2)
• Done: Hier stehen die erledigten Tasks, die dann von der Orga übernommen und abgerechnet werden können

Nicht am KANBAN Board, aber zum KANBAN Prozess gehörend gibt es noch:

• Blocker: Längerfristig geblockte Tasks (Warten auf Zulieferer etc.) werden vom Board genommen und in eine Blockersammlung aufgenommen. Damit ist der Slot wieder frei für andere Tasks.

Sowohl Kundenbetreuer (Vertrieb) als auch Techniker können neue Tasks erfassen. Diese werden in einer Eingangsbox gesammelt. Die Kundenbetreuer (Vertrieb) dürfen am Board nur Tasks im Prozessschritt „Next“ oder „Eingeplant“ austauschen.

Es gibt zwei Meetings:

• tägliches Standup (morgens zu Arbeitsbeginn), 15 Minuten
• Wochenplanung (Freitags), 1,5 Stunden

Im täglichen Standup am morgen besteht Teilnahmepflicht für alle anwesenden Techniker. Techniker die einen außer Haus Termin haben, sind verpflichtet, ihre KANBAN Queue mindestens alle zwei Tage zu aktualisieren bzw. den Kollegen telefonisch Änderungen zu kommunizieren, damit diese das Board stellvertretend aktualisieren können. Der Ablauf des Standup ist wie folgt geregelt:

• Was ist „Done“?
  Kurze Prüfung der Tasks, ggf. mit Kurzinfo vom Techniker, Übergabe an Orga zur Abrechnung
• Was ist in „QS“?
  Klärung der QS Aufgabenstellung und Zuweisung zu einem Kollegen
• Was ist in „Umsetzung“?
  Woran arbeitet der Kollege aktuell? Gibt es Probleme?
• Was ist „Eingeplant“?
  Welche Tasks wird der Kollege als nächstes beginnen? Gibt es ggf. Terminverschiebungen, Prioritätsänderungen?
• Was ist „Neu“?
  Durchsicht aller neuen Tasks vom gestrigen Tag im Eingangskorb mit kurzer Erläuterung durch den Ersteller (Ist der Task verständlich? Gibt es eine Deadline?). Anschließend Übernahme in die Tasksammlung oder in den Prozessschritt „Next“
• Wie ist der Status der „Blocker“?
  Gibt es neue Informationen zu den längerfristig geblockten Tasks? Können sie ggf. wieder eingeplant werden?

In der Wochenplanung am Freitag besteht Anwesenheitspflicht für ALLE Techniker. Hier wird ausführlicher über einzelne Taks oder laufende Projekte und zugehörige Tasks gesprochen. Zusätzlich wird abgestimmt, welche Tasks voraussichtlich in der kommenden Woche durchgeführt werden müssen. Damit wird die „Next“ Spalte am KANBAN Board initial befüllt. Diese Befüllung ändert sich jedoch erfahrungsgemäß im Verlauf der Arbeitswoche. Aber das ist ja auch der Sinn bei KANBAN 😉

Um zu regeln, welche Tasks aus der Tasksammlung in die „Next“ Spalte bzw. von der Next Spalte in die eingeplant Spalte wandern sollten, habe ich Prioritäten festgelegt, die sich an den Empfehlungen von Henrik Kniberg und Mattias Skarin (http://www.infoq.com/minibooks/kanban-scrum-minibook) orientieren. Mit abnehmender Priorität existieren folgende Stufen:

• Fehler: Ein produktionskritischer Fehler führt dazu, dass alle Techniker ihre laufenden Tätigkeiten kurzfristig unterbrechen und gemeinsam den Fehler udn das Vorgehen besprechen. Es wird entschieden, wer den Fehler bearbeitet und wie man vorgehen könnte. Anschließend kehren alle freien Techniker wieder zu ihren Tasks zurück.
• Priorität: Ein Tasks mit Priorität muss als nächstes bearbeitet werden. Er hat Vorrang vor allen anderen eingeplanten Tasks.
• Deadline: Tasks mit naher Deadline haben Vorrang vor Tasks mit Deadlines in der Zukunft
• Eingangsdatum: Alte Tasks haben Vorrang vor neuen Tasks

Über die Erfahrungen mit diesem KANBAN Modell werde ich in einem der nächsten Blogeinträge berichten.

Werbung