Kein Zweifel: Das Konzept von Scrum bringt tolle Ideen und Ansätze mit sich – und nicht nur das: In der Regel ist es auch auf den Prozess der Produktentwicklung übertragbar.
Auf der anderen Seite können die seltsamen Bezeichnungen und Metaphern zu dem ein oder anderen Missverständnis führen – zumindest war das in den Teams, in denen ich mitgearbeitet habe, oft der Fall.
Werden die typischen Scrum-Bezeichnungen zu wörtlichen genommen, kann sich dies kontraproduktiv auswirken. Schauen wir uns die klassischen Beispiele doch einmal an:
Die Selbstorganisation des Teams
Der erste Begriff ist die Selbstorganisation des Teams. Ich vermute, dass insbesondere der Begriff der “Selbstorganisation” zu Missverständnissen führen kann. In vielen Teams, in denen ich mitgearbeitet habe, wurde die “Selbstorganisation” mit “jede Entscheidung wird ohne zu hinterfragen akzeptiert” interpretiert. Die Prozesse endeten in endlosen Diskussionen ohne jedes Ergebnis und waren nicht im Ansatz produktiv.
Im Gegensatz dazu finde ich die “Team”-Metapher mehr als gut gewählt. Der DFB setzt als wichtige Fähigkeit des Trainers voraus, Anführer in jedem Team zu identifizieren und so Teamhierarchien aufzubauen. Der Scrum Guide hat das ähnlich formuliert:
“Development teams are structured… to…. manage their own work.”
Aha! Sie sind strukturiert! “Gleiches Recht für Jeden” ist auch eine Struktur, jedoch aus Entwicklerteams mit Sicherheit nicht die sinnvollste.
Ein Sprint hat nichts mit einem Wettrennen zu tun
Die zweite, missverständliche Metapher ist die des “Sprints”. Ein Sprint ist anstrengend und erschöpfend. Aber möchte ich, dass mein Scrum-Team erschöpft ist? Die Metapher suggeriert, dass der Scrum-Prozess die Entwicklungen des Produktes beschleunigt – und diese Erwartung teilen mitunter sowohl Stakeholder als auch Teammitglieder. Dabei ist das wie die Annahme, ich würde einen Marathon schneller laufen, wenn ich ihn in 422 100 Meter-Sprints aufteile. Das funktioniert nicht. Ich würde stattdessen im Krankenhaus landen.
Übrigens: Diese Notiz habe ich auf einer Flipchart direkt nach einer Sprint-Retrospektive gefunden:
Eigentlich kein so gutes Feedback, oder? Ich würde daher die Begriffe “Wiederholung” oder “Iteration” dem des “Sprints” vorziehen – oder bin ich zu altmodisch?
Muss ich meine Kollegen treten?
Der nächste Begriff ist “Scrum” selbst. Scrum ist ein Begriff aus dem Rugby: das sogenannte “Gedränge”, bei dem die gegnerischen Teams “die Köpfe zusammenstecken” (allerdings nicht auf die produktive Art und Weise) und dann ziehen, zerren und treten, um an den Ball zu kommen.
Wer ist das gegnerische Team im Scrum-Prozess? Wenn muss ich treten und wer zieht und zerrt an mir? Diese Metapher finde ich wirklich schwierig.
Entwickele ich wirklich ein Produkt?
Zu guter Letzt: Der Scrum Guide definiert Scrum als Rahmenwerk für die Entwicklung komplexer Produkte. Daher wird auch die Rolle des Product Owners definiert. Wenn ihr also Scrum anwendet, fragt euch selber: Entwickelt ihr wirklich ein Produkt? Wenn nicht – welche Auswirkungen hat das auf euren Scrum-Prozess?
Also – Ihr Scrum-Verfächter und -Zweifler, hiermit lade ich euch ein, die Köpfe mit mir zusammenzustecken. Mit anderen Worten: Ich freue mich auf eure Kommentare :)
Kommentare