Kanban

Kanban bietet ein agileres Projektmanagement unabhängig vom eingesetzten Prozessmodell, siehe auch Kanban - David J. Anderson, dpunkt.verlag GmbH 2012.

Ein Erfolgsrezept

  1. Fokusiere auf Qualität
  2. Reduziere den Work in Progress (WIP)
  3. Liefere häufig
  4. Sorge für ein Gleichgewicht zwischen Nachfrage und Durchsatz
  5. Priorisiere
  6. Nimm die Quellen von Variabilität ins Visier, um die Vorhersagbarkeit zu verbessern

Ziele des Kanban-Systems

  1. Den bestehenden Prozess optimieren
  2. Hohe Qualität liefern
  3. Die Vorhersagbarkeit der Durchlaufzeit verbessern
  4. Die Zufriedenheit der Mitarbeiter erhöhen
  5. Freiräume schaffen, um Verbesserungen zu ermöglichen
  6. Die Priorisierung vereinfachen
  7. Transparenz über die Gestaltung und den Einsatz des Systems herstellen
  8. Den Prozess so gestalten, dass er die Entstehung einer hochgradig reifen Organisation ermöglicht

Tracking

Zu jedem Ticket werden die folgenden Informationen dokumentiert:

  • ID des elektronischen Trackings
  • Name des Tickets und evtl. kurze Beschreibung (z. B. als User Story)
  • Startdatum, wann das Ticket vom Backlog ins System gekommen ist
  • Enddatum, wann das Ticket ausgeliefert wurde
  • Optional: ein fester Liefertermin
  • Optional: Wenn es sich um ein Problem handelt, Referenz auf das dadurch blockierte Ticket
  • Optional: Flag, ob das SLA überschritten ist

Aus der Differenz von Enddatum und Startdatum ergibt sich die Durchlaufzeit im System.

Die folgenden Service Level Agreements (SLA) sind denkbar:

  • Standard: verspricht eine Durchlaufzeit von 30 Tagen mit 80 % Sicherheit
  • Beschleunigt: hat WIP von 1
  • Fester Liefertermin
  • Unbestimmte Kosten: verspricht eine Durchlaufzeit von 60 Tagen mit 50 % Sicherheit

Das Kanban Board zeigt die Prozessschritte nebeneinander mit WIP-Limit pro Prozesschritt. Für die Softwareentwicklung beginnt der Prozess mit der Input Queue in der Tickets aus dem Backlog in das System gelangen und endet mit Produktion für ausgelieferte Tickets. Dazwischen können z. B. Analyse, Entwicklung, Test und Stage stehen. Zwischen den Prozessschritten können Puffer eingebaut werden mit oder ohne WIP-Limit, um schwankenden Fluss der Tickets zwischen Prozesschritten auszugleichen.

Auswertungen

Cumulative Flow Diagram

Dieses Diagramm stellt die Tickets die noch offen sind, die aktuell bearbeitetet werden (WIP = Work in Progress) und die ausgelieferten gegenüber. Bildet der WIP einen gleichbreiten Streifen ist ein guter Aufgabenfluss erreicht. Entspricht die Breite des WIP-Streifen dem WIP-Limit, dann ist der Fluss im System otimpal.

Kanban: Cumulative Flow Diagram

Spektralanalyse der Durchlaufzeit

Stellt die Anzahl der erledigten Tickets und ihre Durchaufzeit gegenüber. In diesem Diagramm lassen sich u. a. Aussagen zur durchschnittlichen Durchlaufzeit machen.

Kanban: Spektralanalyse der Durchlaufzeit

Termintreue

Mit der folgenden Tabelle kann die Durchlaufzeit und Termintreue dokumentiert werden.

 ø Durchlaufzeit in TagenTermintreue in %
IntervallZielletzter Monatletztes Jahrletzter Monatletztes Jahr
Change Requests & Bugs 30 32,5 31,1 52 50
nur Change Requests 30 32,6 40,4 50 30
nur Bugs 30 32,5 19,6 55 75

Durchsatz

Im diesem Diagramm werden die Anzahl gelieferter Tickets pro Monat dargestellt. Die Auslieferungen pro Monat sind unterteilt in pünktlich und SLA verpasst. Darüber wird der Durchschnitt der letzten drei Monate gelegt.

[TODO: Bild einfügen]

Probleme und blockierte Aufgaben

Analog zum Cumulative Flow Diagram werden hier die geblockten Tickets, vorgeschlagenen Probleme, aktive Probleme, gelöste Probleme und geschlossenen Probleme visualisiert.

[TODO: Bild einfügen]

Flusseffizienz

Dieses Diagramm zeigt pro Monat das Verhältnis der Durchlaufzeit zur zugewiesenen Zeit (touch time) für Change Requests, Bugs und der Kombination aus beiden.

[TODO: Bild einfügen]

Initiale Qualität

Dieses Diagramm zeigt die Anzahl der Bugs, die erst nach dem Release erkannt werden über die Zeit. Die Anzahl der Bus wird als Bugs pro Feature visualisiert.

[TODO: Bild einfügen]

Bruchlast

Die Bruchlast (failure load) ist die Anzahl der Tickets, die erneut bearbeitet werden müssen, weil die gelieferte Qualität zu schlecht war.

Verschwendung reduzieren

Mit Verschwendung sind Dinge gemeint, die keinen sichtbaren Mehrwert für den Kunden bieten. Doch nicht alles was "Verschwendung" ist, ist unnütz. Verschwendung lässt sich unterteilen in

  • Transaktionskosten: z. B. für Beschaffung von Entwicklungswerzeugen, Fahrtkosten, Kosten für die Auslieferung (Zeit + Werkzeuge)
  • Koordinierungskosten: vor allen Meetings
  • Bruchlast: Bugs und jedes Change Request, welches durch eine bessere intialie Qualität hätte vermieden werden können, z. B. durch Tests oder bessere Klärung der Anforderungen mit dem Kunden

Variabilität reduzieren

Variablität wirkt sich negativ auf die Vorhersagbarkeit der Durchlaufzeiten aus und erschwert damit die Planung. Variabilität kann zwei verschiedene Quellen haben:

  • Intern: wenn die Aufgaben in Größe, Typ und Serviceklassen variieren, der Fluss ungleichmäßig ist oder zu viele Nacharbeiten nötig sind
  • Extern: wenn Aufgaben unklar formuliert sind oder es zu viele beschleunigte Aufgaben gibt, aber auch Abhängigkeiten zu Umgebungen (z. B. für Tests), Markfaktoren oder anderen Teams zählen dazu

Die internen Quellen von Variabilität kann das Team direkt beeinflussen, im Gegensatz zu den externen Quellen. Während sich die Variabiliät bei interen Quellen also reduzieren lässt, kann man bei externen Quellen nur reagieren. Man muss aber auch darauf vorbereitet sein, Stichwort Risikomanagement.

Zurück