Der Scrum-Reflex

Kennt ihr das auch?

Ein neues Projekt steht an und einer der ersten Schritte ist es, ein Scrum-Team zusammenzustellen?

Der Punkt ist nur: weshalb eigentlich?

In vielen Jahren in der Softwareentwicklung habe ich diesen Scrum-Reflex sehr oft miterlebt. Entweder wurde der Scrum-Prozess (sic) vom Kunden vorgegeben oder aktiv vom Auftragnehmer vorgeschlagen.

Und ich bereue es im Nachhinein, dass ich selbst dieser Reaktion so oft blind nachgegeben habe. Ich bin mittlerweile der Meinung, dass dieser Reflex fahrlässig ist. Getreu dem Motto “wenn man sich nicht für das schämt, was man letztes Jahr gemacht hat, hat man nicht genug gelernt”, gehe ich das Thema heute anders an.

Ausschlaggebend für diese späte Einsicht waren die eigenen Erlebnisse und die Berichte von Kolleginnen über die generelle Zufriedenheit der Devs - sei es in Sachen Zusammenarbeit oder in Hinsicht auf den Werksstolz. Die Mehrheit dieser “Zwangs-Scrum-Teams” blieben weit hinter ihren Möglichkeiten zurück. Zum einen waren die verschiedenen Implementierungen von Scrum qualitativ - diplomatisch ausgedrückt - durchwachsen. Zum anderen lag der Fokus fast ausschließlich auf Delivery anstatt Discovery. Oder noch einfacher ausgedrückt befand sich das Hauptaugenmerk auf einer stark projektmanagementgetriebenen Maximalauslastung von Entwicklungskraft anstatt auf der gemeinsamen Entwicklung des bestmöglichen Produkts.

Die Gründe hierfür sind vielfältig. Aber eine Teilantwort hat mich besonders erschreckt und es ist ex post so einfach: die Lösung (Scrum) hat nicht zum Problem (Kundenumfeld) gepasst.

…und was das alles mit der Stacey-Matrix und dem Cynefin-Framework zu tun hat und zu welchen Schlüssen ich komme, kannst Du auf Der Scrum-Reflex | Marco Spörl - Freiberuflicher Teamcoach lesen.

Was sind eure Erfahrungen mit Scrum in unpassenden Domänen?