Kanban: Definition of Lead Time and Cycle Time

Important: Cycle time as a concept can have multiple meanings. This blog post uses just one specific meaning. Alexei Zheglov has a more accurate discussion of the cycle time concept.

When doing Kanban for software development measuring cycle and lead times is important but often the terms are confused or defined in a fuzzy way. Here is a useful definition from the “Lean and Kanban” blog:

Lead time clock starts when the request is made and ends at delivery. Cycle time clock starts when work begins on the request and ends when the item is ready for delivery. Cycle time is a more mechanical measure of process capability. Lead time is what the customer sees.

Let’s have a closer look and let’s assume we are working with Kanban in a maintenance team. Bugs are reported via tickets in a ticket system like Bugzilla, Jira or Mantis. When the bug is detected a ticket is created and when the bugfix is live, the ticket is closed. This whole period of time is the lead time. The lead time is the time and not the effort. You may have a lead time of 100 days and only have to work 1 hour to fix the bug. Sometime you start working on the bug. The cycle time is the time from the start of the work until the bugfix is live. Again the cycle time is not the effort. Lead time can’t be shorter than cycle time. Often lead time is a lot longer. In the context of maintenance there is often a SLA (Service Level Agreement) in place that defines in which time frame you have to fix a bug. Often the SLA defines a resolution time. That is the same as the lead time: Most SLAs also define a response time. That is the time available until the team has to respond to a new bug ticket: is it really a bug and what is the priority. With these definitions in place it is obvious that the lead time is what is relevant from the business perspective. The cycle time is what the team can influence by itself by changing its work process. To reduce lead times one can (and should) reduce cycle time. But often the time before the work starts is really long so this wait time should be reduced also.

Kanban: Wer will schon ein Bottleneck sein?

In einem Kanban-Projekt habe ich ein interessantes zwischenmenschliches Problem. In Kanban versuchen wir, sinnvoll mit den Bottlenecks umzugehen, um die Durchlaufzeiten zu reduzieren.

Im Rahmen der Theory of Constraints gibt es sogar ein standardisiertes Verfahren zum Umgang mit Bottlenecks:

  1. Identify. Identify the bottleneck of the system.
  2. Exploit. Exploit this bottleneck, making its throughput efficient by changing processes, equipment maintenance procedures, training, policies, etc.
  3. Subordinate: Subordinate the throughput of all other work centers to this work center.
  4. Elevate. Invest in this work center to increase its throughput – add equipment, manpower, etc.
  5. Inertia. Start the process over on the line to determine the new bottleneck.

Das ganze kommt aus einer allgemeinen Systemtheorie und ist natürlich in der Produktion sehr wichtig und auch nützlich. Kanban für die Softwareentwicklung möchte die Theory of Constraints für die Softwareentwicklung auch anwenden. Und da lauert eine Fußangel, die ich auch nicht vorhergesehen habe.

Bei Kanban für die Softwareentwicklung bilden meistens Menschen das Bottleneck. Und wenn wir jetzt beginnen, diese als Bottleneck zu bezeichnen, fühlen sie sich häufig angegriffen. “Ich bin doch kein Bottleneck. Ich tue doch mein Möglichstes.” etc. Auch wenn niemand diese Menschen angreifen wollte, sind sie nun zunächst in einer Verteidigungshaltung. Und das ist die denkbar schlechteste Voraussetzung dafür, mit diesen Menschen Veränderungen im Prozess und in den Arbeitsweisen herbeizuführen.

Ich habe dafür bisher keine Patentlösung. Der erste wichtige Schritt ist sicherlich, sich dieses Problems bewusst zu sein.

Kanban ohne Stress?

Ich begleite jetzt schon eine Weile ein Kanban-Team bei einem Kunden und mache dort ganz interessante Erfahrungen.
Eine “Falle” bei Scrum ist das Commitment auf das Sprint-Ziel. Es kann so missverstanden werden, als wäre es eine Garantie des Teams. So passiert es leider immer wieder, dass Teams über einen längeren Zeitraum Überstunden ohne Ende schieben mit den bekannten Ergebnissen: miese Qualität, schlechte Arbeitsmoral, Burnout, etc.
Wenn das Commitment zu solchen Problemen führt, handelt es sich meiner Meinung nach um einen Fehler bei der Scrum-Implementierung. Aber trotzdem tritt dieser Fehler relativ häufig auf.

Kanban hat dieses Problem nicht. Es gibt keine Sprints/Iterationen und auch kein Commitment auf Sprint-Ziele.

Allerdings: Vor kurzem musste ich ein Teammitglied vertreten. Bei dem Kunden gibt es gleich zu Anfang auf dem Kanban-Board eine Spalte, in der die Tickets landen, wenn es einen technischen Lösungsvorschlag der Entwickler gibt. Wenn dieser akzeptiert wird, wird das Ticket in die nächste Spalte verschoben und die Entwicklung kann beginnen.
Ich war nun für die Freigabe der Tickets vorantwortlich und natürlich brauchte ich dafür viel länger als das Teammitglied, das ich vertreten habe. Ich wurde also zum Bottleneck im System. Und da war ich ganz plötzlich doch im Stress. Ich wusste, dass 10 Leute oder mehr ohne Arbeit dastehen, wenn ich nicht möglichst schnell die Tickets freigebe. Und ich würde auch bis spät in die Nacht arbeiten, um meine Teamkollegen mit ausreichend Arbeit zu versorgen.

Ähnlich wie bei den Scrum-Commitments handelt es sich hier um eine fehlerhafte Implementierung von Kanban. Tatsächlich ist die Existenz des Bottlenecks ein organisatorisches Problem. Dass meine Teamkollegen keine Arbeit mehr haben, ist gewollt. Es soll das eigentliche Problem deutlich zeigen und dann sollen wir als Team eine Lösung dafür finden und das Bottleneck beseitigen.

Hier scheint mir kein relevanter Unterschied zwischen Scrum und Kanban zu existieren: Beides kann missverstanden werden und so ein Missverständnis kann in Überlastung einzelner oder aller Teammitglieder enden.