Sonntag, 1. April 2012

„Wir verarbeiten aber keinen Müll.“ Oder: Müssen Tickets in Kanban immer die gleiche Größe haben?

Auf dem Treffen aller deutschsprachigen Limited WIP Societies vergangenen Freitag gab es eine spannende OpenSpace-Session zur Ticketgröße in Kanban. Dabei spielte sich folgender kleiner Dialog ab:

A: „Sollten die Aufgaben eigentlich immer die gleiche Größe haben?“
B: „Wenn wir uns mal eine Müllverarbeitsanlage ansehen: Das Erste, was sie tun, ist alles in gleich große Einheiten zu zerteilen, damit sie es besser verarbeiten können.“
A: „Wir verarbeiten aber keinen Müll.“

Die Frage nach gleich großen Tickets wird mir auch regelmäßig nach Vorträgen und in Schulungen gestellt. Und weil ich jetzt eine schöne Überschrift gefunden habe, dachte ich mir, ich poste meine Gedanken dazu einmal.

Vorteile gleich großer Aufgaben
In der Fertigung (z.B. Automobilproduktion) werden Aufgaben schon seit Langem so geschnitten, dass sie gleich groß sind bzw. ihre Bearbeitung immer gleich lange dauert. So lässt sich nicht nur eine maximal hohe Auslastung von Mitarbeitern und Maschinen erreichen, sondern es ergibt sich auch ein anderer, sehr großer Vorteil: Vorhersagbarkeit. Wenn jede Aufgabe gleich lange dauert, dann kann ich auch einen immer gleich langen Takt erreichen, mit dem fertige Produkte (z.B. Autos) vom Band rollen (Tact Time). Das macht es sehr einfach, die Produktion zu steuern und meinen Kunden und Partnern sehr zuverlässige Aussagen darüber zu geben, wann sie wie viele Produkte von mir bekommen können.




Also ist die Sache doch klar, oder?
So weit so gut. Also übertragen wir dieses Vorgehen einfach auf unsere Domäne (Wissensarbeit), und wir können endlich auch mal vernünftige Vorhersagen machen und alle unsere Pläne einhalten! Tatsächlich übernimmt Kanban ja einige Ideen vom Toyota Production System, so dass es nicht verwundert, dass im Zusammenhang mit Kanban immer wieder die Forderung nach gleich großen Aufgaben kommt. Leider gibt es da ein paar Probleme...

Wissensarbeit ist keine Fertigung
Nun wird nämlich der Unterschied zwischen Fertigung und Wissensarbeit extrem wichtig: Während in der Fertigung immer wieder dieselben Aufgaben erledigt (=produziert) werden, ist das in der Regel in der Wissensarbeit nicht der Fall. Entwicklungsteams entwickeln zwar ein Fetaure nach dem anderen; und Wartungsteams fixen einen Bug nach dem anderen. Aber kein Feature ist wie das andere. Und kein Bug ist genau wie der andere. In allen diesen Aufgaben steckt ein (meist recht hohes) Maß an Ungewissheit. Und um diese Aufgaben zu erledigen, ist meistens auch ein hohes Maß an Kreativität erforderlich. Das muss auch so sein. Stellen wir uns einmal vor, es gäbe keinen grundlegenden Unterschied zwischen Fertigung und Softwareentwicklung: Dann würden wir immer wieder haargenau dieselben Systeme entwickeln. Dann bräuchte man keine gut ausgebildeten und hochbezahlten IT-Spezialisten mehr, weil man den Großteil dieser Systeme einfach per Copy&Paste erstellen könnte. Also sollten wir dankbar sein!

Ungewissheit
Na gut, genau gleich groß können wir unsere Features also nicht schneiden. Aber wir könnten die Größen doch wenigstens so weit wie möglich aneinander angleich, um eine bessere Vorhersagbarkeit zu erhalten, oder?
Meine Erfahrung zeigt, dass es tatsächlich oft sinnvoll, und auch ohne größere Probleme möglich ist, Anforderungen in kleinere Häppchen aufzuteilen, als es im Moment der Fall ist. Entscheidend ist dabei nur, dass ich hinterher immer noch fachlich geschnittene Aufgaben haben, die jede für sich einen Mehrwert bringt (der auch darin bestehen kann, mir wertvolles Feedback zu liefern). Wenn wir unsere Anforderungen kleiner schneiden, werden sich die Größen evtl. annähern, aber eine Garantie gibt es noch nicht. Will ich mir sicherer sein, müsste ich vorher ziemlich viel Aufwand in Schätzungen und Analysen stecken. Es mag Situationen geben, in denen diese Aufwände gerechtfertigt sind, meistens sind sie es jedoch nicht. Und selbst, wenn ich diesen Aufwand investieren möchte: Es bleiben Schätzungen, und wir wissen immer erst hinterher, wie gut sie waren.
Oft ist der Mittelweg erfolgversprechend: Anforderungen werden sehr groß klassifiziert, z.B. mit T-Shirt-Größen wie S, M, L und XL. Solche „Schätzungen" kann das Team in der Regel innerhalb weniger Minuten abgeben - und für viele Zwecke sind sie gut genug.

Ticketgrößen und Durchlaufzeiten
Wenn man genauer darüber nachdenkt, interessieren uns die Größen der Aufgaben gar nicht so sehr. Viel wichtiger sind die Durchlaufzeiten (Lead Times), also die Zeit, die wir benötigen, um eine Aufgabe zu erledigen. In unserem Kopf erstellen wir automatisch einen linearen (oder sogar exponentiellen) Zusammenhang zwischen beiden Größen: Wenn Aufgabe A doppelt so groß ist wie Aufgabe B, dann wird die Durchlaufzeit auch (mindestens) doppelt so lang sein. Wenn ich also irgendeine Art der Planung machen möchte, muss ich doch die unterschiedlichen Ticketgrößen berücksichtigen und ins Verhältnis setzen, oder? Erstaunlicherweise lautet die Antwort fast immer: Nein!
Dieses scheinbare Paradox erklärt sich dadurch, dass die Ticketgrößen zwar Einfluss auf die reine Bearbeitungszeit (Touch Time) haben, aber nicht (oder nur sehr wenig) Einfluss auf die Wartezeiten. In fast allen Organisationen, die Kanban einführen, wird der Löwenanteil der Durchlaufzeiten durch die Wartezeiten aufgefressen – zumindest wenn man über die reine Entwicklung hinausgeht und auch Prozesse wie das Deployment mit betrachtet. Die Bearbeitungszeit spielt nur eine untergeordnete Rolle. Wer ein elektronisches Kanban-Tool verwendet, kann sich dies in so genannten Flow Efficiency Diagrams ansehen. Oft beträgt der Anteil der Wartezeiten 80% oder mehr!


So lange wir also große Warteschlangen in unserem Prozess haben, brauchen wir uns um unterschiedliche Ticketgrößen keine großen Gedanken machen, sondern sollten stattdessen darüber nachdenken, wie wir diese Warteschlangen verkleinern können. Wer sicher gehen möchte, kann eine grobe Klassifizierung der Tickets nach T-Shirt-Größen vornehmen und hinterher kontrollieren, wie lang die einzelnen Durchlaufzeiten waren. Oft gibt es keinen beobachtbaren Effekt. Ein Teilnehmer der genannten OpenSpace-Session hat sogar berichtet, dass in seinem Team die S-Tickets längere Durchlaufzeiten haben als die M-Tickets!

Kommentare:

  1. Sehr schöner Artikel, der kurz und knapp den Sinn und Unsinns einer zu genauen Schätzung beleuchtet. Manche schreiben ganze Bücher über die Problematik, aber du bringst es hier in einem kurzen Artikel auf den Punkt. Ich sehe es auch so, dass Schätzungen bei Wartezeit von Tickets keinen Mehrwert bieten. Sind diese aber nicht zur Priorisierung des Backlogs wichtig? Wenn ich als Product Owner einen gleichen Mehrwert für Benutzer mit einem S-Ticket oder einem XL-Ticket erhalte, würde ich immer das S-Ticket wählen.

    AntwortenLöschen
  2. Hi Sven,

    aber wenn die Lead Time durch Wartezeit dominiert wird, dann bekommt der Benutzer das S-Ticket doch auch nur unwesentlich früher als das XL-Ticket, oder? In diesem Fall würde ich für die Priorisierung nur den (vermuteten) Wert ansetzen und den Aufwand als immer gleich ansetzen (und gleichzeitig daran arbeiten, die Warteschlangen zu verkleinern). Oder aber ich müsste Features so auswählen/Schneiden, dass sie nicht durch die langen Warteschlangen durch müssen.

    AntwortenLöschen