Cargo Cult Scrum

Die letzten Wochen habe ich wieder verstärkt in Gesprächen ein Verhalten beobachtet, was ich als „Cargo Cult Scrum“ identifiziere. Dazu gibt es auch andere Artikel im Internet, offenbar ist meine Beobachtung gar nicht so selten.

Unter einem „Cargo Cult“ versteht man allgemein ein Verhalten, bei dem versucht wird, einen positiven Effekt durch die Simulation der „Symptome“ herbeizuführen. Ursprünglich stammt dieser Begriff aus der Beobachtung von Bewohnern einiger pazifischer Inseln, die während des zweiten Weltkriegs von den Zwischenlandungen amerikanischer Flugzeuge auf ihren Inseln profitiert hatten, und nach dem Krieg die ausbleibenden Flieger durch den Bau von Landebahnen und (hölzernen) Funk- bzw. Radarstationen wieder herbeiholen wollten.

Im Scrum-Umfeld beobachte ich nun wieder, wie durch die Verwendung von Scrum-Begriffen für ansonsten gegenüber früheren Methoden weitgehend unveränderten Aufgaben oder Werkzeugen ein agiles Entwickeln quasi herbeigezaubert werden soll.

Klassische Führungskräfte nennen sich jetzt „chief product owner“. Aus den Entwicklern werden einzelne herausgegriffen und als „product owner“ bezeichnet. Sie müssen sich aber gegenüber dem chief product owner und allen möglichen Gremien aus früheren Zeiten mit zum Teil recht kreativen neuen Titeln nicht nur verantworten, sondern sich Entscheidungen wie früher in einer hierarchischen Unternehmensstruktur genehmigen lassen.

Aufgabenlisten heißen jetzt „product backlog“. Frühere Projektleiter werden als „scrum master“ bezeichnet, nur sollen sie nach dem Willen der Führungskräfte wie früher dafür sorgen, dass die Teams tun, was angesagt wird. Ein solcher scrum master, der eventuelle Probleme in Teams nicht durch entsprechende Anweisungen beseitigt, wird abgesetzt.

Regelmäßige Team-Meetings sind nun Retrospektiven, nur sagt dann der product owner und der scrum master was geändert wird.

Allen diesen Benennungen ist gemeinsam, dass der Sinn, die genaue Funktionsweise und das Zusammenspiel dieser Rollen und Werkzeuge in Scrum nicht wirklich verstanden werden. Das Verhalten ist ganz ähnlich dem der Polynesier, die nicht wissen wozu eine Radarstation dient und deren rein äußerliche Nachbildung genauso wenig funktioniert wie im Unternehmen die Verwendung der Begriffe. Scrum ist sehr leichtgewichtig, aber alle Teile müssen zusammenwirken, damit das große Ganze funktioniert.

Nach einer Weile stellt man dann fest, dass Projekte nicht besser oder gar schneller vorankommen, und kommt zu dem Schluss Scrum funktioniert für das Unternehmen einfach nicht so, und man muss es verbessern, indem neue Abstimmrunden und Genehmigungsprozesse für die Bearbeitung von „tickets“ eingeführt werden.

Leider scheint es, dass Unternehmen, die diesen Weg weit genug gegangen sind, für agile Entwicklung verloren sind. Die entstandene negative Belegung des Begriffs „Scrum“ ist wohl kaum korrigierbar.   „

Macht den Selbst-Test und prüft etwa folgende Checkliste !