In diesem Artikel beleuchten wir 5 Mythen aus dem Scrum Framework. Wir unterscheiden zwischen Theorie und Praxis und sehen uns an, wo Aussagen aus dem Scrum Guide oder aus der Scrum-Praxis falsch interpretiert werden. Und das sogar von erfahrenen Scrum-Usern.
Vielleicht fällt dir auf, dass auch du schon so manche Mythen für bare Münze genommen hast.
Ein kleiner Disclaimer: Wir klären hier nur auf, welche Mythen aus dem Scrum Guide gerne falsch interpretiert werden – das bedeutet nicht, dass sie in der Praxis nicht trotzdem Sinn machen können. Der Scrum Guide wird von vielen Teams nach Belieben interpretiert und abgewandelt und oft funktioniert das auch sehr gut. Trotzdem handelt es sich bei diesen Mythen um die Diskrepanz zwischen Theorie und Praxis.
Wenn du dich mit diesem Thema lieber in Form eines Videos auseinandersetzen willst, dann geht das ganz einfach. Unser Scrum-Experte Lars hat alle 5 Mythen auch in einem YouTube Video zusammengetragen und auf ihren Wahrheitsgehalt überprüft.
Diese 5 Scrum Mythen solltest du auf jeden Fall im Blick haben
Wir haben uns in diesem Artikel für 5 Mythen beziehungsweise Aussagen zu Scrum entschieden, die wir in der Praxis sehr oft erkennen können und die im Allgemeinen häufig für „wahr“ gehalten werden, obwohl sie gar nicht derartig im Scrum Guide verankert sind.
Daher kann es dir helfen, diese Mythen als solche zu erkennen, wenn du womöglich bald vor deiner PSM2 Prüfung und Zertifizierung stehst. Dann solltest du auf jeden Fall wissen, dass es sich hierbei um bloße (Best) Practices aus der Praxis handelt.
Mythos #1 Nur der Product Owner interagiert mit den Stakeholdern
Korrekt an diesem Mythos ist die Tatsache, dass der Product Owner die Hauptperson ist, die mit den Scrum Stakeholdern in Kontakt tritt. In erster Linie findet also der Großteil der Interaktion zwischen ihnen statt. Allerdings gibt es keine Regel, die es den Developern, also dem Entwicklungsteam verbietet, dasselbe zu tun. Häufig macht es auch Sinn, dass die Entwickler als Experten für die Projektarbeit ihre Informationen mit den Stakeholdern teilen. Der Grund, wieso sich dieser Mythos überhaupt entwickelt hat, liegt darin, dass sich die Developer hauptsächlich auf die Entwicklungsarbeit konzentrieren sollen. Ablenkung durch ständige Abstimmungen mit anderen Rollen sollen sie vermeiden. Daher dient der Product Owner als eine Art Puffer oder Gatekeeper zwischen ihnen und übernimmt demnach viel der Kommunikation.
Du hast Interesse an einer Product Owner Zertifizierung? Hier findest du alle Infos zu unserem Scrum Training!
Mythos #2 Scrum Teams müssen ein Scrum Board nutzen, um ihre Arbeit transparent zu machen
Die Nutzung von Scrum Boards (in Jira, als physisches Kanban Board oder in anderen Tools) ist auf jeden Fall zu empfehlen! Auch wir bei den Agile Heroes sind große Fans von diesem „Mythos“. Allerdings: Geschrieben steht das so nirgends. Diese Best Practice hat sich offenbar – zurecht – über die Zeit in der Praxis etabliert. Aber lass dich beispielsweise bei der PSM2 Prüfung nicht täuschen: In der Theorie gibt es keine Regel, die besagt, Scrum Teams müssen Scrum Boards nutzen. Um die Arbeit transparent zu machen, reicht oft schon die korrekte Ausführung aller Scrum Events.
Interesse an Jira? In unserem Jira Onlinekurs erfährst du, wie du am besten und effektivsten damit arbeitest!
Mythos #3 Die Arbeit in Scrum wird in Story Points geschätzt
Auch hierbei handelt es sich um eine Aussage, die in außerordentlich vielen Scrum Projekten Alltag ist. Aber das Schätzen in Story Points ist keine Pflicht. Egal für welches Maß ihr euch entscheidet, ihr könnt Schätzen wie ihr wollt: Ob Story Points, Tage, T-Shirt-Größen oder auch gar nicht. Diese Entscheidung liegt ganz bei euch als Developern. Story Points haben sich als Favorit bei vielen Projekten herauskristallisiert und kennen auch viele Vorteile. Allerdings: Pflicht sind sie nicht.
Mythos #4 Der Scrum Master muss beim Daily Scrum anwesend sein
Dieses Thema führt in vielen Teams und Projekten oft zu Diskussionen. Die große Frage steht im Raum: Muss der Scrum Master immer beim Daily Scrum dabei sein oder es sogar moderieren? Nein. Das Daily Scrum ist das selbstorganisierte Event der Developer und dementsprechend muss der Scrum Master nicht dabei sein. Streng genommen sollte er sogar nur dabei sein, wenn das Team dies auch so wünscht. Denn es darf selbst entscheiden, wie dieses Event gestaltet wird und wer daran teilnimmt.
In der Praxis sieht das oft ganz anders aus: In vielen Fällen wird der Scrum Master zum Moderator des Daily und kümmert sich um dessen Organisation. Im Scrum Guide steht davon aber nichts. Auch der Product Owner ist nicht dazu verpflichtet, am Daily Scrum teilzunehmen. Wer also wie regelmäßig dabei ist und was im Daily Scrum besprochen wird entscheiden also einzig und die Developer, die selbstorganisiert für dieses Event zuständig sind.
So führst du das perfekte Daily Scrum durch!
Mythos #5 Product Backlog Items werden in Form von User Storys erfasst
Unser Scrum-Experte sagt: „Das ist falsch!“. Obwohl in der Praxis in nahezu allen Scrum-Projekten mit User Storys gearbeitet wird – und das zurecht. Die Formulierung einer User Story ermöglicht es den Teams vor allem, sich in die(zukünftigen) Anwender:innen hineinzuversetzen und ihre Bedürfnisse zu verstehen. Deshalb kam es zu der Entwicklung, dass nahezu alle Sprint Backlog Items als solche User Storys erfasst werden.
So muss es allerdings nicht sein, denn es kann verschiedene Arten von Backlog Items geben – wie zum Beispiel ein Bug. Einen Bug als User Story zu formulieren, macht keinen Sinn.
Dementsprechend könnt ihr euer Backlog Item definieren, wie ihr wollt. Am Ende geht es darum, das Sprintziel zu erreichen. Sollte es Schwierigkeiten bei der Definition und der Formulierung der Items geben, ist es ratsam, diesen Prozess genauer unter die Lupe zu nehmen und je nach Bedarf anzupassen.
Scrum Mythen: Wieso unterscheiden sich Theorie und Praxis?
Wie bereits am Anfang des Artikels erwähnt, sind die genannten Scrum Mythen nicht zwangsweise Fehler, die Scrum User begehen. All die genannten Mythen haben in der Praxis ihren Platz gefunden. Zahlreiche Teams weltweit nutzen Scrum Boards, schätzen in Story Points oder formulieren die meisten ihrer Backlog Items in Form von User Storys. All das ist keineswegs falsch, doch in der Theorie sind diese Annahmen nicht verankert. Wieso eigentlich nicht, wenn sie doch funktionieren?
Der Scrum Guide ist mit Absicht sehr kurz und knapp gehalten. Als Framework soll Scrum genau das zulassen, was in diesem Artikel beschrieben wird: Eigene Best Practices können sich herauskristallisieren und Teams haben die Möglichkeit, die festgeschriebenen Regeln so anzuwenden, dass sie für ihr Projekt den bestmöglichen Outcome schaffen.
Dennoch: Bei der Scrum Prüfung (PSM1 oder PSM2) gibt es nur ein Richtig oder Falsch. Deswegen ist es von Vorteil, Theorie und Praxis auseinander halten zu können und zu Scrum Mythen identifizieren zu können.
Mehr zu Scrum, agilen Methoden und den Agile Heroes auf Youtube
Wenn du dich noch weiter mit dem Thema Scrum und Agilität auseinandersetzen möchtest, dann ist unser Agile Heroes YouTube Kanal genau das richtige für dich. Dort veröffentlichen wir jede Woche spannenden Content zu den unterschiedlichsten Frameworks und agilen Arbeitsweisen. Außerdem findest du dort Interviews, Business-Tipps und vieles mehr.
Wir wünschen dir viel Spaß beim Durchklicken.
