Scrum hat als agiles und damit modernes Entwicklungsframework bereits vor einigen Jahren Einzug in die Projektwelt der Unternehmen gehalten. Mittlerweile erwarten wir Teammitglieder, dass Scrum ein etabliertes Vorgehen ist und die Konzerne wissen, wie es erfolgreich eingesetzt wird. Leider haben wir andere Erfahrungen gemacht.
Probleme mit Scrum
1. Product Owner:innen und Scrum Master:innen arbeiten nicht Hand in Hand
Häufig werden Produktteams durch einen Coach bzw. eine:n Scrum Master:in angeleitet, um das Scrum Rahmenwerk richtig einzusetzen und letztlich aus voller Überzeugung zu leben. Wir haben festgestellt, dass dies sehr gut funktionieren kann, solange es eine:n Product Owner:in und eine:n Scrum Master:in gibt, die sich ihrer Rolle voll bewusst sind. Fehlt nur eine dieser Disziplinen oder muss ein:e Kolleg:in mehrere Aufgabenteile gleichzeitig übernehmen, kommt es schnell zu Problemen. Häufig münden Plannings und Product Backlog Refinement in endlosen Diskussionsrunden ohne den richtigen Fokus. Oder Teammitglieder arbeiten nicht mit-, sondern gegeneinander, weil Retrospektiven nicht dazu genutzt werden, Missstände im Team aufzudecken. Oder – noch schlimmer – Retros finden erst gar nicht statt.
2. Die Stakeholder wissen zu wenig über Scrum
Ein weiteres Problem, das wir in unseren Projekten häufig erleben, ist, dass nicht das Entwicklungsteam selbst ein Scrum-Training benötigt, sondern die Stakeholder.
Eine der wichtigsten Regeln in Scrum ist die Selbstbestimmtheit des Teams. Das Entwicklungsteam ist interdisziplinär aufgestellt und mit allen relevanten Fähigkeiten ausgestattet, um selbstständig zu entscheiden, was in einem Sprint aufgrund der begrenzten Ressourcen umsetzbar ist. Der:die Product Owner:in verwaltet das Backlog und behält dabei stets die Vision des Produkts im Blick, welche in Zusammenarbeit mit den Stakeholdern entstanden ist. Tut der:die Product Owner:in das nicht oder lässt sich von außen durch das ständige Platzieren neuer Themen zu sehr beeinflussen, ist das behutsam und strategisch aufgebaute Produkt‐Ziel schnell zerstört.
Insbesondere die Stakeholder – darunter Auftraggeber in Form von Management oder Vertriebsleiter:innen – haben das noch nicht verstanden. Womöglich, da sie zur Art und Weise wie Scrum eingesetzt wird nie ein Training erhalten haben. Und so kommt es , dass sie in laufende Sprints eingreifen, um eigene Themen zu platzieren, weil ein:e wichtige:r Kund:in eine vermeintlich großartige Idee hatte. Oder weil ein neues Feature dringend benötigt wird, um Kund:innen davon abzuhalten, andernfalls zur Konkurrenz abzuwandern.
3. Die Stakeholder nehmen zu viel Einfluss
Ein wesentlicher Grund für das Eingreifen der Stakeholder ist oftmals fehlendes Vertrauen ins Team.
Das Team wurde mit der Aufgabe betraut, ein bestehendes Produkt zu verbessern oder neu zu entwickeln. In wiederkehrenden Reviews stellt es den aktuellen Entwicklungsstand vor, den die Endkunden wenige Tage später produktiv nutzen können. Durch die ständige Einflussnahme der Stakeholder von außen wird die Arbeit im Scrum Team so gestört, dass bis zum Ende eines Sprints eventuell kein wertvolles Increment erzeugt werden kann. Oftmals entsteht in einem derartigen Fall etwas Halbgares, das den Endanwender:innen keinen Nutzen bringt, sondern das Produkterlebnis (zer)stört.
Wenn Scrum gut orchestriert wird, läuft es super.
Die Lösung der Probleme mit Scrum
Das oben beschriebene Verhalten der Stakeholder wird oftmals vom gesamten Scrum Team erkannt. Kaum jemand hat jedoch den Mut, dies außerhalb des Teams zu thematisieren. Die gesamte Teamarbeit wird sabotiert und führt zu Ergebnissen, mit denen das Team nicht zufrieden ist. Und sind die Teammitglieder nicht zufrieden mit dem, was sie entwickelt haben, können sie auch keinen Stolz für das Produkt empfinden. Sollte das aber nicht die Grundlage unserer täglichen Arbeit sein?
Also nehmt euch ein Herz – gerne auch gemeinsam als Gruppe – und geht das Problem aktiv an. Das Thema wird sich nicht von alleine lösen,. Nutzt dafür eure Reviews. Bei den Reviews sind die besagten Stakeholder normalerweise anwesend. Fälschlicherweise werden die Reviews oft als reine Präsentationstermine wahrgenommen. Sie sind aber Arbeitstermine, bei denen gemeinsam Veränderungen im Umfeld thematisiert und im Backlog entsprechende Anpassungen vorgenommen werden können.
Habt ihr das Glück, eine:n Scrum Master:in und Product Owner:in zu haben, die dafür sorgen, dass es in eurem Projekt glatt abläuft, dann lobt sie genau für diese Arbeit! Der reibungslose Sprint-Ablauf ist keine Selbstverständlichkeit und damit von hohem Stellenwert für euch und das Produkt.
Empfehlung
Du möchtest mehr über Scrum Erfahren? Schau dir den Scrumguide auf Scrum.org an.
Scrum und UX/UI Designer
Wir als UX/UI Designer bezeichnen uns selbst gerne als empathische Menschen. Wir versuchen, die Perspektive unseres Gegenübers einzunehmen, um dessen Pain Points besser zu verstehen. Das sollten wir nicht nur auf unsere Produktnutzer reduzieren, sondern kann auch für das eigene Scrum Team gelten.
Entsprechend sehen wir uns als UX/UI Professionals auch in der Position, auf solche Probleme im Scrum Prozess frühzeitig hinzuweisen und Lösungsvorschläge zur Optimierung zu unterbreiten. Das darf auch die Mobilisierung des gesamten Scrum Teams bedeuten, auf die Stakeholder Einfluss zu nehmen, um langfristig etwas zu ändern.
Schlussendlich ist das Produkt, an dem ihr arbeitet, nur ein Baustein einer gemeinsamen Konzernphilosophie – jeder sollte Interesse daran haben, das es ein Erfolg wird.
Kurz und knackig – So funktioniert Scrum gut
- Product Owner:in und Scrum Master:in sind sich ihrer jeweiligen Rolle bewusst, übernehmen Verantwortung und vertreten die Interessen von Team und Produkt
- Stakeholder kennen den Scrum Prozess und haben Vertrauen zum Team
- Reviews und Retros finden wie geplant statt und werden effektiv genutzt
