Zurück
|07 May 2017|Klaus Leopold

Praktische Erfahrung mit Blocker Clustering

Flight Levels
0

Blocker Clustering – ein Thema, das mich seit einigen Jahren beschäftigt, darf natürlich auch nicht im neuen Buch Kanban in der Praxis fehlen. Neben einer detaillierten Erklärung, wie Blocker Clustering funktioniert und was man damit erreichen kann, gibt es auch ein Interview mit einem intensiven Anwender: Matt Philip, Director of Learning and Development bei ThoughtWorks in St. Louis, Missouri. Dieses Interview gibt es als quasi Appetizer auch hier im Blog nachzulesen. Viel Spass!


Klaus: In welchem Kontext wendest du Blocker Clustering an?

Matt: Meine Organisation entwickelt maßgeschneiderte Software für unsere Kunden. Daher gibt es bei uns mehr als 30 kleine, crossfunktionale Teams für verschiedene Domänen, von der Gesundheitsfürsorge über den Handel und Produkten für Mobile Apps bis hin zu großen Systemintegrationen.

Klaus: In der Realität von Kanban-Systemen begegnet man den unterschiedlichsten Auffassungen darüber, was eine Blockade ist. Wie habt ihr das für euch definiert?

Matt: Ich rate jedem Team, für sich selbst die passende Definition zu finden, also eine, die in den jeweiligen Kontext passt. Aber ich gebe den Teams auch immer eine Standarddefinition, die ich mir aus dem Buch „Kanban from the inside” von Mike Burrows geliehen habe: „Eine Blockade ist ein anormaler Zustand, der ein bereits committetes Work Item vom Fortschritt abhält.“ Das erfordert üblicherweise eine Antwort auf die Frage: „Wo liegt unser Commitment-Punkt?“ Ich zum Beispiel würde ein Item nicht als blockiert betrachten, wenn es noch im Backlog liegt. Eines der Teams, mit denen ich gearbeitet habe, hat am Anfang die Storys immer blockiert, wenn es zum Mittagessen gegangen ist. Ich habe die Mitglieder dann darauf hingewiesen, dass das Mittagessen kein anormaler Zustand ist.

Klaus: Wenn ihr Blockaden-Cluster bildet, welche Cluster tauchen dabei immer wieder auf?

Matt: Innerhalb der beiden großen Kategorien „interne und externe Blockaden“ sehen wir oft Cluster wie „abhängige Story“, „fehlende Requirements“, „Umgebung nicht verfügbar“ und „Product Owner nicht verfügbar“. Beim ersten Versuch eines Teams hieß der größte Cluster „unbekannt“. Das war für das Team der Ansporn, das nächste Mal beim Aufschreiben der Blockaden etwas genauer zu sein.

Klaus: Welche Maßnahmen habt ihr ergriffen, um an den Ursachen der Blockaden zu arbeiten?

Matt: In einem Fall stellte sich der größte Blockaden-Cluster als internes Problem dar. Mit der Fishbone-Technik sind wir der Ursache des Problems auf den Grund gegangen und haben einige Lösungsmöglichkeiten gefunden. In einem anderen Fall war der externe Cluster auf einen Kunden zurückzuführen. Das Team machte dem Kunden die Kosten dieser Blockaden deutlich und stellte die Frage, ob das für den Kunden akzeptabel sei – das Team gab dem Kunden also eine Information, damit dieser bessere Entscheidungen treffen konnte.

Klaus: Was waren deine Erkenntnisse?

Matt: Zunächst einmal hilft Blocker Clustering einem Team dabei, überhaupt über die Auswirkungen von Blockaden nachzudenken. Viele Menschen sehen Blockaden ja einfach nur als Ärgernis und nicht als eine Quelle für Prozessverbesserungen. Zweitens streicht das Clustering heraus, dass Blockaden etwas kosten. Im Falle eines Kunden, dessen Product Owner nie verfügbar war, war den Beteiligten nicht klar, dass sie damit große Verzögerungen verursachten und das Team nicht zum Spaß immer wieder Erinnerungen schickte. Solche Blockaden in Tagen zu quantifizieren, schafft sehr schnell ein größeres Bewusstsein für die Auswirkungen des eigenen Handelns. Viele Teams beschäftigen sich intensiv mit dem Schätzen und der Größe der Work Items, vergessen aber dabei, dass schlussendlich Blockaden die Lieferung und die Vorhersagbarkeit stark beeinflussen werden. Blocker Clustering hilft ihnen, systemisch verursachte Blockaden zu erkennen und für die Zukunft zu berücksichtigen oder überhaupt zu vermeiden.

Klaus: Welche Verbesserungen hast du beobachtet?

Matt: Wie jede Technik kann das Blocker Clustering nur zeigen, wo das Problem liegt, und dabei helfen, dieses Problem zu quantifizieren. Es liegt am Team, die Information entsprechend zu verwenden. Ein Team kämpfte zum Beispiel mit Blockaden durch voneinander abhängige Storys. Daraufhin entstand die Idee, die Arbeiten anders zu selektieren, indem wir WIP-limitierte Feature-Swimlanes am Kanban-Board anlegten. Auf der Ebene der Organisation kristallisierten sich Blockaden heraus, die sich über sämtliche Teams rund um Storys erstreckten, die nicht fertig für die Entwicklung waren. Also haben wir im Management ein Gespräch über die Teamstrukturen begonnen und darüber, ob in einigen Teams eine neue oder andere Rolle gebraucht wird. Blocker Clustering kann also Verbesserungen auf mehreren Ebenen anstoßen.


Das Interview und eine genaue Erklärung zur Blocker Clustering gibt es im Buch Kanban in der Praxis, Hanser Verlag, 2016

Noch mehr Material zum Thema Blocker Clustering:

Bisher keine Kommentare.
Dieser Unterhaltung fehlt Deine Stimme:
Deine E-Mail Adresse wird nicht veröffentlicht.