„Scrum funktioniert bei uns nicht!“
So lautet häufig die Reaktion auf meine Arbeit als Scrum Master. Ich höre diesen Satz bestimmt bei jedem agilen Coaching, Training oder Workshop mindestens einmal. Bei genauerer Nachfrage höre ich immer wieder die gleichen Probleme. Meine Top 6 der „Scrum funktioniert bei uns nicht!“-Playlist lauten:
Problem 1: Keine Stakeholder beim Sprint Review
Wie sieht der erhoffte Mehrwert von Scrum aus?
Die richtige Antwort lautet: Wert für Kunden und Stakeholder liefern. Das Problem an dieser Antwort ist, dass nur die Kunden und Stakeholder bestimmen können, was wertvoll für sie ist. Das Scrum Team kann eine Vermutung haben, was Wert bedeutet. Aber sicher sein kann es erst, wenn Kunden und Stakeholder ihre Vorstellungen bestätigen. Damit das Scrum Team diesen Wert nicht aus den Augen verliert, gibt es das Sprint Review in Scrum.
„Das Scrum Team stellt die Ergebnisse seiner Arbeit den wichtigsten Stakeholdern vor, und die Fortschritte in Richtung des Produkt-Ziels werden diskutiert.“ – Scrum Guide, 2020
In diesem Event überprüft das Scrum Team seine Vermutungen. Ohne Stakeholder ist das offensichtlich nicht möglich. Das Ergebnis, wenn die Stakeholder fehlen: Das Team hat im Sprint Arbeit verrichtet, aber keinen Wert für die Stakeholder geschaffen.
Wenn du nach einer Anleitung suchst, wie du ein Sprint Review durchführst, zu dem auch die Stakeholder gerne erscheinen, dann empfehle ich dir diesen Artikel: „Wie moderierst du ein Sprint Review? 4 Fragen, die dich leiten können“.
Problem 2: Das Product Backlog wird im Sprint Review nicht angepasst
Das ist ein Anzeichen dafür, dass das Sprint Review kein Arbeitstermin ist, sondern eher einer Präsentation der Arbeitsergebnisse entspricht.
„Auf der Grundlage dieser Informationen arbeiten die Teilnehmenden gemeinsam daran, was als Nächstes zu tun ist. Auch kann das Product Backlog angepasst werden, um neue Möglichkeiten wahrzunehmen. Das Sprint Review ist ein Arbeitstermin und das Scrum Team sollte vermeiden, es auf eine Präsentation zu beschränken.“ – Scrum Guide, 2020
Der Gradmesser für den Erfolg eines Sprint Reviews ist, ob das Product Backlog angepasst wurde. Das Team hat die neue Version des Produkts vorgestellt, die Stakeholder haben sie ausprobiert und dabei sind wieder neue Ideen entstanden. Damit wir diesen Ideen im nächsten Sprint nachgehen können und damit die Stakeholder versichert sein können, dass wir sie gehört haben, halten wir die Idee im Product Backlog fest.
Eine Anpassung des Product Backlogs zeigt, dass im Sprint Review ein Lernprozess stattgefunden hat.
Wenn das Sprint Review deines Teams nur einer Präsentation der Arbeitsergebnisse gleicht, dann lies dir meinen Artikel „Sprint Review: Wie Product Owner aus einer Demo einen Arbeitstermin machen“ durch. Er enthält einige Anregungen, wie du dieses Problem beheben kannst.
Problem 3: Es werden keine Verbesserungen in der Sprint Retrospektive gefunden
Was ist der Zweck der Sprint Retrospektive?
Erstaunlicherweise glauben viele Scrum Master immer noch, dass es in der Sprint Retrospektive darum geht, die Arbeit im Team angenehmer zu gestalten. Dies mag ein Aspekt sein. Aber im Kern geht es nur darum:
„Der Zweck der Sprint Retrospektive ist es, Wege zur Steigerung von Qualität und Effektivität zu planen.“ – Scrum Guide, 2020
Und ohne einen Beschluss, was wir im nächsten Sprint verbessern wollen, ist der Zweck der Sprint Retrospektive nicht erfüllt. Verbesserungen können etwa eine neue Automatisierung, eine Verschärfung der Definition of Done oder die Konkretisierung von Working Agreements sein.
Wenn du nach einer Anleitung suchst, wie du eine Sprint Retrospektive facilitierst, in der sich jeder einbringen kann und die zu Verbesserungen führt, dann wirf gerne einen Blick auf mein neues Video: „German Edition Scrum Pulse: Effektive Facilitation der Scrum Events“.
Problem 4: Es wird kein Sprint-Ziel im Sprint Planning definiert
Womit beginnt das Sprint Planning eigentlich?
Der Scrum Guide gibt uns hier eine eindeutige Antwort:
„Thema Eins: Warum ist dieser Sprint wertvoll?“ – Scrum Guide, 2020
In Problem 1 haben wir bereits über den Unterschied zwischen Arbeit und Wert gesprochen. Um sicherzustellen, dass Scrum Teams dies im Hinterkopf behalten, empfiehlt der Scrum Guide als Thema Nummer 1 die Wertbetrachtung. Ein erfolgreiches Sprint Planning klärt vorrangig die Frage, warum dieser Sprint wertvoll für die Stakeholder und Kunden des Produkts ist. Erst wenn für diese Vermutung Klarheit herrscht, ergibt es Sinn, sich den nächsten Themen im Sprint Planning zuzuwenden!
Konkrete Tipps, wie du deinem Team helfen kannst, ein Sprint-Ziel zu finden, findest du in diesem Artikel: „Verzichtet dein Scrum Team auf Sprint-Ziele? 3 konkrete Tipps, wie du dies ändern kannst“.
Problem 5: Refinement findet nur im Sprint Planning statt
Komplexe Probleme können nicht analysiert, sondern nur entdeckt werden.
Deshalb gibt es in Scrum keine Entwurfsphase, Anforderungsanalyse oder Konzept-Sprints. Stattdessen widmen sich Scrum Teams der Entdeckung von Problemstellungen mit einer eigenen Aktivität, dem Product Backlog Refinement. Da jedes Produkt unterschiedlich ist, jedes Team anders und jedes Unternehmen einzigartig, gibt es keine generellen Empfehlungen, wie viel Zeit in die Entdeckung des Problems investiert werden sollte. Eine gute Daumenregel lautet nach wie vor: Scrum Teams sollten bis zu 10 % ihrer Zeit in die Entdeckung der Problemstellung und der nötigen Arbeit investieren.
Refinement nur im Sprint Planning durchzuführen erscheint mir zu wenig. Es sollte auch nicht mit dem dritten Thema im Sprint Planning verwechselt werden:
„Thema Drei: Wie wird die ausgewählte Arbeit erledigt?“ – Scrum Guide, 2020
Im Refinement entdeckt das Team das Problem. Es geht also hauptsächlich um die Frage „Was sollten wir tun“ und weniger darum, „wie die Arbeit getan werden soll“. Letzteres ist Gegenstand des dritten Themas des Sprint Plannings.
Wenn du nach Ideen suchst, wie du deinem Team helfen kannst, das Refinement produktiver zu nutzen, dann lohnt sich ein Blick auf den Artikel: „Product Backlog Refinement: 5 konkrete Strategien für diese essenzielle Product-Management-Aktivität“.
Problem 6: Im Daily Scrum sprechen die Entwickler nur über gestern
Das Daily Scrum scheint das problematischste Meeting aller Scrum Events zu sein.
Vielleicht liegt es daran, dass es täglich stattfindet und deshalb dabei auftretende Probleme jedem sehr präsent sind. Hier zeigt sich mal wieder, dass Scrum ein Spiegel ist, der Teams all ihre Problemzonen schonungslos aufzeigt.
Wiederholen wir noch einmal, um was es beim Daily Scrum eigentlich geht, indem wir einen Blick in den Scrum Guide werfen:
„Der Zweck des Daily Scrums besteht darin, den Fortschritt in Richtung des Sprint-Ziels zu überprüfen und das Sprint Backlog bei Bedarf anzupassen, um die bevorstehende geplante Arbeit zu justieren.“ – Scrum Guide, 2020
Ich lese diese Zeilen so: Das Team steht hier. Das Ziel ist dort vorn. Die einzige verbleibende Frage lautet: „Was müssen wir noch tun, um das Ziel zu erreichen?“ Wir schauen also in die Zukunft und nicht in die Vergangenheit.
In die Vergangenheit würden wir schauen, wenn wir jemandem Rechenschaft ablegen müssten, was wir bis jetzt erledigt haben. Wir kennen dies als ein Statusmeeting. Allerdings sollten Entwickler im Scrum Team keinem Manager über ihre Arbeit Rechenschaft abliefern müssen. Dies stünde im Widerspruch zum Selbstmanagement, das Scrum voraussetzt.
Wenn das Daily Scrum deines Teams eher wie ein Statusmeeting abläuft und du das ändern möchtest, findest du hier eine konkrete Anleitung: „Wie du ein Statusmeeting in ein Daily Scrum verwandeln kannst“.
Welches Problem habe ich auf der Liste vergessen? Schreibe es in die Kommentare!