Scrum sagt nicht, dass
Mit freundlicher Genehmigung des Autors Adrian Howard (Quietstars) haben wir diesen Artikel von seinem Medium Account übersetzt. Schließlich schreiben und lehren wir tagein, tagaus, was Scrum ist, wie man Scrum sinnvoll anwenden kann und welche Rahmenbedingungen dafür gegeben sein sollten. – Daher ist es vielleicht auch einmal an der Zeit, zu sagen was Scrum definitiv nicht ist und auch gar nicht sein will!
Da Adrian dies bereits perfekt in seinem Artikel getan hat, gibt es hier die deutsche ungekürzte Übersetzung:
Eine Beschwerde darüber, was Scrum nicht ist!
Bei Quietstars verwenden wir selbst kein Scrum. Ich bin auch kein großer Fan von Scrum (vor allem nicht der Zertifizierungsbranche, die sich um Scrum herum aufgebaut hat – siehe CSSTWP für mehr dazu).
Dennoch scheine ich einen Großteil meiner Zeit damit zu verbringen, Scrum zu verteidigen. Denn die meisten Kritiken, die ich höre, beziehen sich nicht auf Dinge, die Scrum vorschreibt.
Zum Beispiel:
Scrum sagt nicht, dass die Stories lauten müssen: „Als Rolle möchte ich aus Vernunft zum Ziel kommen“.
Scrum sagt nicht, dass man nur einmal pro Sprint releasen kann.
Scrum sagt nicht, dass man nur am Ende eines Sprints freigeben kann.
Scrum ist kein Akronym und wird nicht S.C.R.U.M. buchstabiert (okay… ich höre selten Beschwerden darüber, aber es ärgert mich verdammt nochmal!)
Scrum sagt nicht, dass der Sprint und die Product Backlogs die gleiche Art von Dingen enthalten müssen.
Scrum sagt nicht, dass man Diagramme abbrennen oder verbrennen muss.
Scrum sagt nicht, dass man bis zum Sprint Review warten muss, um den Leuten Dinge zu zeigen.
Scrum sagt nicht, dass man bis zur Sprint Retrospektive warten muss, um über Probleme zu sprechen.
Scrum sagt nicht, dass man nur einmal im Sprint vorführen oder mit Stakeholdern sprechen darf.
Scrum sagt nicht, wie wir Backlog Items schätzen sollen.
Scrum sagt nicht, dass man Punkte haben muss.
Scrum sagt nicht, dass man Geschwindigkeit als Ziel verwenden sollte.
Scrum sagt nicht, dass man die Geschwindigkeit überhaupt verfolgen muss.
Scrum sagt nicht, dass man Epics, Stories oder Tasks haben muss.
Scrum besagt nicht, dass man keine Meetings haben darf, die mit Sprintplanung, Stand-Ups, Sprint Reviews oder Sprint Retrospektiven nichts zu tun haben.
Scrum sagt nicht, dass der Product Owner das Team daran hindern kann, an technischen Schulden zu arbeiten.
Scrum sagt nicht, dass der Product Owner dem Team sagen kann, wie das Backlog in releasefähigen Code übersetzt werden soll.
Scrum sagt nicht, dass der Scrum Master dem Team sagen kann, wie das Backlog in releasefähigen Code übersetzt werden soll.
Scrum sagt nicht, dass Mitarbeiter aus dem operativen Bereich nicht im Team sein dürfen.
Scrum sagt nicht, dass Tester nicht im Team sein dürfen.
Scrum sagt nicht, dass Designer oder User Researcher nicht im Team sein dürfen.
Scrum sagt nicht, dass Business-Analysten, Manager, Projektmanager usw. nicht notwendig sind.
Scrum sagt nicht, dass der Product Owner alle Entscheidungen selbst treffen muss.
Scrum sagt nicht, dass der Product Owner das gesamte Product Backlog priorisieren muss.
Scrum sagt nicht, dass Sie mehr als 80 Stunden pro Woche arbeiten müssen, um den Forecast zu erfüllen, den Sie zu Beginn des Sprints gemacht haben.
… und wahrscheinlich sagt Scrum noch viel mehr nicht. – Gebt mir gerne weitere Vorschläge!
Was ist Scrum?
Wie Tim Ottinger schon so treffend als Antwort auf die Twitter-Schimpftirade, die dieser Post ausgelöst hat, sagte:
Ich habe festgestellt, dass die Frage: „Kannst du ein bisschen darüber reden, wie Scrum und Agile zusammenhängen?“ eine wirklich wichtige Frage ist. Denn an einem Ende des Spektrums bekommt man verwirrte Blicke, weil die Leute denken, Scrum und Agile seien Synonyme. Und am anderen Ende des Spektrums bekommt man eine nachdenkliche Diskussion über Scrum, andere Agile Methoden, wie sie zusammenhängen und was die Kompromisse dieser Methoden sind.
Viele, wenn nicht sogar die meisten Beschwerden die ich über Scrum höre, werden dadurch verursacht, dass Menschen gedankenlos Praktiken aus einer dysfunktionalen Organisation heraus kopieren, in der sie zuerst etwas über Agilität gelernt haben.
Wenn du also jemanden sich darüber beschweren hörst, wozu Scrum ihn zwingt, ermutige ihn, den Scrum Guide richtig und nochmal zu lesen. Das kann man in einer Mittagspause tun und hat dabei immer noch Zeit für ein gemütliches Dessert – der Leitfaden ist in der neuen Ausgabe von 2020 weniger als dreizehn Seiten lang.
Scrum ist im Kern ein wirklich minimales Prozessverbesserungs-Framework
Nur, wenn du verstehst, wie dieses Rahmenwerk zusammengesetzt ist, kannst du auch mit dem grässlichen Monster der achtzigstündigen Wochenarbeitszeit, welche oft als Scrum bezeichnet wird, umgehen.
Manchmal ist dieses Wissen das, was dich wissen lässt, dass Scrum nicht das ist, was du brauchst.
Denn Scrum sagt nicht, dass es die einzig wahre Möglichkeit ist, agil zu arbeiten, oder überhaupt die einzige Art zu arbeiten.
Was macht ein Agile Leader?
=> Wodurch zeichnen sich agile Führungskräfte aus?
Agile HR
=> Wenn du agil werden willst, fang bei deiner Personalabteilung an!
Wie können dir agile Fortbildungen helfen?
=> Wir haben eine Personalberatung gefragt, wie beliebt agile Fortbildungen bei Arbeitgebern sind.