Ein Scrum ist ein Scrum.

Über Frameworks wie Scrum wird gerne viel und kontrovers diskutiert, und ein gemeinsames Verständnis darüber sollte man immer im Blick behalten.

Im Laufe der Zeit sind viele neue Kollegen mit unterschiedlichen Erfahrungen und vielfältigem Background bei unseren auf UX Design & App Development spezialisierten Mobile Minds hinzu gekommen. Wachsende Belegschaft kombiniert mit wechselnder Team-Besetzung in Projekten führt aber erfahrungsgemäß dazu, dass es empfehlenswert ist, aktiv und regelmäßig für Alignment zu sorgen und Arbeitsweisen und das tägliche Miteinander zu beleuchten und zu verbessern. Deswegen drehte sich bei zwei unserer letzten Trainings alles um das Thema interne Weiterbildung, und der Fokus lag auf dem Verständnis und der Anwendung des Frameworks Scrum, in dem einen Fall mit besonderem Blick auf das Entwicklungsteam, in dem anderen Fall mit Fokus auf den Product Owner.

Schauen wir einmal auf das Entwicklungsteam und den Product Owner: diese bilden im Framework Scrum zwei von drei Rollen ab, die im Zusammenspiel mit dem Scrum Master das Scrum Team bilden. Das Entwicklungsteam erfüllt dabei die Aufgabe, am Ende eines jeden Sprints ein fertiges, funktionsfähiges und potentiell auslieferbares Produkt-Inkrement zu erstellen. Es ist hierfür interdisziplinär mit Profis besetzt und selbstorganisierend, verfügt also als Team über alle Fähigkeiten, die es für das Wahrnehmen dieser Funktion benötigt. Der Product Owner dagegen ist zuständig für die Wertmaximierung des Produkts, das vom Entwicklungsteam erarbeitet wird. Er ist verantwortlich für das Management des Product Backlogs, und er ist tatsächlich eine Person, kein Gremium. Außerdem muss er über Fachkenntnis verfügen, entscheidungsbefugt und verfügbar sein. So weit, so gut.

Aber wie sollen das Entwicklungsteam und der Product Owner bei ihrer Arbeit vorgehen? Welche Techniken und Praktiken sollen sie anwenden? Was ist eigentlich fester Bestandteil von Scrum, und was sind bewährte, unterstützendene Praktiken,  die aber nicht zum Kern von Scrum gehören? Und was sind Begriffe, die im Kontext von Scrum kursieren, die aber eher im Bereich „Mythen und Legenden" anzusiedeln sind und nicht guten Gewissens damit in Verbindung gebracht werden sollten? Trotz Scrum-Guide scheiden sich darüber gerne die Geister, oft gibt es Missverständnisse und in Teams entstehen immer wieder Grundsatzdiskussionen darüber, die nicht unbedingt fruchtbar sind. Deswegen ist es vorteilhaft, von Anfang an und immer wieder ein gemeinsames Verständnis im Scrum Team dafür zu entwickeln. Eine spielerische Möglichkeit dafür bietet das Core Scrum Game.

Das Core Scrum Game ist eine interaktive und kollaborative Aktivität, bei der es darum geht, Begriffe im Kontext von Scrum zu diskutieren und zu verstehen, indem man sie gemeinsam einordnet als Core Scrum (ein Must-have für Scrum), als Supporting Practice (bewährte, unterstützende aber optionale Praktiken) oder als Not Scrum (hat nichts mit Scrum zu tun). Dadurch können schnell Missverständnisse, unterschiedliche Interpretationen und Sichtweisen aufgedeckt und geklärt werden.

Für jede Kategorie mal ein Beispiel:

• Wo würden Sie den Begriff User Story einordnen? Tick... tack... tick... tack... Und, was ist Ihre Antwort? Der Autor ist der Meinung: Supporting Practice! Warum ist er dieser Meinung? Nicht ganz zufällig werden Sie im Scrum Guide den Begriff "User Story" nicht finden, also schon mal nicht Core Scrum. Wohl aber ist der Einsatz von User Storys eine bewährte Praktik, um die sog. Product Backlog Items zu organisieren, die im Product Backlog die Features, Funktionen, Anforderungen, Verbesserungen und Fixes ausdrücken. Womit schließlich auch Not Scrum wegfällt...

• Wo würden Sie den Begriff Project Manager einordnen? Die Uhr läuft... und? Vorschlag: Not Scrum! Zum einen taucht auch dieser Begriff nicht im Scrum Guide auf, zum anderen liegt hier oft eine Verwechslung oder Vermischung von Begriffen wie „Project" und „Product" oder von „Project Manager" und „Product Owner" vor, also völlig unterschiedlicher Verantwortungs-, Aufgaben- und Organisationskonzepte. Erfahrungsgemäß ist es auch keine bewährte Praktik, um das Scrum Team herum Projekte zu definiereren und entsprechende Rollen mit Scrum Rollen zu vermischen.

• Wo würden Sie in diesem Zusammenhang den Begriff Offenheit einordnen? 21... 22...23... Core Scrum! Zusammen mit Mut, Commitment, Fokus und Respekt, stellt Offenheit einen der Werte des Scrum-Frameworks dar, die das Scrum Team immer in den Vordergrund stellen sollen, und die es bei der Arbeit mit den Rollen, Artefakten und Events ständig im Blick behalten sollen. Konkret heißt es im Scrum-Guide: „Das Scrum-Team und seine Stakeholder sind sich einig, offen mit allen Belangen ihrer Arbeit und den damit verbundenen Herausforderungen umzugehen".

Diese und viele andere Begrifflichkeiten zu diskutieren und ein gemeinsames Verständnis im Team zu entwickeln ist etwas sehr Wertvolles, von dem meiner Erfahrung nach alle profitieren können. Und darüber hinaus macht es Spaß, Dingen mit Offenheit zu begegnen, Anforderungen als User Storys zu formulieren, den Project Manager außen vor zu lassen - und als Team die Gewissheit zu haben, das Gleiche zu meinen!