ISBN 978-3-8252-5974-7 Die utb-Reihe „Frag doch einfach! “ beantwortet Fragen, die sich nicht nur Studierende stellen. Im Frage-Antwort-Stil geben Expert: innen kundig Auskunft und verraten alles Wissenswerte rund um ein Thema. In diesem Band werden unter anderem Antworten auf diese Fragen zu lesen sein: Was ist das Geheimnis hinter dem Erfolgsphänomen? Welche Tools und Methoden haben Scrum so erfolgreich gemacht? Und wie kann es eingesetzt werden, um Projekte erfolgreich zu managen? Die wichtigsten Fachbegriffe werden zudem prägnant vorgestellt und es wird verraten, welche Websites, YouTube-Videos und Bücher das Wissen aus diesem Bandes vertiefen können. Das Buch richtet sich in erster Linie an Studierende des Fachbereichs Betriebswirtschaftslehre, aber auch an Interessierte zu diesem Thema. Management | Projektmanagement Scrum? 2. A. Kaiser | van Bennekum Dies ist ein utb-Band aus dem UVK Verlag. utb ist eine Kooperation von Verlagen mit einem gemeinsamen Ziel: Lehr- und Lernmedien für das erfolgreiche Studium zu veröffentlichen. utb.de QR-Code für mehr Infos und Bewertungen zu diesem Titel Fabian Kaiser Arie van Bennekum Scrum? Klare Antworten aus erster Hand 2. Auflage Frag doch einfach! 5974-7_Kaiser_Bennekum_M-5522.indd Alle Seiten 5974-7_Kaiser_Bennekum_M-5522.indd Alle Seiten 29.08.22 14: 43 29.08.22 14: 43 utb 5522 Eine Arbeitsgemeinschaft der Verlage Brill | Schöningh - Fink · Paderborn Brill | Vandenhoeck & Ruprecht · Göttingen - Böhlau · Wien · Köln Verlag Barbara Budrich · Opladen · Toronto facultas · Wien Haupt Verlag · Bern Verlag Julius Klinkhardt · Bad Heilbrunn Mohr Siebeck · Tübingen Narr Francke Attempto Verlag - expert verlag · Tübingen Psychiatrie Verlag · Köln Ernst Reinhardt Verlag · München transcript Verlag · Bielefeld Verlag Eugen Ulmer · Stuttgart UVK Verlag · München Waxmann · Münster · New York wbv Publikation · Bielefeld Wochenschau Verlag · Frankfurt am Main UTB (M) Impressum_03_22.indd 1 UTB (M) Impressum_03_22.indd 1 23.03.2022 10: 23: 51 23.03.2022 10: 23: 51 Fabian Kaiser ist Co-Gründer und Inhaber der Agile Heroes GmbH, einer der führenden Beratungen zum Thema Agiles Projektmanagement. Er ist Verfasser mehrerer Fachbücher zum Thema Agilität und Pro‐ jektmanagement. Arie van Bennekum ist einer der 17 Co-Autoren des Agilen Manifests. Er hat 1994 begonnen, auf die „sogenannte Agile Art und Weise“ zu arbeiten und ist seitdem nie wieder in alte Gewohnheiten zurück‐ gefallen. Im Laufe der Jahre hat er sich zu einem Experten für Agile Transformationen entwickelt und ist bekannt für seine kraftvollen Vorträge auf Kon‐ ferenzen, für Führungsteams und während (agilen) Transformationen. #fragdocheinfach Weitere Bände sind bereits in dieser Reihe erschienen: Agilität? Frag doch einfach! ISBN 978-3-8252-5790-3 Armut? Frag doch einfach! ISBN 978-3-8252-5554-1 Demokratie? Frag doch einfach! ISBN 978-3-8252-5446-9 Ein Start-up gründen? Frag doch einfach! ISBN 978-3-8252-5436-0 Homeoffice und mobiles Arbeiten? Frag doch einfach! ISBN 978-3-8252-5664-7 Nachhaltigkeit für Deutschland? Frag doch einfach! ISBN 978-3-8252-5435-3 Mobilität im 21. Jahrhundert? Frag doch einfach! ISBN 978-3-8252-5662-3 Scrum? Frag doch einfach! ISBN 978-3-8252-5974-7 Virtuelle Teams führen? Frag doch einfach! ISBN 978-3-8252-5780-4 Fabian Kaiser / Arie van Bennekum Scrum? Frag doch einfach! Klare Antworten aus erster Hand 2., vollständig überarbeitete Auflage UVK Verlag · München DOI: https: / / doi.org/ 10.36198/ 9783838559742 2., vollständig überarbeitete Auflage 2022 1. Auflage 2021 © UVK Verlag 2022 ‒ ein Unternehmen der Narr Francke Attempto Verlag GmbH + Co. KG Dischingerweg 5 · D-72070 Tübingen Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetztes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Ver‐ vielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Alle Informationen in diesem Buch wurden mit großer Sorgfalt erstellt. Fehler können dennoch nicht völlig ausgeschlossen werden. Weder Verlag noch Autor: in‐ nen oder Herausgeber: innen übernehmen deshalb eine Gewährleistung für die Korrektheit des Inhaltes und haften nicht für fehlerhafte Angaben und deren Folgen. Diese Publikation enthält gegebenenfalls Links zu externen Inhalten Dritter, auf die weder Verlag noch Autor: innen oder Herausgeber: innen Einfluss haben. Für die Inhalte der verlinkten Seiten sind stets die jeweiligen Anbieter oder Betreibenden der Seiten verantwortlich. Internet: www.narr.de eMail: info@narr.de Einbandgestaltung: Atelier Reichert, Stuttgart CPI books GmbH, Leck utb-Nr. 5522 ISBN 978-3-8252-5974-7 (Print) ISBN 978-3-8385-5974-2 (ePDF) ISBN 978-3-8463-5974-2 (ePub) Umschlagabbildung und Kapiteleinstiegsseiten: © bgblue - iStock Abbildungen im Innenteil: Figur, Lupe, Glühbirne: © Die Illustrationsagentur Autorenfoto: privat Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http: / / dnb.dnb.de abrufbar. www.fsc.org MIX Papier aus verantwortungsvollen Quellen FSC ® C083411 ® www.fsc.org MIX Papier aus verantwortungsvollen Quellen FSC ® C083411 ® 9 13 17 18 18 20 22 23 25 27 27 28 29 32 34 36 37 38 39 41 41 Alle Fragen im Überblick Vorworte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Was die verwendeten Symbole bedeuten . . . . . . . . . . . . . . . . Scrum ist in aller Munde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wie sollte Agilität und Scrum heute grundsätzlich gesehen werden? . . Für was steht der Begriff ‚Scrum‘? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hat Scrum eine Geschichte? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wenn Scrum agil ist, was ist Agilität? . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wieso wird Agilität aktuell gehypt? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ist Scrum so beliebt, weil Agilität gehypt ist? . . . . . . . . . . . . . . . . . . . . . . Wo wird Scrum eingesetzt? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ist Scrum überhaupt überall anzuwenden? . . . . . . . . . . . . . . . . . . . . . . . . Wer ist der Kunde und was ist das Produkt? . . . . . . . . . . . . . . . . . . . . . . . Ersetzt Scrum das klassische Projektmanagement? . . . . . . . . . . . . . . . . . Was versteht man unter dem Cynefin-Framework? . . . . . . . . . . . . . . . . . Wie findet die Entscheidung für die richtige Vorgehensweise konkret statt? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Heißt das, dass es bei Scrum keine Hierarchien gibt? . . . . . . . . . . . . . . . Aufbau und Funktionsweise von Scrum . . . . . . . . . . . . . . . . . . Was sind die wesentlichen Bestandteile von Scrum? . . . . . . . . . . . . . . . . Wie funktioniert der Scrum-Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Welche Teammitglieder bzw. Verantwortlichkeiten gibt es in Scrum? . . Was ist ein Scrum Master? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 43 46 47 47 49 50 50 51 52 54 56 58 60 60 61 63 64 65 68 69 70 71 71 72 74 74 Wie finde ich einen Scrum Master? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Können wir diese Lösungsmöglichkeiten detaillierter anschauen? . . . . Können wir die Vorteile einer externen Besetzung detaillierter betrachten? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kann man hieraus eine einfache Entscheidungsregel ableiten? . . . . . . . Was ist ein Product Owner? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wie finde ich einen Product Owner? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sind also externe Product Owner die beste Option? . . . . . . . . . . . . . . . . . Was macht das Entwicklungsteam? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wie finde ich die perfekten Entwickler? . . . . . . . . . . . . . . . . . . . . . . . . . . Auch wenn diese Entscheidungshilfe nicht nur Scrum-Beteiligte betrifft; welche Überlegungen stecken hinter diesen Personalauswahlkriterien? Was bin ich nun, wenn ich Projektmanager war? . . . . . . . . . . . . . . . . . . . Welche Werte gibt es in Scrum? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Welche Funktion haben Events in Scrum? . . . . . . . . . . . . . . . . . . . . . . . . . Wer trägt die Verantwortung für die Timebox? . . . . . . . . . . . . . . . . . . . . Sind Meetings ein originärer Bestandteil von Scrum? . . . . . . . . . . . . . . . Was ist ein Sprint? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wie lange dauert ein Sprint tatsächlich? . . . . . . . . . . . . . . . . . . . . . . . . . . Kann ein Sprint geändert oder angepasst werden? . . . . . . . . . . . . . . . . . . Was ist ein Sprint Planning? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wie lange darf ein Sprint Planning dauern? . . . . . . . . . . . . . . . . . . . . . . . Was ist ein Daily Scrum? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ist das Daily Scrum sehr wichtig für die Praxis? . . . . . . . . . . . . . . . . . . . . Hat Daily Scrum etwas mit Daily Standup zu tun? . . . . . . . . . . . . . . . . . . Muss man sich beim Daily Scrum an einem Ort physisch treffen? . . . . . Was ist ein Sprint Review? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Warum ist das Sprint Review gerade in einem dynamischen Umfeld so wichtig? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gibt es auch für das Sprint Review eine Zeitvorgabe? . . . . . . . . . . . . . . . 6 Alle Fragen im Überblick 74 75 77 77 79 79 81 82 83 84 85 87 87 88 89 90 91 91 93 94 95 96 97 98 War trägt die Verantwortung für das Sprint Review? . . . . . . . . . . . . . . . . Was ist eine Sprint-Retrospektive? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wird die Sprint-Retrospektive nicht auch kritisch gesehen? . . . . . . . . . . Was ist das eigentliche Ziel der Sprint-Retrospektive? . . . . . . . . . . . . . . Gibt es ein anschauliches Beispiel für eine praxistaugliche Retrospektive? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Was ist ein Refinement? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wer ist für den Ablauf des Refinements verantwortlich und was ist das Ziel? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Welche Artefakte gibt es? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Welche Commitments sind den jeweiligen Artefakten zugeordnet? . . . Was versteht man unter einem Product Backlog genau? . . . . . . . . . . . . . Was ist ein Sprint Backlog? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wann im Scrum-Prozess wird das Sprint Backlog von den Beteiligten eingesehen? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wer ist für das Sprint Backlog verantwortlich? . . . . . . . . . . . . . . . . . . . . . Was ist ein Inkrement? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Was ist ein Commitment? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Was ist ein Product Goal? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Welche Tools finden in Scrum Anwendung? . . . . . . . . . . . . . . . . . . . . . . Was zeichnet das Scrum-Tool Jira aus? . . . . . . . . . . . . . . . . . . . . . . . . . . . . Was bietet das Scrum-Tool Confluence? . . . . . . . . . . . . . . . . . . . . . . . . . . Wie funktioniert Confluence und was sind die Vorteile dieser Anwendung? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Für wen eignet sich Confluence am besten? . . . . . . . . . . . . . . . . . . . . . . . Welche Vorteile bietet das Scrum-Tool Miro? . . . . . . . . . . . . . . . . . . . . . . Für wen eignet sich Miro? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Welche Vorteile bietet das Scrum-Tool Scrumpanion? . . . . . . . . . . . . . . . 7 Alle Fragen im Überblick 101 102 103 104 106 107 109 109 110 112 113 114 114 115 116 117 118 125 127 133 Die Praxisumsetzung von Scrum . . . . . . . . . . . . . . . . . . . . . . . . . Ist Scrum für mein Projekt geeignet? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wie findet man heraus, ob Scrum sich für mich persönlich eignet? . . . . Was ist ein Sprint Goal? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Was ist eine Definition of Done? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Was ist eine Definition of Ready? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hat Scrum Grenzen in der Praxis? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gibt es dafür ein Beispiel? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wann funktioniert Scrum in der Praxis? . . . . . . . . . . . . . . . . . . . . . . . . . . Wie kommt man an die richtigen Mitarbeiter für Scrum-Projekte? . . . . Anerkennung des Scrum-Know-hows . . . . . . . . . . . . . . . . . . . . Gibt es vergleichbare Aus- und Weiterbildungen? . . . . . . . . . . . . . . . . . . Welche Zertifizierungsinstitute gibt es für Scrum? . . . . . . . . . . . . . . . . . . Welche Zertifizierungen gibt es? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wie kann ich mich auf die Zertifizierung vorbereiten? . . . . . . . . . . . . . . Habe ich als Leser dieses Buches einen Vorteil? . . . . . . . . . . . . . . . . . . . . Welche Fragen kommen in einer Scrum-Musterprüfung auf mich zu? . Wie lauten die Lösungen auf diese Prüfungsfragen? . . . . . . . . . . . . . . . . Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Alle Fragen im Überblick Vorworte „Survival of the fittest“ - ein Ausdruck, der in der Evolutionstheorie beschreibt, wie essenziell die Anpassungsfähigkeit für das Überleben ist. Heute beschreiben wir dies als agil. Und gerade die Pandemiejahre zeigen eindrucksvoll, wie anpassungsfähig und agil Menschen und Unternehmen sein müssen und auch sein können. Auch dieses Buch entstand während der Coronakrise, einer Krise, die uns wirtschaftlich und psychisch vor völlig neue Herausforderungen gestellt hat. Auf einmal tragen wir alle eine Maske. Unternehmen, die vorher gänzlich analog arbeiteten, müssen plötzlich sich und ihre Geschäftsmodelle völlig neu denken. Andererseits erleben Unternehmen wie Amazon und Zoom, die früher schon digital waren, einen wahrlichen Boom. Jenseits des gesundheitlichen Aspekts zeigt diese Krise auf sehr ein‐ drucksvolle Weise, dass das Evolutionsgesetz „Survival of the fittest“ auch in unserem Wirtschaftssystem weiterhin Gültigkeit besitzt. Aus diesem Grund wird das Thema Agilität für jedes Unternehmen und jeden Menschen noch wichtiger als bislang. Es gilt nicht „nur“ eine digitale Disruption zu bewältigen, die Herausforderung ist viel größer als das. Einer der elementarsten Bestandteile von Agilität ist das Prozessrahmen‐ werk Scrum. Scrum bietet die Möglichkeit, mit einer Auswahl an Prozessen und Techniken auf schlanke Weise Produkte zu entwickeln und kontinuier‐ lich weiterzuentwickeln. Wer heute mit aufstrebenden Tech-Sart-ups oder den coronabedingten Veränderungen der Arbeitswelt insgesamt zu tun hat, der kommt an den Themen Agilität und Scrum - und damit an diesem Buch - nicht vorbei. Genau ein Jahr später, bei der Verfassung der Neuauflage diesen Buches lese ich mir diese Zeilen des Vorwortes vor. Inhaltlich aktueller denn je: Ge‐ schäftsmodelle, Prozessuale Abläufe, Lieferketten - alles muss flexibel und neu gedacht werden. Nur die Gründe dafür könnten unterschiedlicher nicht sein. Krieg und Energie Krise, im Juli 2021 verschwendete ich dazu kaum einen Gedanken. Sind diese Aspekte heute schon ein weitere Hauptreiber, Unternehmen noch flexibeler aufzustellen. Als in den vergangenen Wochen ein Head of Suply Chain Management mein Team und mich für ein Agile Workshop im Bereich des Lieferan‐ ten-Managements von Flugzeugen beauftragte, vor welchen neuen Heraus‐ forderungen unsere Unternehmen stehen. Genauso beindruckend empfand ich die Lösung die wir gemeinsam erarbeiteten und feststellte, wie viele Bereiche von Scrum und Agilität auch in diesem Bereich des Unternehmens funktionieren kann und heut zu tage muss. Fabian Kaiser Frankfurt, im Juli 2022 10 Vorworte Agile ist nicht länger ein Trend, Agile ist der Standard. Gleichzeitig ist Agile immer noch voller Legenden, Mythen, offen für viele Interpretationen und oft haben die Menschen Schwierigkeiten, die Vorteile von Agile wirklich zu verstehen. Um ein tieferes Verständnis für das Warum von Agilität und jedweder Agile-Methode zu bekommen, ist es hilfreich, sich gemeinsam mit denjenigen, mit denen man später zusammenarbeitet, am Anfang zu alignen und zu besprechen, wie die agile Transformation ablaufen soll. Diesem Zweck dient dieses Buch. Fabian und ich haben gemeinsam Antworten gefunden, die dir und deinem Team weiterhelfen. Unser Ansatz‐ punkt war einfach, indem wir sehr prominente Fragen auswählten und uns gemeinsam darauf stürzten. Das Endergebnis ist dieses praktische Buch, das dir als Leser eine wichtige Agile Methode, nämlich Scrum, näherbringt. Lies dieses Buch zu deinem Nutzen und wenn du den Nutzen siehst, teile die Antworten dieses Buches mit den Menschen um dich herum, mit genau dem gleichen Zweck, sich gegenseitig voranzubringen. Arie van Bennekum Hardinxveld-Giessendam, im Juli 2021 11 Vorworte Was die verwendeten Symbole bedeuten Toni verrät dir spannende Literaturtipps, YouTube-Seiten und Blogs im World Wide Web. Die Glühbirne zeigt eine Schlüsselfrage an. Das ist eine der Fragen zum Thema, deren Antwort du unbedingt lesen solltest. Die Lupe weist dich auf eine Expertenfrage hin. Hier geht die Antwort ziemlich in die Tiefe. Sie richtet sich an alle, die es ganz genau wissen wollen. → Wichtige Begriffe sind mit einem Pfeil gekennzeichnet und werden im Glossar erklärt. Scrum ist in aller Munde Dieses einführende Kapitel beschreibt die Gründe für die Popularität von Scrum und vergleicht es mit dem klassi‐ schen Projektmanagement. Wie sollte Agilität und Scrum heute grundsätzlich gesehen werden? „Nur weil Scrum ein Hammer ist, ist nicht die ganze Welt ein Nagel“ - mit diesen Worten brachte unser Sales-Mitarbeiter Michael nicht nur mich, sondern auch die Kundschaft, die uns im Teams Call gegenübersaß, zum Lachen. Wir pitchen um einen großen Trainingsrahmenvertrag für unsere Scrum-Trainings bei einem großen Beratungshaus. Diese Metapher beschreibt sehr eindringlich eine gute Einstellung zum Verhältnis von Agilität einerseits und Scrum andererseits. Viele sehen tatsächlich in Scrum eine Art Religion, gehen entsprechend rigoros in die Projektarbei und sind enttäuscht, wenn Scrum nicht akribisch umgesetzt werden kann. Wir empfehlen demnach folgende pragmatische Leitlinien formuliert, mit denen eine erfolgreiche Umsetzung wahrscheinlich ist: 1. Agilität und Scrum passt nicht überall. 2. Aber wenn es passt, dann muss es nicht immer nach dem Lehrbuchideal sein. 3. Agilität und Scrum dienen nie dem Selbstzweck, vielmehr soll deren Anwendung ein Produkt, ein Team oder ein Unternehmen erfolgreicher machen. Für was steht der Begriff ‚Scrum‘? Der Begriff ‚Scrum‘ ist keine Abkürzung. Vielmehr ist Scrum metaphorisch zu verstehen. Denn die Begrifflichkeit findet man neben dem hier gemeinten Prozessrahmenwerk auch im Rugbysport. Hierbei beschreibt Scrum den Spielzug, bei dem alle Spieler dichtgedrängt stehen und durch eine Team‐ leistung versuchen, den Ball zu ergattern. 18 Wie sollte Agilität und Scrum heute grundsätzlich gesehen werden? Abb. 1 In der Metapher gesprochen ist hiermit gemeint, dass nur durch eine enge Zusammenarbeit und Teamleistung ein Ziel erreicht werden kann. Die Wortherkunft des Begriffs ‚Scrum‘ beschreibt damit bereits sehr eindrucks‐ voll die Grundhaltung hinter dem Scrum-Framework. Fernab des Rugbys findet der Begriff Scrum in immer mehr Projekten Wiederhall. Nahezu alle im Projektgeschäft tätigen kennen inzwischen die Inhalte und Hintergründe von Scrum. Fragt man erfahrene Projektmanager, fällt auf, dass Scrum grundsätzlich eher für sehr gute Erfolge steht. Wobei stets auch die Budgetüberschreitungen klassischer Projektbearbeitungen im Blick sein müssen. Videotipp: Ein Beispiel für den diesen Rugbyspielzug findest du hier: ► https: / / youtu.be/ VIfD0nuocVo 19 Scrum ist in aller Munde Hat Scrum eine Geschichte? Und was für eine! Die beiden Erfinder von Scrum, Ken Schwager und Jeff Sutherland, haben Scrum zum ersten Mal auf einer Softwarekonferenz im Jahre 1995 in der heutigen Form vorgestellt. Das Besondere war, dass sie Scrum in einigen Jahren davor schon in Projekten angewendet hatten und damit kontinuierlich verbessern konnten. Ihre Erfahrungen haben die bei‐ den in einem offiziellen Dokument, dem →Scrum Guide, zusammengefasst. Gestartet im Bereich der Softwareentwicklung schauen wir heute auf 90 Millionen Menschen, die Scrum kennen und anwenden - auch außerhalb der IT. Heute, gute 25 Jahre nach Bekanntmachung, erlebt Scrum einen echten Mainstream-Hype. Abb. 2 20 Scrum ist in aller Munde Einerseits ist die Übertragbarkeit von Scrum auf andere Anwendungsberei‐ che ein Vorteil. Andererseits birgt dies jedoch das Risiko, dass Scrum als Lösung für alles angesehen wird, womit eine Enttäuschung vorprogram‐ miert ist. Abb. 3 Umso wichtiger ist es, der Beliebigkeit bei der Anwendung von Scrum entgegenzuwirken, um diese Methode weitere 25 Jahre in die richtige Richtung weiterzuentwickeln. Videotipp: Hier geht es zum Interview mit Jeff Sutherland: ► https: / / youtu.be/ P_6Orv3R9Mg 21 Scrum ist in aller Munde Wenn Scrum agil ist, was ist Agilität? Scrum ist ein nicht zu verkennender Teilbereich der Agilität. Man kann sagen, Scrum ist agil, aber Agile (Agilität) ist nicht Scrum. Scrum ist demnach ein agiles Prozessmodell innerhalb der Welt der Agilität. Und genau diese Welt ist es, die aktuell das Berufsleben so sehr verändert. Jeder möchte agil sein bzw. jedes Unternehmen möchte agil sein. Abb. 4 Aber was genau bedeutet Agile im wirtschaftlichen Kontext wirklich? Ist es das neue krawattenlose Büro-Erscheinungsbild? Ist es das Duzen, das von der Vorstandsebene bis zu den Mitarbeitern durchgereicht wird? Ist es das morgendliche Kurzmeeting, welches auf einmal im Stehen abgehalten wird? Vielleicht auch. 22 Scrum ist in aller Munde Vielleicht sind das aber auch nur die Randphänomene oder sichtbaren Symptome einer neuen, modernen Arbeitswelt, die zum Teil durch Agilität entstanden sind. Agilität bedeutet aber weitaus mehr. Es bedeutet einen Mindset-Change des gesamten Unternehmens. Auf allen Hierarchieebenen. Ein Mind‐ set-Change, der nicht nur das oben beschriebene Offensichtliche meint, sondern Vertrauen durch Transparenz schafft. Ein Mindset-Change, der Selbstorganisation fördert und Talente zu kreativen Umsetzern macht. Ein Mindset-Change, der schnell entlang der Bedürfnisse einen Mehrwert für das Wichtigste eines jeden Unternehmen stiftet: den Kunden. Ein Mind‐ set-Change, der es schafft, eine offene und wertschätzende Fehlerkultur in den Unternehmensalltag zu integrieren. Erst wenn diese Metaebene in einer Organisation erkannt, verstanden und akzeptiert wird, dann wird Agilität gelebt. Und erst, wenn man es schafft, Agilität so zu leben, dass man es nicht mehr Agilität nennen muss, dann kann man als Unternehmen nicht mehr scheitern. Oft werden in diesem Zusammenhang Erfolgsbeispiele wie Google, Tesla oder Amazon genannt. Diese Unternehmen sprechen aber nie wirklich davon, dass sie jetzt agil sind. Sie leben es einfach. Videotipp: Hier erklärt der Autor in weniger als fünf Minuten Agilität: ► https: / / youtu.be/ DAV5xGAVexw Wieso wird Agilität aktuell gehypt? Die Antwort hierauf verbirgt sich im letzten Absatz der vorangegangenen Antwort. Jeder möchte aktuell so werden, wie die oben genannten und vor allem am Aktienmarkt so beliebten Tech-Leader aus den USA. Aber so weit muss man noch nicht einmal fliegen, um Referenzunternehmen zu finden: Man kann sie auch in Marktnischen in Deutschland entdecken. Denn hier stellen etablierte, konventionelle Unternehmen fest, wie schnell und unvorhergesehen ein konkurrierendes, vielleicht sogar junges Start-up-Un‐ ternehmen einem doch den Rang ablaufen kann. Gute Beispiele sind hierfür: 23 Scrum ist in aller Munde ▶ Freenow (früher MyTaxi), die mit einer App den gesamten Taximarkt innerhalb von fünf Jahren verändert haben. ▶ Flixbus, eine günstige Plattform für Fernbusse, die nicht nur die Deut‐ sche Bahn unter Druck setzen, sondern auch jeden privaten Busun‐ ternehmer in Deutschland dazu bringen, sein Geschäftsmodell ohne Plattformteilnahme ernsthaft zu hinterfragen. ▶ N26, die als Mobil-Bank aktuell jeden Tag 10.000 neue Kunden gewin‐ nen und bei diesem Wachstum DAX-notierte Banken in den nächsten zwei Jahren kundenseitig überholen werden. Auch diese Unternehmen brauchen keine Weiterbildung dazu, wie Agilität funktioniert. Sie sind der Inbegriff dessen. Außerdem sind sie für viele Unternehmen der handelsregistermanifestierte Inbegriff von Angst. Zusammenfassend kann man sagen, dass Unternehmen heute alle agil werden wollen, weil sie durch viele bereits agile Unternehmen unter Druck gesetzt werden, weil sie von externen Umwelteinflüssen wie Corona unter Druck gesetzt werden oder weil sie durch die Erfolge der fabelhaften GAFA-Unternehmen (Google, Apple, Facebook, Amazon) motiviert werden. Lesetipp: Weitere Infos zum Thema findest du im Magazinartikel „Warum Agilität kein Hype ist“: ► https: / / www.agile-heroes.de/ magazine/ agilitaet-kein-hype/ 24 Scrum ist in aller Munde Abb. 5 Ist Scrum so beliebt, weil Agilität gehypt ist? Diese Frage ist nicht einfach zu beantworten. Grundsätzlich gilt, dass Agili‐ tät aktuell ein echter Hype ist. Wenn man sich mit dem Thema Agilität näher beschäftigt, wird man über kurz oder lang nicht an Scrum vorbeikommen. Denn wer agil werden will, der fragt sich natürlich schon bald: Wie bzw. welche Best-Practice-Frameworks kann ich anwenden, um agil bzw. agiler zu werden? Der Agilitätshype spielt dem Framework von Scrum demnach in die Karten. Aus diesem Grund könnte man dieser These zustimmen und festhalten, dass Scrum gerade so beliebt ist, weil es auch unter das Konzept der Agilität fällt. 25 Scrum ist in aller Munde Scrum ist in der Welt der Agilität allerdings nicht das einzige Framework, jedoch das bekannteste bzw. das am häufigsten verwendete. Im Zuge dessen könnte man sich natürlich fragen, wieso gerade Scrum am meisten Verwendung fand und findet. Abb. 6 Die Antwort darauf könnte lauten: weil es das beste Framework ist. Eine andere Antwort könnte sein: weil die Erfinder das beste Marketing gemacht haben. Welche Antwort man auch findet, eine echte Garantie, dass diese richtig ist, kann man nicht geben. Fakt ist jedoch: Viele erfolgreiche Produkte und Projekte werden mit Scrum durchgeführt. Viele Unternehmen schwören darauf. Und last, but not least ist Agilität ein Megatrend. Vielleicht ist es auch eine Mischung aus all diesen Faktoren, die dazu geführt haben, dass Scrum das mit Abstand bekannteste und offenbar beliebteste Framework ist. 26 Scrum ist in aller Munde Wo wird Scrum eingesetzt? Als im Jahr 1995 Ken Schwaber und Jeff Sutherland das Scrum-Framework in seiner heutigen Form vorstellten, waren die dort niedergeschriebenen Erfah‐ rungswerte ausschließlich im Bereich der Softwareentwicklung gesammelt worden. Heute, 25 Jahre später, ist es immer noch so, dass die Mehrzahl der Anwendungsfälle im Softwarebereich liegt. Ohne hier auf Statistiken zurückgreifen zu können, wären realistische Schätzung im Bereich von 80 % zu taxieren. Hintergrund ist hierbei, dass die Software der perfekte Use Case für Scrum ist. Denn (vereinfacht gesagt) ein Button in einer App ist in zwei Minuten angepasst. Ein Türgriff in einem Haus hingegen ist mit deutlich höherem Aufwand anzupassen. Hier stellt sich unmittelbar die nächste Frage: Ist Scrum überhaupt überall anzuwenden? Und die klare direkte Antwort zu der Frage ist: Nein. Scrum ist nicht überall anwendbar. Zumindest nicht in seiner vollständigen Form, die dann aber auch per definitionem nicht mehr Scrum wäre. Es gilt jedoch zu beachten, dass fernab der in Scrum niedergeschriebenen Definition, „Scrum ist nur in seiner Reinform wirklich Scrum“, natürlich Teile davon in komplett un‐ terschiedlichen Branchen, Unternehmen und Projekten Anwendung finden können und jene Akteure dann gerne auch publik machen, sie würden nach Scrum arbeiten. Um aber hier die Frage, wo und wann Scrum eingesetzt wird, seriös beantworten zu können, muss zunächst die Frage gestellt werden, welchen Mehrwert eine Arbeit mit Scrum bietet. Der Mehrwert bezieht sich hierbei - ohne an dieser Stelle ins Detail zu gehen - neben den vielen team- und softskillbasierten Mehrwerten vor allem auf die schnelle Entwicklung und Lieferung von Produktkomponenten. „Schnell“ bedeutet hierbei frühestens alle 14 Tage. Welchen Vorteil bietet es aber, eine neue Produktkomponente alle 14 Tage fertigzustellen oder gar auf den Markt zu bringen? Ganz einfach: Feedback von den Kunden. Hierdurch ermöglicht man eine Entwicklung, bei der der Kunde in den Entwicklungsprozess sehr stark eingebunden ist. Der Kunde kann Feedback geben und man kann weiter an seinem Produkt arbeiten - und zwar so, wie es dem Kundenbedürfnis am ehesten 27 Scrum ist in aller Munde entspricht. Der Kunde muss nicht wieder ein ganzes Jahr, sondern ledig‐ lich 14 Tage auf die Berücksichtigung oder Einarbeitungen des Feedbacks warten. Das bedeutet einerseits, dass man sehr schnell erkennt, ob die Umsetzung der kundenseitigen Anforderung wirklich das bringt, was man sich erhofft hat. Andererseits wird das Risiko reduziert, etwas zu entwickeln, was vollkommen am Kundenbedarf vorbeigeht. In diesem Fall wäre eine Zeitverschwendung von 14 Tagen im Vergleich zu einem Jahr sehr viel kostengünstiger. Wer ist der Kunde und was ist das Produkt? Wer der Kunde ist, ist völlig frei zu definieren. Hierbei kann es sich um den klassischen Endkunden handeln, es kann aber auch ein unternehmens‐ interner Kunde sein - also beispielsweise eine Unternehmensabteilung. Auch das Produkt, das hier generisch beschrieben wird, ist frei wählbar. Jedoch wird schnell ersichtlich, dass Produkte, die im besten Fall nach 14 Tagen zur Auslieferung bereitstehen, eher softwarebasiert sind. Hierbei ist Tesla einmal mehr ein sehr gutes Beispiel. Ein Tesla Model 3 ist in seiner Hardware nach Auslieferung nur noch schwer, nämlich über Werkstattbesuche oder Rückrufaktionen, zu ändern oder gar weiterzuentwi‐ ckeln. Darüber hinaus kann ein bestehendes analoges Produkt eher schwer umgebaut werden - im Vergleich zu einer Software. Es kann am Auto nicht mühelos ein Teil abgesägt und ein neues hinzugefügt werden. Dies würde jegliches Kosten-Nutzen-Verhältnis zerstören. Anders sieht es bei der Software des Fahrzeugs aus: Ob der Softwareent‐ wickler einen Button oder gar eine ganze Funktion ändert, ist im Verhältnis kein großer Aufwand. Hinzu kommt, dass diese Änderung nur ein einziges Mal durchgeführt werden muss und dann „per Knopfdruck“ über das Internet in jedes Tesla-Fahrzeug weltweit eingebunden werden kann. Und wenn es am Ende nicht den erhofften Mehrwert für den Kunden bringt, kann es auch wieder relativ einfach entfernt werden. Das beschreibt einfach und doch eindrucksvoll, wo Scrum wirklich seinen vollen Mehrwert im Produktbereich entfalten kann. Weitere Mehrwerte sind neben der schnelleren und bedarfsgerechten Produktentwicklung vor allem im Team-Softskill-Bereich einzuordnen. 28 Scrum ist in aller Munde Ersetzt Scrum das klassische Projektmanagement? Um dieser Frage gerecht zu werden, lohnt es sich, etwas tiefer in den Bereich des Projektmanagements einzusteigen. Grundsätzlich werden drei Projektmanagementansätze unterschieden: ▶ klassisch ▶ agil ▶ hybrid Klassisch: Klassisches Projektmanagement beschreibt demnach einen Ansatz, ein Projekt von Anfang bis Ende grob durchzuplanen und dabei lange, über mehrere Monate andauernde Phasen zu durchlaufen und am Ende mit einem „Big Bang“ das Produkt auf den Markt zu bringen. Wer sich jetzt an das Beispiel aus den vorherigen Kapiteln erinnert, dem wird auffallen, dass hier nie ein Produkt in einem „Big Bang“ auf den Markt gebracht, sondern dieses Produkt immer inkrementell, also Stück für Stück, mit dem Markt entwickelt wurde. Videotipp: Was ist klassisches Projektmanagement? Antworten findest du unter: ► https: / / www.youtube.com/ watch? v=FKCom8wziEk 29 Scrum ist in aller Munde Abb. 7 30 Scrum ist in aller Munde Agil: Wirft man nun einen Blick auf das agile Vorgehen, so fällt auf, dass die Phasen aus dem klassischen Projektmanagement auch hier Anwendung finden, diese aber nicht einmalig über einen langen Zeitraum funktionieren, sondern innerhalb unserer beispielhaften 14 Tage. Also viel schneller. Das Produkt ist hier zur selben Zeit wie im klassischen Projektmanagement im „finalen“ Zustand angekommen, jedoch in einer ganz anderen Ausprägung. Und: Teile des jetzt finalen Produkts waren bereits viel früher für den Kunden verfügbar. Dadurch ergeben sich schnelles Kundenfeedback und auch ein bereits generierter Umsatz. Hybrid: Hierbei wird über ein agiles Vorgehen auf Teamebene ein klassisches Projektmanagement gestülpt. Hintergrund ist, dass Unternehmen bei die‐ sem Zwischenmodell keine erheblichen Veränderungen beispielsweise in der Unternehmensorganisation vornehmen müssen. Weitere Vorteile der hybriden Vorgehensweise sind, dass Teams in den Genuss von agiler, selbstorganisierter Arbeit kommen, man aber dennoch ein Projekt mit einem „Big Bang“ auf den Markt bringen kann. Ein hybrides Vorgehen birgt neben der großen Chance, Vorteile aus beiden Welten zu vereinen, das große Risiko, am Ende mit den Nachteilen aus beiden Welten zu arbeiten. Nach einer solchen Differenzierungsdarstellung wird klar, dass ein agiles Vorgehen - auch im Projektmanagement - mit an Sicherheit grenzender Wahrscheinlichkeit nie ein klassisches Vorgehen komplett verdrängen wird. Vielmehr gilt es für jedes Vorhaben die Frage zu beantworten: Wann wird welches Modell eingesetzt? Diese Frage ist gewiss nicht das erste Mal gestellt worden. Hier hilft das Cynefin-Framework weiter. 31 Scrum ist in aller Munde Literaturtipp: Ein Lehr- und Fachbuchklassiker ist das ebenfalls bei utb erschienene Werk Projektmanagement von Franz Xaver Bea, Steffen Scheurer und Sabine Hesselmann: https: / / www.utb.de/ doi/ book/ 10.36198/ 9783838587066 Was versteht man unter dem Cynefin-Framework? Um auf die häufig gestellte Frage, wann man agil und wann klassisch an ein Projekt herangehe, eine solide Antwort zu entgegnen, kommt man an dem Cynefin-Framework nicht vorbei. Auch große und bekannte Projektmana‐ gementmethoden wie PRINCE2 führen es an, um diese zentrale Frage zu beantworten. Ziel dieses Frameworks ist es, durch verschiedene Sachverhaltsbeispiele herauszufinden, welches Vorgehen zu welcher Herausforderung möglicher‐ weise am besten passt. Wichtig dabei ist das Wort „möglicherweise“. Denn auch ein Cynefin-Framework oder eine Voreinschätzung der Ausgangssi‐ tuation kann falschliegen. Es gibt damit keine Garantie, die richtige Wahl zu treffen. Es hilft allerdings dabei, das Risiko der falschen Vorgehensweise zu reduzieren. Im Folgenden wird das Cynefin-Framework in voller Breite, jedoch nicht in aller Tiefe beleuchtet. 32 Scrum ist in aller Munde Abb. 8 Schaut man sich nun die grafische Darstellung des Cynefin-Frameworks an, so fällt auf, dass es hierbei fünf Bereiche gibt, welche als unterschiedliche Herausforderungslagen beschrieben werden: ▶ Obvious ▶ Complicated ▶ Complex ▶ Disorder (mittleres, unbeschriftetes Feld) ▶ Chaotic Quellenhinweis: Die Grafik stammt aus Wikipedia. 33 Scrum ist in aller Munde Wie findet die Entscheidung für die richtige Vorgehensweise konkret statt? Dies erfolgt durch eine Zuordnung: Obvious: Hierbei handelt es sich um eine Ausgangslage, die bekannt ist. Die Abläufe sind unzählige Male durchlaufen und die Ergebnisse schon oft in derselben Art und Weise fertiggestellt worden. Hat man es mit dieser Ausgangslage zu tun, stellt sich nicht die Frage nach einer richtigen Projektvorgehensweise, da es sich um kein Projekt handelt. Es handelt sich um business as usual, um standardmäßige Linientätigkeiten. Complicated: Diese Ausgangslage beschreibt eine Situation, in der eine nicht standard‐ mäßige Aufgabe erfüllt werden muss. Ähnliche Aufgaben wurden bereits öfter im Unternehmen oder von Kollegen erfüllt. Die Anforderungen sind sehr klar formuliert und das erwartete Ergebnis steht deutlich vor Augen. Hierbei handelt es sich um ein Projekt, das in der klassischen Projektma‐ nagementvorgehensweise durchgeführt werden sollte. Typische Projekte hierfür wären bestandsablösende Systeme, bei denen alle Anforderungen aus dem alten System übernommen werden können und bei denen auch nicht eine schlanke, neue Version live genommen werden kann. Complex: Hat meine eine Ausgangslage, in der die Anforderungen nicht sehr klar sind, also Zusammenhänge und Abhängigkeiten schwer zu durchschauen sind, gleichzeitig das Endergebnis nur wage bekannt ist und der spätere Kunde zunächst nur mit Kernfunktionalitäten, statt einem umfangreichen Produkt leben kann, so haben wir die typische Ausgangssituation, welche sich für ein agiles Vorgehen bestens eignet. Typische Projekte sind neue Produkte oder Dienstleistungen, welche durch ein Feedback des Kunden schnell und zielgerichtet weiterentwickelt werden können oder müssen. 34 Scrum ist in aller Munde Exkurs: Aus diesem Grund gründen große Konzerne oftmals kleine und schlanke Firmen außerhalb ihrer Konzernstruktur und bauen neue Lösungen für dieselbe Zielgruppe unter neuem (Marken-)Namen. Hierdurch müssen sie ihre bestehenden, oft noch gut funktionierenden Produkte nicht mit einem umfangreichen Relaunch im klassischen Modell umsetzen, um am Ende herauszufinden, dass sie gar am Kunden vorbeientwickelt wurden. Vielmehr können sie nun schnell und agil ein junges, frisches Produkt an den Markt bringen und testen. Der Wettbewerbsvorteil dieser Vorgehensweise im Vergleich zum typischen Start-up ist die kapitalträchtige Mutter im Hintergrund, die neben Geld auch Kunden und Wissen zur Verfügung stellen kann. Chaotic: Hierbei ist eine Ausgangslage der völligen Überforderung gegeben. Keiner weiß, wo man anfangen soll und was man am Ende liefern soll. Hier starten die meisten Beteiligten mit blindem Aktionismus und müssen schnell versuchen, der Lage durch Strukturen und Prozesse Herr zu werden. Beispiel hierfür ist die Veränderung der Rahmenbedingungen durch die Coronapandemie, die Unternehmen binnen kürzester Zeit vor extreme Herausforderungen gestellt hat. Um diese Ausgangslage zu beherrschen, macht ein Weg in Richtung der agilen Vorgehensweise Sinn. Disorder: Hierbei handelt es sich um eine Ausgangslage des Nichts-Wissens. Ziel ist es daher, sich einen ersten Überblick über die Situation zu verschaffen, um möglichst viele Informationen zu sammeln, auf Basis derer dann entschieden werden kann, wie die richtige Vorgehensweise ist. Videotipp: Beispielhaft wird hier die Entscheidungshilfe Cynefin-Framework vor‐ gestellt: ► https: / / youtu.be/ hsKTIQR_UNA 35 Scrum ist in aller Munde Heißt das, dass es bei Scrum keine Hierarchien gibt? Scrum gibt einen großen Teil der „Macht“ zum Managen und Organisieren an das Team zurück. Einen Projektmanager im klassischen Sinne gibt es nicht mehr. Dies beruht auf der Annahme, dass die Teams über ausreichende Motivation und genug Wissen verfügen, um sich selbst zu organisieren, und selbst am besten wissen, wie sie ein vorgegebenes Ziel erreichen. Und das ganz ohne detaillierten Projektplan und ganz ohne jemanden, der ihnen sagt, wann sie was genau zu tun haben. Es gibt in einem Scrum-Projektteam kein Hierarchiegefälle, sondern lediglich klar definierte accountabilities. Jeder respektiert jeden als gleichwertig und kennt seine Rolle ganz genau. So funktioniert Scrum. Und nicht nur das - Scrum ist auch außerordentlich pragmatisch: Scrum kommt mit so wenig Administration wie möglich aus. Denkt man daran, wie viel Energie bei nach der klassischen Wasserfall-Methode gemanagten Projekten in Projektplanung, Budgetmanagement und Statusreports anstatt in das eigentliche Management des Projekts fließt, wird schnell klar, warum Scrum so erfolgreich ist. All dieser Aufwand entfällt bei Scrum nahezu gänzlich. Scrum ist einfach pragmatischer und effizienter als andere Me‐ thoden. Kommunikation findet nicht mehr in Form von langen E-Mails, E-Mail-Ketten und PowerPoint-Präsentationen statt, sondern direkt von Angesicht zu Angesicht, ohne Medienbrüche, von Mensch zu Mensch. Probleme werden nicht über Ampeln kommuniziert, sondern direkt mit dem Betroffenen besprochen. Scrum ist also sehr effizient und verzichtet auf fast alles, was nicht direkt mit dem Projektziel bzw. dem Endprodukt zu tun hat. Und was effizient ist, setzt sich in Zeiten knapper Budgets und immer schneller zu liefernder Ergebnisse einfach durch. 36 Scrum ist in aller Munde Aufbau und Funktionsweise von Scrum In diesem Kapitel erfährst du, welche Scrum-Mitglieder welche Verantwortlichkeiten haben und welche Elemente relevant sind. Was sind die wesentlichen Bestandteile von Scrum? Scrum ist als Framework im Vergleich zu anderen Frameworks wirklich ein Leichtgewicht. Während man es in der Welt von PRINCE2 mit einem offiziellen Manuel von rund 300 Seiten zu tun bekommt, hat man mit dem →Scrum Guide -, also dem eigentlichen, niedergeschriebenen Dokument von Scrum, lediglich 17 Seiten vor sich. Die Bestandteile von Scrum sind daher in geringerer Menge vorhanden und im Scrum Guide auch wenig tiefgehend beschrieben. Die tiefergehenden Gedanken zu Scrum finden sich nicht niedergeschrieben, sondern ergeben sich vielmehr durch das Mindset von Scrum. Die niedergeschriebenen Bestandteile gliedern sich wie folgt: ▶ Scrum-Theorie ▶ Scrum-Werte ▶ Scrum-Team ▶ Scrum-Events ▶ Scrum-Artefakte ▶ Scrum-Commitments 38 Aufbau und Funktionsweise von Scrum Abb. 9 Wie funktioniert der Scrum-Prozess Der Scrum-Prozess orientiert sich an der Theorie des Empirismus. Die Theorie des Empirismus besagt, dass eine Entscheidung nur auf der Basis von Informationen getroffen werden kann. Schauen wir uns jetzt die drei Schritte der Theorie des Empirismus an, fällt auf, dass diese dem Grundgedanken von Scrum sehr ähnlich sind und die Scrum-Theorie daran angelehnt ist. Wir unterteilen die Theorie des Empirismus und damit auch die Scrum-Theorie in drei Schritte: ▶ Schritt 1 | Transparency ▶ Schritt 2 | Inspection ▶ Schritt 3 | Adaption 39 Aufbau und Funktionsweise von Scrum Schritt 1 | Transparency: Alle Mitglieder eines Scrum-Teams legen transpa‐ rent ihre Arbeit dar. Durch diese neue Transparenz können in den folgenden Schritten Entscheidungen getroffen werden. Diese Transparenz stellt also eine valide Informationsquelle dar. Schritt 2 | Inspection: Hier werden die Informationen, die durch den ersten Schritt offengelegt wurden, verwertet. Innerhalb der Teams wird bespro‐ chen, wie mit den Informationen umgegangen werden soll und wie auf Basis dessen Entscheidungen getroffen werden können, die für den weiteren Scrum-Verlauf hilfreich sind. Schritt 3 | Adaption: Hier werden die Informationen aus Schritt 1 mit den Entscheidungen aus Schritt 2 umgesetzt. Der dritte Schritt Adaption ist demnach der Schritt, wo es um die konkrete Umsetzung der Maßnahmen geht. Fassen wir diese drei Schritte noch einmal anhand eines Praxisbeispiels zusammen: Das Scrum-Team bemerkt, dass das entwickelte Produkt sehr viele Fehler aufweist, und legt dies in einem ersten Schritt der Transparenz in einem Meeting dar. Wie dieses Meeting heißt, dazu kommen wir noch in einem späteren Kapitel. Im nächsten Schritt erkennen wir als Produktver‐ antwortliche im Zuge von Schritt 2, der dass das Produkt in der Tat noch viele Fehler hat, und kommen dann zu dem Ergebnis, dass sich der Abschluss des Projekts dadurch um vier Wochen verzögern wird. Daraufhin kommen wir zu Schritt 3, das ist der Schritt der Adaption, der Umsetzung auf Basis der neuen Erkenntnisse. Und auf der Basis der Erkenntnisse treffen wir die Entscheidung, den Umfang des Produkts zu reduzieren, um weiterhin innerhalb des festgelegten Zeitrahmens zu bleiben. Dadurch haben wir Agilität im perfekten Maße ausgelebt. Wir haben den Umfang reduziert, um den Zeitplan einzuhalten, und dies auf Basis der Scrum-Theorie bzw. der Theorie des Empirismus. Lesetipp: Zum Scrum-Prozess lies hier weiter: ► https: / / www.agile-heroes.de/ m agazine/ der-scrum-prozess/ 40 Aufbau und Funktionsweise von Scrum Welche Teammitglieder bzw. Verantwortlichkeiten gibt es in Scrum? Scrum unterscheidet grundsätzlich zwischen drei Rollen. Wobei das Wort „Rolle“ bis 2020 das Wort der Wahl war. Seit November 2020 haben die Gründer Jeff Sutherland und Kent Schwaber das Wort „Rolle“ in „Verant‐ wortlichkeiten“ in Scrum unbenannt. Demnach gibt es in Scrum drei Ver‐ antwortlichkeiten: ▶ Verantwortlichkeit 1 | Der Scrum Master: Der →Scrum Master. Der Scrum Master ist kurzgesagt das methodische Lead des Scrum-Teams. Er hat die Verantwortung für die Scrum-Methode. ▶ Verantwortlichkeit 2 | Der Scrum Product Owner: Der →Product Ownerhat die Produktverantwortung, also die Verantwortung für das zu entwickelnde Produkt, das von dem Entwicklungsteam umgesetzt, also entwickelt wird. ▶ Verantwortlichkeit 3 | Das Scrum-Entwicklungsteam: Das Scrum-Ent‐ wicklungsteam - oder wie es seit 2020 heißt: Developers bzw. zu Deutsch Entwickler - hat die Verantwortung, dass in jedem Sprint vereinbarte Sprint Backlog abzuarbeiten. Oder anders gesagt: Es hat die Verantwortung, die versprochenen Aufgaben für den Zyklus, für den aktuellen Zyklus, abzuarbeiten. Was ist ein Scrum Master? Die Verantwortung eines →Scrum Masters innerhalb eines Scrum-Teams umfasst viele Tätigkeiten: Grundlegend geht es darum, die richtige metho‐ dische Umsetzung von Scrum in einem Scrum-Umfeld zu gewährleisten. Der Scrum Master ist außerdem für die Einführung von Scrum in einem neuen Scrum-Umfeld verantwortlich. Die Verantwortungsbereiche gliedern sich dabei wie folgt: Der Scrum Master unterstützt das Team, er unterstützt den Product Owner und er unterstützt die Organisation. ▶ Punkt 1: Die Teamunterstützung des Scrum Masters beinhaltet: Coa‐ ching der Teammitglieder im Selbstmanagement (Selbstorganisation) und in der funktionsübergreifenden Zusammenarbeit. Das Ziel ist es hierbei, das Team so gut wie möglich in Selbstmanagement zu üben. 41 Aufbau und Funktionsweise von Scrum ▶ Punkt 2: Des Weiteren unterstützt der Scrum Master die Scrum-Teams bei der Konzentration, also beim Fokus auf die Entwicklung von hoch‐ wertigen →Inkrementen entsprechend der →Definition of Done (beide Begriffe stellen wir an anderer Stelle genauer vor). Ein Inkrement ist im Grunde genommen ein Teilprodukt des Gesamtprodukts und die Definition of Done entspricht dabei der Qualitätsstrategie. ▶ Punkt 3: Der Scrum Master unterstützt die Entwickler bei der Beseiti‐ gung von Hindernissen, die den Fortschritt des Teams behindern oder verlangsamen. ▶ Punkt 4: Er stellt sicher, dass alle Veranstaltungen (Events) stattfinden und erfolgreich, produktiv und innerhalb der definierten Timebox abgehalten werden. Die Timebox ist eine Technik, welche vorgibt, dass ein Meeting immer zur vorgegebenen Zeit beginnt und spätestens zur vorgegebenen Zeit endet. Es kann jedoch jederzeit früher beendet werden. Zu Punkt 2 | Der Scrum Master unterstützt den →Product Owner: Der →Product Owner wird bei der Verantwortung der Produktziele un‐ terstützt und bei der Verantwortung des Product-Backlog-Managements. Hierbei geht es darum, dass er den Product Owner mit Coaching und Scrum-Best-Practices darin unterstützt, seiner Verantwortung als Product Owner nachzukommen. Der Scrum Master hilft dem Product Owner dabei, die Product-Backlog-Items, also die in der To-do-Liste niedergeschriebenen Anforderungen, so zu formulieren, dass sie für das Scrum-Team verständlich sind. Der Scrum Master hilft dem Product Owner dabei, die Produktpla‐ nung entlang des empirischen Scrum-Prozesses zu vollziehen. Hiermit ist gemeint, dass er das Produkt entlang kontinuierlicher Verbesserungsmaß‐ nahmen plant. Ein Produkt wird dabei in Zyklen auf den Markt gebracht, um es von den Kunden validieren zu lassen und so entlang der bereits vorgestellten Maßgaben der Transparency, Inspection und Adaption auf Kundenbasis Feedback einzuarbeiten. Der Scrum Master unterstützt den Product Owner des Weiteren dabei, die Zusammenarbeit mit anderen Stakeholdern zu fördern. Stakeholder sind Menschen, die an dem Produkt oder Projekterfolg interessiert sind und daher Informationen seitens des Product Owners erhalten wollen. 42 Aufbau und Funktionsweise von Scrum Zu Punkt 3 | Der Scrum Master unterstützt die Organisation: Der Scrum Master unterstützt die Organisation, indem er das Thema Scrum innerhalb der Organisation, Schulungen und Coachings durchführt und auf‐ zeigt, wie Scrum eingeführt werden könnte oder eingeführt wird. Der Scrum Master unterstützt die Organisation bei der Planung und Beratung rund um die Einführung von Scrum innerhalb der Organisation. Darüber hinaus unterstützt der Scrum Master dabei, den Mitarbeitern und Stakeholdern das Verständnis und den empirischen Ansatz von Scrum näherzubringen. Eine weitere Aufgabe eines Scrum Masters innerhalb der Organisation ist es, Barrieren, welche es im klassischen Projektmanagement des Öfteren gab, zwischen Stakeholdern und den Scrum-Teams zu reduzieren und so einen noch größeren Erfolg von Scrum sicherzustellen. Wie finde ich einen Scrum Master? Bist du in deinem Unternehmen mit der Aufgabe betraut, mit einem Scrum-Projekt zu beginnen oder ein bestehendes Scrum-Team mit einem neuen Scrum Master auszustatten, stellt sich schnell die Frage nach dem Wie. Grundsätzlich gibt es zur Lösung dieser Herausforderung folgende gängige Möglichkeiten: - Interne Besetzung aus den Reihen des Entwicklungsteams - Interne Besetzung mit einem Mitarbeiter einer anderen Abteilung - Externe Besetzung eines Scrum Masters Können wir diese Lösungsmöglichkeiten detaillierter anschauen? Ja, sehr gerne. Option 1 | Interne Besetzung aus den Reihen des Entwicklungsteams: In der Praxis beobachtet man oft die Lösung, dass bei Neugründung eines Scrum-Teams oder bei der Neubesetzung der Rolle des Scrum Masters die schnelle Lösung innerhalb des Entwicklungsteams gesucht wird. Das liegt in erster Linie daran, dass diese Lösung „räumlich“ nahe am Problem ist. Zum anderen liegt es auch an der Wahrnehmung vieler Stakeholder, die das Mindset vertreten, ein Scrum-Master-Job sei kein Fulltime-Job. 43 Aufbau und Funktionsweise von Scrum Aus unserer Erfahrung nimmt diese Wahrnehmung bei den Stakeholdern signifikant ab, je größer und komplexer das Projekt ist. Ist ein Team, etwa einer kleinen Werbeagentur, mit drei bis vier Entwick‐ lern für einen Scrum Master auch aus unserer Sicht zu klein - und ja, jetzt wird es ein großen Aufschrei in der Scrum-Community geben, weil wir dem „heiligen“ Scrum Guide widersprechen -, so ist es hingegen für ein Projekt mit neun oder mehr Entwicklern unabdingbar, einen Vollzeit fokussierten Scrum Master zu haben. Letzteres setzt natürlich voraus, dass Stakeholder wirklich möchten, dass ihr Projekt funktioniert. Wenn sie gerne ihren Softwareentwicklern den Fokus rauben, sie mit Impediments beschäftigen oder ihre Projektdeadline reißen möchten, ist Option 1 natürlich auch immer möglich. Natürlich war der letzte Absatz nicht ganz ernst gemeint und es wurde überspitzt dargestellt, was passiert, wenn Entwickler die Verantwortung des Scrum Masters übernehmen. Sie verlieren aber in der Tat den Fokus, haben oft nicht die nötige Sicht von „außen“ und gehen in der Praxis oft zu tief mit in Diskussionen. Option 2 | Interne Besetzung mit einem Mitarbeiter einer anderen Abteilung: Wird man nicht fündig oder will man im bestehenden Team an Entwicklern nicht fündig werden, so ist der nächste naheliegende Schritt, zu versuchen, eine Person aus der Organisation für das Scrum-Team zu begeistern. Dazu werden aus unserer Sicht oft Menschen vorgeschlagen, die sowieso schon projekterfahren sind, also erfahrene Scrum Master oder Personen, die als PMOs oder Projektmanager arbeiten und die eher die methodischen Sicht‐ weisen verantworten. Diese kommen hier auch grundsätzlich gut in Frage, sofern der zwischenmenschliche Anspruch, im Team eine echte Kultur zu entwickeln, vorhanden ist. Herausfordernd werden für diese Lösung vor allem die Punkte: Mut, weitere Karriere und langfristige Motivation. - Mut: Ein Scrum Master benötigt eine gehörige Portion Mut, um sowohl intern als auch extern des Teams die richtigen Dinge anzusprechen und dabei in Kauf zu nehmen, eventuell - vornehmlich in großen Konzernen - politische Gemüter zu verletzten. Dieser Mut kann belohnt werden. Man erlebt es jedoch oft, dass viele interne Scrum Master aufgrund von Angst vor Konsequenzen es lieber unterlassen, derartige Themen anzusprechen. 44 Aufbau und Funktionsweise von Scrum - Karriere: Neben der Frage, ob solche transparenten Darstellungen von Problemen in der Organisation die Karriereentwicklung beflügeln oder behindern, ist die Frage nach der Karriereentwicklung der Scrum Mastern bis dato noch recht ungeklärt. Ja, wir leben und arbeiten in einer sehr hierar‐ chielosen Welt. Die nötige Entwicklung, was das Thema Verantwortung und Geld angeht, bleibt aber dennoch eine Frage, die sich viele in einer (großen) Organisation bestehen. stellen. Bisher sind die nächsten Schritte für Personen, die die Rolle des Scrum Masters übernehmen, aufgrund der erst kürzlich vollzogenen breitenwirksamen Einführung dieser Funktion noch sehr ungewiss. Aus der Sicht der Agile Heroes sehen wir die nächste Entwicklungsstufe eines Scrum Masters in der Rolle des Agile Coaches. Es ist aus unserer Sicht also eher die Rolle eines Experten. - Langfristige Motivation: Eine weitere Herausforderung aus der Praxis ist die langfristige Moti‐ vation von Scrum Mastern oder anders formuliert: die hohe Rotation auf diesen Stellen. Wir glauben, dass viele Scrum Master über einen Zeitraum von ein bis zwei Jahren den Punkt erreichen, an dem sie ein neues Team, ein neues Projekt mit neuen Herausforderungen als sinn‐ voll erachten. Ohne es tiefgehend wissenschaftlich erforscht zu haben, denken wir, dass nach diesem Zeitraum alle Methoden, Techniken und Tools des Scrum Masters im entsprechenden Team verwendet worden sind. Der Scrum Master erfährt eine gewisse Sättigung an Erfahrung und auch das Team ist in seinem höchsten Zustand an Performance angekommen. - Zusatzfaktor Ausbildung (bei neuen Scrum Mastern): Der Aspekt Ausbildung ist für einen erfahrenen Scrum Master weni‐ ger wichtig. Er richtet sich daher eher an neue Scrum Master. Den Punkt der Ausbildung, sei es theoretisch mit einer Weiterbildung oder praktisch mit der Ausbildung on the job, gilt es bei der Evaluierung von entsprechenden Lösungen zu beachten. Die Ausbildung bedarf Zeit und der Rücksicht, dass das Team die höchste Geschwindigkeit erst nach diesem ausbildungsbedingten Einbruch von Geschwindigkeit erlangen wird. Das ist ein absolut normaler Weg. Jedem Stakeholder sollte daher bei einer Verpflichtung eines Internen diese normalen Einarbeitungsthematiken bewusst sein. 45 Aufbau und Funktionsweise von Scrum Option 3 | Externe Besetzung eines Scrum Master Die oben bereits genannten Probleme und Herausforderungen sind durch einen sehr einfachen Weg zu umgehen. Die externe Besetzung eines Scrum Masters, für einen befristeten Zeitraum bietet direkt viele Vorteile: - Schnell - Qualitativ - Weniger Aufwand - Externe Sicht - Keine eigenen Karriereambitionen Können wir die Vorteile einer externen Besetzung detaillierter betrachten? Gerne; die fünf Vorteile im Einzelnen sind folgende: - Schnell: Einen internen Mitarbeiter einzustellen, bedarf eines hohen zeitlichen und oft auch monetären Aufwands. Ein externer Scrum Master ist oft in wenigen Tagen für das Unternehmen verfügbar. - Qualitativ: Sind vor allem neue interne Scrum Master noch auf dem Weg der Ausbildung, kann man über den externen Weg direkt langjährig er‐ fahrene Scrum Master „über Nacht“ einkaufen und seinem Team zur Verstärkung schicken. - Weniger Aufwand: Neben dem geringeren Aufwand im Bereich des Hirings ist auch der Aufwand während der Zusammenarbeit deutlich geringer. Es fallen keine Kosten oder Aufwände für Mitarbeiterentwicklung, Weiterbil‐ dungen oder Vorgesetze an. Es muss sich keine Gedanken über Karriere und Entwicklungen gemacht werden. - Externe Sicht: Der externe Scrum Master bringt den neutralen Blick von außen auf das Team und das Projekt ein. Dies hilft oft, um Herausforderungen mit einem neuen Blick anzugehen und schnell und einfach zu lösen. Außerdem bringt der externe Scrum Master in der Regel einen hohen 46 Aufbau und Funktionsweise von Scrum Benchmark-Vergleich mit. Er hat oft in vielen anderen Projekten und Unternehmen gearbeitet und kann dieses Know-how bei den neuen Herausforderungen gewinnbringend einsetzen. - Keine eigenen Karriereambitionen: Als weiterer Punkt sind die eigenen Karriereambitionen zu nennen, die ein externer Scrum Master nicht mitbringt. In der Regel ist die offene und transparente Kommunikation damit völlig frei und ohne Hintergedanken zu sehen. Er kann ganz ohne Angst um seine eigene Laufbahn im Unternehmen den Finger auf die Wunde legen und damit eventuell auch Spannungen klar benennen, sofern sie den Projekterfolg gefährden. Kann man hieraus eine einfache Entscheidungsregel ableiten? Nachdem alle Vor- und Nachteile der entsprechenden Besetzungsformen eines Scrum Masters dargestellt worden sind, ja. Zusammenfassend kann man eine Faustformel formulieren: Möchte man effizient und günstig ein Teammitglied sowie internes Know-how aufbauen, so sollte man interne Scrum Master einstellen und aufbauen. Spielt Geld keine Rolle, sondern nur der beste Projekterfolg, ist die kurzfristig optimale Lösung, einen externen Scrum Master zu engagieren. Was ist ein Product Owner? Der Product Owner ist verantwortlich für die Maximierung des Values des Produkts. Das Produkt ergibt sich, wie wir bereits gelernt haben, aus der Arbeit des Scrum-Teams, aus der Arbeit der Entwickler. Klingt die Maximierung des Produkt-Values erst einmal sehr abgedroschen, ist hier in der Scrum-Lehre doch einiges dran. Es geht im Grunde darum, dass der Product Owner die volle Verantwortung für das Produkt hat. Das bedeutet, dass er sowohl für die richtige Entwicklung des Produkts zuständig ist als auch dafür, wie das Produkt am Markt ankommt. Demnach ist die logische Schlussfolgerung, dass der Product Owner die Entwicklung des Produkts so vorantreiben wird bzw. sollte, dass es den höchsten Markt-Impact bzw. die 47 Aufbau und Funktionsweise von Scrum höchste Kundenzufriedenheit oder, wie hier Scrum formuliert, den höchsten Produkt-Value erzielt. Im Folgenden sind einige Verantwortungsbereiche des Product Ow‐ ners dargestellt, die natürlich von Organisation zu Organisation oder Scrum-Team zu Scrum-Team oder auch von Product Owner zu Product Owner unterschiedlich ausfallen können. Der Product Owner hat Verant‐ wortung für folgende Bereiche: 1. Effektive Verwaltung des Product Backlogs. Hierzu gehörten die Ent‐ wicklung und explizite Kommunikation des Produktziels (das ist übri‐ gens erst seit dem Scrum Guide in der Verantwortung des Product Owners, da er vorher keine Produktziele definieren musste). Hier ist gemeint, dass der Product Owner eine Art Vision für das zu erstellende Produkt haben sollte. Diese Vision hilft dem Scrum-Team oder den Ent‐ wicklern dabei, die richtigen Entscheidungen zu treffen und zu einem klaren Verständnis von den zu liefernden Inkrementen zu gelangen. 2. Der Product Owner ist auch für die Erstellung und für die klare Kom‐ munikation der →Product-Backlog-Elemente, also der Product-Back‐ log-Items, zuständig. Übersetzt in die Welt vor Scrum könnte man diese Product-Backlog-Elemente als Anforderungen beschreiben, welche der Product Owner bei den entsprechenden Stakeholdern, bei den richtigen Ansprechpartnern, einholt. Und auf Basis dessen ist die Verantwortung des Product Owners, dass er diese Anforderungen in ein Product-Back‐ log-Element umwandelt. Das Product Backlog (darauf gehen wir in einem späteren Kapitel genauer ein), ist eine Art To-do-Liste und diese To-do-Liste gilt es für den Product Owner nicht nur zu erstellen, sondern auch zu priorisieren. 3. Der Product Owner hat die Verantwortung, dass das Product Backlog transparent und verständlich ist. Das bedeutet, dass jeder, der in das Product Backlog hineinschaut, auch versteht, wie die weitere Produkt‐ entwicklung ablaufen wird. Grundsätzlich gilt, dass der Product Owner accountable ist, dass die Arbeiten durchgeführt werden. Das heißt, er hat am Ende die Verantwortung, dass sie durchgeführt worden sind. Es ist aber nicht zwingend notwendig, dass er die Arbeiten selbst durchführt, er kann sie auch an andere delegieren. Für die Praxis ist es unabdingbar, dass die Arbeit des Product Owners vonseiten der gesamten Organisation respektiert wird. Denn nur wenn die Arbeit und die Entscheidungen des Product Owners respektiert werden, ist 48 Aufbau und Funktionsweise von Scrum sichergestellt, dass die Arbeit des Product Owners erfolgreich ist. Die Arbeit, die der Product Owner tätigt, ist zum einen in dem Product Backlog, also in der genannten To-do-Liste, sichtbar, zum anderen am Ende eines jeden Zyklus, in dem sogenannten Sprint Review. Oft stellt sich in der Praxis die Frage, ob der Product Owner eine einzige Person sein muss oder ob die Funktion auch von mehreren Personen ausge‐ füllt werden kann. Hier ist die klare Antwort, dass der Product Owner weder Komitee noch Doppelspitze ist. Vielmehr muss der Product Owner eine einzelne Person sein. Denn am Ende geht es darum, dass Entscheidungen am Produkterfolg getroffen werden. Und Entscheidungen werden auf diese Weise schnell und effizient getroffen. Hat jemand eine andere Meinung als der Product Owner oder Ideen bzw. Verbesserungsvorschläge, dann kann er sie jederzeit an den Product Owner kommunizieren und ihn davon überzeugen, diese anzunehmen und auf Basis dessen eine Änderung am Product Backlog zu vollziehen. Generell ist es so, dass sich der Product Owner - während das Scrum-Team bzw. die Entwickler im Sprint arbeiten - mit dem weiteren Verfeinern des Product Backlogs beschäftigt. Das bedeutet, er spricht mit entsprechenden Stakeholdern und gegebenenfalls mit Kunden. Er nimmt Feedback zu dem Produkt entgegen und integriert es in das Product Backlog, jedoch nur, wenn es für ihn und den Produkterfolg Sinn macht. Daraufhin beschreibt er dieses Feedback in den Product-Backlog-Elementen, bespricht es mit dem Team und priorisiert. Erst danach kann das Team im nächsten Zyklus, im nächsten Sprint, diese Product-Backlog-Elemente an sich neh‐ men und erarbeiten. Wie finde ich einen Product Owner? Im Gegensatz zu einem Scrum Master ist die Frage nach dem Product Owner deutlich anders zu stellen. Welche Möglichkeiten es hier gibt, schauen wir uns im Folgenden genauer an. Die Aufgabe eines Product Owners ist im Vergleich zum Scrum Master weniger generisch, sondern vielmehr fachlich und inhaltlich getrieben. Aus diesem Grund ist eine generische Besetzung eines Product Owners, beispielsweise als Externe, nur schwer möglich. 49 Aufbau und Funktionsweise von Scrum Aus unserer Sicht sind vor allem Menschen mit der größten Berufserfah‐ rung bzw. der meisten Erfahrung mit dem jeweiligen Produkt die besten Product Owner. Es geht in der Rolle des Product Owners darum, die Sicht des Kunden einzunehmen und die gesamte Facette des Produkts zu verstehen. Dafür braucht man Zeit und eine Menge interne Kenntnisse, die es schwer machen, externe oder neue interne Mitarbeiter anzustellen. Schwer heißt jedoch nicht unmöglich. Gerade die Option, neue Mitar‐ beiter für die Rolle des Product Owners anzuwerben, betrachten wir als sinnvolle zweitbeste Möglichkeit. Neue externe Mitarbeiter bringen auch wieder externe - also neue - Sichtweisen mit, die allen helfen können. Außerdem ist eine Einarbeitung letztlich auch einfach eine Frage der Zeit. Sind also externe Product Owner die beste Option? Nein. Gerade in Hinblick auf den internen Know-how-Aufbau ist die Beauftragung eines externen - analog zur Scrum-Master-Beauftragung - mit deutlich mehr Risiko verbunden. Ein externer ist per se für einen kurzfristigen Einsatz geplant. Wenn man einen langfristigen Einsatz planen würde, sollte man nicht die im Vergleich zum internen teureren Tagessätze in Kauf nehmen. Außerdem ist es eine notwendige Aufgabe der Organisa‐ tion, internes Know-how aufzubauen. In der Regel ist das bei der externen Besetzung des Product Owners kaum gegeben. Daher lautet unser aus der Praxis gewonnener Rat, den Product Owner definitiv mit einem Internen zu besetzen. Am besten geeignet ist ein langjährig im Unternehmen arbeitender Mensch oder eine Person, die eine langfristige Perspektive im Unternehmen hat, um möglichst kundenzentral das Produkt zu entwickeln. Was macht das Entwicklungsteam? Wurde in der anfänglichen Welt von Scrum oft von dem Entwicklungsteam gesprochen, sind es in der neuesten Version von 2020 die Entwickler. Die Entwickler sind die Menschen im Scrum-Team, welche sich dazu verpflichtet haben, bei jedem Sprint jeden Teil des nutzbaren Inkrementes zu erstellen. Ein →Inkrement ist im Grunde ein nutzbares Teilprodukt des Gesamtprodukts. Die Entwickler sind in ihrem Team selbstorganisiert bzw. 50 Aufbau und Funktionsweise von Scrum selbstgemanagt unterwegs, das heißt, dass sie grundsätzlich alleine dazu im Stande sind, ihre Aufgaben zu erledigen. Die Entwickler sind in ihrer Natur crossfunktional. Das bedeutet, dass die Entwickler im gesamten Team dazu in der Lage sind, allen Anforderungen, die das Produkt braucht, in der Umsetzung, nachzukommen. Das kann in der Praxis bedeuten, dass es ein Team von Softwareentwicklern, Designern und Marketingspezialisten in sich vereint. Jetzt kann es in der Praxis dazu kommen, dass es Momente gibt, an denen Menschen, die nicht dem Team zugehörig sind, trotzdem einen Teil zum Produkt oder →Inkrement leisten müssen. Ein gutes Beispiel hierfür ist der Einsatz von Beratung durch Rechtsan‐ wälte. Diese würde man hier nicht den Entwicklern zuordnen, sondern als sogenannte Subject-matters-Experts beschreiben, welche kurzzeitig die Entwickler bei der Umsetzung von Aufgaben unterstützen. Die Entwickler haben zudem die Verantwortung, einen Plan für den Sprint zu erstellen, also festzulegen, welche To-dos im nächsten Schritt abgearbeitet werden sollen. Das wird im sogenannten →Sprint Backlog niedergeschrieben. Das Sprint Backlog wird im Folgenden dieses Buches natürlich noch weiter beschrieben. Die Entwickler haben die Verantwortung, die Aufgaben des Sprint Backlogs entlang der →Definition of Done (später im Buch genauer beschrieben) zu erledigen. Die Entwickler haben zudem die Aufgabe, ihren Plan für den Tag jederzeit anzupassen, wenn es das Sprint-Ziel, also das Ende des Zyklus, hergibt. Die Entwickler reden miteinander und unterstützen sich jederzeit gegenseitig, um so Wissenslücken zu schließen und die Transparenz im Team zu erhalten und zu leben. Wie finde ich die perfekten Entwickler? Ähnlich wie bei der Frage nach dem Product Owner lässt sich auch auf die Frage nach dem perfekten Entwickler keine einfache Antwort finden, geht es doch gerade bei der umsetzungsstarken Rolle eines Entwicklers um eine sehr breit gefächerte und fachliche Sicht auf die Dinge. Man könnte die Frage daher fast umformulieren in: „Wie finde ich die perfekten Teammitglieder oder Mitarbeiter? “. Die Antwort auf diese Frage ist aus unserer Sicht nicht scrumspezifisch. Der Vollständigkeit halber lassen wir in die Antwort jedoch eigene Erfahrun‐ 51 Aufbau und Funktionsweise von Scrum gen aus unserer Scrum-Master-Tätigkeit sowie aus dem Unternehmeralltag einfließen, um ein paar Denkanstöße anzubieten: - Stelle nur glückliche Menschen ein. - Stelle nur Menschen ein, die bereit sind, die Extrameile zu gehen. - Stelle nur Menschen ein, die eine hohe Lösungskompetenz mitbringen. - Stelle nur Menschen ein, die dein Team voranbringen. Vor allem der letztgenannte Punkt sollte ein wichtiger Leitsatz für jede Organisation sein. Auch wenn diese Entscheidungshilfe nicht nur Scrum-Beteiligte betrifft; welche Überlegungen stecken hinter diesen Personalauswahlkriterien? Stelle nur glückliche Menschen ein: Wenn du im Bewerbergespräch dem Bewerber die Frage stellst, ob er glück‐ lich sei, wirst du ziemlich schnell ziemlich große Augen sehen. Mit hoher Wahrscheinlichkeit ist die Frage deinem Gegenüber noch nicht untergekom‐ men. Der Tiefgang dieser Frage zielt darauf ab herauszufinden, ob du einem Menschen gegenübersitzt, der glücklich ist. Denn nur glückliche Menschen erbringen beste Teamleistungen. So zumindest unsere Überzeugung und Erfahrung. Unser Team ist geprägt von glücklichen Menschen. Bei uns existiert kein Mobbing, nur selten schlechte Laune und ein großes Bedürfnis, etwas zu erschaffen. Wir sind davon überzeugt, dass Menschen, die nicht glücklich in ihrem Leben sind, auch keinen guten Einfluss auf unser Team und unsere Kunden haben werden. Wenn ein Mensch diese Frage mit Nein beantwortet oder nur sehr zögerlich Antwort gibt, sind die Weichen eher Richtung Nein gestellt. Stelle nur Menschen ein, die bereit sind, die Extrameile zu gehen: Viele von uns kennen das: Ein Kunde benötigt kurzfristig etwas. Vielleicht erreicht uns sogar ein Pitch, der kurzfristig reinkam. Und es bleiben nur wenige Stunden, um zu liefern. In einem solchen Moment braucht man ein Team, das bereit ist, alles für den Erfolg zu geben. Was man nicht braucht, sind Teammitglieder, die den Stift um 17 Uhr fallen lassen. Dabei ist nicht die Rede von Menschen, die am Hochzeitstag oder am Geburtstag früh nach 52 Aufbau und Funktionsweise von Scrum Hause gehen. Es geht um Menschen, bei denen dies der Regelfall ist. Solche Mitglieder im Team stellen ein Impediment da. Daran muss gearbeitet werden und die Menschen müssen sich entweder dahin entwickeln, im Ausnahmefall die Extrameile zu gehen, oder sie müssen das Team verlassen. Die bessere Variante ist, diese Eigenschaft eines Bewerbers vor der möglichen Einstellung zu identifizieren. Aber was steckt hinter der Extrameile? Hierbei geht es nicht um Über‐ stunden. Es geht vielmehr um die Frage, ob sich jemand für das Team oder nur für sich einsetzt. Oft haben wir Menschen erlebt, die sich selbst optimiert haben statt den Prozess oder das Kundenerlebnis. Selbstoptimierung im Sinne von selbst weniger Arbeit in Kauf nehmen, auch wenn damit das Kundenerlebnis, das Produkt oder der Prozess schlech‐ ter wird. Dieses Mindset teilen wir nicht und versuchen, es auch innerhalb von Scrum-Teams nicht aufkommen zu lassen. Die Selbstorganisation im Scrum-Team funktioniert nur dann, wenn die Teammitglieder bereit dazu sind, sich persönlich in den Dienst des Teams und des Kunden zu stellen. Verfolgt man diese Denkweise, wird die Phase, in der man seine Zeit flexibel einteilen kann, sehr schnell von ganz allein kommen. Hat man einen zufriedenen Kunden, hat man ein gutes Teamgefüge, in dem jeder weiß, dass man sich auf sein Gegenüber verlassen kann. Dadurch hat man auch die Zeit und das gegenseitige Vertrauen, Arbeitszeiten anders und selbstorganisiert einzuteilen. Stelle nur Menschen ein, die eine hohe Lösungskompetenz mitbrin‐ gen: Ein Team, auf das komplexe Anforderungen und Herausforderungen zu‐ kommen, sollte von Lösungskompetenz geprägt sein. Nichts ist hinderlicher, als nur die Probleme zu diskutieren. Elon Musk, CEO von Tesla und SpaceX, fragt in den Bewerbungsgesprächen die Menschen nach den größten Lösun‐ gen in ihrem Leben. Er sagt, ihm ist nichts wichtiger als herauszufinden, ob Menschen dazu bereit sind, Lösungen zu finden - große Lösungen für richtig große Probleme und Herausforderungen. Wir teilen diese Überzeugung. Wenn wir an unser Team herantreten, möchten wir über mögliche Ideen und Lösungen sprechen. Wir möchten keine Probleme und Risiken diskutieren, die nicht relevant sind. Wir möch‐ ten auch, dass unser Team selbst Probleme löst und dafür nicht einen Product Owner, einen Scrum Master oder einen Geschäftsführer braucht. Auch diese 53 Aufbau und Funktionsweise von Scrum Charaktereigenschaft ist für das Ziel eines möglichst hohen Grades an Selbstorganisation unabdingbar. Stelle nur Menschen ein, die dein Team voranbringen: Hierbei geht es um die Frage, ob man einen Profi einstellt, der das Team, das Produkt und das Unternehmen voranbringt, oder ob man die Person erst noch dazu entwickeln muss. Natürlich sind Praktikanten und Werkstu‐ denten die Talente von morgen. Dass man auch Menschen, die noch in Ausbildung sind, eine Chance bieten muss, ist absolut klar und einleuchtend. Es geht bei diesem Punkt jedoch um die Hirings der erfahrenen Mitarbei‐ ter. Es ist wichtig, Menschen einzustellen, die auf dem Gebiet dem Team aktuell überlegen sind. Nur dadurch bringst du das Team voran und hebst es auf die nächste Stufe. Was bin ich nun, wenn ich Projektmanager war? In der Praxis, vor allen Dingen in agilen Transformationsprojekten, erlebt man es häufig, dass für alte Rollen innerhalb eines Projekts oder alte Rollen innerhalb einer Organisation in der agilen Welt eine neue äquivalente Rolle gesucht wird. Wenn sie diese Rolle finden würden, entspräche das nicht einer Veränderung der Organisation, sondern nur eine namentliche Veränderung, und wäre somit nicht zielführend. Das bedeutet, wenn man vormals Projektmanager war, ist diese Aufgabe in der agilen Welt grundsätzlich nach Scrum nicht mehr notwendig. In einem Scrum-Projekt mitzuwirken, bedeutet die Wahl zwischen den drei Rollen: ▶ Scrum Master, ▶ Product Owner oder ▶ Entwickler. Ein Projektmanager arbeitet in der Regel nicht fachlich an dem Produkt mit, weshalb die Rolle des Entwicklers nicht in Frage kommt. Bleiben also noch die Rollen eines Scrum Masters oder des Product Owners: ▶ Beschäftigt sich der Projektmanager mit dem Thema Anforderungsma‐ nagement und kennt er das Produkt sehr gut dann wäre die Rolle des Product Owners zu empfehlen - allerdings nur, wenn er auch bereits 54 Aufbau und Funktionsweise von Scrum Fachfeinkonzepte geschrieben hat, die dann von Teilprojekten umge‐ setzt wurden. Dennoch müsste die Arbeitsweise angepasst werden. ▶ Sieht sich der Projektmanager eher in der Rolle eines methodischen Projektmanagers, wird er in der Rolle des Scrum Masters besser aufge‐ hen. Um Missverständnissen vorzubeugen: In der Scrum-Welt gibt es keinen Projektmanager. Und auch in der Praxis ist es das Ziel, dass diese Rolle eher im Product Owner oder im Scrum Master aufgehen würde. Entsprechend verändern sich jedoch auch Herausforderungen, Verantwortlichkeiten und Kompetenzen. Allerdings gibt es Projekte in der agilen Welt, die einen Projektmanager benötigen, etwa in größeren agilen Projekten, in welchen es mehrere Scrum Master und Product Owner gibt. Diese sollten von einem Projektmana‐ ger koordiniert werden. Insbesondere hierarchische Organisationen oder Großkonzerne benötigen weiterhin Projektmanager, weil vor allen Dingen Projektbudget und Ressourcenplanung an dieser Rolle hängen, was in der Scrum-Welt eher ein Thema für den Product Owner wäre bzw. für den Scrum Master. Häufig sind Großkonzerne noch nicht darauf ausgelegt, dass plötzlich von neuen Rollen im Unternehmen bestimmte Aufgaben übernommen werden sollen. Vielmehr halten sie eher am klassischen Modell des Projektmanagers fest. Alternativ müssten solch große Organisationen einen kurzfristigen und drastischen Organisationswandel mit allen denkbaren Folgen erfahren. Deshalb entscheiden sich viele pragmatischer Weise für einen übergeordne‐ ten agilen Projektmanager als bessere Lösung. In der Praxis erhält diese Lösung auch eine höhere Akzeptanz seitens aller Beteiligten, an der es für eine agile Transformation wiederum mangelt. Eine organisch wachsende, agile Community zu schaffen und so inkrementell und bedarfsgerecht die agile Transformation heran‐ schreiten zu lassen, ist zu bevorzugen. 55 Aufbau und Funktionsweise von Scrum Welche Werte gibt es in Scrum? Das Besondere am Scrum-Framework im Vergleich zu Methoden wie zum Beispiel Prince2 ist, dass es fünf feste Werte gibt, nach denen im Scrum-Team gehandelt wird. Einer der Väter von Scrum, Ken Schwaber, hat mit Mike Bedle die fünf Werte als Fundament von Scrum entwickelt und dazu folgendes gesagt: Wenn ein Scrum-Team diese fünf →Scrum Values verinnerlicht und um‐ setzt, ist Scrum auch in der Praxis erfolgreich. Das ist typisch amerikanisch, pragmatisch und marketingoptimiert formuliert, enthält aber auch einen wahren Kern. Diese fünf Werte sind: ▶ Mut, ▶ Fokus, ▶ Selbstverpflichtung, ▶ Respekt und ▶ Offenheit. Die fünf Werte sind, wenn in Schulungen erfragt, oft von den Teilnehmern selbst erwünscht. Bei der Frage, welche Werte in der Arbeitswelt wichtig sind, erhält man im Prinzip derartige Wertvorstellungen als Antwort. Nun zu den Werten im Einzelnen: Mut: Hierbei geht es darum, dass das →Scrum-Team mutig sein soll, neue Pro‐ zesse, Ziele oder Kommunikationsweisen auszuprobieren. Es geht darum, Veränderungen nachzugehen. Das Scrum-Team soll darüber hinaus eben‐ falls den Mut haben, sich auf ein Ziel zu fixieren, welches vielleicht anspruchsvoller als das vorherige ist. Es soll Mut zur Innovation haben und so die richtigen Dinge zu tun. Fokus: Jeder, der bereits einmal an einer Studienarbeit, an einem Buch oder an einem Projekt gearbeitet hat, weiß, dass man am effizientesten ist, wenn es gelingt, die Konzentration hoch zu halten. Übertragen auf den betrachteten Wert Fokus bedeutet dies: Limit the work in progress. Demnach gelingt die Arbeit besser, wenn man sich auf eine geringe Anzahl von Dingen beschränkt. Jeder sollte dies ausprobieren, wenn man nicht schon dieselbe 56 Aufbau und Funktionsweise von Scrum Erfahrung gemacht hat und beim Lesen dieser Zeilen bestätigend nickt. Die Qualität des Arbeitsergebnisses ist vergleichsweise höher als im Falle einer gleichzeitigen Bearbeitung unterschiedlicher Projekte. Und so liegt der Sinn des Wertes Fokus darin, dass die Entwickler oder das gesamte →Scrum-Team auf ihr Sprint-Ziel und ihre Aufgaben des Sprints fokussiert sein sollen. Anderweitige Tätigkeiten in der Linie oder in anderen Positionen im Unternehmen sollten grundsätzlich vermieden werden. Selbstverpflichtung: Der englischsprachige Begriff dafür lautet Commitment. Es geht dabei um die Verpflichtung des Teams ▶ die Arbeit gut zu machen, ▶ die Arbeit richtig zu machen und ▶ sich auch auf die Ziele des Produkts, ▶ auf die Ziele des Inkrements des Sprints zu verpflichten. Der Scrum Master sollte vor jedem neuen Sprint beim Team den Confidence Vote abfragen. Das ist Best Practice, steht also nicht im Scrum Guide. Aber es fördert den Wert Selbstverpflichtung. Die Frage könnte demnach beispielhaft lauten: „Wie sehr verpflichtet ihr euch zu diesem Produkt, wie stark commitet ihr euch zu diesem Sprint? “ Und wenn der Wert hoch ist - auf einer Skala von 1 bis 5 ist das ab 3 der Fall -, dann ist das für den abgefragten Sprint in Ordnung. Respekt: Der Wert Respekt bedeutet, dass sich alle Mitglieder des Teams respektvoll austauschen und generell respektvoll miteinander umgehen sollen. Jeder, der bereits in einem Scrum-Team gearbeitet hat, hat bestimmt festgestellt, wie respektvoll die Teammitglieder miteinander oder auch mit Personen außerhalb des Teams arbeiten. Das bedeutet, dass Themen wie Mobbing und abwertende Aussagen übereinander in einem Scrum-Team keinen Platz haben dürfen. Es geht letztlich eben auch darum, auf diese Weise ein gutes Teamklima herzustellen. 57 Aufbau und Funktionsweise von Scrum Offenheit: Bei dem Thema Offenheit geht es darum, dass das →Scrum-Team zum einen offen für Veränderung sein muss und zum anderen aber auch offen für andere menschliche Aspekte sein sollte - also offen für neue Heraus‐ forderungen und auch für das Feedback der Stakeholder. Das Mindset von Scrum beschreibt, dass man als Scrum-Team Änderungen liebt. Denn Änderungen bedeuten, dass das Produkt stetig verbessert wird. Und dafür gilt es, Offenheit an den Tag zu legen. Videotipp: Die fünf Values werden in diesem Kurzvideo noch einmal erklärt: ► https: / / youtu.be/ RyATmkxBsJc Welche Funktion haben Events in Scrum? In Scrum gibt es Events, die auch Meetings oder Zeremonien genannt werden. 58 Aufbau und Funktionsweise von Scrum Abb. 10 Diese ermöglichen es den Anwendern, ihr vollständiges Potenzial auszu‐ schöpfen. Hier geht es im Grunde genommen immer noch darum, der Scrum-Theorie gerecht zu werden. Der Grundgedanke der jeweiligen Events ist es, Transparenz herzustellen und die Gelegenheit zu nutzen, Scrum-Ar‐ tefakte zu inspizieren und anzupassen. Zur Erinnerung bezüglich der Scrum-Theorie: ▶ Transparency, ▶ Inspection und ▶ Adaption. 59 Aufbau und Funktionsweise von Scrum Die Events sind speziell darauf ausgerichtet, die erforderliche Transparenz zu ermöglichen. Wenn ein Event nicht wie vorgeschrieben stattfindet, geht die Gelegenheit zur Transparenz, zur Inspektion, zur Anpassung verloren. Die Vorteile der Scrum-Events - im Vergleich zu Events im klassischen Projektmanagement oder in klassischen Organisationen - sind vor allem ▶ die Einfachheit, ▶ die gleichbleibende Routine, ▶ die Fokussierung der Meetings, ▶ die kurze Zeitspanne und ▶ die sogenannte Timebox. Wer trägt die Verantwortung für die Timebox? Das Timeboxing ist eine Technik, die für Meetings verwendet wird und dabei hilft, ein Meeting effizienter zu gestalten. Die Technik Timebox beschreibt, dass ein Meeting immer zu einer vorgegebenen Zeit, also pünktlich, beginnt und spätestens zu einer vorgegebenen Zeit endet. Verwendet man die Timebox, wird ein Meeting immer ausdrücklich dann beendet, wenn die Zeit abgelaufen ist. Eine frühere Beendigung des Meetings bzw. des Events ist jederzeit möglich. Die Verantwortung, die Timebox einzuhalten, liegt beim gesamten Team. Der Scrum Master jedoch hat die Verantwortung, die Timebox zu managen und auf die Timebox zu achten. Sind Meetings ein originärer Bestandteil von Scrum? Strenggenommen nein. Man könnte daher auch schlussfolgern, dass Mee‐ tings, die nicht in Scrum definiert sind, auch nicht anzuwenden sind. Außerdem könnte man argumentieren, dass keine Scrum-Meetings bzw. -Events durchzuführen sind, da man ansonsten nicht nach Scrum arbeiten würde. Das klingt sehr radikal und in der Praxis kommt es sehr selten vor, dass die einzelnen Scrum-Events nicht stattfinden. Dennoch kommt es vereinzelt vor, dass man aus Zeit- oder Effizienzgrün‐ den Meetings auch einmal absagen muss. Zur Erinnerung: Jedes Meeting, jedes Event findet zur gleichen Zeit am gleichen Ort statt, um die Kom‐ 60 Aufbau und Funktionsweise von Scrum plexität zu reduzieren. In der Praxis kann man als Scrum Master auch Scrum-Events als Schutzschild für das Team verwenden - vor allem wenn Manager in die Rolle zurückfallen, dass sie klassische Excelreportings haben möchten. Hierbei geht es nicht darum, dem Manager nicht seine Information zur Verfügung zu stellen, sondern ausschließlich darum, den Projekterfolg durch Effizienz sicherzustellen. Dies erreicht man durch die Aussage, dass alle Informationen, die der Manager haben möchte, in einer ordentlichen Durchführung der Scrum-Events enthalten sind. Im Folgenden sind die jeweiligen Scrum-Events dargestellt: ▶ der →Sprint: als Container für den gesamten Scrum-Prozess ▶ das →Daily Scrum: Ein Daily Scrum ist im Grunde genommen, die bekannteste Zeremonie von Scrum. Hierbei handelt es sich um eine tägliche Abstimmung des Entwicklungsteams. ▶ das →Sprint Planning: als Planungsmeeting für den jeweiligen Sprint ▶ das →Sprint Review: als Demonstration der im jeweiligen Sprint erschaffenen Inkremente ▶ die →Sprint-Retrospektive: als methodische Weiterentwicklung/ Les‐ son-to-learn-Möglichkeit für das Team ▶ das Refinementbzw. Research-Meeting: Das gilt es in Klammern zu sehen. Was ist ein Sprint? Der →Sprint, und so steht es sehr emphatisch im Scrum Guide niederge‐ schrieben, ist der Herzschlag von Scrum, die Phase, in der Ideen in Werte umgesetzt werden. Der Sprint ist als Container, als dauerhaftes Event, als dauerhafte Zeremonie der Scrum-Methode zu sehen, innerhalb dessen andere Events stattfinden, Rollen wie der →Scrum Master, der →Product Owner oder die Entwickler ihrer Verantwortlichkeit nachgehen und in denen das →Product Backlog abgearbeitet wird und zu einem →Inkrement geschmiedet wird. Das ist jedoch nur sehr oberflächlich beschrieben. Ein neuer Sprint, also ein Zyklus, innerhalb dessen wir als Team arbei‐ ten, dauert nie länger als einen Monat. In der Regel kürzt man einen Sprint entsprechend so, wie es für die Organisation und das Team passt - vornehmlich in Wochenzyklen. Das bedeutet, ein Sprint dauert in der 61 Aufbau und Funktionsweise von Scrum Praxis zwischen zwei und vier Wochen. Dies ist auch so im Scrum Guide vorgesehen. Er würde aber nie zwei Wochen und drei Tage beispielsweise dauern. Angebrochene Wochen sind ungeeignet. Abb. 11 Ein neuer Sprint beginnt unmittelbar, nachdem der vorangegangene abge‐ schlossen wurde. Alle Events - wie Sprint Planning, Daily Scrum, Sprint Review und Sprint-Retrospektive sowie Refinement finden im Rahmen des Sprints statt. Folgende Rahmenparameter sind für den Sprint zu vermerken: ▶ Während des Sprints werden keine Änderungen vorgenommen, die das Sprint-Ziel gefährden. ▶ Jeder Sprint ist mit einem Sprint-Ziel, auch →Sprint Goal genannt, versehen. ▶ Während des Sprints ist es wichtig, dass die Qualität nicht abnimmt, sondern die Entwickler dauerhaft auf höchstem Niveau am Produkt arbeiten. ▶ Während des Sprints entwickelt das Team das Inkrement. 62 Aufbau und Funktionsweise von Scrum ▶ Während des Sprints arbeitet der Product Owner daran, das Product Backlog weiterhin zu verfeinern, zu refinen. ▶ Während des Sprints ist es die Aufgabe des Product Owners, neue Erkenntnisse über das Produkt, über die Anforderung zu erlangen und diese bei Bedarf, sofern es nicht das Sprint-Ziel gefährdet, in den Sprint zu geben. Wie lange dauert ein Sprint tatsächlich? Das ist häufig eine wichtige Frage, vor allen Dingen in der Praxis: Wie lange sollte ein Sprint optimaler Weise dauern? Und hierauf gibt es keine allgemeingültige Antwort. Im Grunde genommen kann man postulieren: Je höher die Ungewiss‐ heit des zu entwickelten Produkts bzw. der Anforderung des Kunden für das Produkt ist, umso kürzer sollten die Sprintzyklen dauern. Wenn also ein neues Produkt auf den Markt gebracht werden soll, wenn nicht bekannt ist, wie dieses bei den Kunden ankommt, und wenn noch nicht klar ist, welche Features dem Kunden welchen Nutzen stiften, dann sollte eher mit sieben Tagen gesprintet werden - also mit der denkbar kürzesten Dauer. Wenn man genau weiß, was man entwickeln möchte und eher den administrativen „Overhead“ durch zu viel stattfindende Scrum-Events verringern möchte, so ist ein vierwöchiger Sprintzyklus zu bevorzu‐ gen. Im Grunde genommen gilt die Faustregel: Je kürzer der Sprint, desto stärker beschränkt man das Risiko von Kosten und drohendem Aufwand durch eine Falschentwicklung. Je sicherer man sich mit der Entwicklung ist, desto länger können die Sprints sein. Innerhalb eines Sprints gibt es wiederum verschiedene Möglichkeiten, den Fortschritt des Sprints transparent zu machen. Generell hat der Stakeholder, der in der Praxis vor allen Dingen das Interesse hat, die Entwicklung eines Projekts zu beobachten, die Option, in das Sprint Backlog - also die Aufgabenliste des Sprints - hineinzuschauen. Hierfür kann man darüber hinaus weitere Praktiken wie zum Beispiel ein Burn-Down-Chart heranziehen, was den Sprintfortschritt grafisch darstellt. Ein Sprint-Burn-Down-Chart besteht aus zwei Grafen in einem Koordinatensystem, wobei der eine Graf zeigt, wie weit man in dem Sprint gemäß der Planung sein sollte, und der andere Graf zeigt, 63 Aufbau und Funktionsweise von Scrum wie weit das Team tatsächlich ist. Eine Abbildung dafür findest du im nachfolgend: ZEIT IST SOLL ARBEIT Abb. 12: Burn-Down-Chart In der Praxis wird häufig das Daily Scrum als Einladung an die Stakeholder genutzt, dem Scrum beizuwohnen, um zu erfahren, wie die Entwickler und das Team im Fortschritt des Sprints vorankommen. Das Daily Scrum bietet mit seinem 15-Minuten-Rhythmus beste Voraussetzung dafür, kurz, prägnant und effizient alle darüber zu informieren, wie der aktuelle Stand des Sprints ist. Natürlich funktioniert es nicht immer, dass die Stakeholder am Daily Scrum teilnehmen können. Kann ein Sprint geändert oder angepasst werden? Der Sprint sollte in seinem Rhythmus nicht geändert werden. An diese Vorgabe sollten sich vor allen Dingen frisch gebildete Teams halten, welche sich vielleicht erst austesten müssen. Der einmal festgelegte Sprint bleibt fix und wird nicht frühzeitig beendet. Es ist eine absolute Ausnahme und Besonderheit, wenn ein Sprint abge‐ brochen bzw. beendet wird. Dies geschieht nur dann, wenn das endgültige Ziel obsolet wird. Die Entscheidung, ob ein Sprint abgebrochen wird und komplett neu geplant werden muss, obliegt dem Product Owner. Er allein hat die Autorität, den Sprint abzubrechen. Falls ein Sprint abgebrochen wird, findet automatisch Sprint Review statt und darauffolgend die Retrospektive und wiederum darauf das neue Sprint Planning. 64 Aufbau und Funktionsweise von Scrum Ein weiterer Grund, wieso ein Sprint vorzeitig beendet werden könnte, ist etwa die Coronasituation: Geben wir in diesem Beispiel vor, dass wir einen Onlineshop entwickeln und gerade dabei sind, ein neues Feature auf den Markt zu bringen, in dem Kunden nun auch innerhalb des Online‐ shops miteinander chatten können. Im Laufe der Coronakrise beschließt die Bundesregierung eine Mehrwertsteuersenkung auf 16 %. Das ist die Basis unseres Sprints, den wir betrachten: Wir berücksichtigen dies und die Mehrwertsteuersenkung auf 16 % wird im folgenden Sprint umgesetzt. Inmitten der Umsetzung im Onlineshop muss aus rechtlichen Gründen die Steueränderung zurückgenommen werden. Damit wäre das Sprint-Ziel obsolet und der Product Owner hat einen validen Grund, den Sprint abzu‐ brechen. Was ist ein Sprint Planning? Das Sprint Planning ist eine Zeremonie bzw. ein Event, das den Sprint initiiert. Man legt in diesem Meeting innerhalb des Entwicklungsteams fest, welche Arbeiten man erledigen will. Dies wird in der To-do-Liste für diesen Sprint festgehalten, dem Sprint Backlog. Dieser Plan wird durch die kollektive Arbeit des gesamten Scrum-Teams erstellt. Wir gliedern das Sprint Planning in drei Themen: ▶ Thema 1: Warum ist dieser Sprint wertvoll? ▶ Thema 2: Was kann in diesem Sprint getan werden? ▶ Thema 3: Wie wird die gewählte Arbeit erledigt werden? 65 Aufbau und Funktionsweise von Scrum Abb. 13 Warum ist dieser Sprint wertvoll? Hierbei ist es die Aufgabe des →Product Owner vorzuschlagen und vorzu‐ stellen, wie das Produkt, an dem wir als Scrum-Team arbeiten, im aktuellen Sprint seinen Wert und Nutzen steigern könnte. Das Scrum-Team arbeitet dann gemeinsam daran, ein Sprint-Ziel zu definieren, das kommuniziert und festlegt, warum der Sprint für die Kunden und die Stakeholder wertvoll 66 Aufbau und Funktionsweise von Scrum sein wird. Das Sprint-Ziel muss benannt werden, bevor das Sprint Planning absgechlossen wird. Wichtig dabei ist zur Erinnerung: Ein Sprint kann immer nur dann seitens des Product Owners abgebrochen werden, wenn dieses Sprint-Ziel obsolet wird. Das Sprint-Ziel bietet außerdem dem Entwicklungsteam ein Warum für diesen Sprint. Was kann in diesem Sprint getan werden? Im nächsten Schritt besprechen die Entwickler mit dem Product Owner, welche Items, welche Elemente aus dem Product Backlog in den Sprint einfließen sollen. Das Scrum-Team hat nun die Möglichkeit, offene Fragen mit dem Product Owner zu klären und so das Was bestmöglich für den Sprint vorbereitet zu haben. Übrigens, das Scrum-Team respektive die Entwickler haben hier nicht allzu viel Mitspracherecht. Sie können lediglich den Product Owner beraten, wenn es um die Frage der Priorisierung geht. Denn, die Priorisierung des Product Backlogs und den daraus resultierenden Elementen für das Sprint Backlog obliegt weiterhin dem Product Owner. Jedoch kann es innerhalb des zweiten Teils des Sprint Plannings vorkommen, dass die Entwickler den Product Owner auf Synergieeffekte oder logische Veränderungen der Elemente hinweisen, die der Product Owner dann mitgeben kann. Ein Beispiel hierfür: Der →Product Owner ist bei seiner Priorisierung der Meinung, dass zuerst die Tapete an die Wand kommt und erst danach diese mit Kleister versehen wird. Dann könnte der Entwickler mit einer Alternativlösung einschreiten: Stopp, unser Vorschlag: zuerst den Kleister auf die Tapete aufzutragen und danach diese an die Wand kleben. Offen‐ sichtlich ist der Einwand berechtigt und die Arbeit logischer und einfacher zu handhaben. Wie wird die gewählte Arbeit erledigt? Für jedes Product-Backlog-Element planen die Entwickler die Arbeit, die notwendig ist, um das Inkrement, das im Grunde genommen das mate‐ rialisierte Sprint-Ziel ist, zu erstellen. Wichtig hierbei ist, dass es entspre‐ chend der Definition of Done erledigt wird. Häufig passiert es, dass die Product-Backlog-Elemente, welche in das Sprint Backlog übernommen wurden, in noch kleinere Arbeitsaufgaben bzw. Tasks von einer Zeitspanne von einem Tag und weniger seitens der Entwickler zerlegt werden. 67 Aufbau und Funktionsweise von Scrum Beispielsweise könnte es vorkommen, dass man den Task des oben genannten Beispiels „Tapete an die Wand kleben“ in die Schritte 1. Aufbau des Tapeziertisches, 2. Auftragen des Kleisters, 3. Tapete an die Wand kleben aufteilt. Diese Unterteilung und wie dieses Product-Backlog-Element abge‐ arbeitet wird, liegt allein im Ermessen der Entwickler. Nur sie legen fest, wie das Product-Backlog-Element gemäß der in der Definition of Done geforderten Qualität entwickelt werden kann. Hierzu macht man sich der Technik knowledge based decision, also Entscheidungen werden da getroffen, wo das Wissen ist, zunutze. Der →Product Owner und der →Scrum Master respektieren hier die Meinung des Entwicklungsteams. Wie lange darf ein Sprint Planning dauern? Das Sprint Planning besitzt ebenfalls eine zeitliche Timebox, welche auf maximal acht Stunden für einen einmonatigen Sprint begrenzt ist. Bei kürzeren Sprints ist das Event entsprechend zu skalieren. Der Scrum Master hat bei diesem Event die Verantwortung, dass alle Verantwortlichkeiten eingehalten werden, dass der Prozessschritt nach den drei Themen unterteilt verläuft und dass am Ende ein Sprint-Ziel mit einem für den Sprint bereites Sprint Backlog entsteht. In der Praxis geschieht es oft, dass die Themen 1 und 2 in ein erstes Meeting gelegt werden, während ein zweites Meeting Thema 3 behandelt. Der Hintergrund ist: Der Product Owner muss bei Thema 3 nicht unbedingt anwesend sein. Videotipp: Die wichtigsten Aspekte des Sprint Plannings werden in diesem Kurz‐ video noch einmal erklärt: ► https: / / youtu.be/ NB3LBLKa4xA 68 Aufbau und Funktionsweise von Scrum Was ist ein Daily Scrum? Ein Daily Scrum ist die bekannteste Methode des Scrum-Frameworks. Es beschreibt ein täglich stattfindendes Meeting des Scrum-Teams mit Anwesenheitspflicht - jedoch nur für die Entwickler. Das Daily Scrum ist wie jedes Meeting bzw. wie jedes Event immer zur selben Zeit am selben Ort durchzuführen. Es dauert maximal 15 Minuten und auch hier kommt die Timebox zum Einsatz. Das Daily Scrum hat die Funktion, dass die Entwickler sich unterein‐ ander austauschen. Damit wird ihnen ermöglicht, den Fortschritt des Sprint-Ziels überprüfen zu können. Bei Bedarf dürfen die Entwickler im Rahmen des Sprint Backlogs eine Anpassung vornehmen. Die Stakeholder haben ebenfalls das Recht an dem Daily Scrum teilzu‐ nehmen. Jedoch ist hier zu beachten, dass sie sich absolut schweigend verhalten müssen, also nur als stiller Zuhörer dem Meeting beiwohnen dürfen. Das Meeting, das nun jeden Arbeitstag stattfindet, kann auch vom →Product Owner und vom →Scrum Master besucht werden. Ihre Rolle ähnelt jedoch der des Stakeholders. Sie haben keine aktive Rolle - es sei denn, sie haben selbst ein Element am Sprint Backlog, an dem sie arbeiten. Dann nehmen sie allerdings in ihrer Rolle als Entwickler teil. Die Entwickler können das Daily Scrum in jeder beliebigen Struktur und Technik anwenden, solange ihr Daily Scrum sich auf den Fortschritt in Richtung des Sprint-Ziels konzentriert und ein umsetzbarer Plan für den Arbeitstag erstellt wird. Das Daily Scrum so einen Fokuspunkt schaffen und dazu beitragen, dass das Team sein Selbstmanagement verbessert. 69 Aufbau und Funktionsweise von Scrum Abb. 14 Ist das Daily Scrum sehr wichtig für die Praxis? In der Praxis erlebt man es doch immer wieder, dass Daily Scrums zu Beginn sehr geringfügig von Kommunikation geprägt sind. Der Scrum Master muss in diesen Fällen häufig eine Kommunikation erst „anschieben“. Mit der Zeit werden die Entwickler jedoch immer besser darin, einen Austausch herbeizuführen. Schließlich benötigen sie am Ende ihres Reifegrades keine externe Unterstützung mehr, um das Meeting erfolgreich zu gestalten. Das Daily Scrum bietet einige Vorteile in der Praxis. Es ▶ verbessert die Kommunikation, ▶ identifiziert Hindernisse und Stolpersteine, ▶ fördert eine schnelle Entscheidungsfindung, weil man andere Meetings nicht mehr benötigt, sondern sie auf das Daily Scrum vertagt. Oft denken die Entwickler, dass das Daily Scrum die einzige Möglichkeit ist, an dem sie sich austauschen dürfen. Das ist so nicht richtig. Die 70 Aufbau und Funktionsweise von Scrum Entwickler dürfen den ganzen Tag kommunizieren. Es ist nur die einzige von Scrum vorgegebene Zeremonie, bei der die Entwickler wirklich anwesend sein und darüber sprechen müssen, was sie aktuell tun. Damit hat man die Garantie, dass jedes Teammitglied auf demselben Wissenstand ist. Das Daily Scrum schafft also in erster Linie Transparenz. Videotipp: In diesem Kurzvideo findest du die wesentlichen Informationen zum Daily Scrum: ► https: / / youtu.be/ -Tm_MUIudjk Hat Daily Scrum etwas mit Daily Standup zu tun? In der Praxis stellt man fest, dass das Daily Scrum sehr einfach in eine Organisation einzuführen ist und schnell einen Mehrwert erzielt. Das Daily Scrum ist übrigens eine Methode, die es auch über Scrum hinaus geschafft hat und vielleicht in der einen oder anderen Organisation als Daily Standup bekannt ist. Das Daily Standup ist jedoch noch ein wenig abgewandelt, stammt aber von der Idee des Daily Scrums. Das Daily Standup beschreibt sehr bildlich die Methode, dass man sich bei diesem Meeting hinstellt. Es soll dazu beitragen, dass das Meeting wirklich auch sehr kurzgehalten wird. Diese Vorgehensweise hat sich im Daily Scrum ebenfalls eingebürgert, weshalb in der Praxis eigentlich ausschließlich Daily Scrums im Stehen durchgeführt werden. Muss man sich beim Daily Scrum an einem Ort physisch treffen? Tatsächlich ist die Frage vor dem Hintergrund der Vorsichtsmaßnahmen in Zeiten einer Pandemie berechtigt. In der Scrum-Theorie war nie angedacht, dass Meetings remote stattfinden, aber man hat sich inzwischen an die aktu‐ elle Situation angepasst und Daily Scrums in Zeiten von Videokonferenzen funktionieren sehr gut. 71 Aufbau und Funktionsweise von Scrum Am Anfang braucht jedes Team, wenn es in die Remote-Welt wechselt, immer einen kurzen Moment, um sich einzugewöhnen. Aber man kommt doch sehr schnell auf die Idee, auch in der Remote-Welt eine Struktur einzuführen, wie zum Beispiel, dass man immer an dieselbe Person das Wort weitergibt oder immer dieselbe Person das Meeting eröffnet. So bleibt auch ein digitales Meeting effizient. Was ist ein Sprint Review? Das →Sprint Review ist eine Zeremonie bzw. ein Event innerhalb des Scrum-Prozesses respektive innerhalb des Sprints. An diesem Event haben die Entwickler und das Entwicklungsteam die Möglichkeit, ihre Ergebnisse des Sprints, also jene Ergebnisse, die einmal im Sprint Planning festgelegt wurden, zu präsentieren. Diese Präsentation findet in einem großen Umfeld von Stakeholdern statt, die nicht Mitglied des normalen Scrum-Teams sind. Hier hat jeder die Mög‐ lichkeit, dazuzustoßen und sich die Vorstellungen des Entwicklungsteams anzuschauen. Übrigens: In der Praxis wird diese Veranstaltung auch oft „Demo“ ge‐ nannt. Hieran erkennt man, dass Scrum aus der IT-Branche stammt, da oft die entwickelte Software präsentiert wird. Das Review hat den großen Vorteil, Transparenz über den aktuellen Entwicklungsstand des Produkts herzustellen und das Inkrement, also das Teilprodukt, welches am Ende jedes Sprints hergestellt ist, zu überprüfen. Der echte Wert eines jeden Reviews wird vor allen Dingen dann hergestellt, wenn die Stakeholder ihr Feedback geben. Dieses Feedback fällt immer anders aus, als wenn die Stakeholder das Produkt nicht sehen würden. Diese Tatsache macht das Review zu einem so wertvollen Termin: Schließlich gibt es zum aktuellen Produktstand eine Vorschau, die transparent visualisiert, wie der aktuelle Stand aussieht. Dies wiederum führt dazu, dass die Stake‐ holder ein deutlich besseres und qualifizierteres Feedback geben können. 72 Aufbau und Funktionsweise von Scrum Abb. 15 73 Aufbau und Funktionsweise von Scrum Warum ist das Sprint Review gerade in einem dynamischen Umfeld so wichtig? Während des Sprint Reviews überprüft das Scrum-Team und die Stakehol‐ der, was im Sprint erreicht wurde und vor allen Dingen was sich in dem Umfeld verändert hat, auf dessen Grundlage der nächste Sprint starten würde. Hier geht es vor allem darum, dass der Product Owner die Stakehol‐ der versteht und bespricht, was als nächstes zu tun ist. Bei Bedarf kann auch tatsächlich jetzt schon das→ Product Backlog angepasst werden, um für den nächsten Sprint vorbereitet zu sein. Das Sprint Review ist laut Scrum Guide genaugenommen die vorletzte Veranstaltung des jeweiligen Sprints und findet meist am selben Tag wie die Sprint-Retro‐ spektive statt. Gibt es auch für das Sprint Review eine Zeitvorgabe? Ja. Bei einem einmonatigen Sprint ist das Sprint Review auf maximal vier Stunden zu begrenzen, bei kürzeren Sprints ist das Ganze zeitlich herunterzuskalieren. In der Praxis ist dies zumeist so gestaltet, dass es vor dem Sprint Review eine kleine Teamsitzung gibt, um sich für das Event vorzubereiten. Das ist zwar im Scrum Guide nicht vorgesehen, entspricht aber der gängigen Praxis. Hier hat es sich bewährt. Immerhin kommen bei größeren Unternehmen auch gerne die Vorstände, um sich die Präsentationen anzusehen. In diesem Kontext ist es ein wichtiges Projekt-Marketing-Instrument bzw. ein Team-Marketing-Instrument. Es empfiehlt sich, für dieses Event gut vorbereitet zu sein. War trägt die Verantwortung für das Sprint Review? Die Vorbereitung und methodische Durchführung sowie Moderation des Meetings obliegt dem Scrum Master: Er führt mit den Entwicklern durch dieses Meeting und schreitet gerne auch ein, sollten sich die Teammitglieder mit den Stakeholdern in eine zu tiefgehende Diskussion verstricken, welche für den einen oder anderen Zuhörer nicht relevant ist. 74 Aufbau und Funktionsweise von Scrum Neben den bereits aufgeführten Vorteilen zeichnet das Sprint Review noch der wichtige Aspekt der Wertschätzung aus. Es ist tatsächlich so, dass die Entwickler gerne ihre Arbeit vorstellen und das Review bietet die Gelegenheit, hier als Stakeholder oder Verantwortlicher Lob auszusprechen oder die geleistete Arbeit wertzuschätzen. Oft kommt es in der Praxis leider vor, dass eher kritische Fragen gestellt werden, als das Lob ausgesprochen wird. Da obliegt es auch dem Scrum Master gerne mal die Stakeholder darauf hinzuweisen, wenn nicht sogar selbst die Aussprache von Lob und Wertschätzung zu übernehmen, da dies ein zentraler Motivationsaspekt des Teams ist. Videotipp: In diesem Kurzvideo findest du die wesentlichen Informationen zum Sprint Review: ► https: / / youtu.be/ AWBA0DFSMKU Was ist eine Sprint-Retrospektive? Die Sprint-Retrospektive, oder umgangssprachlich auch einfach nur „Retro“ genannt, ist ein wichtiges Event für das Scrum-Team hinsichtlich der Qua‐ litätssteigerung in ihrem Team. Und hierbei ist nicht die Qualität ihres Pro‐ dukts, was eher die B-Note betreffen würde, dieser Retrospektive gemeint, sondern tatsächlich die Qualität der Zusammenarbeit, der methodischen Zusammenarbeit, des Teamgefühls. Die Sprint-Retrospektive findet stets am Ende des Sprints statt, meist unmittelbar nach dem Sprint Review. Sie dient der Analyse, wo in den Pro‐ zessen, in den Tools, in der Zusammenarbeit das Team noch Möglichkeiten zur Verbesserung hat. 75 Aufbau und Funktionsweise von Scrum Abb. 16 76 Aufbau und Funktionsweise von Scrum Wird die Sprint-Retrospektive nicht auch kritisch gesehen? In der Praxis existiert oft der Irrglaube, dass eine Retro irgendwann keinen Wert mehr hat. Diese Interpretation stammt meist von Stakeholdern, die nicht in einem Scrum-Team mitarbeiten. Sie fragen sich, ob die Retro wirklich notwendig ist, um bessere Ergebnisse zu erzielen, oder ob die Retro reine Zeitverschwendung ist, ein reiner Overhead? Und wenn derartige Fragen aufkommen, ist es meist ein gutes Zeichen dafür, dass der Scrum Master noch Potenzial zur Verbesserung auf der Stakeholder-Ebene hat. Denn eine Retro ist in aller Regel keine Zeitverschwendung, sondern dient zur deutlichen Steigerung des Teamgefüges. Auch denken einige Teammitglieder, einige Entwickler vielleicht, dass die Retro nicht mehr wertvoll ist. Auch Scrum Master kommen hin und wieder zu dem Schluss, die Retro wäre irgendwann so ausgepresst, dass kein Mehrwert entsteht. Aber es gibt einen guten Tipp aus der Praxis: Das Team hat immer genügend Paintpoints. In der Regel sogar mehr Paintpoints als Zeit zur Verfügung steht, um diese zu beheben. Sollte euer Team einmal an die Stelle kommen, keine Paintpoints mehr zu haben, und es gibt nichts mehr zu besprechen, dann sollte man als Scrum Master an dieser Stelle deutlich tiefer nachbohren, um die Verbesserungsvorschläge zu identifizieren. Denn jedes Team kann sich verbessern. Videotipp: In diesem Kurzvideo findest du die wesentlichen Informationen zur Sprint-Retrospektive: ► https: / / youtu.be/ f3QPX6zlu8Y Was ist das eigentliche Ziel der Sprint-Retrospektive? Im Grunde genommen geht es darum, dass das Team sich in der Zusammen‐ arbeit verbessern kann. Hierbei moderiert der Scrum Master die Retrospek‐ tive anhand verschiedener Retro-Beispiele durch. Es gibt eine Vielzahl an Retro-Formaten, welche bei manchen Unternehmen ständig variieren. Bei anderen Unternehmen wird jede Retro im gleichen Format durchgeführt. 77 Aufbau und Funktionsweise von Scrum Was hier richtig oder falsch ist, muss jedes Team oder jedes Unternehmen für sich selbst entscheiden. Folgende Ziele haben jedoch alle Formate gemeinsam: ▶ Transparenz über die aktuelle Situation herstellen, ▶ Entwicklungsfelder identifizieren und ▶ diese verbessern oder umsetzen. Es fällt auf, dass diese drei Schritte dem des Scrum-Prozesses der der empirischen Theorie entsprechen: ▶ Transparency, ▶ Inspection und ▶ Adaption werden innerhalb der Retrospektive - wie auch in allen anderen Meetings - angewendet. Man identifiziert und analysiert ein Problem und findet Verbesserungsmöglichkeiten. Wenn dies vorgenommen wurde, identifiziert das Team die hilfreichsten Änderungen, also meistens nach Effektivität und Umsetzbarkeit. Es sucht sich im besten Fall eine dieser Maßnahmen aus und fügt sie dem Sprint Backlog - und das ist eine ganz entscheidende Sache - für den nächsten Sprint hinzu, um diese umzusetzen. Die Sprint-Retrospektive ist für einen einmonatigen Sprint auf maximal drei Stunden begrenzt. Im Falle von einem kürzeren Sprint wird hier zeitlich auch wieder herunterskaliert. In diesem Fall, in einem zweiwöchigen Sprint würde die Retro dann 1,5 Stunden dauern. Der Sprint endet mit der durchgeführten Retro und der nächste Sprint folgt direkt. 78 Aufbau und Funktionsweise von Scrum Gibt es ein anschauliches Beispiel für eine praxistaugliche Retrospektive? Ja, nehmen wir das Segelboot Retro: Zeichne ein Segelboot auf ein Flipchart-Papier. Dieses symbolisiert das Team. Wichtig sind dabei: - ein großes Segel und - ein schwerer Anker. Die Teammitglieder schreiben in Stillarbeit jeder für sich auf Haftnoti‐ zen, was das Team einerseits vorwärts getrieben hat, also der Wind in den Segeln war, und andererseits was es an Ort und Stelle gehalten hat, also der schwere Anker für das Team war. Jedes Teammitglied bringt nun pro Kategorie - Segel sowie Anker - mindestens eine Notiz an der entsprechenden Stelle des Flipchart-Pa‐ piers an. Durch die Hinzunahme einer weiteren Kategorie ist eine Erweiterung denkbar: Manche Teams malen noch einen Eisberg in das Schaubild - dieser symbolisiert entweder ein sich näherndes Hindernis, welches man bereits erkennen kann, oder ein Risiko, das neu entstanden ist. Entsprechend muss bei dieser Erweiterung jedes Teammitglied mindestens drei Notizen erstellen und anbringen. Was ist ein Refinement? Ein Refinement ist im Scrum Guide nicht als Scrum-Event aufgeführt. Jedoch wird es in der Praxis als absolut gängige Methode oder Technik angesehen. 79 Aufbau und Funktionsweise von Scrum Abb. 17 80 Aufbau und Funktionsweise von Scrum Das Refinement ist eine Technik oder eine Form des Meetings, bei dem der Product Owner mit dem Entwicklungsteam gemeinsam über den Sprint spricht. Dabei geht es darum, welche Tätigkeiten dort zu erwarten sind. Der Zeitpunkt für ein Refinement ist vollkommen unabhängig von der von Scrum vorgegebenen Meetingstruktur. Die einzige Bedingung lautet, dass der gewählte Zeitpunkt vor dem nächsten Sprint liegt. Übrigens können im Refinement auch Aufgaben für darauffolgende Sprints besprochen werden. Es ist nicht notwendig, dass diese im nächsten Sprint sofort umgesetzt werden. Vielmehr geht es darum, dass der →Pro‐ duct Owner die Product-Backlog-Items so definiert, dass die Entwickler diese verstehen. Nur so können die Anforderungen umgesetzt werden. Wer ist für den Ablauf des Refinements verantwortlich und was ist das Ziel? Oft wird in der Praxis der Termin für ein Refinement von einem →Scrum Master begleitet. Er übernimmt die Moderation. Das Ziel des Refinements ist es, das Product Backlog so verständlich wie möglich mit den Entwicklern durchzugehen, um ein sehr effizientes Sprint Planning durchführen zu können. Hierbei geht es darum, ▶ die einzelnen Product-Backlog-Elemente mit den Entwicklern zu be‐ sprechen, ▶ diese zu beschreiben, ▶ den Wert - also den Value - für den Kunden den Entwicklern zu erklären und ▶ letztlich die jeweiligen Product-Backlog-Elemente zu schätzen. Das ist das Ziel des Refinements. Damit könnte es auch als sogenanntes Preplanning fungieren, mit der Absicht, das reguläre →Sprint Planning so effizient wie möglich zu gestalten. 81 Aufbau und Funktionsweise von Scrum Welche Artefakte gibt es? Artefakte sind in der Scrum-Lehre ein anderes Wort für Tools oder Dokumente für das Scrum-Team. Diese sollen dabei helfen, in Bezug auf die erledigte Arbeit Transparenz herzustellen und so allen beteiligten Stakeholdern die Option zu bieten, selbst der Scrum-Theorie des Empi‐ rismus nachzukommen. Die Transparenz wird über die →Artefakte hergestellt. Dabei hat ent‐ weder das →Scrum-Team selbst oder die Stakeholder die Möglichkeit, ▶ zu inspizieren und ▶ eventuell zu adaptieren sowie ▶ Verbesserungen umzusetzen oder ▶ Verbesserungen umsetzen zu lassen. Jedes Artefakt besitzt, so ist es im Scrum Guide beschrieben, ein Com‐ mitment, bei dem es eine Challenge des Artefakts zu bewältigen gilt. Aber zurück zur eigentlichen Frage: Welche Artefakte gibt es? ▶ Das Product Backlog, ▶ das Sprint Backlog und ▶ das Inkrement, das nach einem Sprint herauskommt. 82 Aufbau und Funktionsweise von Scrum Abb. 18 Welche Commitments sind den jeweiligen Artefakten zugeordnet? Das →Product Backlog hat das Product Goal als Commitment, das →Sprint Backlog hat das Sprint Goal als Commitment und das →Inkrement hat die Definition of Done als Commitment. Artefakt Commitment Product Backlog Product Goal Sprint Backlog Sprint Goal Inkrement Definition of Done 83 Aufbau und Funktionsweise von Scrum Der Zusammenhang lässt sich gut am Beispiel aus der letzten Zeile verständ‐ lich machen: Erst wenn das Inkrement alle Elemente der Definition of Done erfüllt hat, ist das Inkrement tatsächlich ein Inkrement. Was versteht man unter einem Product Backlog genau? Ein Product Backlog ist zunächst eine To-do-Liste, welche der Product Ow‐ ner für notwendig hält, um das Produkt mit einem Mehrwert zu entwickeln. Abb. 19 Dem Produkt und dem Kunden, der dieses Produkt nutzt, einen höheren Value zuzuschreiben, gilt als höchste Anforderung an die Aufgabe des →Product Owners und somit auch an das →Product Backlog. Das Product Backlog ist die einzige Quelle für die Arbeit des Scrum-Teams. Alles, was das 84 Aufbau und Funktionsweise von Scrum Scrum-Team - mit Ausnahme der Retro-Maßnahme - in das Sprint Backlog übernimmt, kommt aus dem Product Backlog und wurde vorher mit Details versehen, beschrieben, priorisiert und geschätzt. Erst auf diese Weise entspricht das jeweilige Product-Backlog-Element der sogenannten, zwar nicht in Scrum beschriebenen, aber in der Praxis oft verwendeten Definition of Ready. Sind die Product-Backlog-Elemente derartig beschrieben und geordnet, also priorisiert, können sie seitens der Scrum-Entwickler im Sprint Planning aus dem Product Backlog entnommen und in das Sprint Backlog eingefügt werden. Das Product Backlog ist ein lebendes Artefakt, ein lebendes Dokument, welches in der Theorie niemals fertiggestellt wäre, solange das Produkt am Markt aktiv ist. Hierbei sind die Begriffe ‚Produkt‘ und ‚Markt‘ durchaus unterschiedlich zu definieren: So kann sowohl von einem Softwareprodukt im klassischen Usermarkt die Rede sein als auch von einem Prozess inner‐ halb der Organisation. Auch in diesem Fall kann ein Scrum-Projekt oder eine Scrum-Produktentwicklung Sinn machen und der Prozess selbst wäre dann das beschriebene Produkt. Was ist ein Sprint Backlog? Das Sprint Backlog ist im Grunde - wie das →Product Backlog auch - eine To-do-Liste. Allerdings ist diese To-do-Liste nicht auf das Gesamtprodukt bezogen, sondern lediglich auf den nächsten Sprint. 85 Aufbau und Funktionsweise von Scrum Abb. 20 Das →Sprint Backlog beinhaltet sowohl das Warum, also das Sprint-Ziel bzw. →Sprint Goal, als auch das Was, also welche Product-Backlog-Ele‐ mente im Sprint Planning herangezogen wurden, und letztlich auch das Wie, also die Art und Weise der Umsetzung der Elemente. Das erinnert an die drei Fragen: ▶ Warum? ▶ Was? ▶ Wie? Dies wurde bereits bei den Fragen zum Sprint Planning beantwortet. Das Sprint Backlog stellt also die To-do-Liste bzw. den Plan für den nächsten Sprint dar. Das Besondere daran ist, dass das Sprint Backlog jeden Tag aktualisiert wird. Arbeitet man nun mit einer Software wie Jira oder 86 Aufbau und Funktionsweise von Scrum Trello, so ist dieser Plan auch jeder Zeit aktuell und für jeden sichtbar. Er kann dadurch auch von den Stakeholdern des Projekts aufgerufen werden. Dieses Instrument besitzt demnach während der gesamten Arbeit im Sprint die Funktion der Transparenz. Es bringt alle Beteiligten auf den aktuellen Stand. Mithilfe des Sprint Backlogs werden die aufwändigen Konferenzen des klassischen Projektmanagements obsolet. Durch Scrum spart man sich Bericht-, Statusmeetings und Lenkungsausschusssitzungen - zumindest im herkömmlichen Sinne. In der Realität reichen diese Mechanismen leider nicht immer aus, so dass es dennoch vorkommt, dass Entwickler und auch andere Scrum-Teammit‐ glieder kontinuierlich Berichte an etwaige Stakeholder senden müssen - obgleich in der Scrum-Theorie alle Mechanismen vorhanden wären, um die notwendige Transparenz herzustellen. Wann im Scrum-Prozess wird das Sprint Backlog von den Beteiligten eingesehen? Das →Sprint Backlog wird in der Regel während des →Daily Scrum eingesehen. Für die Praxis heißt das, dass man sein Jira- oder Trello-Board offenhält. Alternativ - das geschieht oft in der Praxis - werden diese Elemente ausgedruckt und auf ein physisches Board geklebt. Das ist deshalb häufig hilfreich, da man auf diese Weise den aktuellen Fortschritt erkennen kann. Bei dieser Vorgehensweise entsteht allerdings ein höherer Pflegeaufwand, da man nicht nur das automatisierte Board aktuell halten muss, sondern auch das physische Board im Raum. Infolge der Coronapandemie und der damit verbundenen virtuellen Arbeitsweise der Scrum-Beteiligten scheint das physische Board langsam auszusterben. Schließlich arbeiten viele inzwischen im Homeoffice. Wer ist für das Sprint Backlog verantwortlich? Die Verantwortlichen für das Sprit Backlog sind die Entwickler. Sie zeichnen für seine Umsetzung verantwortlich und wählen Struktur und Methode des Sprint Backlogs. 87 Aufbau und Funktionsweise von Scrum Allerdings dürfen →Product Owner und →Scrum Master hier eine bera‐ tende Funktion einnehmen. Der Scrum Master kann dabei aus methodischer Sicht in der Regel mehr beitragen als der Product Owner. Was ist ein Inkrement? Das dritte Artefakt, von dem innerhalb der Scrum-Theorie die Rede ist, ist das Inkrement. Ein Inkrement ist im Grunde genommen eine neue Produktversion bzw. eine Weiterentwicklung. Es ist damit ein Teil des Gesamtprodukts. Abb. 21 Das Inkrement stellt demnach einen weiteren Schritt hin zum Produktziel dar. Jedes Inkrement ist passgenau zu den vorherigen Inkrementen. Es ist als additive Weiterentwicklung zu sehen. Bevor ein Inkrement zu den 88 Aufbau und Funktionsweise von Scrum vorherigen hinzugefügt wird, muss es getestet und gründlich überprüft werden. Ziel ist es herauszufinden, ob tatsächlich an alles gedacht wurde, um nicht die bereits vorangegangenen Inkremente oder Produktversionen zu gefährden. Das Inkrement muss in erster Linie verwendbar sein, damit es in der Praxis Kundenwert, also Value für das Produkt und für das Unternehmen, generieren kann. Das Inkrement wird am Ende jedes Sprints ausgeliefert. Es kann jedoch auch vorkommen, dass es innerhalb eines Sprints mehrere Inkremente gibt. Entweder das einzelne neue Inkrement oder sämtliche Inkremente werden bei dem Sprint Review präsentiert. Dieses Vorgehen macht den aktuellen Stand des Projekts für die Stakeholder transparent. Die Arbeit bzw. das Inkrement ist nur dann als fertig bzw. erledigt anzusehen, wenn die sogenannte Definition of Done erreicht wurde. Ist die Definition of Done nicht vollständig erfüllt, kann das Inkrement nicht ausgeliefert und auch nicht im Sprint Review betrachtet werden, sondern es wird zurückgestellt und muss im nächsten Sprint vollendet werden. Es ist nicht notwendig, dass das Inkrement am Ende des Sprints auch an den Kunden gegeben wird. Es kann auch sein, dass man mehrere Sprints benötigt, bis man etwas an den Kunden geben kann. Es ist deshalb nicht zwingend notwendig, jedes Sprint-Inkrement an den Kunden zu übergeben, sondern nur dann, wenn es für ihn Sinn macht. Lesetipp: Die wichtigsten Punkte zum Scrum-Inkrement findest du hier im Ma‐ gazin nochmals zusammengetragen: ► https: / / www.agile-heroes.de/ m agazine/ scrum-inkrement/ Was ist ein Commitment? Ein Commitment ist im übertragenen Sinne ein Handschlag, eine Vereinba‐ rung über die zu liefernden Artefakte, welche wir bereits kennengelernt haben. Es soll zum einen eine Hilfe sein, zum anderen aber auch eine Mo‐ tivation und eine objektive Unterstützung zur Überprüfung der Abnahme der jeweiligen Artefakte. Commitments unterstützen damit wiederum die in Scrum beschriebene Theorie des Empirismus, welche darauf aufbaut, dass alles transparent sein soll. 89 Aufbau und Funktionsweise von Scrum Und um zu überprüfen, ob die Artefakte stimmen, müssen diese transpa‐ rent dargelegt und anhand der Commitments durchgegangen werden. Die Commitments stellen demnach eine Technik bzw. ein Tool zur Verbesserung der Artefaktqualität dar. Was ist ein Product Goal? Ein Product Goal (Produktziel) beschreibt einen zukünftigen Zustand des Produkts, an welchem das Scrum-Team arbeitet. Das Produktziel dient dazu, als Ziel die Planung für das Scrum-Team zu verdeutlichen und zu vereinfachen. Es hilft aber auch dem Product Owner dabei, die richtige Priorisierung innerhalb des Product Backlogs zu finden, um möglichst schnell und effizient das Produktziel zu erreichen. Abb. 22 Das Produktziel wird als langfristiges Ziel beschrieben, kann sich jedoch im Laufe der Entwicklungszeit verändern. Die Verantwortung für das Produkt‐ ziel liegt beim Product Owner, er kann eine Produktzielveränderung anhand der neuen Interessen der Stakeholder vornehmen und darf das Scrum-Team, die Entwickler, darüber informieren. Die Definition eines Produktziels ist seit November 2020 im neuen Scrum Guide hinterlegt und entspricht, unserer Meinung nach, bereits gängiger Praxis. Es ist selbstverständlich, 90 Aufbau und Funktionsweise von Scrum dass man für sein Produkt, das man inkrementell weiterentwickeln möchte, eine langfristige Planung, ein langfristiges Ziel benötigt, um das Team zu motivieren. Das ist die Voraussetzung, um ein Commitment seitens des Teams für die Produktentwicklung zu schaffen. Aus diesem Grund ist das Produktziel das Commitment des Product Backlogs, anhand dessen bewertet werden kann. Welche Tools finden in Scrum Anwendung? Grundsätzlich sind die Tools in Scrum vor allem in Remote-Zeiten nochmals deutlich vielfältiger geworden. Davor gab es im Grunde nur Jira und Confluence, welche neben den gängigen Office-Tools genutzt wurden. Inzwischen werden neben einem guten Videokonferenztool vor allem Miro und Scrumpanion eingesetzt. Damit haben wir nun diese vier Tools zur Verfügung: - Jira - Confluence - Miro - Scrumpanion Was zeichnet das Scrum-Tool Jira aus? Bei Jira handelt es sich um ein Tool von der australischen Softwarefirma At‐ lassian. Seit seiner Gründung im Jahr 2002 hat das Unternehmen mittler‐ weile über 89.000 Kunden und dazu Niederlassungen in mehr als fünf Ländern. Die Produkte von Atlassian richten sich im Grunde alle an Teams und Projektmanager - so auch Jira. Seinen Namen hat das Tool dem japanischen Wort „Gojira“ zu verdan‐ ken, was sich grob mit „Godzilla“, also „Monster“ übersetzen lässt. Das ist tatsächlich eine sehr passende Übersetzung, denn Jira ist ein wahres „Softwaremonster“ mit vielen verschiedenen Funktionen und Facetten. Für Projektmanager ist das Tool auf jeden Fall eine große Unterstützung. Jira lässt sich in drei verschiedene Produkte bzw. Varianten unterteilen. Jedes dieser Produkte richtet sich an eine andere Ziel- und Aufgabengruppe: 91 Aufbau und Funktionsweise von Scrum - Jira Core - Jira Software - Jira Service Mithilfe von Jira Core lassen sich ganz einfach Projekte und Teams orga‐ nisieren, Abläufe darstellen und Aufgaben verteilen. Gleichzeitig behält man alle Vorgänge im Auge, da sie transparent für alle sichtbar sind. Hier findet sich also der große Vorteil von Jira Core: die Transparenz. Alle Beteiligten behalten den Überblick und können außerdem über die Kommentarfunktion miteinander kommunizieren. Während die Features und Vorteile von Jira Core sich bereits hervorra‐ gend für agiles Projektmanagement eignen, setzt Jira Software noch eins drauf: Neben den Grundfunktionen bietet Jira Software die Möglichkeit, individuelle Scrum-Boards oder auch Kanban-Boards zu erstellen. So können Jira-Software-Anwender ganz einfach Sprints erstellen, Back‐ logs pflegen und planen. Ursprünglich war Jira Software für die Softwa‐ reentwicklungsbranche angedacht, doch das Programm kann ohne Pro‐ bleme in allen Branchen genutzt werden. Die dritte Jira-Variante nennt sich Jira Service Desk. Diese Variante ist ein Service-Management-Tool, das mithilfe eines Ticketsystems Aufgaben in Form von „Tickets“ an die zuständigen Mitarbeiter weiterleitet. Zusammenfassend kann man sagen: Jira ist ein sehr umfangreiches Tool für: - Projektmanager, - Aufgabenverwaltung, - Dokumenation und - Service-Management. Es fördert die Flexibilität und Transparenz innerhalb von Unternehmen, Teams und Projekten. Zusätzlich lässt sich Jira mithilfe von zahlreichen Plugins anpassen und erweitern. Allerding ist Jira auch nicht ganz unkompliziert. Um die Software best‐ möglich zu verwenden, bedarf es oft einiges an Übung und Erfahrung. Viele Teams setzen deshalb auf ein Jira-Training, um die Einfindungsphase zu überspringen und sofort richtig mit Jira zu starten sowie die Vorteile der Software voll auszuschöpfen. 92 Aufbau und Funktionsweise von Scrum Videotipp: Mehr Infos zu Jira haben wir in diesem Video zusammengefasst ► https: / / youtu.be/ 487XyapqhDo Was bietet das Scrum-Tool Confluence? Confluence ist ein sogenanntes Enterprise-Wiki-Unternehmen und dient Teams als Plattform für den Wissensaustausch, für einfache Kommunikati‐ onswege, für Projektzusammenarbeit und zur Dokumentation. Genau wie Jira stammt Confluence aus der Feder der australischen Firma Atlassian und sammelt allein dadurch bereits Pluspunkte bei Jira-Liebhabern. Confluence kommt also aus der Schmiede von Atlassian und bezeichnet sich selbst als „zentrale Datenbank für Ihr Unternehmen“. Die Software vereint all die Bereiche, die für die Zusammenarbeit in Teams vor allem in Zeiten von Remote-Working und Homeoffice essenziell sind. Die klaren Strukturen und das einfache Design der Software verhelfen zu einem unkomplizierten Start und sollen die Handhabung auch technisch „unbegab‐ teren“ Mitarbeitern leicht machen. Das letzte Update des Tools, das erstmals 2014 erschienen ist, hat 2021 stattgefunden. Als „Unternehmens-Wiki“ dient Confluence in erster Linie als Wissens‐ datenbank. Vor allem in Bereichen mit häufigem Kundenkontakt ist es wichtig, dass alle Mitarbeiter auf einem Wissensstand sind und nicht unterschiedliche Informationen nach außen tragen. Für eine einfache Be‐ dienung und schnelle Orientierung verspricht Confluence simple Such- und Filtermöglichkeiten, um schnell und gezielt an Unternehmensinformationen zu gelangen. Diese Informationsseiten können von Usern erstellt und bearbeitet wer‐ den. Zusätzlich können sie andere Dokumentationen und Produktanforde‐ rungen selbst erstellen und anderen Teammitgliedern ganz einfach zur Verfügung stellen. Auch Vorlagen stellt Confluence seinen Nutzern zur Verfügung. Nicht zuletzt deswegen wird Confluence auch gerne als eine Art Cloud-Service bezeichnet. Hinzu kommt die Bearbeitungsmöglichkeit von Dokumenten: Mehrere Mitarbeiter können somit gleichzeitig an einem Projekt arbeiten und Seiten bearbeiten. Ein persönlicher Feed gibt jedem Mitarbeiter einen Überblick zu 93 Aufbau und Funktionsweise von Scrum seinem Arbeitsstand. In Chats können die Teams untereinander kommuni‐ zieren und sich zu Infos und anderen Neuigkeiten austauschen. Wie funktioniert Confluence und was sind die Vorteile dieser Anwendung? Teammitglieder können ihr persönliches Dashboard selbstständig gestalten. Sie sehen ihre und andere Aufgaben, erhalten Benachrichtigungen und Nachrichten. Das Dashboard lässt sich in fünf Bereiche aufteilen. Auf der linken Seite befinden sich die sogenannten Seiten der Plattform. Hier sehen die Nutzer alle Seiten, für die sie das Leserecht besitzen. Diese Seiten werden in die sogenannten Bereiche aufgeteilt, welche verschiedene Funktionen haben können. Bereiche werden einfach erstellt, bearbeitet und angepasst. Zugriff hat jeder, der dazu berechtigt ist. Teammitglieder können sich auch persönliche Bereiche für Notizen und anderes anlegen, auf die nur sie zugreifen dürfen. Mithilfe von Vorlagen und anderen Bearbeitungsmöglichkeiten lassen sich ganz einfach Projektpläne, Listen, Informationsseiten und vieles mehr erstellen und mit allen oder nur bestimmten Kollegen teilen. Zusätzlich lässt sich Atlassins Confluence sehr einfach mit anderen Tools und Apps wie Jira oder Trello verknüpfen: ein weiterer großer Vorteil für alle, die mit mehreren Tools abreiten. Confluence ist bereits fest in der Businesswelt verankert und wird von Firmen wie der Deutschen Bahn oder der Bundeswehr genutzt. Der größte Vorteil der Software ist Transparenz. Alle Mitglieder (mit Zugriffsrechten) können zeitgleich dieselben Arbeitsschritte sehen und nachverfolgen. Informationen stehen allen zu und können von allen Betei‐ ligten ganz einfach gefunden und auch nachvollzogen werden. Bei Confluence ist im Kern alles für alle sichtbar! Für viele bedeutet das womöglich erst eine Umgewöhnung (Aber keine Angst, mit Zugriffsrechten lässt sich nach wie vor kontrollieren, wer was sehen darf). Speziell unter Flächen wie „All Updates“ erfährt man theoretisch von al‐ lem, was im Unternehmen so vor sich geht. Der Wissenstransfer, der dadurch geschaffen wird, ermöglicht es allen Mitarbeitern, auf einem Stand zu sein und vor allem auch dieselben Informationen nach außen weiterzugeben. 94 Aufbau und Funktionsweise von Scrum Grundsätzlich schafft es Confluence, alle wichtigen Bereiche, die für eine reibungslose Zusammenarbeit notwendig sind, an einem Platz zu bündeln. Anstatt viele unterschiedliche Programme und Tools für einzelne Funktionen zu verwenden, können Teams das nun alles an einem Ort tun. Vor allem remote arbeitende Unternehmen haben dadurch trotzdem eine Art shared workspace, an dem sie sich und alle Informationen sammeln. Für wen eignet sich Confluence am besten? Confluence bietet einfaches und transparentes Arbeiten für (große) Teams - Teams, die sich ein Büro teilen, aber vor allem auch für die, die sich haupt‐ sächlich remote koordinieren müssen. Denn gerade diese Teams müssen neue Wege finden, Informationen auszutauschen, zu kommunizieren und zusammen an einem Projekt zu arbeiten. Confluence ermöglicht ein sehr hohes Maß an Transparenz. Gerade das erleichtert vielen Anwendern die Arbeit; schreckt aber auch manche anderen ab. Besonders für Kollegen mit viel Kundenkontakt ist das Tool besonders hilfreich: In kurzer Zeit finden sie Informationen, und zwar in der Form, wie sie das gesamte Team auch vor sich hat. Grundsätzlich eignet sich Confluence für alle, die gerne alles an einem Ort hat. Atlassian kann außerdem noch mit vielen anderen Tools punkten, die sich selbstverständlich gut mit Confluence verknüpfen lassen. Digital arbeitende Teams, die den Überblick behalten möchten, sollten sich Confluence auf jeden Fall einmal näher ansehen. Zusammenfassend kann man sagen: Seit vielen Jahren bewährt sich Atlassians Confluence bereits am Markt und konnte viele große Kunden für sich gewinnen. Auch die Umstände spielen Confluence in die Karten: Immer mehr Teams finden sich im Homeoffice wieder. Dort sorgt das Enterprise-Wiki für Organisation, Kommunikation und insbesondere Wis‐ sensaustausch. Ganz im Sinne der Agilität ist genau das wichtig, um sein Unternehmen voranzubringen. Obwohl es bereits zahlreiche andere Tools gibt, die Ähnliches verspre‐ chen, kann Confluence damit überzeugen, dass es einen Großteil deines Arbeitsplatzes (in vielen Fällen wohl sogar deinen gesamten Arbeitsplatz) an einen Ort zusammenbringt und du deine Arbeit von dort auch noch mit all deinen Kollegen teilen kannst. Für uns definitiv einen Versuch wert! 95 Aufbau und Funktionsweise von Scrum Videotipp: Mehr Infos zu Confluence sind in diesem Video zusammengefasst: ► https: / / youtu.be/ iK5zW_vacGk Welche Vorteile bietet das Scrum-Tool Miro? Digitale Tools entwickeln sich immer mehr zu den Stars des Alltags und ersetzen bereits erfolgreich zahlreiche analoge Helferlein. So auch „Miro“: das digitale Whiteboard. Was macht es besser als das klassische Whiteboard? Es bietet dir unendlich viel Platz. Die Software Miro ermöglicht es, viele Menschen auf einem „digitalen Whiteboard“ zu vereinen, obwohl sie alle an unterschiedlichen Orten vor ihrem Computer sitzen. Mit zahlreichen Gestaltungsmöglichkeiten lässt sich Miro zum Präsentieren von Informationen, aber auch zum Zusammenarbei‐ ten und beispielsweise Erstellen von Mindmaps nutzen. Hier gibt es nicht nur die beliebten Haftnotizen, die wir auch in der „echten Welt“ lieben, sondern auch viele Textoptionen, Pfeile, Emojis und alles, was das Herz begehrt, um Gedanken zu visualisieren. Durch das einfach Teilen eines sogenannten Miro-Boards haben alle Teammitglieder und auch Externe die Option, auf das Board zuzugreifen und zeitgleich daran zu arbeiten. Das Tool wird hauptsächlich im Businessbereich verwendet und bietet seinen Nutzern eine Vielzahl an Möglichkeiten, um übersichtliche, kreative und komplexe Mindmaps, Grafiken und andere visuelle Pläne zu gestalten. Im Prinzip ist Miro eine endlos große weiße Fläche, die man zur visuellen Gestaltung verschiedener Projekte nutzt. Das Tool beinhaltet zahlreiche Möglichkeiten, um seine Gedanken bestmöglich darzustellen. Textflächen, Post-its, Pfeile, Zeichnungen und Kommentare zählen dabei zu den wichtigsten und beliebtesten Werkzeugen. Daneben gibt es viele Vorlagen, die man für Workshops, Mindmaps, Sprint-Retrospektiven etc. nutzen kann. Dabei wird klar: Miro ist ein praktisches Hilfsmittel für agiles Arbeiten. Durch die vielen Funktionen lässt sich mit etwas Geschick alles visuell darstellen. 96 Aufbau und Funktionsweise von Scrum Auf dem Dashboard können Nutzer auf ihre eigenen und auf die Boards, die mit ihnen geteilt wurden, zugreifen. Dabei ist die Anzahl der Boards und die Zugriffmöglichkeiten von der Art des Accounts abhängig. Mit Miro können Teams und Einzelpersonen (mit etwas Übung) all ihre Gedanken, Pläne, Ziele, Rückblicke festhalten und gemeinsam daran arbeiten. Grenzen gibt es kaum auf dem digitalen Whiteboard: Es bietet unzählige Möglichkeiten, um anderen etwas zu präsentieren oder einer Gruppe von Personen einen Raum für das gemeinsame Brainstorming zur Verfügung zu stellen. Egal ob es die Mindmap, das Kanban-Board, der Stammbaum oder der Design-Thinking-Workshop ist, mit den hilfreichen - und vor allem agilen - Vorlagen kannst du alles gliedern, miteinander verbinden, Notizen anbrin‐ gen und im Team daran arbeiten. Miro ist Übungssache: Um wirklich gut damit umzugehen und die einzel‐ nen Gestaltungswerkzeuge zu beherrschen, erfordert das Tool ein wenig Übung und Geschick. Vor allem wenn gleich mehrere Personen in einem Board arbeiten, sorgt das oft für verwirrte Gesichter. Ist eine Textblase oder ein anderes Element nicht an seinem Platz fixiert, kann es schnell einmal passieren, dass das Objekt versehentlich wegen eines Scrollversuchs verschoben wird. Für wen eignet sich Miro? Miro ist das digitale Whiteboard für Teams, die nicht mehr zusammen in einem Büro sitzen und sich regelmäßig im Besprechungsraum treffen können. Denn der große Vorteil von Miro ist der Remote-Faktor. Die Mög‐ lichkeit, in Gruppen zusammenzuarbeiten und das über Distanz hinweg, ist heutzutage in den meisten Teams gefragt. Bereits die simple Funktion der Haftnotizen ermöglicht es einem Team, ganz einfach und gleichzeitig Ideen und zusammenzutragen, über die alle Beteiligten sofort einen Überblick gewinnen. Miro ist also gut für alle Whiteboard-Fans, die aber das Ohr am Puls der Zeit haben möchten, sowie all diejenigen, die aufgrund von remote work ihre Teammitglieder nicht mehr neben sich haben. Auf unterhaltsame und praktische Weise bleibt so das Whiteboard auch digital erhalten. Und ein weiterer großer Vorteil: nie wieder fünf verschiedene, ausgetrocknete Eddings ausprobieren, bis man einen funktionierenden findet! 97 Aufbau und Funktionsweise von Scrum Wir empfehlen das Tool vor allem agilen Teams. Hier kommt es beispiels‐ weise bei einer Sprint-Retrospektive zum Einsatz. Gerade hier werden oft Übungen gemacht, für die Post-its und Whiteboards verwendet werden. Eine solche Retrospektive remote abzuhalten, ist für viele Teams eine Herausforderung. Doch mithilfe von Videocalls, einem vorbereiteten Scrum Master und dem Miro-Board lässt sich das Event kurzerhand auch in die digitale Welt verlegen. Videotipp: Mehr Infos zu Miro findest du in diesem Video: ► https: / / youtu.be/ fqkAkV5eI58 Welche Vorteile bietet das Scrum-Tool Scrumpanion? Ein sehr hilfreiches und unserer Meinung nach immer bekannter werdendes Scrum-Tool möchten wir euch im Folgenden kurz vorstellen: die App Scrumpanion. Hierbei handelt es sich um eine schlanke und intuitiv zu bedienende Applikation, die wir vor allem für das Schätzen von User Stories in den Refinement-Meetings gerne nutzen. Das Tool kann sowohl über eine App für mobile Endgeräte als auch über eine Browserversion genutzt werden. Auf beiden Plattformen sind alle Funktionen erreichbar. Hierfür stehen neben der klassischen und der für Scrum so typischen, abgewandelten Fibonacci-Reihe auch ein CardSet mit T-Shirt-Sizes zur Wahl. Auch in der Retrospektive leistet Scrumpanion gute Dienste, da ein CardSet für die Abfrage des Happiness Index zur Verfügung steht. Des Weiteren gibt es noch ein CardSet mit Delegation-Poker-Karten. Weitere ergänzende Features, wie z. B. eine Jira-Integration, sollen bei einer großen Reichweite der Applikation in Zukunft noch dazukommen. Der entscheidende Aspekt für uns persönlich ist die Tatsache, dass wir hier kein Milliardenunternehmen wie die Hersteller von Jira vorzuzeigen haben, sondern ein hervorragendes deutsches Start-up. Scrumpanion wurde von einer kleinen Softwareentwicklungsfirma (www.beskgroup.com) in Süddeutschland entwickelt, und das sozusagen aus einer eigenen Not heraus. Da die Entwickler der Firma auf verschiedenen Kontinenten verteilt arbeiten, gestaltete sich das Schätzen in den Refine‐ ment-Meeetings immer ein wenig kompliziert über Chatprogramme und 98 Aufbau und Funktionsweise von Scrum mit Herunterzählen, so dass alle Teammitglieder gleichzeitig ihre Schätzung übermitteln. Wer schon remote Refinement-Meetings durchgeführt hat, weiß wovon wir sprechen. Also hat diese scrum-begeisterte Firma angefan‐ gen, ein Tool für sich zu entwickeln, um genau dieses Problem zu lösen. Für alle remote arbeitenden Teams ein absolutes Must-have, doch wir nutzen die App auch gerne, wenn wir alle in einem Raum zusammensitzen, so entfällt die langwierige Suche nach den Planning-Poker-Karten, da alle Teammitglieder sie jederzeit bei sich haben. Falls du neugierig auf das Tool geworden bist, kannst du mit dem unten‐ stehenden Link Scrumpanion ProPlus für vier Monate kostenfrei testen. Einfach den QR-Code scannen und deinen Code aktivieren: 99 Aufbau und Funktionsweise von Scrum Die Praxisumsetzung von Scrum In diesem Kapitel erfährst du, welche Aspekte bei der Umsetzung von Scrum in die Praxis relevant sind und wo Grenzen liegen können. Ist Scrum für mein Projekt geeignet? Generell gilt: Nutzt man Scrum, so müssen alle Bestandteile von Scrum umgesetzt werden, da es sich nach dem offiziellen Scrum Guide im Falle einer Ausnahme nicht mehr um Scrum handelt. Ist man eine Art Scrum-Militant, so ist diese Regel sicher richtig. In der Praxis arbeiten wir in unseren Teams jedoch nicht ‚militant‘, son‐ dern ganz im Gegenteil: ‚agil-liberal‘. Daher lautet auch unser größter Kritikpunkt am Scrum-Konzept: Scrum ist unseres Erachtens zu radikal, damit auch etwas widersprüchlich. Was meinen wir damit? Man liest im Scrum-Guide häufig: Selbstmanagement für das Team erhöht die Produktivität und lässt Teams motivierter arbeiten. Aber stößt nicht genau dieses Team im Rahmen ihres Selbstmanagements an den Punkt, wo es zu sagen pflegen würde: „Lass uns an dieser Stelle von Scrum abweichen, um den Produkterfolg zu maximieren! “ An dieser Stelle würde jedoch die Leitlinie des Scrum Guide greifen und es verbieten. Das hat etwas von orthodoxer Religion, ja fast möchte man sagen, von Sektentum. Wir distanzieren uns ganz klar von diesen Vorgaben in der Praxis. Im Team der Agile Heroes erklären wir in jedem Pitch, dass wir alles für ein erfolgreiches Projekt tun. Und obwohl wir „Agile“ im Unternehmensna‐ men tragen, sind wir es, die sagen: „Agilität nach Augenmaß - so viel wie möglich, so gering wie nötig, um einen hohen Produkt-, Unternehmens- oder Projekterfolg zu garantieren.“ 102 Die Praxisumsetzung von Scrum Abb. 23 Damit erhalten wir oft auf der Theorieebene von aggressiven „Agilisten“ viel Kritik, aber von Praktikern, von unseren Kunden viel Lob. Nicht jede Organisation, nicht jedes Projekt oder Produkt ist nun mal zu 100 % für Scrum bzw. zur 100 % für Agilität geeignet. Hat man das verinnerlicht, so kann man mit viel weniger Druck gute Ergebnisse erzielen. Wie findet man heraus, ob Scrum sich für mich persönlich eignet? Die folgenden Punkte können hierfür als Kriterien hilfreich sein: 1. Ist das zu entwickelnde Produkt neu? Hintergrund dieses Kriteriums Frage ist einfach: Wenn du ein Haus mit deinem Projekt-Team schon das 19. Mal baust, ist der genaue Ablauf bekannt. Dann inkrementelle Feedback-Zyklen nicht notwendig. Baust du hingegen eine nie dagewe‐ sene App, hast du noch keine genaue Vorstellung, ob die Funktion, die du erschaffst, am Markt angenommen wird. Die Einschätzung beruht lediglich auf Annahmen. Daher eignet sich hier ein Vorgehen nach Scrum. 2. Kann dein Produkt auch „halbfertig“ oder in „kleiner Ausführung“ am Markt überleben? Zunächst steht die Akzeptanz, dass du gegebenenfalls 103 Wie findet man heraus, ob Scrum sich für mich persönlich eignet? ein unfertiges Produkt auf den Markt gelangt. Oft verfallen Ideengeber oder Verantwortliche in falsche Nostalgie und sterben dann gemeinsam mit ihrer Idee in Schönheit. Der Gedanke von Scrum ist oft auch ein MVP-Gedanke (Minimal Viable Product) und das sollte auch jedes Produkt hergeben. 3. Bist du in einem veränderungswilligen Umfeld? Das umfasst dein Team, deine Geschäftsleitung, deine Kunden. Können alle damit leben, dass sich Produkt, Abläufe und Team verändern müssen? Oder wird es Widerstände geben? Davon hängt auch ab, welche Energie man aufbringen muss, Scrum in einer Organisation einzuführen. Es gibt einen Punkt, ab dem sich deine Energieleistung nicht lohnt und du lieber deinen Drang nach New Work, besserem Arbeiten und erfolgreicheren Produkten in einem anderen Umfeld einsetzen solltest. Scrum benötigt unbedingt ein innovationsfreudiges Umfeld. 4. Wünschen sich die Mitarbeiter mehr Selbstorganisation? Es ist der Schrei der Zeit, dass Menschen mehr Verantwortung, Selbstwirkung und Selbstorganisation erfahren wollen. Auch im „War of Talents“ gewinnt dieser Aspekt immer mehr an Bedeutung. Wenn du ein Team hast, das genau das möchte, kann Scrum auch ein wundervoller „Nach‐ brenner“ sein um deiner Team-Entwicklung zu helfen. Außerdem hilft diese Proaktivität im Team, dass Scrum erfolgreicher funktionieren kann. Was ist ein Sprint Goal? Das Sprint Goal bzw. das Sprint-Ziel ist, und das mag vielleicht überraschend klingen, das einzige Ziel für den Sprint, obwohl das Sprint-Ziel dadurch ein Commitment, eine Verpflichtung der Entwickler auf die Erreichung der Sprint-Ergebnisse bietet, kann es flexibel, hinsichtlich der Umsetzung, betrachtet werden. 104 Die Praxisumsetzung von Scrum Abb. 24 Das Sprint-Ziel gliedert dabei das Wie aus. Es wird während des Sprint Plannings erstellt und wird dann dem Sprint Backlog hinzugefügt, zum Beispiel als Überschrift. Während des Sprints ist das Sprint-Ziel die Motivation für das Team, ihr Sprint Backlog umzusetzen, und auch gleichzeitig ihr Kompass, wenn es um die Frage geht: Machen wir hier gerade das Richtige, kommen wir so unserem Ziel näher oder nicht? Bemerkst du innerhalb des Sprints, dass sich deine Arbeit doch in eine andere Richtung entwickelt, hast du die Möglichkeit, mit dem Product Owner den Umfang des definierten Sprint Backlogs so zu verhandeln, dass es das Sprint-Ziel nicht gefährdet. Hiermit sind meistens optionale Sprint-To-dos gemeint, die man eventuell, ohne das Sprint-Ziel zu gefährden, aus dem Sprint Backlog herausnehmen kann und für den nächsten Sprint einplanen könnte. Das Sprint-Ziel hat außerdem eine entscheidende Bedeutung, wenn es darum geht, den Sprint anzubrechen, nämlich dann, wenn das Sprint-Ziel obsolet wurde. Wenn das Sprint-Ziel obsolet ist, hat der Product Owner das Recht, den Sprint abzubrechen. 105 Die Praxisumsetzung von Scrum Was ist eine Definition of Done? Eine Definition of Done ist im Grunde ein Commitment hinsichtlich des Inkrements. Folgt man der Logik des Scrum Guide, könnte man die Definition of Done auch als Inkrementziel beschreiben. Abb. 25 Generell gilt, ein Task, ein Inkrement ist immer nur dann fertig, wenn es der Definition of Done entspricht. Definition of Done ist die formelle Beschreibung des Zustands des Inkrements und beinhaltet formelle Quali‐ tätskriterien, welche erfüllt werden müssen. Beispiele könnten hierbei sein, 106 Die Praxisumsetzung von Scrum dass ein Inkrement vorher drei Mal von verschiedenen Personen getestet wurde. Dies ist eine sehr einfache und plastische Definition of Done. In der Praxis existieren mindestens 10 bis 15 Kriterien, die erfüllt sein müssen, bevor ein Inkrement als erledigt, als fertiggestellt gilt. Gemäß der strengen Definition im Scrum Guide kann ein Inkrement nur dann im Sprint Review präsentiert werden, wenn es der Definition of Done entspricht. Wenn ein Product-Backlog-Item nicht der Definition of Done entspricht, muss es zurück zum Product Backlog und in zukünftigen Sprints berücksichtigt werden. Häufig gestaltet es sich so, dass es innerhalb der Organisation bereits Standardqualitätsanforderungen gibt, an die sich das Scrum-Team als Min‐ destanforderung halten muss. Es kann aber zudem weitere, eigene Standards einführen, um ihre Definition of Done zu erweitern. Aber in einer Organi‐ sation, in welcher eine Definition of Done besteht, muss sich in jedem Fall an diese vorgegebene Definition of Done gehalten werden. Schließlich kommt es auch vor, dass mehrere Scrum-Teams gemeinsam an einem Produkt arbeiten. Diese müssen gemeinsam die gleiche Definition of Done definieren und einhalten. Was ist eine Definition of Ready? Die Definition of Ready findet sich nicht im Scrum Guide, ist jedoch in der Praxis absolut gängig und schlüssig. Die Definition of Ready beschreibt, wann ein Product-Backlog-Item ready to sprint ist. 107 Die Praxisumsetzung von Scrum Abb. 26 Sie signalisiert, wann ein Product-Backlog-Item so gut beschrieben ist, dass es die Entwickler verstehen und im Sprint umsetzen können. Ähnlich wie die Definition of Done beschreibt, wann ein Product-Backlog-Item oder ein Inkrement fertig ist, beschreibt die Definition of Ready, wann es bereit zur Umsetzung ist. Auch über die Definition of Done kann die inhaltliche Darstellung der Definition of Ready vollkommen unterschiedlich sein und ist so - wie immer - nicht einheitlich geregelt. Aber meist enthält sie Punkte wie: ▶ Wer ist der Ersteller? ▶ Wie hoch ist die Schätzung dafür? ▶ Ist die Story beschrieben? ▶ Gibt es Abhängigkeiten zu anderen Teams? ▶ Gibt es vielleicht Dokumentationshilfen zu diesem Thema? Solche Fragen werden in der Definition of Ready bearbeitet und müssen in einem Product-Backlog-Item beschrieben werden, damit dieses bereit zur Sprintumsetzung ist. 108 Die Praxisumsetzung von Scrum Hat Scrum Grenzen in der Praxis? Ja. Natürlich. Alles hat Grenzen. Ein perfektes Fit auf alles kann es aufgrund der in Projekten vorherrschenden Komplexität gar nicht gehen. Diese Grenzen müssen auch seitens des Agilitätsbeauftragten, des Scrum Masters, der Agile Coaches oder der Berater stets aufgezeigt werden. Abb. 27 Gibt es dafür ein Beispiel? Ja - nehmen wir einmal den Bereich der Stadtplanung: Wir wollen eine neue Reihenhaussiedlung bauen. Wir haben diese Siedlung bereits in fünf anderen Städten gebaut. Die Baupläne sagen genau, wann wo was gebaut werden muss. Man kennt demnach die genaue Zeitplanung, die erwartete Qualität und auch die Kosten. Das Endprodukt ist schon - im wahrsten Sinne des Wortes - in Stein gemeißelt. Welche Vorteile für das Produkte hätte man also, nach Sprint-Rhythmen zu arbeiten, Feedback vom Kunden 109 Die Praxisumsetzung von Scrum einzuholen und alle zwei Wochen zu planen, obwohl man ja schon weiß, was als nächstes kommt? Richtig. Der Vorteil wäre nahe Null. Aus diesem Grund ist hier ein klas‐ sisches, durchplanerisches Vorgehen absolut zu empfehlen. Natürlich kann man hier die anderen Gesichtspunkte von Scrum, wie das Selbstmanagement des Teams oder die Transparenz, anwenden. Im Grunde aber sollte das klassische Vorgehen hier als State of the Art gesehen werden. Wann funktioniert Scrum in der Praxis? Scrum funktioniert immer dann sehr gut, wenn Unklarheit vorherrscht, Unklarheit, über das eigentliche Endprodukt. Ist das Produktthema scrumfähig, fehlt lediglich noch die Bereitschaft der Organisation, Scrum zu nutzen. Hier sind weitaus mehr und deutlich komplexere Voraussetzungen notwendig, um mit Scrum zu arbeiten. Bleiben wir zunächst auf der Produktseite. Damit Scrum in der Produkt‐ entwicklung den vollen Umfang an Mehrwert liefern kann, sollte eine große Unsicherheit hinsichtlich der vom Kunden gewollten Anforde‐ rungen vorliegen. Jetzt könnte man sehr einfach fragen: „Wieso holen wir uns die Anforderung nicht einfach? Wieso fragen wir nicht einfach den Kunden? “ Und das ist genau richtig, wenngleich etwas simplifiziert gesagt. Zur Veranschaulichung dient folgendes Beispiel: Wir möchten eine App zur Erkennung von gefährlichen Muttermalen entwickeln. Grundsätzlich haben wir die Vision, dass ein fotografiertes Muttermal auf unserem Smartphone gescannt und durch künstliche Intelligenz bewertet wird. Ob es gefährlich ist oder nicht, soll uns damit binnen Sekunden mitgeteilt werden. Jetzt könnten wir dazu 1.000 Menschen befragen, welche nützlichen Features und Funktionen sie als potenzielle Nutzer dafür erwarten würden. Wir hätten so vielleicht 1.000 neue Anforderungen. Wir könnten aber auch alternativ ein einfaches MVP entwickeln. Dies könnte innerhalb von zwei Tagen ohne Programmierkenntnisse erfol‐ gen. Unter einem MVP versteht man ein minimal variables Produkt, 110 Die Praxisumsetzung von Scrum das nur die Kernfunktionalität beinhaltet und so als Produkt-Start-In‐ krement bei einem neuen Produktlaunch gilt. Gesagt, getan: Dieses MVP wurde von uns in einem Meetup präsentiert: Jeder konnte sein Muttermal scannen lassen. Das Feedback dieser Menschen war ungleich mehr wert als die Ergebnisse einer 1.000-fachen Befragung. Warum? Weil sie es getestet und erlebt haben. Ein MVP sagt mehr als 1.000 Worte, könnte man hier festhalten. Für eine Weiterentwicklung dieser Beispiel-App wäre Scrum die richtige Methode gewesen. Man hätte so alle zwei bis vier Wochen ein neues Inkrement an die Kunden ausliefern können. Und jedes Mal wäre ein neues Feedback gekommen. Jetzt liegt euch vielleicht noch brennend auf der Seele, wie man dieses MVP, ohne Softwareentwicklungserfahrung innerhalb von zwei Tagen entwickeln konnte. Die Antwort ist sehr einfach: „Fake it until you make it! “ Die dargestellte App war natürlich keine App und hatte auch keine big-data-basierte Künstliche Intelligenz, die in Sekunden Millionen Muttermale in ihrer Datenbank untersucht und abgleicht. Die App war eine einfache Website, zusammengebastelt auf Basis von Wix.com. Dort konnte man dann in einem Chat, den wir für den Anfang noch selbst bedient hatten, ein Foto hochladen. Dieses Foto wäre dann nicht von der KI, sondern von einem Hautarzt untersucht worden. Mit diesem einfachen Hack hätte man tausende User über Nacht über Onlinewerbung auf das Produkt kommen lassen können. Sie hätten die App benutzt und hätten auch valide Auskunft erhalten. Und als Kuppelprodukt hätte man ausreichend Feedback für die App erhalten. Aber alles eben mit manuellem Aufwand. Warum? Weil es sonst anfallende hohe Kosten für eine MPV-Fähigkeit innerhalb von zwei Tagen eingespart hätte. 111 Die Praxisumsetzung von Scrum Lesetipp: Zu den acht Gründen für den Erfolg von Scrum geht es hier: ► https: / / www.agile-heroes.de/ magazine/ erfolg-von-scrum/ Wie kommt man an die richtigen Mitarbeiter für Scrum-Projekte? Möchte man jetzt in seinem Unternehmen Scrum einsetzen und hat die Produkttauglichkeit bereits bewiesen, fehlt tatsächlich nur noch das Team. Hier kommen die typischen Change-Management-Methoden zum Tragen, um ein Team zu neuen Methoden zu bewegen. Der typische Weg wäre, sich eine Change-Community zu suchen, also Menschen, die offen für neue Wege sind. Diese Community müsste dann das Mittelfeld, also die Menschen, die sowohl Blockierer als auch Community werden könnten, überzeugen. Hat man das geschafft, funktioniert es, Scrum in der Praxis anzuwenden. Es wird zwar immer das restliche Feld der Blockierer geben, die keine Lust darauf haben. Wichtig ist jedoch, diese Blockierer nicht in Managementpositionen sitzen zu haben. Hier gilt es mit viel Empathie, Ängste, formuliert in Gedanken wie „Ich verliere meine Macht, meine Position, mein Job“ abzubauen, anfängliche Blockierer mit den neuen Rollen vertraut zu machen und sie mit in die Community zu holen. Dieses Thema ist jedoch so groß und umfangreich, dass es ein eigenes Buch verdient hätte, daher wurde es an dieser Stelle nur umrissen. Hier noch ein Tipp: Wenn du richtig gute Scrum Master suchst, dann kannst du auch einen externen Scrum Master anfragen. Unsere Organisation (Agile Heroes) bietet dies beispielsweise an; sofort verfügbar und hoch qualifiziert: https: / / www.agile-heroes.de/ scrum-master/ 112 Die Praxisumsetzung von Scrum Anerkennung des Scrum-Know-hows In diesem Kapitel erfährst du, wie Scrum-Kenntnisse er‐ worben werden können und welche Akzeptanz sie in der Praxis finden. Gibt es vergleichbare Aus- und Weiterbildungen? Grundsätzlich ist der Markt der Scrum-Zertifizierungen anders zu bewerten als der Markt von PRINCE2-Zertifizierungen. Hintergrund dafür ist, dass PRINCE2 als Begriff und Methode rechtlich geschützt ist. Scrum hinge‐ gen als Begrifflichkeit und als Methode nicht. Daher ist der Markt der Scrum-Zertifizierungen deutlich diversifizierter. Dennoch haben sich über die Jahre drei relevante Zertifizierungsinstitute herauskristallisiert. Welche Zertifizierungsinstitute gibt es für Scrum? Die Empfehlungen belaufen sich klar auf die folgenden Institute: ▶ Scrum.org ▶ IFAAI ▶ Scrum Alliance Scrum.org: Hierbei handelt es sich um das Zertifizierungsinstitut von einem der Scrum-Gründer, Ken Schwaber. Es genießt dadurch ein hohes Vertrauen in der Welt der Agilität. Die Prüfungen sind sehr anspruchsvoll und bieten das Potenzial zum Durchfallen, ohne ausreichende Vorbereitung. Bei Agile Heroes haben wir uns dazu entschieden, mit unseren Scrum-Trainings und Onlinekursen auf die Prüfungen der Scrum.org vorzubereiten. IFAAI: Das Institute for Agility & Innovation hat sich als Metainstitut für Agile Methoden zu einem Generalisten unter den Zertifizierungsinstituten entwi‐ ckelt. Hier findet man neben der Scrum-Zertifizierung auch Zertifizierungen für Design Thinking, OKR, Agile Coach oder Kanban. Das IFAAI bietet durch die Playbook-Download-Funktion eine gute Möglichkeit, sich selbstständig auf die Prüfungen vorzubereiten und mit geringerem Aufwand eine hoch‐ wertige Zertifizierung zu erlangen. 114 Anerkennung des Scrum-Know-hows Scrum Alliance: Die Scrum Alliance hat sich als Netzwerk von Scrum-Experten über die Jahre zu einem ernst zu nehmenden Zertifizierungsinstitut entwickelt. Zu beach‐ ten ist jedoch, dass man zum einen einen offiziellen Scrum-Alliance-Kurs besuchen muss, um die Prüfung ablegen zu dürfen. Und zum anderen kann man die Prüfung so oft wiederholen, bis man besteht. Das klingt auf den ersten Blick vorteilhaft, mittelfristig birgt es jedoch das Risiko, dass die Zertifikate am Markt anders interpretiert werden könnten. Welche Zertifizierungen gibt es? Genauso heterogen wie die Anbieter sind auch die Zertifikate an sich. Orientiert man sich jedoch an den drei erwähnten Instituten, sind im Grunde zwei Zertifizierungen wichtig - auch wenn diese immer unterschiedlich genannt werden. Diese sind für die Rolle des Scrum Masters und die Rolle des Product Owners relevant. Im Folgen findest du die Namen der Zertifizierungen nach Instituten gegliedert: Scrum.org: Scrum Master: • Professional Scrum Master Level 1 (PSM1): das Einstiegslevel, für Neulinge • Professional Scrum Master Level 2 (PSM2): das Fortgeschrittenenle‐ vel für Scrum Master mit Erfahrung • Professional Scrum Master Level 3 (PSM3): das Level für Scrum-Ex‐ perten Product Owner • Professional Scrum Product Owner Level 1 (PSPO1): das Level für Product-Owner-Neulinge • Professional Scrum Product Owner Level 2 (PSPO2): das Level für erfahrene Product Owner • Professional Scrum Product Owner Level 3 (PSPO3): das Level für echte Product-Owner-Profis 115 Anerkennung des Scrum-Know-hows IFAAI: Scrum Master • Accredited Scrum Master Level 1 (ASM1): das Einstiegslevel für Scrum Master • Accredited Scrum Master Level 1 (ASM2): die Prüfung für erfahrene Scrum Master Product Owner • Accredited Product Owner Level 1 (ASPO1): das Einstiegslevel für Product Owner • Accredited Product Owner Level 2 (ASPO2): die Prüfung für erfah‐ rene Product Owner Scrum Alliance: Scrum Master • Certified Scrum Master: das Einstiegslevel • Advanced Certified Scrum Master: das Fortgeschrittenenlevel • Certified Scrum Professional - ScrumMaster: das Profi-Level Product Owner • Certified Scrum Product Owner: das Einstiegslevel • Advanced Scrum Product Owner: das Fortgeschrittenenlevel • Certified Scrum Professional - Product Owner: das Profi-Level Wie kann ich mich auf die Zertifizierung vorbereiten? Auf diese Frage gibt es zwei Antworten. Diese unterscheiden sich hin‐ sichtlich des zeitlichen und monetären Aufwands und des inhaltlichen Umfangs: ▶ Mit diesem Buch und der folgenden Musterprüfung: Grundsätzlich reicht dieses Buch aus, um mit der folgenden Mus‐ terprüfung die Fragen des IFAAI richtig zu beantworten und auf diesem Weg die Prüfung und Zertifizierung zu bestehen. Des Weiteren findest du bei IFAAI.org auch Prüfungssimulationen zur 116 Anerkennung des Scrum-Know-hows Scrum-Prüfung, die du so oft, wie du magst, wiederholen kannst, um dein Scrum-Know-how vor einer kostenpflichtigen Prüfung gratis zu testen. ▶ Mit einem Training bei den Agile Heroes: Bei Agile Heroes haben wir uns auf Beratung und Trainings im Bereich von Agilität spezialisiert. Natürlich kannst du auch den Weg mit einer richtigen Schulung gehen, um die Scrum-Zertifizie‐ rung zu erhalten. Dieser Weg kostet mehr, hat aber entsprechend inhaltlich auch einiges mehr zu bieten, vor allem durch den aktiven Austausch mit dem Trainer. Habe ich als Leser dieses Buches einen Vorteil? Trainingsrabatt bei Agile Heroes: Mit dem Rabattgutschein „fragdochein‐ fach“ erhält man 10 % Rabatt auf die Scrum-Weiterbildungen bei Agile Heroes. Gehe hierzu einfach auf ► www.agile-heroes.de/ Scrum oder scanne den folgenden QR-Code: Zertifizierungsrabatt beim IFAAI: Mit dem Gutscheincode „fragdochein‐ fach“ erhält man als Leser dieses Buches einen Rabattgutschein in Höhe von 10 %. Gehe hierzu einfach auf ► www.ifaai.org/ Scrum oder scanne den folgen‐ den QR-Code: 117 Anerkennung des Scrum-Know-hows Videotipp: Der Videokanal des Unternehmens Agile Heroes vermittelt einen guten Eindruck zum Weiterbildungsumfeld dort: ► www.youtube.com/ c/ AgileHeroes/ videos Welche Fragen kommen in einer Scrum-Musterprüfung auf mich zu? Die Scrum-Master-Musterfragen sind im gleichen Format wie beim IFAAI gestellt. Hierbei ist immer nur eine Antwort richtig. Die Lösungen findest du in Kapitel 6. [1] SCRUM is a method of … A. agile project management. B. classical project management. C. hybrid project management. D. waterfall Project Management. [2] Agile project management is characterized by: A. comprehensive project planning. B. short and regular development cycles. C. regular status reports in the form of slides. 118 Anerkennung des Scrum-Know-hows D. focus on hierarchy and control. [3] According to the fathers of SCRUM… A. SCRUM can be supplemented by other methods. B. SCRUM can be mixed with classical methods. C. SCRUM can only be used in its pure form. D. SCRUM can only be used in modular form. [4] SCRUM is … A. one of the leading methods of agile project management. B. the only successful method of project management from today’s point of view. C. to give preference to any other form of project management. D. not the only successful method of project management. [5] SCRUM is … A. used in more than 90 % of all agile projects worldwide. B. so far only spread in North America. C. a further development of Kanban. D. necessary to structure and plan projects in phases. [6] A SCRUM team characterizes … A. that everyone has a certain role on the team. B. Competence Center. C. None of the possible answers is correct. D. Self-Management. [7] The fathers of SCRUM are A. Ken and Jeff Schwaber. B. Jeff Schwaber and Ken Sutherland. C. both Japanese. D. Jeff Sutherland and Ken Schwaber. [8] SCRUM stands for a game formation in which… 119 Anerkennung des Scrum-Know-hows A. the players in rugby form a double spiral. B. the players in rugby come close together. C. the coach gives instructions to the players. D. the captain instructs the players. [9] SCRUM emerged as a … A. Framework for software development projects. B. Tool to test software. C. Framework for Frameworks. D. Framework to optimize processes. [10] The SCRUM framework consists of: A. only principles and rules. B. tools and tools only. C. Values, Principles and Rules. D. None of the possible answers is correct. [11] The theoretical basis for SCRUM is the… A. Empirical process control. B. Waterfall Method. C. Empire of SCRUM. D. None of the options listed. [12] Empirical process control states that… A. transparency is the prerequisite for verification. B. knowledge is based on experience and decisions are made on the basis of knowledge C. review is a prerequisite for adjustment. D. None of the listed answer options. [13] The theory of empiricism is based on three steps: A. Practice, learn, practice. B. Transparency, intransparency, decisions 120 Anerkennung des Scrum-Know-hows C. Transparency, Inspection and Adaptation. D. Transparency, information and adaptation. [14] The five values according to SCRUM are A. Courage, Focus, Commitment, Respect, Openness. B. courage, focus, happiness, commitment, respect. C. courage, focus, commitment, adaptation, openness. D. None of the possible answers is correct. [15] The SCRUM guide … A. is the summary of what the SCRUM fathers Jeff Sutherland B. and Ken Schwaber understand SCRUM to be. C. is a manifesto written by all representatives of agile management on the most important agile rules in project management. D. was first published in 2010. E. was last updated in 2017. [16] The SCRUM guide … A. is only available in English language. B. is a glossary of the most important terms of agility. C. None of the possible answers is correct. D. is available in several languages also authorized. [17] The SCRUM process describes … A. the roles that are relevant in SCRUM B. which tools are used in Sprint Planning. C. None of the possible answers is correct. D. the interaction of events and artifacts. [18] The elements of the SCRUM process are … A. artifacts, tools and events. B. only artifacts and events. C. only Sprint Planning and Sprint Review. 121 Anerkennung des Scrum-Know-hows D. the two roles: Product Owner and SCRUM Master. [19] The Product Backlog … A. is managed by the product owner and contains all essential product features. B. is maintained by the SCRUM team to ensure that transparency is always up-to-date. C. is used in the sprint to manage the individual tasks in the sprint. D. None of the options listed. [20] The sprint backlog… A. is managed and created by the SCRUM master. B. permanently replaces the product backlog after it has been created once and initialized was created. C. is used by the development team to support its Manage tasks opera‐ tionally. D. None of the listed answer options. [21] As part of the sprint … A. the Daily SCRUM takes place once a day, so that the development team can coordinate and synchronize. B. the Sprint Review takes place daily to measure the progress of the project. C. only the development team is involved in the events, in order not to disturb the development work. D. None of the possible answers is correct. [22] After the development work was done in the Sprint, … A. ta new Sprint Planning is carried out, in order to update the plan to the new development status to update. B. he Sprint Review takes place to check what was achieved in the last sprint was. C. a Daily SCRUM will continue to be conducted to provide regular feedback on the completed development process. D. None of the possible answers is correct. [23] The Sprint Retrospective … A. serves to check the current quality of the product. 122 Anerkennung des Scrum-Know-hows B. serves to collect feedback on the development process. C. serves to develop improvement measures. D. None of the possible answers is correct. [24] The Events within the framework of the SCRUM process are: A. Sprint Planning, Sprint, Daily SCRUM, Sprint Review and Sprint Retrospective. B. only Daily SCRUM and the Sprint. C. Sprint Planning and Sprint Review only. D. always for a maximum of fifteen minutes. [25] The timing of the events in the SCRUM process is … A. Sprint Planning, Sprint, Daily SCRUM, Sprint Review, Sprint Retro‐ spective. B. Sprint Review, Sprint Planning, Sprint, Sprint Retrospective. C. Sprint Planning, Daily SCRUM, Sprint Retrospective, Sprint, Sprint Review. D. Sprint Retrospective, Sprint Planning, Sprint, Daily SCRUM, Sprint. [26] In SCRUM there are … A. exactly five rolls. B. exactly four rollers. C. None of the possible answers is correct. D. exactly three responsibilities. [27] The roles of the SCRUM team are … A. Users, customers, management. B. Stakeholder, Product Owner, SCRUM Master. C. None of the possible answers is correct. D. Product Owner, SCRUM Master, The Developers [28] The SCRUM team … A. is in close coordination with the stakeholders through the SCRUM Master. B. must apply the rules and principles of SCRUM. 123 Anerkennung des Scrum-Know-hows C. is defined by the fact that each team member is assigned a role. D. also includes the stakeholders who have an interest in the product to be developed product. [29] The stakeholders … E. can be anyone who has an interest in the development of the product. F. are part of the SCRUM team. G. are represented by the product owner in the SCRUM team. H. take part in all events of the SCRUM team. [30] Which of the following statements is correct? A. The SCRUM Master is project manager. B. The development team only programs. C. The Product Owner is responsible for the success of the product. D. None of the listed answer options. 124 Anerkennung des Scrum-Know-hows Wie lauten die Lösungen auf diese Prüfungsfragen? [1] A [2] B [3] C [4] A [5] A [6] D [7] D [8] B [9] A [10] C [11] A [12] B [13] C [14] A [15] A [16] D [17] D [18] B [19] A [20] C [21] A [22] B [23] C [24] A [25] A [26] D [27] D [28] B [29] A [30] C 125 Anerkennung des Scrum-Know-hows Glossar Im Text waren zentrale Fachbegriffe mit einem → gekenn‐ zeichnet. Diese werden nun erklärt, allerdings nicht, wie üblich, in wenigen Sätzen, sondern, der Komplexität der Begriffe entsprechend, ausführlich und eingehend. Artefact Zu Deutsch Artefakt: Artefakte sind das Product Backlog, Sprint Backlog und das Inkrement. Ziel der Artefakte ist es, die Arbeit und ihren Wert im Rahmen des Scrum-Prozesses transparent zu machen. Burn-down-Chart Burn-down-Charts zeigen den Fortschritt bezogen auf die noch zu erledigen‐ den Aufgaben in Relation zur Zeit. Burn-down-Charts sind eine optionale Möglichkeit in Scrum, den Fortschritt transparent zu machen. Burn-up-Chart Burn-up-Charts zeigen den Fortschritt bezogen auf die noch zu erledigenden Aufgaben in Relation zur Zeit. Burn-up-Charts sind eine optionale Möglich‐ keit in Scrum, den Fortschritt transparent zu machen. Cumulative-Flow-Chart Cumulative-Flow-Charts zeigen den Fortschritt des noch zu schaffenden Aufwands als Anstieg inklusive verschiedener Detailinformationen bezogen auf den aktuellen Status in Relation zur Zeit. Cumulative-Flow-Charts sind eine optionale Möglichkeit in Scrum, den Fortschritt transparent zu machen. Daily Scrum Ein Event mit einer festgelegten Zeitdauer von maximal 15 Minuten. Es dient dem Entwicklungsteam dazu, den anstehenden Tag der Entwicklungsarbeit während eines Sprints zu planen. Änderungen und Aktualisierungen wer‐ den im Sprint Backlog eingetragen. Definition of Done Zu Deutsch Definition von „fertig“: ein gemeinsames Verständnis über die Erwartungen, die die Software (oder das zu entwickelnde Produkt) erfüllen muss, um ausgeliefert werden zu können. Sie wird vom Entwicklungsteam gemanagt. Development-Team Zu Deutsch Entwicklungsteam: Das Entwicklungsteam ist die Rolle im Scrum-Team, die dafür verantwortlich ist, all die Entwicklungsarbeit zu leisten, die notwendig ist, um in jedem Sprint ein auslieferungsfähiges Inkrement des Produktes zu erstellen. Emergence Zu Deutsch Vorkommnis: der Prozess der Entstehung oder des Bekanntwer‐ dens eines neuen Fakts oder des Wissens über ein Faktum oder das Wissen über einen Fakt, der unerwartet auftritt. Empiricism Zu Deutsch Empirie: ein Vorgehen zur Prozesskontrolle, in dem nur die Vergangenheit als sicher angenommen wird und in dem Entscheidungen auf Beobachtungen, Erfahrungen und Ausprobieren beruhen. Empirie basiert auf drei Säulen: Transparenz, Überprüfung und Anpassung. Engineering Standards Zu Deutsch Entwicklungsstandards: ein einheitliches Verständnis über Entwicklungs- und Technologiestandards, die vom Entwicklungsteam an‐ gewandt werden, um ein auslieferungsfähiges Inkrement der Software (oder des Produkts) zu erstellen. Forecast (of Functionality) Zu Deutsch Vorschau (auf Funktionalitäten): Die Auswahl von Back‐ log-Items aus dem Product Backlog, die ein Entwicklungsteam dafür geeig‐ net ansieht, dass sie in einem Sprint umgesetzt werden. 128 Glossar Increment Zu Deutsch Inkrement: ein Teil einer funktionierenden Software, die zu einem bereits vorher entwickelten Inkrement hinzugefügt wird. Alle Inkre‐ mente zusammen - in ihrer Gänze - ergeben ein Produkt. Product Backlog Eine nach Rang geordnete Liste der Arbeit, die noch zu erledigen ist, um ein Produkt zu entwickeln, in Stand zu halten oder fortzuführen. Das Product Back-log wird vom Product Owner gemanagt. Product Backlog Refinement Die Tätigkeit während des Sprints, durch die der Product Owner und das Entwicklungsteam Detailinformationen zum Product Backlog hinzufügen. Product Owner Die Rolle in Scrum, die dafür verantwortlich ist, den Wert des Produkts zu maximieren. Dies erfolgt vorrangig dadurch, dass der Product Owner fortlaufend die fachlichen und geschäftlichen Erwartungen an das Produkt in Abstimmung mit dem Entwicklungsteam managt. Role Zu Deutsch Rolle: Jedes Mitglied eines Scrum-Teams hat eine klar definierte Rolle. Jede Rolle verfügt über eine klare Definition von Aufgaben, Kompe‐ tenzen und Verantwortung. Ready Zu Deutsch bereit. Ein gemeinsames Verständnis des Product Owners und des Entwicklungsteams bezogen auf das erwartete Informationslevel jedes Backlog-Items. Das Ready wird im Rahmen des Sprint Plannings festgelegt. Scrum Ein Rahmenwerk, um Teams bei komplexen Produktentwicklungen zu unterstützen. Scrum besteht aus dem Scrum-Team und den dazugehörigen Rollen, Events, Artefakten und Regeln, so wie diese im Scrum Guide be‐ schrieben sind. 129 Glossar Scrum Guide Die Definition von Scrum, geschrieben und zur Verfügung gestellt von Ken Schwaber und Jeff Sutherland, den beiden Entwicklern bzw. Vätern von Scrum. Diese Definition besteht aus Scrum-Rollen, Events, Artefakten und den Regeln, die diese verbinden. Scrum Master Die Rolle in einem Scrum Team, die dafür verantwortlich ist, ein Scrum-Team und sein Umfeld bezogen auf ein klares Verständnis von Scrum und seiner Anwendung zu begleiten, zu beraten und zu schulen. Scrum-Team Ein sich selbst organisierendes Team, das aus dem Product Owner, dem Entwicklungsteam und dem Scrum Master besteht. Scrum Values Zu Deutsch Scrum-Werte: die grundlegenden fünf Values und Fähigkeiten, die das Scrum-Framework ermöglichen. Die Values sind Selbstverpflich‐ tung, Fokus, Offenheit, Respekt und Mut. Self-Organization Zu Deutsch Selbstorganisation: Managementprinzip, das davon ausgeht, dass Teams ihre Arbeit autonom und selbst organisieren. Diese Selbstor‐ ganisation erfolgt innerhalb festgelegter Grenzen auf der Basis von klar vorgegebene Rollen. Die Teams entscheiden selbst, wie sie ihre Arbeit aus‐ führen, anstatt von jemandem außerhalb des Teams angeleitet zu werden. Sprint Ein zeitlich festgelegtes „Event“ mit einer maximalen Dauer von 30 Tagen. Es dient als „Container“ für andere Scrum-Events und -Aktivitäten. Sprints erfolgen lückenlos nacheinander, ohne Pausen zwischen den einzelnen Sprints. Sprint Backlog Eine Übersicht über die Entwicklungsarbeit, die notwendig ist, um das Sprint-Ziel zu erreichen. Es handelt sich hierbei typischerweise um eine Vorschau auf die Funktionalitäten und die Arbeit, die notwendig ist, um eine 130 Glossar Funktionalität zu entwickeln. Das Sprint Backlog wird vom Entwicklungs‐ team gemanagt. Sprint Goal Zu Deutsch Sprint-Ziel: eine kurze Zusammenfassung des Grunds oder des Mottos des Sprints. Hierbei handelt es sich oft um ein geschäftliches Problem, das adressiert wird. Seine Funktionalitäten können während eines Sprints angepasst werden, um das Sprint-Ziel zu erreichen. Sprint Planning Ein zeitlich begrenztes Event mit einer maximalen Dauer von acht Stunden. Es findet zu Beginn jedes Sprints statt. Es dient dem Scrum-Team dazu zu überprüfen, welche Arbeit aus dem Product Backlog am besten dafür geeignet ist, als nächstes erledigt zu werden, um dann ins Sprint Backlog übertragen zu werden. Sprint Retrospective zu Deutsch Sprint-Retrospektive: ein zeitlich begrenztes Event von maximal drei Stunden. Es stellt den Abschluss jedes Sprints dar. Es dient dem Scrum-Team dazu, den letzten Sprint zu überprüfen und Verbesserungen zu planen, die im nächsten Sprint umgesetzt werden sollten. Sprint Review Ein zeitlich begrenztes Event mit einer maximalen Dauer von vier Stunden. Ziel ist es, die Entwicklungsarbeit des Entwicklungsteams abzuschließen. Es dient dem Scrum-Team und den Stakeholdern dazu, das Inkrement des Produkts, das aus dem Sprint geliefert wurde, zu überprüfen. Stakeholder Eine externe Person, die nicht Teil des Scrum-Teams ist. Sie verfügt über ein besonderes Interesse an oder über Wissen zu dem zu entwickelnden Produkt. Die Stakeholder werden im Scrum-Team über den Product Owner repräsentiert. Aktiv eingebunden werden die Stakeholder im Sprint Review. Velocity Zu Deutsch Geschwindigkeit: eine optionale, jedoch oft verwendete Indi‐ kation dafür, wie viele Backlog-Items des Product Backlogs durch das Scrum-Team während eines Sprints in ein Inkrement des Produkts überführt 131 Glossar wurden. Es wird vom Entwicklungsteam für das gesamte Scrum-Team getrackt. 132 Glossar Register Adaption 39, 78 Amazon 24 Apple 24 Artefakte 82 Burn-Down-Chart 63 Coaching 41 Commitment 57, 83, 89 Confidence Vote 57 Container 61 Cynefin 32 Daily Scrum 69 Definition of Done 42 Definition of Ready 107 Entwicklungsteam 50 Events 58 Facebook 24 Flixbus 24 Fokus 56 Framework 38 Freenow 24 Google 24 Homeoffice 87 Inkrement 42, 88 Inspection 39, 78 Jeff Sutherland 20 Jira 86 Ken Schwager 20 Kunde 28 Kundenwert 89 Lenkungsausschusssitzung 87 Motivation 105 Mut 56 MyTaxi 24 N26 24 Offenheit 58 Paintpoints 77 Preplanning 81 PRINCE2 32 Product Goal (Produktziel) 90 Product Owner 41 Produkt-Value 48 Produktziel 88 Projektbudget 55 Projektmanagement 29 Projektmanager 54 Refinement 79, 81 Respekt 57 Ressourcenplanung 55 Retrospektive 78 Scrum Guide 38 Scrum Master 41, 81 Scrum-Meetings 60 Scrum-Theorie 59 Selbstverpflichtung 57 Sprint 61, 63 Sprint Backlog 85 Sprint Goal 104 Sprint Planning 81 Sprint-Retrospektive 75 Sprint Review 72 Stakeholder 72 Subject-matters-Experts 51 Team 112 Tesla 28 Transformation 55 Transparency 39, 78 Transparenz 78, 87 Trello 87 Wertschätzung 75 Zertifizierungen 114 Zusammenarbeit 77 134 Register ISBN 978-3-8252-5974-7 Die utb-Reihe „Frag doch einfach! “ beantwortet Fragen, die sich nicht nur Studierende stellen. Im Frage-Antwort-Stil geben Expert: innen kundig Auskunft und verraten alles Wissenswerte rund um ein Thema. In diesem Band werden unter anderem Antworten auf diese Fragen zu lesen sein: Was ist das Geheimnis hinter dem Erfolgsphänomen? Welche Tools und Methoden haben Scrum so erfolgreich gemacht? Und wie kann es eingesetzt werden, um Projekte erfolgreich zu managen? Die wichtigsten Fachbegriffe werden zudem prägnant vorgestellt und es wird verraten, welche Websites, YouTube-Videos und Bücher das Wissen aus diesem Bandes vertiefen können. Das Buch richtet sich in erster Linie an Studierende des Fachbereichs Betriebswirtschaftslehre, aber auch an Interessierte zu diesem Thema. Management | Projektmanagement Scrum? 2. A. Kaiser | van Bennekum Dies ist ein utb-Band aus dem UVK Verlag. utb ist eine Kooperation von Verlagen mit einem gemeinsamen Ziel: Lehr- und Lernmedien für das erfolgreiche Studium zu veröffentlichen. utb.de QR-Code für mehr Infos und Bewertungen zu diesem Titel Fabian Kaiser Arie van Bennekum Scrum? Klare Antworten aus erster Hand 2. Auflage Frag doch einfach! 5974-7_Kaiser_Bennekum_M-5522.indd Alle Seiten 5974-7_Kaiser_Bennekum_M-5522.indd Alle Seiten 29.08.22 14: 43 29.08.22 14: 43