Kommen wir gleich zum Punkt:
Du kannst dich nicht Scrum Master nennen, wenn du den Scrum Guide nicht kennst.
Der Scrum Guide ist wie die Straßenverkehrsordnung fürs Autofahren. Als Autofahrer kannst du nicht am Verkehr teilnehmen, wenn du die Verkehrsregeln nicht kennst und weißt, was sie bezwecken sollen. Und wenn du sie brichst, solltest du sehr gute Gründe haben.
Leider gibt es immer wieder Scrum Master, die zum „Professional Scrum Master 2“-Training erscheinen und noch nie den Scrum Guide in der Hand hatten. Dementsprechend fallen sie vielen Irrglauben, Halbwahrheiten und Mythen über Scrum zum Opfer. Und nirgendwo zeigt sich dies mehr als beim Verständnis des Sprint-Backlogs.
Hier sind 7 Mythen, die du als Scrum Master unbedingt kennen solltest. Am Ende findest du auch noch eine Checkliste, die dir hilft zu bewerten, welche der Mythen in deinem Unternehmen kursieren.
Beginnen wir mit dem ersten Mythos:
Mythos 1: Das Sprint-Backlog wird vom Scrum Master verwaltet.
Hier lässt sich Scrum Master auch durch Product-Owner, Teamleiter oder Projektmanager ersetzen.
Alle Varianten habe ich schon mehrfach erlebt. Alles ist nicht Scrum. In Scrum setzen wir auf Selbstmanagement. Wir glauben, wenn die Arbeit von den Personen gestaltet, verwaltet und geplant wird, die sie auch erledigen, übernehmen sie auch die Verantwortung für das Ergebnis ihrer Arbeit. Deshalb steht im Scrum Guide:
„Das Sprint-Backlog ist ein Plan von und für die Developer.“
Soll heißen: Das Sprint-Backlog wird von den Entwicklern verwaltet. Noch mal in anderen Worten: Die Entwickler bewegen die Einträge auf dem Sprint-Board.
Jeder andere: Finger weg.
Mythos 2: Das Sprint-Backlog besteht nur aus Tasks.
Dann gleicht das Sprint-Backlog nur einer To-do-Liste.
To-do-Listen können wir nutzen, um wiederkehrende, routinemäßige oder einfache Aufgaben zu erledigen. Die Entwicklung von Software im Team gehört nicht dazu. Deshalb ist das Sprint-Backlog weit mehr: „Das Sprint-Backlog besteht aus dem Sprint-Ziel (Wofür), den für den Sprint ausgewählten Product-Backlog-Einträgen (Was) sowie einem umsetzbaren Plan für die Lieferung des Increments (Wie).“ Laut dem Scrum Guide besteht es also aus drei Komponenten. Und „Tasks“ beschreiben, „wie“ eine neue Version des Produkts erstellt und geliefert werden soll. Sie stellen also nur einen Bestandteil des Sprint-Backlogs dar.
Hier ein Bild eines Sprint-Backlogs mit allen drei Komponenten zur Veranschaulichung:
Dieses Sprint-Backlog enthält Tasks, User-Stories und alle Arbeiten, die notwendig sind, um das Sprint-Ziel zu erreichen.
Mythos 3: Das Sprint-Backlog muss zu Beginn des Sprints vollständig sein.
Hier verstecken sich gleich zwei Fehler in einem.
- Der Sprint beginnt nicht nach dem Sprint-Planning.
- Das Sprint-Backlog ist niemals vollständig.
Ein Sprint ist nur ein Zeitraum. Er beginnt, wenn der letzte Tag des letzten Sprint abgelaufen ist. Und nicht, wenn die Planung des Sprints vorgenommen wurde (auch wenn Jira uns das weismachen will). Als Scrum Master können wir getrost das Wort „vollständig“ aus unserem Sprachgebrauch streichen. Das Einsatzgebiet von Scrum sind gerade die Situationen, die sich nicht vollständig beschreiben, erklären oder vorhersagen lassen. Die Arbeit der Softwareentwicklung lässt sich niemals vollständig beschreiben. Somit auch nicht das Sprint-Backlog. Was wir aber brauchen, ist ein gemeinsames Ziel, damit wir mit dem Entwickeln anfangen können und nicht jeder im Team in eine andere Richtung rennt.
Deshalb schreibt der Scrum Guide auch:
„Das Sprint-Ziel muss vor dem Ende des Sprint-Plannings finalisiert sein.“ Und: „Das Sprint-Backlog wird während des Sprints laufend aktualisiert.“
Mythos 4: Das Sprint-Backlog dient dazu, die Leistung von Einzelpersonen zu verfolgen.
Es beginnt damit, dass Aufgaben Einzelnen in Jira zugewiesen werden, dann wird die Anzahl der Storypoints pro Entwickler erfasst und zum Schluss die Leistung des Entwicklers an der Anzahl der Storypoints pro Monat gemessen.
Diese Praktik klingt nach Fabrikarbeit im 19. Jahrhundert, ist aber leider noch in vielen Köpfen verbreitet. Im 21. Jahrhundert, in dem Kreativarbeit dominiert, sollten wir es besser wissen und damit aufhören.
Scrum ist ein Teamsport. Mit allen Konsequenzen. Ein Team gewinnt nicht, wenn ein Stürmer zwar 3 Tore schießt, die gegnerische Mannschaft allerdings 4. Die Leistung der Einzelnen ist die Leistung des Teams. Der Scrum Guide will uns daran erinnern:
„Das Sprint-Backlog dient den Entwicklern dazu, ihren eigenen Fortschritt in Bezug auf das Sprint-Ziel zu verfolgen.“
Beachte hier, dass „Entwicklern“ im Plural steht. Und damit ist Teamsport gemeint.
Mythos 5: Das Sprint-Backlog muss nicht sichtbar sein.
Worauf beruht der Erfolg von Scrum?
Der Erfolg beruht auf der Fähigkeit, die wichtigsten Aspekte des Prozesses transparent zu machen. Hierzu zählen der Nutzen für den Kunden, die Qualität des Produkts und die Zusammenarbeit im Team. Je transparenter diese Aspekte sind, desto besser funktioniert Scrum. Da der Erfolg von Scrum nicht dem Zufall überlassen werden soll, gibt es auch die Verantwortlichkeiten. Mindestens eine Person im Team kümmert sich darum, dass diesem Aspekt Beachtung geschenkt wird. Der Fortschritt bei der Entwicklung und die Zusammenarbeit im Team werden mit dem Sprint-Backlog transparent gemacht:
„Es ist ein deutlich sichtbares Echtzeitbild der Arbeit, welche die Developer während des Sprints zur Erreichung des Sprint-Ziels ausführen wollen. Folglich wird das Sprint-Backlog während des gesamten Sprints immer dann aktualisiert, wenn mehr gelernt wurde.“
Damit schafft das Sprint-Backlog Möglichkeiten für das Team, Verbesserungen in der Zusammenarbeit, Entwicklung des Produkts und Erreichung des Sprint-Ziels zu erkennen. Dazu muss das Sprint-Backlog sichtbar sein.
Der Zweck des Sprint-Backlogs ist es, Transparenz zu schaffen.
Mythos 6: Das Sprint-Backlog ist ein Vertrag.
Dieser Irrglaube ist leider tief verwurzelt.
Um diesem Problem entgegenzuwirken, sprechen wir in Scrum von Commitment. Commitment heißt nicht Versprechen, sondern, dass sich jeder im Team dazu verpflichtet, sein Bestes zu geben.
Und diese Verpflichtung gilt dem Sprint-Ziel.
Nicht dem Weg, wie dieses erreicht werden soll. Da sich der Weg durchaus ändern kann, wenn das Team mehr über die Arbeit im Sprint lernt. Wenn dies der Fall ist, dann besprechen die Entwickler mit dem Product-Owner die Arbeit im Sprint erneut:
„Wenn sich herausstellt, dass die Arbeit von ihren Erwartungen abweicht, arbeiten sie mit dem Product-Owner zusammen, um den Umfang des Sprint-Backlogs innerhalb des Sprints zu verhandeln, ohne das Sprint-Ziel zu beeinflussen.“
Abschließend noch mal zurück zu Mythos 2. Ich möchte ihn erneut aus einem anderen Blickwinkel betrachten:
Mythos 7: Das Sprint-Backlog ist eine To-do-Liste.
„Das Sprint-Backlog sind die To-dos für die Entwickler.“
Diesen Satz höre ich häufig. Deshalb lohnt es sich, diesen Mythos noch mal separat zu betrachten. Lass uns dazu diese Frage beantworten:
Wie unterscheidet sich Koordination von Zusammenarbeit?
Koordination funktioniert nur, wenn vorab alle Informationen bekannt sind. Dass dies so gut wie nie der Fall ist, erkennst du daran, dass viele Teams, Projektpläne oder Sprint-Backlogs „etwas Luft lassen“. Es wird ein Puffer eingeplant. Die Einplanung eines zeitlichen Puffers für Unvorhergesehenes ist ein Eingeständnis, dass wir doch nicht alles vorab planen können. Entwickler werden krank, die Integrationstests flackern oder der Code muss doch erst refaktoriert werden, bevor neue Änderungen vorgenommen werden können.
Deshalb fußt Scrum auf Zusammenarbeit.
Zusammenarbeit unterscheidet sich von reiner Koordination dadurch, dass wir an einem Problem gemeinsam arbeiten. Wir lösen das Problem, welches sich als Nächstes vor uns auftut. Und das machen wir gemeinsam. Damit können wir auf die Koordination von Aufgaben eher verzichten. Das beste Beispiel, wie diese Zusammenarbeit aussieht, ist für mich Mod-Programming.
In diesem Video kannst du es live sehen.
Was fällt dir auf? Die Entwickler koordinieren nicht vorab ihre Arbeiten und führen dann alle To-dos getrennt aus. Stattdessen arbeiten die Entwickler gemeinsam an einer Sache, bis diese abgeschlossen ist. Oder in anderen Worten ausgedrückt: Sie koordinieren nicht ihre Arbeiten (To-do-Liste der Aufgaben), sondern ihre Zusammenarbeit (Driver-Navigator-Rotation.)
Das Sprint-Backlog ist dazu da, um zu dieser Zusammenarbeit einzuladen. Deshalb ist das zentrale Element des Sprint-Backlogs auch das Sprint-Ziel und nicht die Aufgaben. Dass es sich dabei um das wichtigste Element handelt, erkennst du auch daran, dass es im Sprint-Planning als erstes vom Team definiert wird.
Das Sprint-Backlog auf eine reine To-do-Liste zu reduzieren, reduziert es auf ein Werkzeug zur Koordination. Das ist ein Irrglaube.
Es ein Werkzeug zur Zusammenarbeit.
Wie versprochen: zum Abschluss noch die Checkliste. Nutze sie, um zu prüfen, welche Mythen noch in deinem Team kursieren.
Checkliste:
- Wird das Sprint-Backlog vom Scrum Master verwaltet?
- Besteht das Sprint-Backlog nur aus Tasks?
- Muss das Sprint-Backlog zu Beginn des Sprints vollständig sein?
- Dient das Sprint-Backlog dazu, die Leistung von Einzelpersonen zu verfolgen?
- Darf das Sprint-Backlog nicht einsehbar sein?
- Gleicht das Sprint-Backlog einem Vertrag?
- Ist das Sprint-Backlog eine To-do-Liste?
Je mehr Fragen du mit „Ja“ beantwortet, desto mehr Mythen kursieren noch in deinem Unternehmen.