Ein paar Gedanken zum Zeitbegriff in agilen Verfahren.

In allen agilen Methoden versucht das Entwicklungsteam, dem Kunden ein gewünschtes Feature möglichst schnell zur Verfügung zu stellen. Das ist ein wichtiger Bestandteil des Entwicklungsprozesses: zeitnahe Lieferung löst zeitnahes Feedback aus und hilft, das Projekt auf der Spur zu halten.

Die agilen Methoden können dabei von den jahrzehntelangen Erfahrungen aus der Lean Production profitieren. Kanban tut das explizit, XP und Scrum tun das implizit. Die Frage ist nur : Was heißt eigentlich „schnell“ oder „zeitnah“? Über welche Zeit reden wir da eigentlich?

Lead time

Die für den Kunden interessante Zeit ist eigentlich diese: „Wenn ich heute ein Feature in die Entwicklung gebe, wann kann ich es in der lauffähigen Software erkennen und testen?“. Diese Zeit nennt man in der Lean-Welt lead time. Ihre Einheit ist tatsächliche, abgelaufene Zeit (elapsed time). Sie enthält sowohl die Zeit für den Fertigungs-Workflow (also Analyse, Design, Unit-Test, Implementierung, Integration, etc.) als auch eventuelle Wartezeiten vor der Fertigung, weil das Team gerade noch andere Features zu entwickeln hatte.

Cycle time

Eine andere Zeit, die weniger für den Kunden und mehr für die Entwickler und deren Manager interessant ist, nennt man in der Lean-Welt cycle time. Ihre Einheit ist nicht tatsächlich abgelaufene Zeit (elapsed time), sondern der Rhythmus (engl. cadence), wie oft der Entwicklungsprozess ein Feature fertigstellt. Um den Unterschied zu verstehen, ein Beispiel: Ein GUI-Designer wird beauftragt, eine größere Anzahl bereits fertig entwickelter HTML-Seiten (z.B. 100 Stück) graphisch schön aufzubereiten. Sagen wir, er liefert jede Woche (5 Arbeitstage) 20 Stück, dann beträgt die cycle time pro HTML-Seite 2 Stunden (5 Tage mal 8 Stunden = 40 Stunden, dividiert durch 20 Stück, also 2 Stunden pro Stück).

Littles Gesetz und Work in Process

Wie stehen nun diese beiden Zeiten in Beziehung? Das fand John D.C. Little schon 1961 heraus. Damals formulierte er es so: In einem stabilen Wartesystem (Beispiel: Supermarkt) ist die durchschnittliche Anzahl von Kunden gleich dem Produkt aus Ankunftsrate und der durchschnittlichen Verweildauer im System.

Was heißt das, übertragen auf lead time und cycle time? Nun, die Ankunftsrate ist der Kehrwert der cycle time, die Verweildauer ist gleich der lead time und die durchschnittliche Kundenanzahl entspricht der Anzahl der Features, an denen das Team im Durchschnitt gleichzeitig arbeitet. In der Lean-Welt nennt man das work in process.

Also können wir Littles Gesetz so umstellen: lead time = work in process * cycle time.

Wenn der oben erwähnte GUI-Designer zu viele Aufträge hat, weil er für zu viele Kunden gleichzeitig arbeitet, ist seine work in process sehr hoch, z.B. befinden sich 100 HTML-Seiten bei ihm in Arbeit. Wenn ein Kunde nun eine neue Seite zum „Schönmachen“ beauftragt, bekommt er sie erst nach einer lead time von durchschnittlich 5 Wochen zurück (100 Seiten x 2 Stunden/Seite, geteilt durch 40 Stunden pro Woche). Der Kunde wird unzufrieden sein, und der GUI-Designer sollte sich überlegen, ob er nicht mehr Aufträge ablehnen oder seinen Kollegen weitergeben sollte.

Handlungempfehlung

Was lernen wir daraus, wenn wir zu einem Software-Entwicklungsteam gehören oder ein solches managen? Um den Kunden zufrieden zu machen, sollte das Team die lead time optimieren. Das Einfachste ist, die work in process zu reduzieren, also einfach nicht an so vielen Sachen gleichzeitig zu arbeiten. Das Schwierigere ist, die cycle time zu reduzieren, also effizienter zu arbeiten. Dazu braucht es Methode. Wenn Sie Lust haben, zeige ich Ihnen , wie auch das geht. Rufen Sie mich an.