Scrum ohne Scrum Master

Scrum-Fails

Scrum Pioniere

Grundlegend ist das Scrum Framework auf wenigen Seiten präzise in dem Scrum Guide erfasst und verfasst. Leider kommt es immer wieder zu Modifikationen, wenn Personen es in ihrem Umfeld zu ihrem eigenen Scrum umformen. Was von solchen „Pionieren“ leider nicht beachtet wird, ist der Fakt, dass die Grundregeln nicht gelernt sind, sondern dass man es liest und ohne es angewendet zu haben, direkt nach seinen Wünschen formt.

Undurchdachte Lösungen stiften mehr Tumult als sie Lösungen hervorbringen. Mehr Meinungen führen zu mehr Diskussionen. Wenn es ein Framework trifft, das bereits präzise ausformuliert ist. Eine weitere Falle ist das Thema, dass jemand die Rolle des Scrum Master übernimmt, der keinerlei Vorerfahrungen hat.

Definierte oder undefinierte Rollen?

Es ist kein Übel sich sein eigenes Scrum Framework zu erdichten und danach zu leben. Wenn die Rollen, Artefakte, Ereignisse und Werte gelebt werden, kann man gerne darin versinken und etwas Neues ausprobieren. Doch das Scrum-Herz darf nicht verkommen und muss im Kern bestehen bleiben.

Immer wieder sehe ich Leute – vor allem ungeduldige Personen in Kundenprojekten – die gerne sofort Ergebnisse wollen und wenn es nicht auf Anhieb klappt, soll Scrum an das angelehnt werden, was man schon kennt. Dies führt zu Cargo Kult. Leider gerät dann das Framework in eine schiefe Lage und kann nicht zu einer Agilisierung führen, da man die ersten Schritte im „klassischen Scrum” nicht gegangen ist.

Dabei ist die Lösung vorhanden. Einen ungelernten Entwickler lässt man auch nicht an Codezeilen, die seitlich im Quellcode implementiert sind und zu einem wichtigen Feature gehören. Man lernt diesen an, man erklärt es ihm und versucht es ihm so nahe zu bringen, dass nach einiger Zeit seine Fähigkeiten ausgebaut werden.

Scrum-Zertifizierung = Scrum Master?

Dasselbe gilt in Scrum. Eine Scrum-Zertifizierung ohne die gelebte Erfahrung und Kenntnisse aus Gesprächen mit Entwicklern in der Scrum Master Rolle führt zu Illusionen. Diese Illusionen wiederum führen dazu, dass man etwas proklamiert, was nicht Scrum ist. Aus diesen Gründen ist es unerlässlich, einen Scrum Master direkt bei Start des Projektes zu rekrutieren und diesen einem Team zuzuteilen. Dieser erklärt die Regeln, fortwährend coached er das Team und alle weiteren Beteiligten, damit diese erkennen was und wieso Scrum im Einsatz ist. Es steckt viel mehr dahinter als ein Daily zu führen. Es ist mehr als eine Retromethodik anzuwenden und es ist mehr als nur eine Agenda für die Review zu schreiben. Leider wird dieses detaillierte Wissen in den meisten Seminaren nicht mitgeteilt. Bisweilen gibt man sich mit Oberflächlichkeiten zufrieden, nur damit ein bedruckter Zettel ausgeteilt wird und Personen sich damit rühmen.

Daher schützt euch davor, ein Projekt zu starten mit Personen die nicht schon einmal als Scrum Master gearbeitet haben und mit den Menschen gemeinsam einen Weg gefunden haben. Schützt euch davor, zu sehr den Wert auf Zertifizierungen zu legen und beschützt Scrum im Kern, denn alles andere ist kein Scrum.

Teile diesen Beitrag:
Menü