Scrums größte Stärke ist dessen Einfachheit, welche aber auch die Quelle vieler Mythen und Fehlinterpretationen ist.
In meinem fortgeschritten Professional Scrum Master Training helfe ich den Teilnehmern auf unterhaltsame Art und Weise zu verstehen, dass Scrum keine Einheitslösung, kein Allheilmittel oder eine vollständige Methodik ist. Indem ich ihnen Aussagen präsentiere und sie begründen müssen, ob es sich hierbei um eine Tatsache oder um einen Mythos handelt, lernen sie die Grenzen des Rahmenwerks kennen. Diese Grenzen bieten den Rahmen, innerhalb derer sich Scrum Teams selbst organisieren können, um ein komplexes Problem mit einem empirischen Ansatz zu lösen.
Die meistverbreiteten Mythen, die jeder fortgeschrittene Scrum Master kennen und widerlegen können sollte, lauten:
Mythos #1: In Scrum wird nicht geplant
Im Gegenteil, das Scrum-Rahmenwerk lädt zum Planen ein.
Im Sprint Planning plant das Scrum Team gemeinschaftlich die Arbeit, um das Sprint-Ziel zu erreichen. Im Daily Scrum planen die Entwickler, welche Arbeit sie heute erledigen wollen, damit sie dem Sprint-Ziel näher zu kommen. Auf Grundlage der Ergebnisse des Sprints planen die Teilnehmer, was als Nächstes für die Erreichung des Produkt-Ziels zu tun ist. In der Sprint Retrospektive plant das Scrum Team, wie sie in Zukunft die Qualität des Produkts und die Effektivität ihrer Zusammenarbeit verbessern können.
Im Unterschied zu traditionellen Ansätzen komplexe Probleme zu lösen, gibt es in Scrum keine einmalige Planungsphase, sondern die Planung findet in Zyklen statt.
Mythos #2: Mit Scrum können keine Projekte durchgeführt werden
Scrum ist ein Rahmenwerk, welches Teams und Organisationen hilft, Wert durch adaptive Lösungen für komplexe Probleme zu generieren.
Wenn ein Projekt dadurch ausgezeichnet ist, dass der Umfang der Arbeit bereits vor dem Beginn festgelegt wurde, dann kann mit Scrum nicht adaptiv Wert generiert werden. Für diese Situation ist Scrum ungeeignet. Wenn wir ein Projekt, wie vom Project Management Institute vorgeschlagen, als ein zeitlich begrenztes Unterfangen zur Schaffung eines einzigartigen Produkts, einer Dienstleistung oder eines Ergebnisses auffassen, dann spricht nichts gegen die Verwendung von Scrum zur Durchführung eines Projekts.
Mit dieser Definition kann jeder Sprint sogar als ein kurzes Projekt betrachtet werden.
Mythos #3: In Scrum ist ein Sprint-Ziel optional
Ohne ein Ziel kann es auch kein Team geben.
Das Sprint-Ziel ist das einzige Ziel, welches ein Scrum Team während eines Sprints verfolgt. Aus einer Gruppe von Experten, die zusammenarbeiten, wird erst ein Team, wenn sie ein gemeinsames Ziel verfolgen. Das Sprint-Ziel hilft den Teammitgliedern bei ihrer täglichen Arbeit, sich auf das Wesentliche zu fokussieren: Wert für den Nutzer zu schaffen.
Da das Scrum Team der zentrale Bestandteil von Scrum ist, kann somit das Sprint-Ziel niemals optional sein.
Mythos #4: Das Product Backlog wird ausschließlich vom Product Owner gepflegt
Der Product Owner ist für das Product-Backlog-Management verantwortlich.
Ein Product Owner entwickelt und kommuniziert das Produkt-Ziel. Er erstellt klar formulierte Produkt-Backlog-Einträge und kommuniziert diese dem Scrum Team. Ein Product Owner legt die Reihenfolge der Einträge im Product Backlog fest und stellt sicher, dass das Product Backlog transparent, sichtbar und von jedem verstanden ist.
Allerdings bedeutet dies nicht, dass er diese Tätigkeiten selbst ausführen muss; er ist lediglich für sie verantwortlich. Die Umsetzung kann er jederzeit an andere Personen delegieren.
Mythos #5: Refinement ist eine Pflichtveranstaltung für das gesamte Scrum Team
Tatsache ist, dass das Refinement des Product Backlogs essenziell ist, aber dabei muss nicht das ganze Team anwesend sein.
Refinement-Aktivitäten, wie die Product-Backlog-Einträge zu detaillieren, zu beschreiben, mit einer Größe zu versehen, kleiner zu schneiden und im Backlog einzuordnen, hilft dem Scrum Team den Product Backlog transparent zu machen. Product-Backlog-Einträge sind dann vollständig verstanden, wenn die Entwickler zuversichtlich sind, diese innerhalb eines Sprints fertigstellen zu können. Dieses Verständnis ist essenziell für den Erfolg eines Scrum Teams, aber dafür muss nicht immer jedes Teammitglied im Refinement anwesend sein. Manchmal kann es auch genügen, Refinement nur mit ausgewählten Entwicklern durchzuführen und nur die Ergebnisse mit dem Rest des Teams zu teilen.
Refinement ist kein weiteres verpflichtendes Meeting für alle Mitglieder im Scrum Team, sondern der fortlaufende Prozess, das Product Backlog transparent zu machen.
Mythos #6: Der Scrum Master kann keine Leute aus dem Scrum Team entfernen
Scrum Master sind echte Führungskräfte, die ihrem Scrum Team und der Organisation dienen.
Sie tun dies, indem sie Hindernisse beseitigen, die dem Fortschritt des Scrum Teams im Weg stehen. Menschen sollten niemals als Hindernisse bezeichnet werden. Was jedoch zum Hindernis bei der Erreichung des Sprint Ziels werden kann, sind die Interaktionen und Dynamiken zwischen den Personen. Nur in Ausnahmefällen, wenn die Konflikte zwischen den Personen nicht anders gelöst werden können, ist es eine Option, jemanden aus dem Team zu entfernen.
Jemand aus dem Team zu entlassen ist eine unglaublich schwierige Entscheidung und es sollte auf jeden Fall das Management mit einbezogen werden.
Mythos #7: Nur der Product Owner interagiert mit Stakeholdern
Zur Bewertung, was wertvoll ist, stützt sich ein Product Owner auf das Feedback der Stakeholder.
Aber nirgendwo im Scrum Guide steht, dass der Product Owner die einzige Person ist, die für die Kommunikation mit den Stakeholdern verantwortlich ist. Im Gegenteil: Der Scrum Guide schreibt, dass das Scrum Team für die Umsetzung aller produktbezogenen Aktivitäten verantwortlich ist und führt dabei explizit die Zusammenarbeit mit den Stakeholdern auf. Das Lösen adaptiver, komplexer Probleme erfordert eine Kombination aus Entdeckung, Entwicklung und Bereitstellung.
Das Scrum-Rahmenwerk fördert kollaborative Entdeckung.
Mythos #8: Das Sprint Review ist eine Demo
Das Sprint Review ist weder eine Demonstration noch einer Präsentation.
Der Scrum Guide ist hier eindeutig: Das Sprint Review ist ein Arbeitstermin, und das Scrum Team sollte vermeiden, es auf eine Präsentation zu beschränken. Scrum fußt auf der Empirie. Der Schleife aus Transparenz, Überprüfung und Anpassung. Nur wenn das Scrum Team und die Stakeholder die Ergebnisse des Sprints gemeinsam überprüfen, stellen sie wirklich Transparenz über den aktuellen Zustand des Produkts her. Basierend darauf kann das Product-Backlog angepasst und die Empirie-Schleife geschlossen werden.
Nur wenn im Sprint Review die Empirie zum Leben erweckt wird, kann mit Scrum das Risiko effektiv kontrolliert werden.
Mythos #9: In Scrum verbringen wir zu viel Zeit in Meetings
Hand aufs Herz, wie viel Zeit kosten die Events in Scrum wirklich?
Für ein Vollzeit-Mitglied im Scrum Team genau 22,5 %. Ein vierwöchiger Sprint umfasst 160 Arbeitsstunden. Das Sprint Planning von 8 Stunden, Daily Scrum von täglich 15 Minuten, Sprint Review von 4 Stunden und Sprint Retrospektive von 3 Stunden zusammengerechnet sind 20 Stunden. Setzten wir noch 16 Stunden Backlog Refinement an, dann verbringt ein Teammitglied nicht mehr als 22,5 % der Arbeitszeit mit den Scrum Events.
Beim Rechnen sollten wir nicht vergessen, dass der Zweck der Scrum Events darin besteht, eine klare Kadenz, einen Rhythmus und Fokus zu ermöglichen, um unnötiges Task-Switching zu verhindern und Zusammenarbeit zu fördern.
Mythos #10: Story Points sind in Scrum erforderlich
Nur weil viele Scrum Teams mit Story Points arbeiten, sind sie nicht verpflichtend in Scrum zu verwenden.
Der Scrum Guide schreibt nicht, welche Größenskala Teams für die Beschreibung der Größe der Product-Backlog-Einträge verwenden müssen. Es gibt viele Möglichkeiten wie T-Shirt-Größe, Gummibären oder Stunden. Story Points sind nur eine weitere Möglichkeit.
Letztendlich sollten wir bei der Diskussion um Story Points nie vergessen, warum Scrum Teams ihre Arbeit schätzen. Sie schätzen, um ein gemeinsames Verständnis für Arbeit herzustellen.
Mythos #11: Der Scrum Master ist ein Junior Agile Coach
Hast du schon mal darüber nachgedacht, deine Berufsbezeichnung auf "Agile Coach" zu ändern, damit du ein höheres Gehalt bekommst?
Leider ist das die Realität in vielen Unternehmen und der Mythos, dass der Scrum Master nur ein Junior Agile Coach ist, hält sich weiterhin hartnäckig. Und mit ihm der Glaube, dass sich ein agiler Coach um die größeren organisatorischen Umstrukturierungen kümmert und ein Scrum Master nur um ein Scrum Team. Im Scrum Guide deutet nichts auf diese Praxis hin, ganz im Gegenteil. Dort steht:
Der:die Scrum Master:in ist ergebnisverantwortlich für die Einführung von Scrum, wie es im Scrum Guide definiert ist. Er:sie tut dies, indem er:sie allen dabei hilft, die Scrum‐Theorie und ‐Praxis zu verstehen, sowohl innerhalb des Scrum Teams als auch in der Organisation.
Wird der Scrum Master in einem Unternehmen nur als Junior Agile Coach gesehen, dann ist dies eines von vielen Hindernisse, die ein Scrum Master beseitigen muss. Scrum kann nur seine volle Wirkung entfalten, wenn Scrum Master auch Hindernisse außerhalb des Teams beseitigen.
Mythos #12: Der Scrum Master muss jedes Problem lösen
Nicht alles in Scrum ist ein Hindernis.
Besprechungstermine erstellen, Wi-Fi Router reparieren und altes Geschirr abspülen sind keine Hindernisse für Scrum Teams. In Scrum bezeichnen wir Probleme als Hindernisse, wenn sie die Entwickler davon abhalten, das Sprint-Ziel zu erreichen und die sie selbst nicht lösen können. Erfolgreiche Scrum Master helfen dem Scrum Team, ihre Problemlösungsfähigkeit zu verbessern, um immer mehr Probleme selbstständig zu lösen. Sie tun dies, indem sie die Probleme transparent machen und dem Team die Möglichkeit geben, diese zu beseitigen. Dadurch fördern sie langfristig das Selbstmanagement des Teams.
Langfristig sollte der Scrum Master als Rettungsanker für das Team fungieren, an den es sich wenden kann, wenn sie selber nicht mehr weiterkommen.
Mythos #13: In Scrum wird das Product Backlog nach Prioritäten geordnet
Wenn das Product Backlog nur priorisiert ist, kann alles gleich wichtig priorisiert werden. Wenn allerdings alles gleich wichtig ist, dann ist nichts mehr wichtig.
Mit der Fokussierung auf "geordnet" statt nur "priorisiert" unterstreicht der Scrum Guide eindrucksvoll die Notwendigkeit eines Product Owners. Geordnet bedeutet, dass es nur genau einen wichtigsten Eintrag gibt. Ein geordnetes Product Backlog drückt die Reihenfolge der Lieferung der Einträge aus und damit, wie im Laufe der Zeit Wert geschaffen wird. Für diese Aufgabe übernimmt der Product Owner die Verantwortung.
Nur wenn das Product Backlog (neu)geordnet wird, falls neue Erkenntnisse gewonnen werden, wird der Wert der Arbeit des Scrum Teams maximiert.
Mythos #14: In Scrum muss das Product Backlog aus User Stories bestehen
User Stories sind weder ein Bestandteil von Scrum noch für effektives Product-Backlog-Management notwendig.
Das Product Backlog ist eine emergente, geordnete Liste der Dinge, die das Produkt in Zukunft enthalten soll. Kurz gesagt, es werden alle Arbeiten aufgeführt, die für das Produkt, aus aktueller Sicht, als notwendig erachtet werden. Wie die Arbeiten festgehalten werden, kann jedes Scrum Team eigenständig bestimmen. User Stories sind eine gute Möglichkeit, da sie den Fokus weg von der technischen Lösung hin zum Nutzer und dessen Problem legen.
Das Product Backlog sollte als Ganzes verständlich sein und zusammen mit dem Product-Ziel dem Scrum Team und dessen Stakeholdern die Richtung weisen. Die einzelnen Einträge stellen dabei eine Einladung zur Diskussion dar, dieses Verständnis herzustellen.
Mythos #15: In Scrum werden neue Features erst am Ende des Sprints geliefert
Ist Kanban oder DevOps besser als Scrum, da man da jederzeit releasen kann?
Aussagen wie diese sind ein Anzeichen dafür, dass das Scrum-Rahmenwerk wichtiger genommen wird als der Zweck des Rahmenwerks. Scrum in einem Wort: Done. Das Scrum-Rahmenwerk definiert den Sprint als die minimale Grenze dafür, wann ein "Done"-Inkrement spätestens lieferbereit sein muss. Natürlich können innerhalb eines Sprints auch mehrere Inkremente erstellt und geliefert werden.
Tatsächlich würde das die Scrum-Implementierung sogar verbessern, da der beste Weg, um den Wert des Produkts zu maximieren , darin besteht, frühzeitig Feedback zu bekommen.
Mythos #16: Das Sprint Backlog kann sich während des Sprints nicht ändern
Diese Sichtweise des Sprint Backlog ist nicht mehr zeitgemäß.
Sie berücksichtigt die Natur komplexer Arbeit nicht. Selbst bei einem Sprint von nur einer Woche wird sich das Verständnis der zu erledigenden Arbeiten, die nötig sind, um das Sprint-Ziel zu erreichen, im Laufe der Tage verfeinern und verändern. Darüber hinaus können auch immer noch unvorhergesehene Dinge auftreten, wie Krankwerden von Teammitgliedern oder das Zurückwerfen des Teams durch Infrastrukturprobleme. Auf diese Dinge muss das Scrum Team reagieren und sie entsprechen in ihren Sprint Backlog aufnehmen.
Zusammenfassend können wir sagen, dass ein Sprint Backlog flexibel ist, solange die Änderungen nicht die Erreichung des Sprint-Ziels gefährden.
Mythos #17: Der Scrum Master muss während des Daily Scrums anwesend sein
Kann die Anwesenheit des Scrum Masters beim Daily Scrum zum Hindernis zu mehr Selbstmanagement werden?
Selbstmanagement bedeutet auch, dass die Entwickler des Scrum Teams sich eigenständig jeden Tag zu einem 15-minütigen Event treffen, um den Fortschritt bei der Erreichung des Sprint-Ziels zu überprüfen. Der Scrum Master dient dem Scrum Team, indem er den Entwicklern hilft, dieses Event produktiv zu Gestalten. Dazu kann der Scrum Master selber am Daily Scrum teilnehmen, was aber vom Scrum Guide nicht verlangt wird. Scrum Master müssen bei ihrer Teilnahme am Daily Scrum immer sehr genau bewerten, ob sie dadurch das Team unterstützen oder doch im Selbstmanagement behindern.
Scrum Master sollten bei ihrer Arbeit nie vergessen, dass es darum geht, Selbstmanagement zu fördern.
Möchtest Du mehr erfahren?
Hoffentlich war dieser Artikel nützlich für Dich. Die Scrum Mythen, sind eines der vielen interessanten Themen, die in meinen Professional Scrum Trainings behandelt werden.
Wenn du keinen neuen Beitrag mehr verpassen willst, dann abonniere meinen Newsletter, dort wirst du als Erster über neue Beiträge informiert.
👉 Hier geht zur Anmeldung.