Versteh mich nicht falsch: Die aktuelle Version des Scrum Guides ist die beste.
Die Einführung des Produkt-Ziels, die Reduzierung auf ein einziges Team, das Einbeziehen von Commitments in die Artefakte, die Verwendung des Begriffs „Verantwortungen“ anstelle von „Rollen“ und die Betonung des Sprint-Ziels bei der Sprintplanung bieten eine leicht verständliche Anleitung, um komplexe Probleme adaptiv zu lösen und Wert zu generieren.
Allerdings wäre ich kein Scrum Master, wenn ich mich damit zufriedengeben würde. Ein Scrum Master treibt Verbesserungen voran, vereinfacht und erfindet Neues. Als echter Scrum Master sollten wir auch nicht vor dem Scrum Guide haltmachen!
Hier sind meine vier wichtigsten Vorschläge zur Verbesserung des Scrum Guides:
Verbesserung 1: Refinement auf 10 % der Sprintdauer begrenzen
Es ist frustrierend, wenn das Team eine User Story im Sprint nicht abschließen kann.
In solchen Situationen höre ich immer wieder denselben Rat, sogar von erfahrenen agilen Coaches: „Das Scrum Team sollte mehr Zeit in das Refinement des Product Backlogs investieren.“
Dieser Rat ist gefährlich!
Denn mehr Refinement, also mehr Analyse, mehr Beschreibung und eine genauere Abschätzung des Arbeitsumfangs, bietet niemals eine absolute Garantie dafür, dass das Team die Arbeit auch innerhalb eines Sprints erledigen kann. Letztlich kommt der Zeitpunkt, an dem das Team die Unsicherheit akzeptieren und bereit sein muss, mit der Arbeit zu beginnen. Einige Teams beginnen möglicherweise zu früh mit der Entwicklungsarbeit, aber die meisten Teams eher zu spät. Ein typisches Anzeichen für eine solche Arbeitsweise im Team ist eine Definition of Ready, die detailliert beschreibt, welche Informationen bekannt sein müssen, bevor die Entwicklung beginnen kann.
Zum Beispiel:
- Der Product-Backlog-Eintrag muss als User Story formuliert sein.
- Alle Akzeptanzkriterien müssen definiert sein.
- Ein UI-Design-Mock-up muss vorhanden sein.
- Ein Testkonzept muss ausgearbeitet sein.
- Ansprechpartner auf der Business-Seite müssen identifiziert sein.
- Nutzer oder Stakeholder für den UAT müssen bestimmt sein.
- Die User Story muss in Story Points abgeschätzt worden sein und kleiner als 21 Punkte sein.
Als Scrum Master ist es unsere Aufgabe, dem Team dabei zu helfen, den richtigen Zeitpunkt für den Arbeitsbeginn zu finden. Der Scrum Guide kann uns diese Aufgabe nicht abnehmen, aber er kann uns eine Empfehlung geben. So wie er es bereits im Jahr 2017 getan hat:
„[Refinement-Aktivitäten] sollten normalerweise nicht mehr als 10 % der Kapazität des Development Teams in Anspruch nehmen.“
Ich wünsche mir diese Empfehlung zurück. Sie hilft unerfahrenen Scrum Mastern zu verstehen, dass mehr Analyse, mehr Dokumentation und mehr Planung bei komplexer Arbeit niemals das Risiko minimieren können. Nur durch den Arbeitsbeginn können zuverlässig alle Unwägbarkeiten erkannt werden.
Verbesserung 2: Das Wort „Meeting“ in „Workshop“ ändern
Sind Scrum Events Meetings?
Die meiste Zeit spricht der Scrum Guide von Events und das ist gut so. Diese abstrakte Bezeichnung lässt Raum für Interpretationen darüber, wie das Event durchgeführt werden kann, beispielsweise, ob alle Teilnehmer in einem Raum versammelt sein müssen oder ob es asynchron online stattfinden kann.
Allerdings weicht der Scrum Guide 2020 an einer Stelle vom abstrakten Begriff „Event“ ab und setzt diesen mit einem Meeting gleich:
„Wenn ein Event nicht wie vorgeschrieben durchgeführt wird, verpasst man die Gelegenheit, zu überprüfen und anzupassen. Events werden in Scrum verwendet, um Regelmäßigkeit zu schaffen und die Notwendigkeit von Meetings, die in Scrum nicht definiert sind, zu minimieren.“
Aus meiner Sicht ist das eine verpasste Gelegenheit, sich von der Meeting-Kultur in vielen Unternehmen zu distanzieren.
Was meine ich damit? In den meisten Unternehmen werden Meetings nur für den Austausch von Informationen, die Koordination von Arbeit oder Entscheidungsfindungen verwendet, aber die eigentliche Zusammenarbeit steht selten im Vordergrund. Dabei sollte es doch eigentlich genau darum gehen. Für mich bedeutet ein Unternehmen, dass die Mitarbeiter zusammenkommen, um gemeinsam an der Erreichung der Unternehmensziele zu arbeiten. Die Zusammenarbeit sollte im Zentrum des Unternehmens stehen und sie steht auch im Zentrum von Scrum. Scrum definiert ein Team, das gemeinsam an der Erreichung eines Ziels arbeitet: dem Produkt-Ziel.
Um diese Zusammenarbeit noch stärker in den Mittelpunkt von Scrum zu rücken, würde ich mir wünschen, dass in der nächsten Version des Scrum Guides nicht mehr von Scrum Events, sondern von Scrum Workshops die Rede ist. In Workshops werden gemeinsam Probleme gelöst und konkrete Ergebnisse erzielt. Das drückt den Zweck der Scrum Events meiner Meinung nach besser aus.
Wenn du wissen möchtest, wie du bereits jetzt die Scrum Meetings als Workshops gestalten kannst, dann wirf einen Blick auf diesen Artikel.
Verbesserung 3: Die Verbesserung aus der Sprint Retrospektive ist Bestandteil des Sprint Backlogs
Hast du dich schon einmal gefragt, ob Retrospektiven-Verbesserungen Bestandteil des nächsten Sprints sein müssen?
Bevor ich dir diese Frage beantworte, lass uns zunächst eine grundsätzliche Frage klären: Warum funktioniert Scrum eigentlich?
Der Erfolg von Scrum beruht auf zwei Elementen: Feedbackschleifen und Minimalismus.
Widmen wir uns dem ersten Element: Im Kern ist das Scrum Framework eine geschickte Abfolge von Feedbackschleifen. Feedback in Scrum bedeutet, dass das Team Informationen erhält, die auf seine Handlungen reagieren. Dadurch ermöglichen Feedbackschleifen den Scrum Teams, fundierte Entscheidungen zu treffen und das Risiko von Fehlentscheidungen zu reduzieren.
Das zweite Element ist Minimalismus.
Im Scrum Guide 2020 ist die Rede von einem „minimal ausreichenden Framework“. Dieser Minimalismus gewährleistet Anpassungsfähigkeit. Je weniger Techniken, Praktiken, Regeln, Prinzipien und Empfehlungen der Scrum Guide vorgibt, desto einfacher können Teams ihre Prozesse ändern oder anpassen, wenn sich ihre Umgebung oder die Rahmenbedingungen ändern, in denen sie agieren. Minimalismus bedeutet jedoch auch, dass, wenn wir ein Element des Scrum Frameworks weglassen, Scrum nicht mehr als Instrument zur Risikokontrolle funktioniert. Das Weglassen eines Elements würde eine Feedbackschleife zerstören.
Die wichtigsten Feedbackschleifen in Scrum sind:
- Das Feedback, das zu Produktverbesserungen führt.
- Das Feedback, das zu Prozessverbesserungen führt.
Nun, da du weißt, wie Scrum funktioniert, können wir uns der ursprünglichen Frage widmen: Müssen Retrospektiven Bestandteil des nächsten Sprints sein?
Mit deinem Wissen über Feedbackschleifen wirst du die Frage sicherlich mit einem klaren „Ja“ beantworten. Wenn du das tust, wird dich die folgende Aussage des Scrum Guides 2020 wahrscheinlich genauso verwundern wie mich:
„Das Scrum Team identifiziert die hilfreichsten Änderungen, um seine Effektivität zu verbessern. Die wirkungsvollsten Verbesserungen werden so schnell wie möglich in Angriff genommen. Sie können sogar in das Sprint Backlog für den nächsten Sprint aufgenommen werden.“
Ich würde mir wünschen, dass der Scrum Guide betont, dass Änderungen im nächsten Sprint umgesetzt werden sollten, und der folgende Satz zu einer Regel wird: „Sie können sogar in das Sprint Backlog für den nächsten Sprint aufgenommen werden.“ Dies würde Scrum Anwendern helfen, die Wichtigkeit von zeitnahem Feedback besser zu verstehen. Mir ist vollkommen klar, dass nicht jede Verbesserung immer sofort angegangen werden kann und dass der Satz deshalb nicht als Regel formuliert wurde. Ich weiß auch, dass nicht jede Prozessverbesserung zusätzliche Arbeit für das Scrum Team bedeuten muss. Eine Retrospektive kann auch die Verbesserung der Definition of Done oder die Klärung eines schwelenden Konflikts im Team bedeuten. Ich verstehe auch, dass erfahrene Scrum Teams bereits erkannt haben, wie wichtig die Transparenz ihrer Retrospektivenverbesserungen ist, damit sie den Fortschritt bei der Umsetzung überprüfen und anpassen können.
Allerdings handelt es sich beim Scrum Guide um eine Anleitung, wie mit Scrum gearbeitet wird. Sie richtet sich vornehmlich an unerfahrene Scrum Teams.
Deshalb würde ich mir einen Satz wie diesen aus dem Scrum Guide 2017 im Abschnitt der Sprint Retrospektive zurückwünschen:
„Die Umsetzung dieser Verbesserungen im nächsten Sprint ist die Anpassungsleistung zur Selbstüberprüfung des Scrum Teams.“
Verbesserung 4: Nun bist du an der Reihe.
Wenn du Scrum Master bist und deine Verantwortung erst nimmst, dann sucht du immer auch den Weg Scrum zu verbessern. Dieser Drang sollte auch nicht vor dem Scrum Guide halt machen!
Welche Verbesserungen würdest du am Scrum Guide vornehmen?
Schreibe es in die Kommentare, damit wir uns darüber austauschen können.
Ich freue mich, von dir zu lesen! Nun warte nicht mehr länger und haue in die Tasten …