Tobias Renk - Der Scrum-Reiseführer

Nachfolgend wollen wir den Dienstleistungscharakter der Scrum Master Rolle deutlicher herausarbeiten, indem wir uns anschauen, welche Aufgaben der Scrum Master in Bezug auf die anderen Scrum Rollen und die Organisation übernimmt.

Fangen wir mit der Organisation an. Wie eingangs kurz angedeutet, besteht die Hauptaufgabe darin, die Organisation mit Scrum vertraut zu machen. Das geschieht durch Trainings und Coachings. Der Scrum Master hat dabei natürlich auch eine beratende Funktion, in die er Erfahrungen aus anderen agilen Projekten mit einbringen sollte (sofern bereits vorhanden). Als größte Hürde hat sich dabei das Agile Mindset gezeigt. Es zeigt sich in der Praxis immer wieder, dass es für Unternehmen eine Hürde ist, von einer über Jahrzehnte gelernten Denkweise, die hauptsächlich auf traditionellen Projekt- und Produktdurchführungsmethoden (Zeit, Geld, Umfang) basiert, loszulassen. Der Schritt weg von einer – sind wir ehrlich – gefühlten Sicherheit der Projekt- und Budgetpläne sowie der Lasten- und Pflichtenhefte hin zu einem empirischen Ansatz, der bewusst Experimentieren zulässt und damit Fehlschläge akzeptiert, ist oftmals deutlich schwieriger als man vermutet und ein Hauptgrund dafür, dass Agilität in Organisationen scheitert. Zu guter Letzt ist der Scrum Master dafür zuständig, sich um sämtliche Hindernisse, welche Gestalt auch immer diese annehmen mögen, zwischen dem Scrum Team und anderen Beteiligten innerhalb der Organisation zu kümmern und sie bestmöglich zu beseitigen.

Kommen wir zur Bedeutung des Scrum Masters für den Product Owner. Der Scrum Master unterstützt ihn bei der Definition und dem Management des Produktzieles und des Produkt Backlogs. Er übernimmt keine inhaltlichen Aufgaben, sondern bietet vielmehr Unterstützung und Techniken an, wie die zwei zuvor genannten Aufgaben erfolgreich umgesetzt werden können. Zudem fördert und erweitert der Scrum Master das tiefergehende Verständnis des Product Owners, die Relevanz klarer und prägnanter User Stories zu begreifen und diese entsprechend umzusetzen (ein Punkt, der auch vom gesamten Team verstanden und mitgetragen werden muss – eine weitere Aufgabe des Scrum Masters). Zwar ist der Scrum Master selbst nicht der Product Owner (und hat unter Umständen keine eigene Produktentwicklungserfahrung, wenngleich das sehr hilfreich ist), dennoch gehört es zu seinen Aufgaben, dem Product Owner dabei zu helfen, geeignete Methoden hinsichtlich der Planung und Priorisierung der User Stories anzuwenden. In Lehrbüchern werden an dieser Stelle of Cost of Delay und Weighted Shortest Job First genannt. [Fußzeile: Cost of Delay bezeichnet dabei die Kosten, die auf ein Unternehmen zukämen, wenn eine bestimmte User Story erst zu einem späteren Zeitpunkt umgesetzt wird. Weighted Shortest Job First stellt den Nutzen einer User Story in Relation zum entsprechenden Aufwand und erlaubt damit, zumindest aus rein betriebswirtschaftlicher Sicht, eine optimale Priorisierung von User Stories.] Jedoch zeigt sich in der Praxis, dass Organisationen in Bezug auf Priorisierung von User Stories sehr kreativ sein können. Die Anwendung einer bestimmten Lehrbuchmethode ist dabei gar nicht entscheidend. Von höher Bedeutung ist, dass der Scrum Master die Dringlichkeit der Priorisierung herausstellt. Argumente à la „wir müssen das unbedingt im nächsten Sprint machen, weil wir es brauchen“ sollten nicht akzeptiert werden. Ebenso fungiert der Scrum Master als Vermittler und unterstützt, soweit erwünscht oder notwendig, den Product Owner bei der Zusammenarbeit mit anderen Beteiligten aus der Organisation.

Im Team äußert sich der Dienstleistungscharakter des Scrum Masters in der Form, als dass dieser alle Teammitglieder kontinuierlich darin coacht, ihre Zeit und Arbeit selbst zu managen. Er begleitet sie auf dem Weg in ein crossfunktionales Umfeld, was für einige zu Beginn noch ein ungewohntes Terrain darstellt. Einer der Gründe, weshalb Agilität nicht erfolgreich in eine Organisation implementiert wird, kann sein, dass dieser Punkt schlichtweg unterschätzt wurde. Teammitglieder benötigen Zeit und lernen erst, mit der neuen Freiheit in einem agilen Umfeld umzugehen. Wenn Personen mehrere Jahre in einem Umfeld gearbeitet haben, in dem sie von außen gemanagt wurden und Selbstorganisation unerwünscht war, ist die Wahrscheinlichkeit hoch, dass eine agile Umgebung erst einmal überfordernd ist. Der Scrum Master bezieht an diesem Punkt eine Leuchtturmposition. Durch Vorbild und Expertise verhindert er, dass eine Lähmung entsteht, in der Personen lieber nichts tun als Fehler zu begehen. Darüber hinaus unterstützt der Scrum Master das Team hinsichtlich der gemeinsam vereinbarten Definition of Done dabei, die Sprintziele zu erreichen. Er hilft dem Team dabei, sämtliche Hindernisse zu beseitigen, die zur Erreichung der Sprintzieles im Weg stehen. In der Praxis beinhaltet das die die Identifizierung von Abhängigkeiten und das entsprechende Management derselben. Folgende Situation wird anfangs immer mal wieder passieren und kann schnell in den Griff bekommen werden: Ein Sprint wird geplant, ohne die entsprechenden Abhängigkeiten der einzelnen User Stories zueinander zu berücksichtigen. Nicht selten führt das zu Situationen während eines Sprints, in denen einzelne Teammitglieder nicht weiterarbeiten können, da sie auf die Ergebnisse anderer Teammitglieder angewiesen sind (sogenannte Blocker). Der Scrum Master wird auch als Prozesswächter von Scrum bezeichnet. Damit ist gemeint, dass der Scrum Master dafür zu sorgen hat, dass alle Scrum Events stattfinden und innerhalb des vorgeschriebenen zeitlichen Rahmens bleiben.

Das gesamte Rahmenwerk Scrum kann und sollte individuell auf das Unternehmen, das Produkt und die Teammitglieder angepasst werden. Die Regeln nach Textbuch sind nicht dogmatisch zu verstehen. Es gab bereits erfolgreiche Scrum Teams, die bestimmte Events wie die Retrospektiven gestrichen haben. Genauso konnte so manches Scrum Team, das sich präzise an die Regeln gehalten hat, die gewünschten Ergebnisse nicht erreichen. Diese Freiheit ist ein wesentlicher Bestandteil von selbstorganisierenden Teams.

Die Rolle des Product OwnersProduct Owner ist – im Vergleich zu den beiden anderen Rollen – innerhalb eines Scrum Teams diejenige, die durchaus unterschätzt wird. Außerdem stehen Fachbereiche vor personellen Herausforderungen, wenn sie einen ihrer Fachexperten für eine andere Tätigkeit abstellen müssen. Folgende zwei Kernaspekte entwickeln sich aus diesen Reibungspunkten:

1 Der Product Owner ist eine Rolle innerhalb der Organisation, die gegebenenfalls neu geschaffen werden muss! Optimal ist es, wenn sich der Product Owner vollständig auf die Tätigkeiten im Scrum Team fokussieren kann und keine zusätzlichen, anderweitigen Aufgaben erhält.

2 Der Product Owner ist eine (!) Person, keine Gruppe oder Komitee. Gleichzeitig kann er die Interessen mehrerer Personen vertreten. Die finale, produktbezogene Entscheidung obliegt jedoch immer dem Product Owner.

Welche Entscheidungen sind gemeint und was sind nun die konkreten Aufgaben eines Product Owners? Der Grundgedanke ist einfach: Der Product Owner trägt die Verantwortung dafür, den Wert zu maximieren, den das Produkt für das Unternehmen erzeugt. So generisch dies klingen mag, so vielfältig sind auch die Methoden, die ein Product Owner dabei anwenden kann.

Ein effektives Management des Product Backlogs bildet dabei das Herzstück, um den maximalen Wert aus dem Produkt zu kitzeln. Dazu gehören insbesondere das Herausarbeiten und Kommunizieren eines Produktziels. Hier kann es zu den ersten Differenzen kommen, die den Erfolg des Scrum Teams negativ beeinflussen. Das Team möchte schnelle sichtbare Ergebnisse erzielen. Das kann dazu führen, dass der strategische Part stiefmütterlich behandelt und aus den Augen verloren wird. Hier ist also besondere Aufmerksamkeit erforderlich: Stellen Sie im Laufe Ihres Projektes eine ungewünschte Veränderung der Ergebnisse fest, werfen Sie doch nochmal einen Blick auf die Ausarbeitungen und die Kommunikation des Produktziels. Nehmen Sie sich dafür Zeit, sie wird sich rentieren! User Stories zu erzeugen und zu kommunizieren ist ein weiterer Aufgabenbereich des Product Owners. Er bringt diese in eine sinnvolle Reihenfolge, was in der Praxis eine Herausforderung sein kann. Besonders in diesem Teilschritt treten veraltete, hierarchisch geprägte Denkweise ans Tageslicht, die dem agilen Grundgedanken widersprechen. Nehmen wir zur Illustration ein beispielhaftes Projekt, das sich mit dem Erstellen von Berichten beschäftigt. Es liegt nahe, zunächst einmal User Stories anzulegen, die sich lediglich mit dem Sammeln und Anbinden von Datenquellen beschäftigen, um dann, in einem zweiten Schritt, mit der Erstellung der Berichte zu beginnen. Das jedoch ist genau die traditionelle Wasserfall-Denkweise, die ein sequenzielles und kein inkrementelles Vorgehen vorsieht. Geht ein Product Owner so vor, würde er der Maxime Wertgenerierung entgegenarbeiten. Denn eines ist klar: Wert wird erst dann geschaffen, wenn mindestens ein Bericht von der Fachabteilung im operativen Betrieb genutzt werden kann. Deshalb wäre es ein – im Sinne eines Product Owners – geschickteres Vorgehen, zunächst einen wichtigen, wertgenerierenden Bericht auf Basis weniger Datenquellen zu erzeugen, um anschließend darauf aufbauend die Daten- und Berichtslandschaft zu erweitern Eine weitere, grundlegende Funktion des Product Owners ist, ein für alle Teammitglieder nachvollziehbares und transparentes Product Backlog sicherzustellen.