Wo steht das im Scrum Guide?

Eine Schimpftirade darüber, was Scrum nicht ist.

Ich bin kein großer oder überzeugter Fan von Scrum (vor allem nicht die nimmersatte Zertifizierungsbranche, die sich darum herum aufgebaut und die Taschen voll gemacht hat.)

Trotzdem scheine ich einen Großteil meiner Zeit damit zu verbringen, Scrum zu verteidigen. Denn die meisten Kritikpunkte, die ich höre, beziehen sich nicht auf Dinge, die Scrum wirklich vorschreibt, sondern auf die Dinge, sich im Laufe der Zeit – mehr so still und (un-) heimlich – wie Unkraut – drum herum gerankt haben. Und wenn ich hier eine Schimpftirade versuche, dann sehe ich zwangsläufig auch auf die „an- bzw. drübergepflanschten“ Skalierungen, die wie ein sehr wiederstandsfähiges, chamäleonartiges Gewächs, dazu gewachsen ist. Es ist immer noch Unkraut und wir sind an einem Punkt angekommen, wo Nutzer und Organisationen beginnen, sich von Scrum wieder abzuwenden. Willkommen in der postagilen Zeit. Was war Schuld? War Scrum selbst nun daran schuld? Nein, Es waren Gier, Ignoranz, Macht- und Darstellungsstreben und das gute Gefühl, es etablierten Systemen „gezeigt“ zu haben. Und?

Zum Beispiel:

Scrum sagt nicht (oder gibt es vor), dass Geschichten (User Storys) lauten müssen: „Als (Rolle, Funktion) will ich (a,b,c) nutzen, weil (damit) Begründung“.
Scrum sagt nicht (oder gibt es vor), dass man nur einmal pro Sprint Arbeiten oder Ergebnisse freigeben kann.
Scrum sagt nicht (oder gibt es vor), dass man erst am Ende eines Sprints Arbeiten oder Ergebnisse freigeben kann.
Scrum ist kein Akronym und wird auch nicht SCRUM geschrieben (okay… Ich hör(t)e selten Beschwerden darüber, aber es ärgert trotzdem)
Scrum sagt nicht (oder gibt es vor), dass der Sprint als solches und die Product Backlogs die gleichen Dinge enthalten müssen.
Scrum sagt nicht (oder gibt es vor), dass Sie Burn-Down- oder Burn-Up-Charts haben müssen. Schon gar nicht, um Geschwindigkeiten zu messen.
Scrum sagt nicht (oder gibt es vor), dass man bis zum Sprint-Review warten muss, um den Leuten, Kunden oder Stakeholdern fertige Dinge zu zeigen.
Scrum sagt nicht, dass man bis zur Sprint-Retrospektive warten muss, um über Probleme zu sprechen.
Scrum besagt nicht (oder gibt es vor), dass man nur einmal pro Sprint eine Demo durchführen oder mit Stakeholdern sprechen darf.
Scrum sagt nicht (oder gibt es vor), wie Sie Backlog-Items schätzen sollten. Nein, weder Punkte, noch T-Schirt-Größen oder sonst etwas.
Scrum sagt schon gar nicht (oder gibt es vor), dass Sie Geschwindigkeit als Ziel verwenden sollten.
Scrum sagt überhaupt nicht, dass Sie die Geschwindigkeit verfolgen müssen. (Das möchten Vorgesetzte sehen, damit sie „glänzen“ können)
Scrum sagt nicht (oder gibt es vor), dass Sie Epics, Storys oder Aufgaben haben müssen.
Scrum sagt nicht, dass man keine Meetings abhalten kann, die nicht Sprint-Planung, Standups, Sprint-Reviews oder Sprint-Retrospektiven sind.
Scrum sagt auch nicht, dasss man Meetings, die nur noch ihren Selbstzweck als Pflichtmeeting erfüllen, ausfallen lassen kann.
Scrum sagt nicht (oder gibt es vor), dass der Product Owner das Team daran hindern kann, an technischen Schulden zu arbeiten.
Scrum besagt nicht, dass der Product Owner dem Team sagen darf, wie das Backlog in releasefähigen Code umgewandelt werden soll.
Scrum besagt auch nicht, dass der Scrum Master dem Team sagen darf, wie das Backlog in releasefähigen Code umgewandelt werden soll.
Scrum gibt nicht vor, dass Betriebsmitarbeiter nicht im Team sein können. Ebenson wie Tester
Scrum sagt nicht, dass Designer oder User Researcher nicht im Team sein können.
Scrum gibt nicht vor, dass Business Analysten, Manager, Projektmanager usw. nicht notwendig sind.
Scrum sagt nicht, dass der Product Owner alle Entscheidungen selbst treffen muss. Er soll das Produkt besitzen. Das Team soll(te) machen.
Scrum besagt nicht, dass der Product Owner das gesamte Product Backlog priorisieren muss. So verbrennen Product Owner.
Scrum sagt nicht (oder gibt es vor), dass Sie eine 80+ Stunden-Woche arbeiten müssen, um die Prognose zu erfüllen, die Sie zu Beginn des Sprints gemacht haben.

… und wahrscheinlich noch viele, viele mehr – machen Sie Vorschläge!

Ich habe festgestellt, dass „Können Sie ein wenig darüber sagen, wie Scrum und Agile zusammenhängen?“ eine wirklich wichtige Frage ist. Scrum behautet von sich selbst, nicht agil zu zu sein. Am einen Ende des Spektrums aller Fragen bekommt man verwirrte Blicke, weil die Leute denken, dass Scrum und Agile Synonyme sind. Auf der anderen Seite erhalten Sie eine nachdenkliche Diskussion über Scrum, andere agile Methoden, wie sie zusammenhängen und was die Kompromisse sind.

Fazit

Viele, wenn nicht sogar die meisten Beschwerden über Scrum, die ich höre, werden von Menschen verursacht, die gedankenlos Praktiken aus der bisherigen, dysfunktionalen Organisation über Scrum kopieren, seit dem sie zum ersten Mal von Agile erfahren haben. Warum? Ja, warum eigentlich?

Wenn Sie also hören, dass sich jemand darüber beschwert, wozu Scrum ihn zwingt, ermutigen Sie ihn, den Scrum Guide wirklich zu lesen. Wort für Wort, Absatz für Absatz. Sie werden es in der Mittagspause schaffen können und haben immer noch Zeit für ein gemütliches Dessert – es ist weniger als zwanzig Seiten lang. Scrum ist im Kern ein wirklich minimales Framework zur Prozessverbesserung. Es sind Vorschläge, wie es optimalerweise funktioniert. Es ist eine Pflanze, die regelmäßig gegossen, gepflegt und gehegt werden will – ohne Unkraut. Sonst erstickt sie.

Wenn Sie verstehen, wie dieses Framework im Innern zusammengestellt ist, können Sie mit dem grässlichen Stretch-Goal, der Geschwindigkeitsverfolgung und der Achtzig-Stunden-Woche-Monstrosität umgehen, die oft als Scrum bezeichnet wird. Manchmal ist dieses Wissen das, was Sie wissen sollten, dass Scrum NICHT das ist, was Sie brauchen. Denn Scrum sagt von sich selbst nicht, dass es der einzige Weg ist, agil zu arbeiten, oder der einzige Weg ist, überhaupt zu arbeiten.