Der Scrum-Reiseführer. Tobias Renk

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.

      4.4 Product Owner als Wertmaximierer

      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.

      Diese Fülle an Aufgaben macht deutlich, weshalb die Rolle eines Product Owners nicht einfach mal so nebenbei erledigt werden kann. Ein Product Owner kann zusätzlich bei den oben beschriebenen Aufgaben von anderen unterstützt werden. Die Prämisse dafür ist, dass allen zu jeder Zeit bewusst ist, dass am Ende der Product Owner die Verantwortung für diese Tätigkeiten trägt.

      Einen erfolgreichen Product Owner zeichnet aus, dass seine Entscheidungen innerhalb der Organisation respektiert und akzeptiert werden. Daher ist es notwendig, dass ein Product Owner ein Entscheidungsmandat erhält. Ist dies nicht gewährleistet, kann es zu Situationen kommen, in denen die Entscheidungen infrage gestellt werden, was die Produktivität des Scrum Teams negativ beeinflusst.

      4.5 Führung und Teambildung in agilen Teams

      Das Entstehen eines Spitzenteams durchläuft vorab verschiedene Phasen, genauso wie bei der Buchung eines langersehnten Traumurlaubs. Zunächst wird ein passender Zeitraum und das zur Verfügung stehende Budget festgelegt. Anschließend werden Urlaubsziele miteinander verglichen und das bestmögliche ausgesucht. Ein Hotelzimmer oder eine Pension wird reserviert. Reisen Sie per Flugzeug, kaufen Sie Flugtickets und je näher das Abreisedatum rückt, umso tiefer stecken Sie in den letzten Vorbereitungszügen. Die Wanderstiefel werden geputzt oder der Bikini noch einmal kritisch auf seinen Sitz beäugt. Der Nachbar ist bereits im Besitz des Hausschlüssels und hat sich freundlicherweise dazu bereit erklärt, zweimal die Woche die Pflanzen zu gießen. Das Taxi wird vorbestellt und auch der Mietwagen am Zielflughafen ist bereits organisiert. Jetzt kann der Urlaub richtig losgehen!

      Ähnlich verhält es sich auch mit agilen Teams (beziehungsweise mit Teams im Allgemeinen, agil macht hier keinen Unterschied). Bringt man Personen aus unterschiedlichen Bereichen zusammen, um gemeinsam an einem Projekt zu arbeiten, durchläuft die Gruppe zwangsläufig gewisse Schritte, bevor sie zu einem Höchstleistungsteam wird. Der US-amerikanische Psychologe Bruce Tuckman hat die Dynamiken von Teams auf dem Weg hin zu Hochleistungsteams untersucht. Er entwickelte in den 1960er Jahren ein vierphasiges ModellTeam-Building-Phasen, welches er 1977 um eine weitere, fünfte Phase ergänzte. Die fünf von Tuckman festgelegten Phasen lauten Forming, Stroming, Norming, Performing