Scrum Missverständnisse: Die 7 größten Missverständnisse ❌

Mittlerweile stößt man auf unzählige Scrum Missverständnisse, wenn man näher mit dem Framework arbeiten möchte. Doch wieso?

Der Scrum Guide zählt in der englischen Version nur 14 Seiten. Außerdem ist das Framework, wie der Begriff schon sagt nur ein Framework und keine durchstrukturierte Methode. Daher wenden verschiedene Teams und Unternehmen Scrum auf unterschiedliche Weisen an.

So schwer ist es ja nicht, oder?

Das stimmt, Scrum ist aufgrund der wenigen Regeln relativ simpel und verständlich. Doch aus demselben Grund kommt es vermehrt zu Missverständnissen bezüglich des Frameworks. Die 7 größten Scrum Missverständnisse sehen wir uns heute in diesem Artikel an.

1. Das Team commited sich auf alle im Planning ausgemachten Backlog Items
2. Scrum eignet sich nur für Softwareentwicklung
3. Im Daily Scrum müssen die berühmten 3 Fragen beantwortet werden
4. Scrum ist eine Methode
5. Der Scrum Master muss das Daily moderieren
6. Das Inkrement kann nur am Ende des Sprints veröffentlicht werden
7. Nur der PO darf mit den Stakeholdern kommunizieren

Sehen wir uns diese Missverständnisse genauer an und klären die Mythen auf!

Die 7 Scrum Missverständnisse – und ihre Aufklärung

1. Das Team commited sich auf alle im Planning ausgemachten Backlog Items

Oft herrscht in Teams der Irrglaube, dass Items, die im Planning für den Sprint ausgewählt werden, auch ohne Kompromiss erfüllt werden müssen und das Team sich vollständig darauf commited.

Stimmt das?

In der Theorie ist dieser Gedanke nicht verkehrt und im besten Fall läuft der Sprint auch so ab. Allerdings läuft auch bei Scrum nicht immer nach Plan und auch während dem Sprint kann es sein, dass Änderungen vorgenommen werden müssen. Denn manche Ausgaben könnten redundant werden – im Ernstfall könnte sogar das geplante Sprint Goal obsolet werden.

Außerdem: Das Ziel bei Scrum ist es, das Sprint Goal (wenn nicht obsolet) zu erreichen und nicht, jedes einzelne Backlog Item abzuhaken. Ist das Sprintziel also auch ohne einige dieser Items zu erreichen, ist das völlig legitim.

2. Scrum eignet sich nur für Softwareentwicklung

Ein weit verbreiteter Mythos besagt, Agilität und Scrum würden nur in der Softwareentwicklung funktionieren und ihre vielen Vorzüge nur dort geltend machen.

Obwohl der agile Grundgedanke tatsächlich aus der IT stammt und das Scrum Framework von zwei Softwareentwicklern entwickelt wurde, handelt es sich hier um ein Missverständnis.

Die agile Herangehensweise eignet sich in nahezu allen Branchen – überall, wo komplexe Sachverhalte entwickelt oder behandelt werden.

Denn im Grunde geht es dabei um die stete Überarbeitung und Verbesserung von Produkten und Arbeitsprozessen. Davon profitieren Teams in den unterschiedlichsten Bereichen. Ob Marketing, Sales, HR oder Produktion: Bei Agilität geht in erster Linie um Kundenfokus und angemessene Reaktionen auf äußere Umstände.

3. Im Daily Scrum müssen die berühmten 3 Fragen beantwortet werden

Was habe ich gestern gemacht, um das Sprintziel zu erreichen?

Was werde ich heute machen, um das Sprintziel zu erreichen?

Gibt es Hindernisse, die mir die Entwicklungsarbeit erschweren?

Diese Fragen waren in der alten Version des Scrum Guides verankert. Sie sollten als Vorschlag dienen, um das Daily Scrum sinnvoll zu gestalten. Daran haben sich zahlreiche Scrum Teams überall auf der Welt gehalten und tun es auch immer noch. Was dabei aber untergegangen ist: Die drei Fragen dienten von Vornherein nur als Vorschlag und waren nie verpflichtend. Denn das Daily Scrum kann von den Developers frei gestaltet werden (insofern das Event auf das Sprintziel einzahlt).

Inzwischen sind die Fragen in der aktuellen Version des Scrum Guides gar nicht mehr zu finden. Es soll dadurch zu keinen Verwirrungen mehr kommen.

Dennoch sind die drei bekannten Fragen ein hilfreicher Anhaltspunkt, besonders für Teams, die gerade erst frisch mit dem Scrum Framework arbeiten.

4. Scrum ist eine Methode

Wir müssen gestehen: Auch wir haben Scrum schon öfter als Methode bezeichnet. Doch streng genommen ist es das nicht. Bei Scrum handelt es sich um ein Framework, das in Form des Scrum Guides gewisse Konzepte vorgibt, an die sich Teams halten können. Wie anfangs beschrieben ist dieser Scrum Guide allerdings sehr knapp gehalten. Denn dabei handelt es sich um wenige Regeln und Anhaltspunkte für Scrum Teams. Im Kern geht es aber um den agilen Grundgedanken, den Scrum vertritt. Der große Unterschied zwischen einem Framework und einer Methode ist, dass das Framework auf verschiedene Weisen implementiert werden kann.

Wie das Framework dann tatsächlich ausgeführt wird, liegt also beim Team und dem Scrum Master. Scrum als Methode zu bezeichnen ist zwar kein wesentlicher Fehler – eng betrachtet aber schlichtweg nicht korrekt.

5. Der Scrum Master muss das Daily moderieren

Ja, der Scrum Master kümmert sich um die korrekte Implementierung des Scrum Frameworks und dazu gehört auch das Daily Scrum als Event. Allerdings ist er nicht der Moderator des Daily, denn wie schon in Punkt 3 beschrieben, darf das tägliche Treffen gestaltet werden, wie auch immer das Team das tun will.

Dabei geht es nicht darum, dass die Developer dem Scrum Master ein Reporting abgeben. Sinn des Daily Scrums ist es, Transparenz zu schaffen und mögliche Hindernisse ausfindig zu machen.

Da das Meeting allerdings frei gestaltet werden darf, kann der Scrum Master theoretisch die Moderations-Rolle übernehmen. Müssen tut er das aber nicht.

6. Das Inkrement kann nur am Ende des Sprints veröffentlicht werden

In der Regel ist das zu entwickelnde Inkrement am Ende eines Sprints fertiggestellt und wird dann „ausgeliefert“ (das bedeutet, es ist potenziell zur Veröffentlichung bereit). Kritiker:innen des Frameworks behaupten, dies wäre ein Nachteil, denn die Abstände zwischen regelmäßigen Auslieferungen würden sich dadurch unnötig in die Länge ziehen.

Das stimmt allerdings nicht, denn das Inkrement kann theoretisch auch bereits während des Sprints fertig gestellt sein und somit ausgeliefert werden. Der Sprint verkürzt sich dadurch nicht.

7. Nur der Product Owner darf mit den Stakeholdern kommunizieren

Ein häufiger Irrglaube im Zusammenhang mit Scrum ist, dass ausschließlich der Product Owner mit den Stakeholdern kommunizieren dürfe und die Developer nur einmal im Sprint, und zwar im Sprint Review, auf diese treffen. Das ist allerdings nicht ganz richtig so. Es ist zwar die Aufgabe des Product Owners und des Scrum Masters, die Developer vor äußeren Umständen und Ablenkungen zu schützen, aber das bedeutet nicht, dass nur sie mit diesen äußeren Einflussfaktoren in Kontakt treten dürfen. Vielmehr geht es darum, dass der Product Owner – wenn notwendig – den Dialog zwischen Developern und Stakeholdern ermöglicht.

Wenn also Austausch wichtig ist, kann das auch außerhalb der Sprint Review geschehen und sogar, wenn der Product Owner nicht dabei ist. Das wäre allerdings trotzdem immer ratsam. Denn er ist dafür verantwortlich, dass die Developer wieder schnell und gut informiert an die Arbeit gehen, damit das Inkrement fertig gestellt werden kann.

Fazit: Popularität sorgt für zahlreiche Scrum Missverständnisse

Viele der Scrum Missverständnisse ranken sich darum, ob gewisse Dinge im im Framework erlaubt sind oder nicht. Das lässt sich jedoch relativ pauschal beantworten: Scrum ist ein relativ offenes Framework, in dem es nicht viele Regeln und Vorgaben gibt. Die Regeln, die existieren, sind im Scrum Guide verankert, auf den man zurückgreifen kann. Alles, was darüber hinaus geht kann nach Belieben angepasst werden. Du solltest aber nicht vergessen, dass sich inzwischen viele Best Practices entwickelt haben, bei denen es sich lohnt, es anderen Team gleichzutun und auf sie zurückzugreifen. Denn oft kommt es vor, dass sich Teams mehr Anhaltspunkte wünschen als vom Scrum Guide aktuell gegeben.

Fest steht allerdings, dass das Scrum Framework aufgrund seiner steigernden Popularität mit immer mehr Missverständnissen und Kritiken zu kämpfen hat, die oft nicht gerechtfertigt sind.

Am besten machst du dir aber dein eigenes Bild davon und implementierst Scrum auf eine Weise, wie sie für dich am meisten Sinn macht.

Die Agile Heroes als Scrum Profis

Dabei helfen dir auch gerne die Agile Heroes! Egal, ob du auf der Suche nach agiler Beratung bist, oder selbst ein Scrum Training ablegen willst – die Agile Heroes können dir auf jeden Fall dabei weiterhelfen! Vereinbare einfach ein unverbindliches Erstgespräch mit den Heroes und finde heraus, wie das am besten geht.