Ist das noch Scrum oder kann das weg?

Bild: Flickr/Enrique Fernandez - CC BY 2.0

Ein immer wiederkehrendes Phänomen in Scrum ist es, dass Teams sich darüber beschweren, dass die Methode ihnen zu restriktiv und zu einengend ist. Der Zwang die User Stories immer gleich zu formulieren (Als [Rolle] möchte ich [Aktion] um [Mehrwert]), die Vorschrift, dass man nicht mehrere von ihnen gleichzeitig bearbeiten darf (Sequenzielle Abarbeitung), das Verbot digitale statt physischer Boards zu benutzen (haptische Erfahrung), die Begrenzung von Sprints auf zwei Wochen (kurze Auslieferungszeit) und viele weitere Vorgaben werden als nicht immer zielführend empfunden. Mitunter wird aufgrund solcher Regeln sogar in Frage gestellt, ob Scrum wirklich eine agile Methode ist, da es scheinbar eine Anpassung an aktuelle Aufgaben und Probleme erschweren und verhindern könnte. Diese Einwände sind zwar in gewisser Weise richtig, dennoch steckt ein Denkfehler in ihnen: keine der genannten Regeln ist wirklich ein Teil von Scrum, genauso wenig wie viele andere von denen das häufig behauptet wird.

Das tatsächliche Scrum-Regelwerk ist eher schlank. Der offizielle Scrum Guide ist je nach Formatierung lediglich zwischen 15 und 20 Seiten lang, regelt nur die wichtigsten Bereiche (drei Rollen, fünf Events, drei Artefakte und wenige grundlegende Definitionen) und lässt sonst sehr viel Freiraum. Selbst scheinbar selbstverständliche Bestandteile der Methode erwähnt er nicht einmal - z.B. findet man in ihm weder die Taskboards noch die Backlog Refinements oder das Minimum Viable Product (MVP). Das alles (genau wie die weiter oben genannten Punkte) sind optionale Erweiterungen, die sich irgendwann mal eingebürgert haben ohne verpflichtend zu sein. Wenn man es wollte könnte man sie alle weglassen ohne damit gegen die Regeln zu verstoßen, das Ergebnis würde sich immer noch mit vollem Recht Scrum nennen können. Allerdings: Nur weil man es könnte heißt es nicht, dass man es auch sollte.

Praktisch alle gängigen Erweiterungen sind nicht durch Willkür entstanden sondern das Ergebnis jahrzehntelanger Best Practices. Egal ob sie aus anderen Methoden wie Kanban, Extreme Programming und Lean Startup übernommen oder extra für Scrum entwickelt wurden, hinter ihnen steckt immer die Motivation, die Ideen von Scrum und Agile möglichst optimal in die operative Arbeit umzusetzen. An dieser Stelle setze ich nach Möglichkeit auch immer an wenn sich eines meiner Teams gegen die scheinbar restriktiven und dogmatischen Regeln auflehnt: ich biete an, in einer Diskussionsrunde darüber zu sprechen wo diese Best Practices herkommen, warum man sie übernommen hat, was sie bewirken und welche Risiken man eingeht wenn man sie fallen lässt.

In fast allen Fällen haben sich die Teams danach entschieden, ihre Vorgehensweisen doch nicht zu ändern oder sie nur minimal zu modifizieren. Ihr Problem waren in diesen Fällen nicht die Regeln selbst, sondern deren fehlende Begründung und Erklärung. Sobald diese nachgereicht wurden stieg die Akzeptanz deutlich an. Und in den wenigen Fällen in denen doch Änderungen vorgenommen wurden gab es einen wirklich guten Grund dafür.