Wer über Bücher, Blogs oder Gespräche einen Einstieg in Scrum finden will, wird mit einer Vielzahl an Regeln konfrontiert, die eigentlich keine Regeln sind. Zweifelt eigentlich noch irgendwer daran, dass eine Anforderung als User Story formuliert wird?
Die Sache mit den User Stories ist ein ganz wunderbares Beispiel. Jedes Buch spricht von diesen Dingern. Jeder Scrum Praktiker (oder auch jeder Scrum Theoretiker – das sind die schlimmsten) sagt ganz einfach, dass ihr Team User Stories schreibe. Ein beliebiger externer Agile Coach, den man sich ins Haus holt, fängt auch gern damit an, Anforderungen am Beispiel von User Stories zu präsentieren.
Mein Punkt an dieser Stelle ist nicht, dass ich Stories für Blödsinn halte, mein Punkt ist lediglich, dass einem Scrum Einsteiger fast nichts Anderes übrig bleibt, als zu glauben, dass Anforderungen als User Story formuliert werden müssen, dass dies eine Scrum Regel sei. Das ist es jedoch keinesfalls. Sie sind Best Practices, die in vielen Projekten und in vielen Teams ganz wunderbar funktionieren, sie sind jedoch kein Bestandteil des Scrum Regelwerks.
Anstatt von User Stories kann ich auch Use Cases, Job Stories oder ganz simpel einfache Stichwörter verwenden. In der Wahl der Form der Formulierung einer Anforderung ist unser Team frei. Wir können uns für unseren eigenen Weg entscheiden und machen dann daraus eine eigene Regel.
Ein weiteres Beispiel?
Kein Problem: der Product Owner schreibt die Anforderungen und priorisiert das Backlog. Dies einfach als Regel zu akzeptieren, ist für mich sogar noch weit dramatischer als die Sache mit den User Stories. Die sind nur eine Sache der Form (ja, ich weiß – daran hängt auch die klare Formulierung der Motivation usw., aber dafür kann ich auch andere Wege finden), den Product Owner zum Schreiber der Anforderungen zu machen, beeinflusst jedoch massiv unser Vorgehen.
Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen
Scrum sagt, der Product Owner ist für das Backlog verantwortlich. Das bedeutet, dass er alles selber machen kann, es aber nicht muss. Er kann die Anforderungen gemeinsam mit den Stakeholdern schreiben und dann gemeinsam mit dem Team priorisieren. Er kann die Anforderungen auch von Teammitgliedern schreiben lassen und dann mit den Stakeholdern priorisieren. Beides kann – je nach Projekt, Team und Unternehmen – sinnvoll sein. Das Team entscheidet darüber, wie es vorgeht. Es ist selbstorganisiert, d.h. es legt seine eigenen Regeln fest.
Scrum gibt uns hierfür ein Rahmenwerk vor, aber eben auch nicht mehr als das. Wir sind selbst aufgefordert, diesen Rahmen mit Leben und unseren eigenen Regeln zu füllen. Das ist das Prinzip eines Frameworks. Es ist jedoch eine weit verbreitete menschliche Eigenschaft, dass wir uns nach festen Vorgaben sehnen (was wir jedoch niemals zugeben würden, schließlich sind wir alle Freigeister), weil es uns sehr schwer fällt, unsere eigenen Regeln zu bestimmen. Das sind wir schließlich auch nicht gewohnt.
Hier liegt jedoch eine der Stärken von Scrum: wir können es an unsere eigenen Bedürfnisse anpassen. Ein zu starres Regelwerk wäre von vornherein zum Scheitern verurteilt. Zu unterschiedlich sind die jeweiligen Ausgangssituationen. Scrum sagt lediglich, dass es bestimmte Zeremonien, Artefakte und Rollen mit bestimmten Verantwortlichkeiten gibt. Danach hören die Vorgaben schon sehr bald auf, und wir sind aufgefordert, selbst zu denken.
Ich komme gelegentlich in Teams, die bereits ihre ersten Erfahrungen mit Scrum gemacht haben. Wenn ich dann frage, warum wir bestimmte Dinge auf bestimmte Art lösen, ist die Antwort gelegentlich, dass dies in Scrum so sei, was ich doch wissen müsse. Entgegne ich dann, dass das eben nicht der Fall sei, dass wir sehr viel mehr Freiheiten haben, dann ist die Ratlosigkeit zwar groß aber auch kurz. Im allgemeinen möchte das Team dann den eingeschlagenen Weg weiter verfolgen – funktioniert schließlich. Fordere ich das Team jetzt auf, die Dinge zu hinterfragen, dann kann ich dabei zusehen, wie es dem einen oder anderen plötzlich sehr ungemütlich wird. In diesem Moment werden die Kollegen mit einer neuen Situation konfrontiert: den scheinbar sicheren Hafen der festen Vorgaben zu verlassen und seine eigenen Regeln festzulegen. Das ist ungewohnt und neu, und damit oft auch unangenehm und schwierig.
Was tun wir also in einzelnen?
Das Scrum Regelwerk hat zwei Ebenen: zum einen die allgemeinen, die im Scrum Guide definiert sind (und nur dort: https://www.scrumguides.org/), und zum anderen diejenigen, die wir selbst für unser Team festlegen. Zunächst einmal sollten wir uns klar machen, was tatsächlich Regel ist, und was wir nur dafür halten. Wenn Sie also den Scrum Guide noch nicht gelesen haben, dann tun Sie es so bald wie möglich. Lesen Sie aufmerksam. Der Unterschied ist oft eine Sache einer einzelnen Formulierung. Das beste Beispiel hierfür ist die Sache mit dem Product Owner und seiner Verantwortlichkeit für das Backlog. Ein einzelnes Wort macht den ganzen Unterschied.
Es ist übrigens egal, ob Sie das englische Original oder die deutsche Fassung lesen. Die Jungs haben einen guten Job bei der Übersetzung gemacht. Wäre das nicht der Fall, hätte die Scrum Community den Beteiligten die deutsche Version um die Ohren gehauen.
Wenn Sie mit Ihrem Team noch am Anfang stehen, dann haben Sie es jetzt leicht. Sie wissen ganz genau, was Scrum vorgibt, und wo Sie Freiheiten haben. Nun können Sie gemeinsam mit dem Team das eigene Vorgehen definieren und eigene Regeln festlegen.
Was tun Sie aber, wenn sich die Dinge schon eingespielt haben? Wollen wir dann alles noch einmal hinterfragen, woran wir uns gewöhnt haben, und womit wir gut umgehen können? Womit alle scheinbar sehr zufrieden sind? Ich warne davor. Das erzeugt Unruhe und Unsicherheit, die in dieser Form sicherlich nicht nötig und auch nicht hilfreich sind. Wenn die Dinge in der Empfindungswelt unseres Teams gut laufen, dann müssen wir nicht zwingend etwas daran ändern. Berühren wir aber z.B. in der Retro einen dieser Punkte, die wir für Regeln halten, die es aber nicht sind, dann spricht nichts dagegen, mit dem Team darüber zu sprechen, dass wir an genau dieser Stelle Freiheiten haben.
So kann sich nach und nach eine Veränderung ergeben. Wir müssen nicht alles auf einmal machen und unsere Kollegen damit völlig verunsichern.
Folgt mir auf twitter, um keine neuen Beiträge zu verpassen.
