Kitabı oku: «Der Scrum-Reiseführer», sayfa 2
3.3 Scrum Artefakte
Unter Artefakten versteht man Prozessdokumente, die während eines Projekts erstellt werden. Scrum kennt die drei Artefakte Product Backlog, Sprint Backlog und Produktinkrement. Das Product Backlog listet die priorisierten Anforderungen an das zu erstellende Produkt auf. Diese Aufstellung ist niemals vollständig und existiert in der Regel so lange, wie das Projektprodukt entwickelt wird. Der Product Owner ist für das Product Backlog verantwortlich und überarbeitet kontinuierlich die Backlog-Anforderungen und deren Prioritäten. Das bedeutet, dass er die Einträge regelmäßig verfeinert, das Backlog um neue Anforderungen erweitert und obsolet gewordene Anforderungen aus der Aufstellung löscht. Je wichtiger eine Anforderung ist, desto detaillierter muss sie ausformuliert und desto größer muss deren Priorität sein. Beschrieben werden die Anforderungen häufig in Form von User Stories. Das Sprint Backlog enthält die Product Backlog-Einträge, die in der aktuellen Projektiteration umgesetzt werden sollen. Diese Einträge werden auch als Sprint Backlog Items bezeichnet. Die Verantwortung für das Sprint Backlog liegt beim Entwicklerteam. Das bedeutet insbesondere, dass das Team entscheidet, welche Product-Backlog-Einträge es in der nächsten Iteration bearbeitet und wie diese in detaillierte Aufgaben (Tasks) unterteilt werden können. Während eines Sprints wird das Sprint Backlog nach der Erledigung eines Tasks vom Entwicklerteam aktualisiert. Das Ergebnis einer Iteration bezeichnet man als Produktinkrement. Dieses Artefakt besteht somit aus den in der aktuellen Iteration umgesetzten User-Stories und allen Anforderungen, die bereits in den vorherigen Iterationen realisiert wurden. Wichtig ist, dass jedes Produktinkrement release-fähig ist, also potenziell an den Kunden ausgeliefert werden kann.
Im neuen Scrum Guide wird das ProduktzielProduktziel (Product Goal) als zusätzliche Begrifflichkeit eingeführt. Dieses Ziel beschreibt, was der Sinn des zu erstellenden Produkts ist. Eine konkrete Benennung des Sinns vermeidet eine willkürliche Ansammlung von Features, Tasks und Defects. So steht das Produktziel als Leitbild über dem Product Backlog und mit jedem Sprint wird das Produkt näher an dieses Produktziel herangebracht.
Die Einführung des Produktziels ermöglicht es, jedem Scrum Artefakt eine klare Zuordnung (CommitmentCommitment) zuzuweisen: Das Produktziel gehört zum Product Backlog, das SprintzielSprintziel zum Sprint Backlog und die Definition of Done zum Produktinkrement. Diese drei Commitments sollen die Transparenz erhöhen und den Entwicklungsfortschritt sicht- und messbarer machen. Das Produktziel wird vom Product Owner entwickelt und gilt für das gesamte Scrum Team. Das Sprintziel wird vom Scrum Team festgelegt und ist die selbstverpflichtende Zielvorgabe für den aktuellen Sprint. Die Abschlusskriterien für ein Produktinkrement (Definition of DoneDefinition of Done) werden vom Scrum Team in Einklang mit den Organisationsvorgaben erstellt. Die Entwickler verpflichten sich dazu, diese Kriterien bei der Erstellung des Produktinkrements zu erfüllen.
Der Scrum Guide 2020 ermöglicht die Erstellung mehrerer Produktinkremente in einem Sprint. In der Vergangenheit war es notwendig, bis zum Sprintende zu warten, um ein neues Produktinkrement produktiv setzen zu können. Stattdessen gilt nun: Jedes Mal, wenn ein Product Backlog Item die Definition of Done erfüllt, gibt es ein neues Produktinkrement. Diese Inkremente können also auch während eines Sprints abgenommen und theoretisch ausgeliefert werden. Dadurch wird nicht nur eine kontinuierliche Auslieferung ermöglicht, die Änderung führt hoffentlich auch dazu, dass das Sprint Review nicht mehr als „Freigabe-Veranstaltung“ missinterpretiert wird. Ziel des Sprint Reviews ist es vielmehr, anhand der Prüfung der erstellten Produktinkremente neue Impulse für das Product Backlog zu bekommen, um so die zukünftigen Sprintziele noch besser am Produktziel ausrichten zu können. Damit sind wir bereits mittendrin in den Scrum Events.
3.4 Scrum Events
Das Vorgehensmodell Scrum beinhaltet fünf Ereignisse mit festgelegter Dauer. Dazu gehören der Sprint, das Sprint Planning, das Daily Scrum, das Sprint Review und die Sprint Retrospektive. Der ein- bis vierwöchige Sprint repräsentiert einen vollständigen Iterationslauf. Innerhalb dieser Zeitspanne findet die eigentliche Entwicklungsarbeit statt und es werden die übrigen vier Ereignisse praktiziert. Endet ein Sprint, startet direkt im Anschluss die nächste Iteration. Ein Sprint kann vom Product Owner jederzeit abgebrochen werden. Der Sprint wird mit dem Ereignis Sprint Planning eröffnet. In diesem Meeting stellt der Product Owner das Ziel des Sprints vor. Das Entwicklungsteam erstellt das Sprint Backlog, indem es so viele Anforderungen aus dem Product Backlog übernimmt, wie es in einem Sprint umsetzen kann. Während des Sprints findet täglich zur gleichen Zeit das Daily Scrum statt. Dies ist ein kurzes Meeting, in dem jeder Entwickler auf seine aktuelle Arbeit eingeht und den Fortschritt bis zum nächsten Daily Scrum prognostiziert. Hierzu beantworten die Entwickler üblicherweise nacheinander folgende drei Fragen:
1 Was war mein Beitrag zum Sprintziel seit dem letzten Daily Scrum?
2 Welche Aktivitäten plane ich bis zum nächsten Daily Scum?
3 Sehe ich Hindernisse, die mich oder das Entwicklungsteam vom Erreichen des Sprintziels abhalten?
Die beiden übrigen Ereignisse folgen am Ende eines Sprints. Zunächst wird im Sprint Review das erstellte Produktinkrement vorgestellt. An dieser Veranstaltung nehmen das ganze Scrum Team und die Projekt Stakeholder teil. Ziel ist es, von den Stakeholdern ein Feedback über das Produktinkrement zu erhalten. Dieses wird anschließend genutzt, um das Product Backlog anzupassen und um neue Anforderungen aufzunehmen. In der abschließenden Sprint Retrospektive reflektiert das Team den Verlauf und diskutiert Verbesserungsmöglichkeiten für den nächsten Sprint.
Während eines Sprints findet die Entwicklungsarbeit an den Sprint Backlog Items statt. Gestartet wird mit dem Sprint Planning Meeting. In dieser Besprechung fokussiert man sich auf folgende zwei Fragestellungen: Was kann in diesem Sprint realisiert werden und wie wird diese Arbeit umgesetzt? Das Entwicklungsteam übernimmt im ersten Teil der Planungssitzung so viele User Stories aus dem Product Backlog in das Sprint Backlog, wie es im Sprint umsetzen kann. Hieraus abgeleitet formuliert das gesamte Scrum Team das Ziel des Sprints. Im zweiten Teil überlegt das Entwicklungsteam, welche Tasks zum Erreichen ihres Sprintziels und zur Abarbeitung der ausgewählten Product Backlog-Items notwendig sind.
Im Sprint Planning ging es bisher um die Beantwortung von zwei zentralen Fragestellungen: Die Entscheidung, welche Product Backlog Items im nächsten Sprint bearbeitet werden sollen und wie diese realisiert werden können. Im aktuellen Scrum Guide kommt nun eine dritte Fragestellung hinzu: Warum ist der Sprint sinnvoll bzw. wie kann der Wert des Sprints am effektivsten maximiert werden? Mit der genauen Beschreibung dieses Sprintziels bekommt das selbstverwaltende Team eine klare Richtschnur für den Sprint.
In Abbildung 3 wird das Zusammenspiel der Scrum Rollen, der Scrum Events, der Scrum Artefakte und der zugehörigen Commitments dargestellt.
Abbildung 3:
Scrum Framework
4 Scrum Rollen – Die Idealbesetzung eines Scrum Teams
Unsere Reise in Scrum ist weniger auf den Individualtouristen ausgerichtet, sondern erlangt seine volle Pracht erst in einer Gruppe, die zu einem echten Team werden soll. Lernen Sie daher die Wege kennen, die auch abseits grauer Theorie einen perfekten Blick auf das Wesentliche bei der Teamzusammensetzung geben.
4.1 Passende Rollenbesetzung als Erfolgsschlüssel
Wie in jedem Team ist die passende Rollenbesetzung wichtig. Eine Reisegruppe zu den Pyramiden Südamerikas hat viel mehr Spaß, wenn ein kenntnisreicher Reiseführer dabei ist. Eine Fußballmannschaft ohne Torwart dürfte es schwer haben, Spiele zu gewinnen. Und auch ein American Football Team dürfte vor großen Herausforderungen stehen, ohne Quarterback im Super Bowl zu brillieren. Auch Scrum „benötigt“ bestimmte Rollen, damit es in der Praxis gut funktionieren kann.
Scrum macht es sich dabei sehr einfach, denn es gibt nur drei RollenScrum Rollen: Den Product Owner, den Scrum Master und das Entwicklungsteam. Wie die Rollenbezeichnungen schon andeuten, sind der Product Owner und der Scrum Master jeweils eine Person, das Entwicklungsteam jedoch eine Gruppe (siehe Abbildung 4).
Abbildung 4:
Rollen in einem Scrum Team
Ein wesentlicher Aspekt von Scrum ist, dass es prinzipiell keine Hierarchien innerhalb des Teams gibt. Zwar hat jede Rolle die ihr zugeordneten Aufgaben, für die sie jeweils auch verantwortlich ist, aber ein hierarchisches Gefälle, in dem eine Person Anweisungen erteilt, die dann nur noch von anderen ohne Hinterfragen umgesetzt werden, wird klar vermieden. Diese Freiheit hat Vor- und Nachteile. Einerseits wird das Wissen aller Teammitglieder eingebracht, was in der aktuellen VUCA-Welt sinnvoll und notwendig ist – die notwendige Expertise für eine Produktentwicklung konzentriert sich auf Grund der Komplexität nicht in einem Individuum. Andererseits gibt es in der Praxis Momente, in denen der eine oder die andere sich ein bisschen „Basta“-Mentalität zurückwünscht, um längere Diskussionen abwürgen zu können. Und damit sind wir schon bei einem Kernthema von Scrum und von agilen Arbeitsmethoden im Allgemeinen: Kommunikation. Agile Arbeitsmethoden benötigen zwingend deutlich mehr Kommunikation und Abstimmung als Wasserfall-Methoden.
Wenn es keine Hierarchien innerhalb des Teams gibt, bedeutet das zusätzlich, dass das Team sich selbst organisieren muss. Selbstorganisierende Teams sind derzeit äußerst beliebt und finden als Schlagwort Eingang in viele Reden, Präsentationen und Veröffentlichungen (wie auch in diese). Aber was bedeutet Selbstorganisation überhaupt für ein Scrum Team? Wo liegen die Schwierigkeiten? Wie sieht das in der Praxis aus? Und kann das überhaupt funktionieren oder ist es eine Wunschvorstellung vom idealen, aber nie zu erreichenden Team Utopia? Die gute Nachricht ist, es kann funktionieren. Die Schlechte ist, es gestaltet sich oft schwieriger als es oft erwartet wird. Selbstorganisation bedeutet, dass das Scrum Team die Art und Weise der Zusammenarbeit innerhalb eines vorgegebenen Frameworks selbst definiert. Orchestriert wird das Ganze vom Scrum Master. In der Praxis kann dies eine Herausforderung für den Scrum Master sein. Dafür gibt es zwei Gründe: Erstens befürchten viele Manager einen gewissen Kontrollverlust, wenn sie dem Scrum Team nicht die Art und Weise der Zusammenarbeit vorgeben können. Zweitens fällt es manchen Mitarbeitern schwer, mit der neugewonnenen Freiheit umzugehen. Dies ist umso verständlicher, wenn man berücksichtigt, dass viele Unternehmen die letzten Jahre oder Jahrzehnte in einer Wasserfallwelt zuhause waren, in der sich eine Kultur der Compliance entwickelt hat. In einem solchen Umfeld wurde den Mitarbeitenden wenig Freiheit gegeben, um eigene Ideen voranzutreiben und auszuprobieren. Wird nun Selbstorganisation über Nacht per Dekret eingeführt, weil das Wort häufig in Verbindung mit agilen Arbeitsweisen fällt, kann dies schnell zu einer Überforderung der Mitarbeitenden führen, die noch kein Vertrauen in die neue Herangehensweise entwickeln konnten. Die Ursache beider Punkte liegt im agilen Mindset, das sich erst noch im gesamten Unternehmen ausbilden muss. Dieser Vorgang benötigt Zeit und sollte durch einen umfassenden Veränderungsprozess begleitet werden.
Scrum Teams sind crossfunktional, was bedeutet, dass innerhalb des Teams alle Fähigkeiten vorhanden sind, die für die Erreichung des Produktziels notwendig sind. Nehmen wir als Beispiel eine Webapplikation, die unter Verwendung von Wetter- und Verkehrsdaten die Besuchszahlen für einen Zoo vorhersagen will. Ein solches Scrum Team könnte aus einem Product Owner, einem Scrum Master und Entwicklern bestehen, die folgende Fähigkeiten bereithalten: UX/UI-Design, Frontend- und Backendentwickler, Testentwickler, Datenbankentwickler, Data Scientist.
Das obige Team würde aus circa sieben Mitgliedern bestehen (abhängig davon, ob bestimmt Fähigkeiten in einer Person vereint sind oder, ob bestimmte Kompetenzen mehrfach vorhanden sein müssen). Die Frage nach der Größe eines Scrum Teams wird vor dem Beginn des Projektes beantwortet. Folgende Faustregel kann dabei verwendet werden: Das Scrum Team sollte klein genug sein, um flexibel agieren zu können und den Kommunikationsaufwand nicht zu groß werden zu lassen. Gleichzeitig sollte es groß genug sein, um einen signifikanten Fortschritt zu erzielen. Typischerweise liegt die Zahl zwischen sieben und neun Teammitglieder. Kleine Teams sind meist produktiver und kommunizieren effizienter. Jeff Bezos hat bei Amazon die Zwei-Pizzen-Regel eingeführt, um die ideale Teamgröße für ein produktives Arbeiten zu bestimmen (siehe Abbildung 5).
Abbildung 5:
Performance – Teamgröße
Sie besagt, dass an einem Meeting nur so viele Mitarbeiter teilnehmen dürfen, wie von zwei Pizzen satt werden. (Achtung, gemeint sind amerikanische Pizzen, die im Gegensatz zu europäischen Pizzen einen Durchmesser von 40 cm anstatt von 26 cm haben. Von einer amerikanischen Pizza werden vier Personen satt.) Die Anzahl an Teilnehmern ist demnach auf acht beschränkt. So willkürlich diese Zahl erscheinen mag, sie ist wissenschaftlich fundiert und wird auch von Bob Sutton in seinem Buch Scaling Up Excellence: Getting to More without Settling for Less bestätigt. Wird ein Team zu groß, sollte das Team in kleinere Einheiten zerteilt werden. Ab jetzt betreten wir den Bereich der Skalierung von agil, der wir uns später in einem separaten Kapitel widmen. So viel sei bereits an dieser Stelle gesagt: Wird das Thema Skalierung nicht umfänglich durchdacht, was in der Praxis häufiger vorkommt, kann dies mittel- und langfristig sowohl zu funktionalen als auch technischen Problemen führen, die nur mit einem enormen Zeit- und Kostenaufwand wieder beseitigt werden können.
Scrum Teams kümmern sich um alles Produktbezogene. Das umfasst unter anderem das Stakeholder Management, das Erfassen und die Verifikation von Anforderungen (in Form von Epics und User Stories), die Entwicklung eines wert- und sinnvollen Produktinkrements am Ende eines Sprints, den operativen Betrieb und was sonst noch alles anfallen könnte. In einem solchen Szenario kann es zu Situationen kommen, in denen die Teammitglieder eigenverantwortlich Entscheidungen im Sinne des Produktes treffen müssen. Um die Produktivität des Teams durch aufwendige Rücksprachen dazu nicht zu behindern, ist ein gewisser Spielraum förderlich, indem selbst Entscheidungen getroffen werden dürfen. Hierbei spricht man von Empowerment. Es ist ein wesentlicher Erfolgsfaktor von agilen Teams, wenngleich sich dieser Aspekt auf Grund der bereits oben genannten Herausforderungen als schwierig in der Praxis erweisen kann.
4.2 Entwickler als T-Shaped Professionals
Die Hauptaufgabe der Entwickler ist es, ein nutzbares Produktinkrement am Ende eines Sprints erzeugt zu haben. Wir werden in Kapitel 5.5 und 5.6 noch einmal intensiv auf diesen Punkt eingehen, da er ein essenzieller Bestandteil von Scrum ist und in der Praxis manches Mal falsch umgesetzt wird. Die Betonung liegt insbesondere auf nutzbares Produktinkrement, also etwas, was Fachabteilungen im operativen Geschäft verwenden können und das einen Nutzen, einen Mehrwert, bringt.
Die lediglich drei vorhandenen Rollen in Scrum erwecken den Eindruck, dass Vorgehensmodell sei einfach umzusetzen und strukturiert. In der praktischen Anwendung führt ebendiese Einfachheit jedoch gelegentlich zu Verwirrungen. Das Verständnis für das Konzept crossfunktionaler Teams ist deshalb umso wichtiger. Crossfunktional bedeutet, dass in einem Entwicklerteam alle notwendigen Kenntnisse, um ein Produktinkrement zu erzeugen, vorhanden sind. Zerlegen wir als Beispiel einen Softwareentwicklungsprozess in drei Schritte: Analyse, Programmierung, Testen. Ein Scrum Team würde mindestens diese drei Fähigkeiten abbilden müssen. Im Idealfall wird jeder Schritt von einem Experten begleitet, der über zusätzliches Know-how in den anderen Bereichen verfügt. Solche Teammitglieder bezeichnet man als T-Shaped ProfessionalsT-Shaped Professional (siehe Abbildung 6). Der große Vorteil besteht darin, dass T-Shaped Professionals Tiefenwissen (Expertenwissen) in einem Bereich besitzen und zeitgleich über ein Breitenwissen aus anderen Bereichen verfügt. Solche Mitarbeiter haben in der Regel einen scharfen Blick für das große Ganze und greifen die Gesamtzusammenhänge schnell; eine Fähigkeit, die besonders in dynamischen und agilen Arbeitsumgebungen von Vorteil ist.
Abbildung 6:
T-Shaped Professionals
Um die oben beschriebene Hauptaufgabe, ein nutzbares Produktinkrement am Ende eines Sprints zu erzeugen, erreichen zu können, sind folgende Tätigkeiten ebenfalls in der Verantwortung des Entwicklerteams: Das Team erzeugt einen Plan für den Sprint, das sogenannte Sprint Backlog. Hierin werden alle Aufgaben, die innerhalb des Sprints erledigt werden sollen, transparent aufgelistet. Um jedoch eine zielgerichtete Erledigung der Aufgaben zu gewährleisten, ist es notwendig, Abhängigkeiten bereits im Vorfeld zu identifizieren und die Planung entsprechend anzupassen. Wird dieser Punkt nicht beachtet, könnten einzelne Aufgaben die Tätigkeiten anderer Teammitglieder blockieren und somit die Erreichung des Sprintziels gefährden. Das Entwicklerteam ist maßgeblich für die Qualität des Produktes zuständig. Hierbei ist vor allem die Definition of Done wichtig, die konkret definiert, wann eine bestimmte Aufgabe oder User Story fertiggestellt ist. Qualität sollte dabei bereits als integraler Bestandteil des Entwicklungsprozesses gesehen werden, um sie von vornherein in das Produkt zu integrieren und nicht erst anschließend in aufwendigen Testphasen zu ergänzen. Dieser Umgang mit Qualität ist eine Umsetzung des Andon Cords, dass bei Toyota Verwendung findet und zu einer enormen Steigerung der Qualität geführt hat. Das Andon Cords ist eine Leine, die jeder Mitarbeiter entlang der Produktionsstrecke ziehen kann – und damit die gesamte Produktion stoppt –, sobald ihnen Qualitätsmängel auffallen. Als Folge werden Probleme und Qualitätsmängel frühzeitig im Prozess erkannt und können kostengünstiger korrigiert werden, als wenn man diese nach der Produktion feststellt. Die tägliche Anpassung des Plans gehört deshalb zu den Aufgaben eines Entwicklerteams. Die Korrekturen finden im Rahmen der Daily Stand-ups statt. Sie dienen dazu, den Weg zum Sprintziel zu optimieren und somit das Ziel schneller, effizienter oder günstiger zu erreichen. Veränderungen, die keinen Einfluss auf die Erreichung des Sprintziels haben sind obsolet. Darüber hinaus trägt jedes Teammitglied die Verantwortung, sich selbst und die anderen immer wieder aufs Neue in die Pflicht zu nehmen, die vereinbarten Ergebnisse im Rahmen eines Sprints zu erreichen.
4.3 Scrum Master als Servant Leader
Die Rolle des Scrum MastersScrum Master ist entscheidend bei der Implementierung von Scrum in Unternehmen. Der Scrum Master übernimmt gleich mehrere Schlüsselaktivitäten, die maßgeblichen Einfluss auf eine erfolgreiche Einführung haben. Zusammengefasst kann die Rolle so definiert werden, dass der Scrum Master der Dienstleister im Scrum Team ist, denn seine Hauptaufgaben als Servant LeaderServant Leader, die wir uns im Nachgang näher anschauen werden, weisen einen gewissen Dienstleistungscharakter auf.
Der Scrum Master ist dafür zuständig, Scrum als Produktentwicklungsmethode in einem Unternehmen einzuführen und zu etablieren. Diese Aufgabe beinhaltet zu einem großen Teil Training- und Coachingaktivitäten, um das Team und die Organisation zuerst mit den üblichen Begrifflichkeiten und ihren jeweiligen Bedeutungen bekannt zu machen. Ein wesentlicher Aspekt für die erfolgreiche Einführung von Scrum ist, dass die Aufgabe des Scrum Masters die Teamgrenzen überschreitet. Erst wenn auch das Stakeholder-Umfeld mit Scrum verstanden hat, wie Scrum funktioniert und welche Anforderung auf die umstehenden Parteien außerhalb des Teams zukommen, hat Scrum eine Chance, erfolgreich zu sein. Es ist dabei in der Praxis nicht so wichtig – der eine oder die andere mag hier widersprechen –, dass Scrum eins-zu-eins wie im Scrum Guide beschrieben umgesetzt wird. Vielmehr ist es ausschlaggebend, dass der Scrum Master das Unternehmen mit agiler Denkweise, dem oft zitierten Agile Mindset, vertraut macht und dass eine Variante von Scrum gefunden wird, die zum Unternehmen passt und bestmögliche Erfolgsaussichten hat. Weiterhin hat der Scrum Master die Aufgabe, sich um die Effektivität des Scrum Teams zu kümmern und es dabei zu unterstützen, sich stetig zu verbessern. Dies kann auf vielfältige Weise geschehen. Dazu gehören gut strukturierte Retrospektiven ebenso wie offene und ehrliche Gespräche mit dem Team und mit einzelnen Mitgliedern. Die in Managementliteratur immer prominenter werdende Transparenz kann sich genauso durch Teamzusammenkünfte mit allen Personen wie auch im Einzelgespräch mit den Mitgliedern herauskristallisieren. Die vertrauensvollere Atmosphäre unter vier Augen lässt die ein oder andere Schwierigkeit in den Aufgaben oder im Team manchmal eher ans Licht kommen. Das verdeutlicht, dass ein guter Scrum Master Fingerspitzengefühl für unangenehme Situationen oder schwelende Konflikte benötigt, um diese zeitnah zu beseitigen, bevor daraus größere Probleme erwachsen.
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.
