The Blog

An Kanban angelehnter workflow mit Jira

Folgendes Diagramm zeigt unseren Kanban ähnlichen Workflow in JIRA.

Ein Issue geht durch folgende Abteilungen/Phasen:

  1. Planung, Analyse
  2. Entwicklung
  3. Test
  4. Dokumentation und Auslieferung

Jede Phase ist geteilt in „Bereit für Bearbeitung“ und „In Arbeit“. Praktisch sollte maximal ein Element „In Arbeit“ sein, also einen WIP (Work Items in Progress) von 1 haben.

Wir haben JIRA wenig restriktiv konfiguriert, alle Arbeitsphasen lassen sich direkt erreichen.

Unterschiede zu KANBAN

Kanban betrachtet Puffer als Verschwendung (waste) und probiert diese zu vermeiden. Werden für eine Phase die maximalen WIP (work items in progress) Werte überschritten, hält das System an. In unserem Worfklow ist jedoch jede Phase „Bereit für Arbeitssschritt“ als Puffer gedacht. Wir arbeiten also gezielt mit Puffern und  nutzen diese auch, um Engpässe zu erkennen und einzugreifen.

Kanban setzt auf eine reines Pull Prinzp. Ist ein Arbeitselement in der Phase „Entwicklung“ abgeschlossen, dann bleibt es in dieser Phase bis die nächste Phase das Arbeitselement aufnimmt (pulled). Stattdessen verwenden wir ein Push – Pull Prinzip. Ein Arbeitselement wird immer von einem Puffer geholt (Pull) und nach Fertigstellung auf einen anderen passenden Puffer gelegt (Push).

Parallelen zu KANBAN

Der Arbeitsfluss ist auch in unserem Vorgehen sehr gut einsehbar und transparent, Engpässe sind leicht zu identifizieren. Der Durchsatz einzelner Arbeitsphasen/Abteilungen für eine Kategorie von Tätigkeiten könnte gemessen  und optimiert werden. Auch wir sehen Puffer als Verschwendung und wollen diese möglichst klein halten.

Praktische Umsetzung

Die Einführung des Worfklows erfolgte mit Jira. Konkurrent nach einer Vorauswahl war zuletzt TargetProcess. In einem anderen Kontext konnte ich sehr positive Erfahrungen mit TargetProcess sammeln. Ausschlaggebend für JIRA war u.a. dessen umfangreiche Anpassbarkeit an unterschiedlichste Bedürfnisse – so erfassen wir für Arbeitselemente Beispielsweise auch Daten für die Rechnungslegung, eine Erweiterungen die in TargetProcess so nicht  möglich ist. Insgesamt ist der Eindruck soweit recht positiv, auch wenn die Nutzung des administrativen Bereichs intuitiver sein sollte. Die Einführung mit Datenmigration und Benutzerunterstützung und diversen Anpassungen dauerte insgesamt 50h.


Kick It auf dotnet-kicks.de

4 Awesome Comments So Far

Don't be a stranger, join the discussion by leaving your own comment
  1. Arne Roock
    Juli 14, 2011 at 7:35 #

    Hallo Robert,

    dass Items in Puffer gepullt werden, ist immer so. Wer sollte sie auch darein pullen? Insofern sehe ich hier keinen Unterschied zu Kanban. Spannend finde ich tatsächlich zum einen die Frage, ob es nicht sinnvoll ist, die Puffer zu limitieren. Ansonsten bedeutet das, dass die Gesamt-WIP-Menge im System sehr ungleich ist und man dadurch schlechte Vorhersagbarkeit bekommt und der Veränderungsdruck, den man auf sich selbst ausübt, auch nicht besonders groß ist.
    Zum Anderen hätte ich bedenken, ob die Visualisierung in Jira gut genug ist. Meine Erfahrung ist: Es gibt in Jira (ohne Greenhopper) keine vernünftige Visualisierung. Wenn man seine Arbeit und seinen Workflow nicht sieht, ist es ziemlich schwierig, gute Entscheidungen zu treffen, um sich zu verbessern. Wäre es nicht einen Versuch wert, zusätzlich zu Jira eine Card Wall zu pflegen?

    Viele Grüße,
    Arne

    • Robert
      Juli 14, 2011 at 11:19 #

      @Arne, ah ich verstehe, wir machen also praktisch auch Kanban. Das bei uns Puffer nicht zum vorgelagerten Prozess, sondern zum bearbeitenden Prozess gehören, ist nur ein anderes Modell der gleichen Sache.

      Zu WIP haben wir eine allgemeine Absprache, dass das WIP pro Person in den Phasen „In Arbeit “ 1 sein sollte. Nach Eurem großartigen Vortrag/Workshop am Dienstag, sackt bei mir auch langsam die Erkenntnis durch, dass WIP-Limits für alle Puffer eine gute Idee sind. In Krankheits- und Urlaubszenarien sollte es sich jedoch mal stauen dürfen.

      Zu JIRA, die Gesamtübersicht finde ich sehr gut. Die 2 Dimensionalen Statistiken bieten einen sehr guten Überblick aufs Ganze. Diese Statistiken müssen jedoch erst mal konfiguriert werden. Für einzelne Prozesse haben wir Dashboards, daher gibt es ein Dashboard für „Bereit für Entwicklung“, „Bereit für Test“, usw. Würden WIP-Limit eintreten und der vorgelagerte Prozessschritt sollte anhalten, dann müsste die betroffen Personen das aktiv mitteilen oder jemand der das Ganze im Blick hat, müsste eingreifen.

      Vor uns liegt noch einiges an KAIZEN 🙂 Was wir jetzt eingeführt haben, hat eine alte Access Lösung abgelöst, aus der wir keine historischen Daten verlieren wollten. Das gute bei JIRA ist, dass es recht kompatibel zu unserem alten Vorgehen ist, aber so flexibel, dass neue Abläufe gut abbildbar waren.

      Zu Greenhooper, wir haben die Einführung erst mal zurückgestellt, da wir erst mal den Sprung zu JIRA abschließen wollten und Greenhopper in der aktuellen Situation keinen Nutzen versprach.

      Zur Card-Wall, das funktioniert nur Co-Located und wir wollen externe Partner, Kunden und Kollegen (von denen ich auch einer bin) einbeziehen.

      Danke nochmal für die vielen Impulse!

  2. Fabian
    Juli 14, 2011 at 7:58 #

    Was mich interessiert.
    Der gezeigt Workflow funktioniert sehr gut für Storys/Tasks.

    Wie behandelt ihr im selben Jira Projekt die üblichen Tickets (Bugs). Hier hat sich ja der übliche Workflow: Open, InProgress, Resolved, Closed, Reopened, etc. bewährt.

    Lassen sich zwei Workflows implementieren?
    Wie unterscheidet ihr im Jira zwischen Storys und Tickets?

    • Robert
      Juli 14, 2011 at 11:31 #

      Hallo Fabian,

      wir haben für alle Issuetypen (Fehler, Neue Funktionen, Aufgaben) nur einen Workflow und einen einheitlichen Ablauf, mir scheint das sehr gut zu funktionieren. Fehlerbehebung, Neue Funktionen, Aufgaben haben bei uns auch tatsächlich die gleichen Arbeitsschritte. (Bei Fehlern wird vermutlich oft die Planung überschritten, aber auch nicht immer.)

      In Jira lassen sich Workflows für alle Issuetypen konfigurieren. Ich würde das aber nicht machen, da das ganze System dadurch komplexer wird und nicht mehr so leicht zu beobachten und zu verstehen ist.