Montag, 18. Februar 2019

Datengetriebene Retrospektiven (II)


Es ist eine der Anekdoten die von nahezu jedem erzählt werden können, der in verschiedenen agil arbeitenden Unternehmen unterwegs gewesen ist. Irgendwann kommt ein Scrum-Team auf die Idee, auf Kanban umsteigen zu wollen. Natürlich geht das, die Teams sind ja selbst organisiert. Und kurz danach geht die Liefergeschwindigkeit drastisch in den Keller. Was ist da passiert und warum passiert das immer und immer wieder?

Der typische Hintergrund einer solchen Verschlechterung ist ein populärer Irrtum: viele Teams (meisten die, die der Meinung sind, dass der Scrum Master der Einzige ist der sich für Methoden interessieren muss) halten Kanban für "Scrum ohne Sprints und ohne Meetings" und setzen es auch so um. Auf der linken Seite wird immer neue Arbeit aufs Board gehängt, wandert nach rechts und wird abgenommen. Natürlich ist das nicht im Sinn der Idee.

Was in diesen Fällen verloren geht sind die Effekte wegen denen Scrum überhaupt erfunden wurde. Ohne Sprints ist es nicht offensichtlich wenn Arbeitspakete zu gross sind, ohne Retrospektiven wird das nicht als Problem adressiert, ohne Plannings findet kein Kleinschneiden der Aufgaben statt. Stauungen und Probleme sind nur dann sichtbar wenn sie auftreten und nicht rückverfolgbar. Es wird einfach irgendwie vor sich hingearbeitet, ohne Gedanken daran ob es vielleicht besser ginge.

Die Ironie dieser Geschichte - wenn Kanban richtig eingesetzt wird gibt es für diese Probleme eine gleich gute Lösung. Sie besteht darin, Metriken zu erheben. Das ist mit einfachen Mitteln möglich, in der Regel reichen zu Beginn sogar die, die das Team ohnehin bereits benutzt: Stift und Papier. Wenn für jeden Tag zwischen Anfang und Ende der Umsetzung ein Punkt auf den Zettel gemacht wird hat man am Ende die wichtigste Zahl parat, die Durchlaufzeit oder Lead Time.

Bei Systemen in denen Arbeit durch mehrere Phasen geht kann auch das einfach dargestellt werden. Während der ersten Phase werden blaue Punkte gemacht, in der zweiten grüne, in der dritten schwarze etc. Und noch weitere Informationen lässt sich durch farbliche Markierungen darstellen: wenn ein Arbeitsvorgang blockiert ist und nicht weitergehen kann, kann der Punkt Rot oder Rot umrandet sein, wenn er in einem Rückstau feststeckt Orange.

Aus diesen Punktzahlen lässt sich auf unkomplizierte Weise Redebedarf ableiten. Sobald eine abgeschlossene Arbeit vom Board abgehängt wird werden die Punkte gezählt. Und ab einer vereinbarten Schwelle (z.B. ab 5 roten Punkten, 8 Punkten in Rot und Orange oder in Summe mehr als 14 Punkten aller Farben) sollte eine Retrospektive stattfinden in der besprochen werden kann was die Ursache für den Rückstau, die Blockade oder die lange Dauer war (für ein alternatives Vorgehen siehe hier).

Erfahrungsgemäss haben viele der von Scrum auf Kanban umgestiegenen Teams Probleme mit diesem Vorgehen, da es dazu führen kann, dass ähnlich viele oder sogar mehr Retrospektiven (und Planungsmeetings für die Umsetzung der dort vereinbarten Massnahmen) nötig sind als in Scrum. Das ist dann ein wunderbarer Anlass für ein Gespräch darüber, dass zu einem selbstorganisierten Team auch dann ein selbstorganisierter Verbesserungsprozess gehört wenn es nach Kanban arbeitet.

Related Articles