Kennst du den Scrum Guide wirklich?
Halbwissen ist gefährlich. Es führt zu Fehlinterpretationen.
Hier stelle ich 9 gängige Fehlinterpretationen vor, damit dir niemand vorwerfen kann, dass du den Guide nicht verstanden hättest.
Fehlinterpretation #1: Im Sprint Planning dürfen keine Stakeholder anwesend sein
Vier Produktmanager streiten sich mit dem Product Owner im Sprint Planning über die Reihenfolge des Product Backlogs.
Dürfen Produktmanager bei der Sprint-Planung anwesend sein? Wenn ich diese Situation den Teilnehmern im Professional-Scrum-Master-Training präsentiere, lautet ihre Antwort immer, dass Stakeholder nur im Sprint Review anwesend sein dürfen. Das ist nicht korrekt und der Scrum Guide schreibt dazu:
„Das Scrum Team kann zu Beratungszwecken auch andere Personen zur Teilnahme am Sprint Planning einladen.“
Natürlich sind Stakeholder nicht gleich Stakeholder. Für vier Produktmanager, die die Reihenfolge des Product Backlogs infrage stellen, ist kein Platz, wenn der Sprint geplant wird. Muss unser Team aber in diesem Sprint eng mit einem anderen Team zusammenarbeiten, kann es hilfreich sein, die Entwickler des anderen Teams von Anfang an dazuzuholen und die enge Abstimmung zwischen den beiden Teams zu planen.
Fehlinterpretation #2: Das Sprint-Ziel ist nur für das Scrum Team sichtbar
Das Sprint-Ziel beschreibt die entstehende Arbeit im Sprint auf übergeordneter Ebene.
Es beschreibt, warum das Scrum Team diesen Sprint vornimmt und warum der Sprint für die Stakeholder wertvoll ist. Kunden und Stakeholder empfangen diese Arbeit bis zum Ende des Sprints durch die Bereitstellung eines oder mehrerer Inkremente des Produkts. Der Scrum Guide hält Folgendes fest:
„Der sich entwickelnde Prozess und die entstehende Arbeit müssen sowohl für diejenigen sichtbar sein, die die Arbeit ausführen, als auch für diejenigen, die die Arbeit empfangen.“
Aus Sicht des Scrum Guides spricht nichts dagegen, dass das Sprint-Ziel nach dem Sprint Planning bereits mit den Stakeholdern geteilt wird.
Fehlinterpretation #3: Nur Softwareentwickler sind Entwickler in Scrum
Im Scrum Guide wird von Entwicklern gesprochen, nicht, um Personen auszuschließen, sondern um die Dinge zu vereinfachen:
„Developer:innen sind jene Personen im Scrum Team, die sich der Aufgabe verschrieben haben, jeden Sprint jeden Aspekt eines nutzbaren Increments zu schaffen.“
Das schließt UX-Professionals, Marketers, Tester und Analysten mit ein. Aus der Perspektive von Scrum sind dies alles Entwickler. Sie sind Bestandteil des Scrum Teams, wenn sie nötig sind, um eine nutzbare Version des Produkts zu liefern.
Fehlinterpretation #4: Scrum funktioniert nicht mit Projekten oder Schätzungen in Arbeitstagen
Scrum ist kein Prozess, sondern:
„Scrum umhüllt bestehende Praktiken oder macht sie überflüssig. Scrum macht die relative Wirksamkeit des aktuellen Managements, der Umgebung und der Arbeitstechniken sichtbar, sodass Verbesserungen vorgenommen werden können.“
Scrum ist wie ein Spiegel.
Es funktioniert dann, wenn Verbesserungspotenziale sichtbar gemacht werden. Als Rahmenwerk hilft es, bestehende Prozesse und Methoden regelmäßig auf ihre Effektivität hin zu überprüfen. Dies schließt die aktuell vorherrschende Projektstruktur oder das Vorgehen, wie Aufwände abgeschätzt werden, mit ein.
Fehlinterpretation #5: Scrum funktioniert nicht mit großen Projekten, da ein Product Owner allein einen Backlog nicht managen kann
Produkt-Backlog-Management ist zeitaufwendig.
Die Definition und Kommunikation von Zielen, die Erstellung und Schaffung eines Verständnisses für Product-Backlog-Einträge, die Bestimmung der Reihenfolge der Einträge im Product Backlog und vieles mehr kann bei einem großen Produkt, an dem unter Umständen auch viele Teams arbeiten, viel Zeit in Anspruch nehmen.
Dies ist den Erstellern des Scrum Guides bewusst und deshalb trennt der Scrum Guide auch zwischen Verantwortung und Umsetzung:
„Der:die Product Owner:in kann die oben genannten Arbeiten selbst durchführen oder die Umsetzungsverantwortung an andere delegieren.“
Deshalb funktioniert Scrum auch mit großen Projekten, aber die Art und Weise, wie der Product Owner seine Arbeit erledigt, unterscheidet sich dann natürlich von der Entwicklung kleinerer Produkte.
Fehlinterpretation #6: Entdeckungsarbeit kann nicht im Scrum Team durchgeführt werden, da sie nicht die Definition of Done erfüllt
Muss jeder Eintrag, der sich im Product Backlog befindet, auch fertiggestellt werden?
Wenn mit fertiggestellt gemeint ist, dass der Eintrag die Definition of Done erfüllt, dann lautet die Antwort „Nein“. Die Definition of Done bezieht sich nicht auf den Product Backlog, sondern auf das Inkrement: „Arbeit kann nicht als Teil eines Inkrements betrachtet werden, solange sie nicht der Definition of Done entspricht.“ Das bedeutet aber nicht, dass das Scrum Team nicht auch Arbeiten verrichten kann, die nicht Bestandteil eines Inkrements sein werden.
Ein prominentes Beispiel hierfür ist Entdeckungsarbeit in Form von User Research.
Fehlinterpretation #7: Verbesserungen können nur in der Sprint-Retrospektive umgesetzt werden
Scrum ist ein leichtgewichtiges Rahmenwerk. Es werden nur Elemente vorgeschrieben, die minimal nötig sind, um empirisches Arbeiten zu ermöglichen.
Die Sprint-Retrospektive beschreibt nur die minimale Notwendigkeit, den aktuellen Arbeitsprozess zu hinterfragen, nach Verbesserungsmöglichkeiten Ausschau zu halten und diese umzusetzen. Der Scrum Guide schreibt sogar vor, dass von einem Team häufige Verbesserungen erwartet werden:
„Von einem Scrum Team wird erwartet, dass es sich in dem Moment anpasst, in dem es durch Überprüfung etwas Neues lernt.“
Fehlinterpretation #8: Ein Release kann nur am Ende des Sprints gemacht werden
Angenommen, es wird ein kritischer Fehler in der Anwendung entdeckt – sollte ein Scrum Team dann wirklich das Sprint Review abwarten, um den Fehler zu beheben?
Natürlich nicht. Deshalb schreibt der Scrum Guide auch:
„Ein Inkrement könnte jedoch auch schon vor Ende des Sprints an die Stakeholder:innen geliefert werden. Das Sprint Review sollte niemals als Barriere zur Lieferung von Wert angesehen werden.“
Fehlinterpretation #9: Wenn mehrere Scrum Teams ein Produkt entwickeln, darf es nur einen Product Owner geben
Ein Produkt, ein Product Owner – so lautet die Regel bei einem Scrum Team.
Ändert sich dies, wenn mehrere Scrum Teams an einem Produkt arbeiten?
Hierzu schreibt der Scrum Guide: „Wenn Scrum Teams zu groß werden, sollten sie in Erwägung ziehen, sich in mehrere zusammengehörende Scrum Teams zu reorganisieren, die sich alle auf dasselbe Produkt konzentrieren. Daher sollten sie sich Produkt‐Ziel, Product Backlog und Product Owner:in teilen.“
Das kleine, aber entscheidende Wort lautet hier „sollten“ und nicht „müssen“. Das bedeutet: Wenn mehrere Scrum Teams an einem Produkt-Ziel mit einem Product Backlog arbeiten, kann es sinnvoll sein, dass sie sich mehr als einen Product Owner teilen.
Die Regel „ein Produkt, ein Product Owner“ ist für mehrere Scrum Teams eher als Empfehlung zu interpretieren. Sie soll uns einen Anhaltspunkt geben, wie wir Scrum effektiv skalieren können.