<?page no="0"?> ,! 7ID8C5-cffcca! ISBN 978-3-8252-5522-0 Fabian Kaiser Arie van Bennekum Scrum? Klare Antworten aus erster Hand 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 diesem 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? 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-shop.de QR-Code für mehr Infos und Bewertungen zu diesem Titel Frag doch einfach! 55220 Kaiser_M-5522.indd 1 55220 Kaiser_M-5522.indd 1 06.08.21 10: 44 06.08.21 10: 44 <?page no="1"?> utb 5522 Eine Arbeitsgemeinschaft der Verlage Brill | Schöningh - Fink · Paderborn Brill | Vandenhoeck & Ruprecht · Göttingen - Böhlau Verlag · 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 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 <?page no="2"?> 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 Projektmanagement. 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ückgefallen. 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 Konferenzen, für Führungsteams und während (agilen) Transformationen. #fragdocheinfach <?page no="3"?> Fabian Kaiser / Arie van Bennekum Scrum? Frag doch einfach! Klare Antworten aus erster Hand UVK Verlag · München <?page no="4"?> © UVK Verlag 2021 ‒ 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 Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Internet: www.narr.de eMail: info@narr.de Einbandgestaltung: Atelier Reichert, Stuttgart CPI books GmbH, Leck utb-Nr. 5522 ISBN 978-3-8252-5522-0 (Print) ISBN 978-3-8385-5522-5 (ePDF) ISBN 978-3-8463-5522-0 (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. <?page no="5"?> 11 13 15 17 19 20 22 23 25 27 27 28 29 32 34 36 37 39 Alle Fragen im Überblick Vorworte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Was die verwendeten Symbole bedeuten . . . . . . . . . . . . . . . Infografik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scrum ist in aller Munde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Für was steht der Begriff Scrum? . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hat Scrum eine Geschichte? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wenn Scrum agil ist, was ist Agilität? . . . . . . . . . . . . . . . . . . . . . . . . Wieso wird Agilität aktuell gehypet? . . . . . . . . . . . . . . . . . . . . . . . . . Ist Scrum so beliebt, weil Agilität gehypet 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? . . . . . . . . . . . . <?page no="6"?> 40 42 42 44 45 48 49 49 51 52 52 53 54 56 58 60 62 62 63 65 67 67 70 71 Wie funktioniert der Scrum-Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . Welche Teammitglieder bzw. Verantwortlichkeiten gibt es in Scrum? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Was ist ein Scrum Master? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wie finde ich einen Scrum Master? . . . . . . . . . . . . . . . . . . . . . . . . . . Können wir diese Lösungsmöglichkeiten detaillierter anschauen? Können wir gerade 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, wenn man 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? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alle Fragen im Überblick 6 <?page no="7"?> 72 73 74 74 76 76 76 77 79 79 81 81 83 84 85 86 87 89 90 90 92 92 94 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? . . . . . . . . . . . War trägt die Verantwortung für das Sprint Review? . . . . . . . . . . . Was ist eine Sprint Retrospektive? . . . . . . . . . . . . . . . . . . . . . . . . . . . Wird 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 Refinement verantwortlich und was ist sein Ziel? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Welche Artefakte gibt es? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Was sind die zu den Artefakten entsprechenden Commitments? . . 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? . . . . . . . . . . . . . . . . . . Alle Fragen im Überblick 7 <?page no="8"?> 94 96 97 98 99 100 101 103 105 106 108 109 111 111 112 114 115 117 117 118 120 Was macht Jira im Hinblick auf die Nützlichkeit der Scrum-Anwendung aus? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Was macht Confluence im Hinblick auf die Nützlichkeit der Scrum-Anwendung aus? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wie funktioniert Confluence und was sind die Vorteile dieser Anwendung? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Für wen eignet sich Confluence am besten? . . . . . . . . . . . . . . . . . . . Was macht Miro im Hinblick auf die Nützlichkeit der Scrum-Anwendung aus? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Für wen eignet sich Miro? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Was macht Scrumpanion im Hinblick auf die Nützlichkeit der Scrum-Anwendung aus? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Praxisumsetzung von Scrum . . . . . . . . . . . . . . . . . . . . . . . Kann Scrum auch teilweise in der Praxis umgesetzt werden? . . . . 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? . . . . . . . . . . Alle Fragen im Überblick 8 <?page no="9"?> 120 122 129 131 137 Habe ich als Leser dieses Buches einen Vorteil? . . . . . . . . . . . . . . . . Welche Fragen kommen in einer Scrum Muster-Prüfung auf mich zu? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wie lauten die Lösungen auf diese Prüfungsfragen? . . . . . . . . . . . . Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alle Fragen im Überblick 9 <?page no="11"?> Vorworte „Survival of the fittest“ - Ein Ausdruck, der in der Evolutionstheorie beschreibt, was passiert, wenn man nicht anpassungsfähig war. Heute beschreiben wir dies als agil. Und gerade das Jahr 2020 zeigt sehr eindrucksvoll, wie anpassungsfähig und agile Menschen und Unter‐ nehmen 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 völlig 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. Fernab dem gesundheitlichen Aspekt dieser Krise, zeigt sie auf sehr eindrucksvolle 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. Die Herausforderung ist größer als dass „nur“ eine digitale Disruption zu bewältigen gilt. Einer der elementarsten Bestandteile von Agilität ist das Prozessrah‐ menwerk Scrum. Eine Möglichkeit mit einer Auswahl an Prozessen und Techniken, auf schlanke Weise Produkte zu entwickeln und kon‐ tinuierlich weiterzuentwickeln. Wer sich heute im Jahre 2021 betroffen von aufstrebenden Tech-Startups oder Corona bedingten Veränderungen sieht, der kommt an den Themen Agilität und Scrum - und damit an diesem Buch - nicht vorbei. Fabian Kaiser Frankfurt, im Juli 2021 <?page no="12"?> Agile ist nicht länger ein Trend, Agile ist der Standard. Gleichzeitig ist Agile immer noch voller Legenden, Mythen, offen für viele Inter‐ pretationen 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 einer (beliebigen) Agile-Methode zu bekommen, ist es hilfreich, gemeinsam mit den jenigen, mit denen man später zusammenarbeitet, sich 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 Ihnen und Ihrem Team weiterhelfen. Der Blickwinkel, der dafür gewählt wurde, war einfach, indem wir sehr prominente Fragen auswählten und uns gemeinsam darauf stürzten. Das Endergebnis ist dieses praktische Buch, das Ihnen als Leser eine wichtige Agile Methode, Scrum näher bringt. Lesen Sie es zu Ihrem Nutzen und wenn Sie den Nutzen sehen, teilen Sie die Antworten dieses Buches mit den Menschen um Sie herum, mit genau dem gleichen Zweck, sich gegenseitig voran zu bringen. Arie van Bennekum Hardinxveld-Giessendam, im Juli 2021 Vorworte 12 <?page no="13"?> 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 wer‐ den im Glossar erklärt. <?page no="17"?> Scrum ist in aller Munde Dieses einführende Kapitel beschreibt die Ursachen der Popularität von Scrum und vergleicht es mit dem klassi‐ schen Projektmanagement. <?page no="19"?> Für was steht der Begriff Scrum? Der Begriff „Scrum“ ist keine Abkürzung. Vielmehr ist Scrum meta‐ phorisch zu sehen. Denn die Begrifflichkeit findet man neben dem hier gemeinten Prozessrahmenwerk auch im Rugby Sport. Hierbei beschreibt Scrum den Spielzug, bei dem alle Spieler auf einem dicht‐ gedrängt stehen und durch eine Teamleistung versuchen den Ball zu ergattern. Abb. 1 In der Metapher gesprochen ist hiermit gemeint, dass nur durch eine enge Teamleistung ein Ziel erreicht werden kann. Scrum, als Begriff beschreibt damit sehr eindrucksvoll die Grundhaltung hinter dem Scrum-Framework. Videotipp: Ein Beispiel für den Rugby-Spielzug: ► https: / / youtu.be/ VIfD0nuocVo Scrum ist in aller Munde 19 <?page no="20"?> 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 Software-Konfe‐ renz im Jahre 1995 in der heutigen Form vorgestellt. Das Besondere war, dass sie Scrum in einigen Jahren davor schon in Projekten angewendet haben und damit kontinuierlich verbessern konnten. Ihre Erfahrungen haben die beiden in einem offiziellen Dokument, dem →Scrum-Guide zusammengefasst. Gestartet im Bereich der Software-Entwicklung schauen wir heute auf 90.000.000 Menschen, die Scrum kennen und anwenden - auch au‐ ßerhalb der IT. Heute, gute 25 Jahre nach offizieller Bekanntmachung, erlebt Scrum einen echten Mainstream-Hype. Abb. 2 Scrum? Frag doch einfach! 20 <?page no="21"?> Einerseits ist die Übertragbarkeit von Scrum auf andere Anwendungs‐ bereiche ein Vorteil. Andererseits birgt es jedoch das Risiko, dass Scrum als Lösung für alles angesehen werden könnte, womit eine Enttäuschung vorprogrammiert ist. Abb. 3 Umso wichtiger ist, die Beliebigkeit der Anwendung von Scrum ent‐ gegenzuwirken, um diese Methode weitere 25 Jahre in die richtige Richtung weiterzuentwickeln. Videotipp: Ein Interview mit Jeff Sutherland: ► https: / / youtu.be/ P_6Orv3R9Mg Scrum ist in aller Munde 21 <?page no="22"?> 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 die berufliche Welt 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 Mitarbeiterinnen und Mitar‐ beitern durchgereicht wird? Ist es das, morgendliche Kurzmeeting, welches auf einmal im Stehen abgehalten wird? Vielleicht auch. Scrum? Frag doch einfach! 22 <?page no="23"?> Vielleicht sind das aber auch nur die Rand-Erscheinungen oder sichtbaren Symptome einer neuen, modernen Arbeitswelt, die zum Teil durch Agilität entstanden sind. Agilität bedeutet aber weitaus mehr. Es bedeutet einen Mind‐ set-Change des gesamten Unternehmens. Auf allen Hierarchieebenen. Ein Mindset-Change, der nicht nur das oben beschriebene Offensicht‐ liche meint, sondern das Vertrauen durch Transparenz schafft. Ein Mindset-Change, der Selbstorganisation fördert und Talente zu kreati‐ ven Umsetzern macht. Ein Mindset-Change, der schnell entlang der Bedürfnisse einen Mehrwert für das wichtigste eines jeden Unterneh‐ men stiftet: den Kunden. Ein Mindset-Change, der es schafft, eine offene und wertschätzende Fehlerkultur in den Unternehmensalltag zu bringen. Erst wenn diese Meta-Ebene in einer Organisation erkannt und 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 einfach damit. Videotipp: Hier erklärt der Autor in weniger als fünf Minuten Agilität: ► https: / / youtu.be/ DAV5xGAVexw Wieso wird Agilität aktuell gehypet? Die Antwort hierauf verbirgt sich im letzten Absatz der vorangegange‐ nen 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 Referenzunter‐ nehmen 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 Scrum ist in aller Munde 23 <?page no="24"?> sogar junges Startup-Unternehmen, einem doch den Rang ablaufen kann. Gute Beispiele sind hierfür: ▸ Freenow (früher MyTaxi), die mit einer App den gesamten Taxi‐ markt innerhalb von fünf Jahren verändert haben. ▸ Flixbus, eine günstige Plattform für Fernbusse, die nicht nur die Deutsche Bahn unter Druck setzen, sondern auch jeden privaten Busunternehmer in Deutschland dazu bringt sein Geschäftsmo‐ dell ohne Plattformteilnahme ernsthaft zu hinterfragen. ▸ N26, die als Mobil-Bank aktuell jeden Tag 10.000 neue Kunden gewinnt und bei diesem Wachstum DAX notierte Banken in den nächsten zwei Jahren kundenseitig überholen wird Auch diese Unternehmen brauchen keine Weiterbildung darüber, 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: Magazin „Warum Agilität kein Hype ist“, https: / / www.agile-heroe s.de/ magazine/ agilitaet-kein-hype/ Scrum? Frag doch einfach! 24 <?page no="25"?> Abb. 5 Ist Scrum so beliebt, weil Agilität gehypet ist? Diese Frage ist nicht einfach zu beantworten. Grundsätzlich gilt, dass Agilitä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. Beziehungsweise welche Best Practise 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 nachkommen und sagen, dass Scrum gerade so beliebt ist, weil es auch Agilität ist. Scrum ist in aller Munde 25 <?page no="26"?> Scrum ist in der Welt der Agilität allerdings nicht das einzige Frame‐ work. Jedoch das bekannteste bzw. das am häufigsten verwendete. Im Zuge dessen könnte man sich natürlich fragen, wieso es gerade Scrum war oder ist, das mit Abstand am meisten Verwendung findet? Abb. 6 Die Antwort darauf könnte sein: 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 abgeben. 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 scheinbar beliebteste Framework. Scrum? Frag doch einfach! 26 <?page no="27"?> Wo wird Scrum eingesetzt? Als im Jahr 1995 Ken Schwaber und Jeff Sutherland das Scrum-Frame‐ work in seiner heutigen Form vorstellten, waren die dort nieder‐ geschriebenen Erfahrungswerte ausschließlich im Bereich der Soft‐ ware-Entwicklung gemacht worden. Heute, 25 Jahre später, ist es immer noch so, dass die Mehrzahl der Anwendungsfälle im Software‐ bereich liegen. Ohne hier auf Statistiken zurückgreifen zu können, wären realistische Schätzung im 80 %-Bereich 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 ange‐ passt. Ein Türgriff in einem Haus hingegen ist mit deutlich höherem Aufwand zu ändern. Hiermit 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 Definition 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 unterschiedlichen Branchen, Unternehmen und Projekten Anwendung finden kann und jene Menschen 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 die Frage gestellt werden, welchen Mehrwert eine Arbeit von Scrum bringt. 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 auf Produktkom‐ ponenten. „Schnell“ bedeutet hierbei frühestens alle 14 Tage. Welchen Vorteil bietet es aber, eine neue Produkt-Komponente 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 im Entwicklungsprozess sehr stark eingebunden ist. Der Kunde kann Feedback geben und man kann Scrum ist in aller Munde 27 <?page no="28"?> weiter an seinem Produkt arbeiten - und zwar so, wie es dem Kunden‐ bedürfnis am ehesten entspricht. Der Kunde muss dann nicht wieder ein ganzes Jahr, sondern lediglich 14 Tage auf die Berücksichtigung oder Einarbeitungen des Feedbacks warten. Das bedeutet einerseits, dass man sehr schnell erkennt, ob die kundenseitige Anforderung in die Realität umgesetzt, 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 unternehmensinterner Kunde sein - also beispielsweise eine Unterneh‐ mensabteilung. Auch das Produkt, das hier generisch beschrieben wird, ist frei wählbar. Jedoch fällt schnell auf, dass diese Produkte, die im besten Fall 14 Tage bis zur Auflieferung brauchen, eher Software basiert sind. Hierbei ist Tesla wieder einmal 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 weiterzuentwickeln. Darüber hinaus kann ein bestehendes analo‐ ges Produkt eher schwer umgebaut werden - im Vergleich zu einer Software. Es kann am Auto nicht mühelos ein Teil weggesägt werden und ein neues hinzugefügt werden. Dies würde jegliches Kosten-Nut‐ zen-Verhältnis zerstören. Anders sieht es bei der Software des Fahrzeugs aus: Ob der Soft‐ ware-Entwickler 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, dann kann es auch wieder relativ einfach entfernt werden. Scrum? Frag doch einfach! 28 <?page no="29"?> Das beschreibt einfach und gleichzeitig 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 einzuord‐ nen. Ersetzt Scrum das klassische Projektmanagement? Um dieser Frage gerecht zu werden, lohnt es sich etwas mehr im Bereich des Projektmanagements auszuholen. 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 wir dort nie ein Produkt in einem „Big Bang“ auf den Markt gebracht haben, sondern dieses Produkt immer inkrementell, also Stück für Stück, mit dem Markt entwickelt haben. Videotipp: Was ist klassisches Projektmanagement; ► https: / / www.youtube. com/ watch? v=FKCom8wziEk Scrum ist in aller Munde 29 <?page no="30"?> Abb. 7 Scrum? Frag doch einfach! 30 <?page no="31"?> Agil: Wirft man nun einen Blick auf das agile Vorgehen, so fällt auf, dass die Phasen aus dem klassischen Projektmanagement auch hier Anwen‐ dung finden, diese aber nicht einmalig über einen langen Zeitraum funktionieren, sondern innerhalb unserer beispielhaften 14 Tage. Also viel schneller. Das Produkt ist dann ebenfalls zur selben Zeit wie im klassischen Beriech 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 Feedback vom Kunden und auch ein bereits generierter Umsatz. Hybrid: Hierbei wird über ein agiles Vorgehen auf Team-Ebene, ein klassisches Projektmanagement gestülpt. Hintergrund ist, dass Unternehmen, die aus dem Bereich des klassischen Projektmanagements ein Zwischen‐ modell fahren wollen, um keine erheblichen Veränderungen beispiels‐ weise in der Unternehmensorganisation durchzuführen. Weitere Vor‐ teile der hybriden Vorgehensweise sind, dass man Teams in den Genuss von agiler, selbstorganisierter Arbeit kommen lassen will, aber dennoch ein Projekt mit einem „Big Bang“ auf den Markt bringen will. 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 Differenzierungsdarstellung wird klar, dass ein agiles Vorge‐ hen - auch im Projektmanagement - mit Sicherheit grenzender Wahr‐ scheinlichkeit 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. Scrum ist in aller Munde 31 <?page no="32"?> Literaturtipp: Ein Lehr- und Fachbuchklassiker: ist das ebenfalls bei utb erschie‐ nene 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 dieser sich immer wieder wiederholenden Frage, wann geht man agil und wann klassisch an ein Projekt heran, mit einer soliden Antwort zu entgegnen, kommt man an dem Cynefin-Framework nicht vorbei. Auch große und bekannte Projektmanagementmethoden wie PRINCE2 erwähnen es, um diese zentrale Frage zu beantworten. Hintergrund dieses Frameworks ist es, durch verschiedene Sachver‐ haltsbeispiele herauszufinden, welches Vorgehen zu welcher Heraus‐ forderung möglicherweise am besten passt. Wichtig dabei ist das Wort „möglicherweise“. Denn auch ein Cynefin-Framework oder eine Voreinschätzung der Ausgangssituation kann sich irren. 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 der vollen Breite, jedoch nicht in der vollen Tiefe durchleuchtet. Scrum? Frag doch einfach! 32 <?page no="33"?> Abb. 8 Schaut man sich nun das verbildlichte Cynefin-Framework an, so fällt auf, dass es hierbei 5 Bereiche gibt, welche als unterschiedliche Herausforderungslagen beschrieben werden: ▸ Obvious, ▸ Complicated, ▸ Complex, ▸ Disorder (mittleres, unbeschriftetes Feld) und ▸ Chaotic. Quellenhinweis: Die Grafik stammt von Wikipedia. Scrum ist in aller Munde 33 <?page no="34"?> 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 sehr bekannt ist. Abläufe sind unzählige Male durchlaufen und Ergebnisse sind schon oft in derselben Art und Weise fertig gestellt worden. Hat man diese Ausgangslage vorliegen, 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 stan‐ dardmäßige Aufgabe erfüllt werden muss. Ähnliche Aufgaben wurden bereits öfter im Unternehmen oder von Kollegen erfüllt. Die Anfor‐ derungen sind sehr klar formuliert und das erwartete Ergebnis ist absolut bewusst. Hierbei handelt es sich um ein Projekt, das in der klassischen Projektmanagementvorgehensweise 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, 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 umfangrei‐ chen Produkt leben kann, so haben wir die typische Ausgangssituation, welche sich für ein agiles Vorgehen bestens eignen würde. Typische Projekte sind neue Produkte oder Dienstleistungen, welche durch ein Feedback des Kunden schnell und zielgerichtet weiterentwickelt werden können oder müssen. Scrum? Frag doch einfach! 34 <?page no="35"?> 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 manchmal noch gut funktionierenden Produkte nicht mit einem umfangreichen Re-Launch im klassischen Modell umsetzen, um am Ende herauszu‐ finden, dass sie gar am Kunden vorbeientwickelt haben. 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 Startup ist die kapi‐ talträ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. Kei‐ ner 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 Corona-Pandemie, 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 hier, sich einen ersten Überblick über die Situation zu verschaffen, um möglichst viele Informationen zu sammeln auf Basis dessen dann entschieden werden kann, wie die richtige Vorgehensweise ist. Videotipp: Beispielhaft wird hier die Entscheidungshilfe Cynefin-Framework vorgestellt: ► https: / / youtu.be/ hsKTIQR_UNA Scrum ist in aller Munde 35 <?page no="36"?> Heißt das, dass es bei Scrum keine Hierarchien gibt? Scrum gibt einen großen Teil der „Macht“ zum Managen und Orga‐ nisieren an das Team zurück. Einen Projektmanager im klassischen Sinne gibt es nicht mehr. Die Annahme, die hierbei zugrunde liegt, ist, dass die Teams selbst ausreichende Motivation und genug Wissen haben, um sich selbst zu organisieren, und selbst am besten wissen, wie sie ein vorgegebenes Ziel erreichen. Und das ganz ohne detaillier‐ ten 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 dass - 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-Me‐ thode gemanagten Projekten in Projektplanung, Budgetmanagement und Statusreports anstatt in das eigentliche Management des Pro‐ jekts geht, 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 Methoden. 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 Medien-brü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, auf ein Minimum. Und was effizient ist, setzt sich in Zeiten knapper Budgets und immer schneller zu liefernder Ergebnisse einfach durch. Scrum? Frag doch einfach! 36 <?page no="37"?> Aufbau und Funktionsweise von Scrum In diesem Kapitel erfahren Sie, welche Scrum-Mitglieder welche Verantwortlichkeiten haben und welche Elemente relevant sind. <?page no="39"?> Was sind die wesentlichen Bestandteile von Scrum? Scrum ist als Framework im Vergleich so anderen Frameworks wirk‐ lich ein Leichtgewicht. Spricht man in der Welt von PRINCE2, von einem offiziellen Manuel von rund 300 Seiten, so erhält man mit dem →Scrum-Guide, also dem eigentlich niedergeschriebenen Dokument von Scrum, lediglich 17 Seiten. Die Bestandteile von Scrum sind daher in geringe Menge vorhanden und im Scrum-Guide auch wenig tiefge‐ hend beschrieben. Die tiefgehenden Gedanken von Scrum, sind 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 Aufbau und Funktionsweise von Scrum 39 <?page no="40"?> 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 deswegen die Scrum-Theorie danach 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 Scrum? Frag doch einfach! 40 <?page no="41"?> Schritt 1: Transparency: Alle Mitglieder eines Scrum-Teams legen transparent 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. Wir besprechen inner‐ halb der Teams, wie wir mit den neuen Informationen umgehen und auf Basis dessen Entscheidungen treffen können, die uns im weiteren Scrum-Verlauf helfen können. Schritt 3: Adaption: Hier werden die Informationen aus Schritt 1 mit den Entscheidungen aus Schritt 2 umgesetzt. Dieser dritte Schritt Adaption ist demnach der Schritt, wo es um die exekutive 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 vorweist und stellt 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 Produktverantwortliche mit dem Schritt 2 Inspection, dass wir viele Fehler mit dem Produkt haben, und kommen dann zu dem Entschluss, dass sich die Zeit um vier Wochen verzögern wird. Daraufhin kommen wir zum 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, wir reduzieren den Umfang des Produkts, um weiterhin innerhalb des festgelegten Zeitrahmens zu bleiben. Dadurch haben wir Agilität im perfekten Maße ausgelebt. Wir haben den Umfang reduziert, um die Zeit einzuhalten. Und Dies auf Basis der Scrum-Theorie bzw. der Theorie des Empirismus. Lesetipp: Der Scrum-Prozess; https: / / www.agile-heroes.de/ magazine/ der-sc rum-prozess/ Aufbau und Funktionsweise von Scrum 41 <?page no="42"?> 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 Rollen in Verantwortlichkeiten in Scrum unbenannt. Demnach gibt es in Scrum drei Verantwortlichkeiten: ▸ Verantwortlichkeit 1: Der →Scrum Master. Der Scrum Master ist kurzgesagt das methodische Lead des Scrum-Teams. Er hat die Verantwortung für Scrum-Methode. ▸ Verantwortlichkeit 2: Der Scrum-Product Owner. Der →Product Owner hat die Produktverantwortung. Also die Verantwortung für das entwickelnde Produkt, das von dem Entwicklungsteam umgesetzt wird, also entwickelt wird. ▸ Verantwortlichkeit 3: Das Scrum-Entwicklungsteam. Das Scrum-Entwicklungsteam - oder wie es seit 2020 heißt: Deve‐ lopers bzw. auf 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 methodische Obacht von Scrum in einem Scrum-Umfeld zu gewähr‐ leisten. Der Scrum Master ist außerdem für die Einführung von Scrum, wenn man sich in einem neuen Scrum-Umfeld bewegt, wie es im Scrum-Guide definiert wurde, verantwortlich. Die Verantwortungsbe‐ reiche 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: Der Scrum Master unterstützt das Team beinhaltet: Coaching der Teammitglieder im Selbstmanagement (Selbstorga‐ Scrum? Frag doch einfach! 42 <?page no="43"?> nisation) und in der funktionsübergreifenden Zusammenarbeit. Das Ziel ist es hierbei, das Team so gut wie möglich in Selbstma‐ nagement zu üben. ▸ Punkt 2: Des Weiteren unterstützt der Scrum Master die Scrum-Teams bei der Konzentration, also bei dem Fokus, von der Entwicklung von hochwertigen →Inkrementen (hierauf gehen wir im späteren Teil des Buchs genauer ein) entsprechend der →Definition of Done (auch hier gehen wir später nochmal genauer darauf ein). 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 Beseitigung von Hindernissen, die den Fortschritt des Teams behindern oder verlangsamen. ▸ Punkt 4: Er stellt sicher, dass alle Veranstaltungen (Events) statt‐ finden und erfolgreich, produktiv und innerhalb der definierten Timebox abgehalten werden. Die Timebox ist eine Technik, welche besagt, dass ein Meeting immer zur vorgegebenen Zeit beginnt und maximal 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 unterstütz und bei der Verantwortung des Product Backlogmanage‐ ments. Hierbei geht es darum, dass er den Product Owner mit Coaching und Scrum-Best-Practices unterstützt, seiner Verantwortung als Pro‐ duct Owner nachzukommen. Der Scrum Master hilft dem Product Owner dabei die Product Backlog-Items, also den 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 Produktplanung entlang des empirischen Scrum-Pro‐ zesses zu vollziehen. Dabei ist gemeint, dass er das Produkt entlang kontinuierlicher Verbesserungsmaßnahmen planen könnte. Als Beispiel ist hier zu sehen, dass ein Produkt in Zyklen auf den Markt gebracht wird, um es von den Kunden validieren zu lassen um so der bereits bekannten Transparency, Inspection und Adaption, also dann auf Kundenbasis Feedback einzuarbeiten, nachgekommen Aufbau und Funktionsweise von Scrum 43 <?page no="44"?> werden kann. 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 Pro‐ jekterfolg interessiert sind und so Informationen seitens des Product Owner erhalten wollen. 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 verantwortet. Schulungen und Co‐ achings innerhalb der Organisation durchführt und hilft wie Scrum eingeführt werden könnte oder eingeführt wird. Der Scrum Master unterstützt die Organisation bei der Planung und Beratung von der Einführung von Scrum innerhalb der Organisation. Darüber hinaus unterstützt der Scrum Master, den Mitarbeitern und Stakeholdern das Verständnis von Scrum und den empirischen Ansatz von Scrum zu folgen. Eine weitere Aufgabe eines Scrum Masters innerhalb der Orga‐ nisation 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, sicher zu stellen. Wie finde ich einen Scrum Master? Bist du in deinem Unternehmen in der Position mit einem Scrum Projekt zu beginnen oder ein bestehendes Scrum Team mit einem neuen Scrum Master auszustatten, ist die Frage nach dem „Wie“ sicher schnell gegeben. Grundsätzlich gibt es zur Lösung dieser Herausforderung folgende gängige Möglichkeiten. - Interne Besetzung aus den Reihen des Entwicklungsteams - Interne Besetzung aus nicht Entwicklungsteams Reihen - Externe Besetzung eines Scrum Masters Scrum? Frag doch einfach! 44 <?page no="45"?> Können wir diese Lösungsmöglichkeiten detaillierter anschauen? Ja, sehr gerne. 1. Interne Besetzung aus den Reihen des Entwicklungsteams: In der Praxis sehe ich 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, weil die 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 ist kein Fulltime-Job. Aus meiner Erfahrung nimmt diese Wahrnehmung der Stakehol‐ der signifikant ab, je größer und komplexer das Projekt ist. Ist ein Team, einer kleinen Werbeagentur mit 3 bis 4 Entwicklern für ein Scrum Master auch aus meiner Sicht zu klein - und ja, jetzt wird es ein großen Aufschrei in der Scrum Community geben, weil ich dem „heiligen“ Scrum Guide widerspreche - ist es bei einem Projekt mit neun oder mehr Entwicklern unabdingbar einen Vollzeit fokussierten Scrum Master zu haben. Zweiteres setzt natürlich voraus, dass Stakeholder wirklich möchten, dass ihr Projekt funktioniert. Wenn sie gerne ihre Software-Entwicklern den Fokus rauben, sie mit Impediments auseinandersetzen lassen möchten und ihre Projekt-Deadline reißen möchten, ist Option 1 natürlich auch immer möglich. Na‐ türlich war der letzte Absatz nicht ernst gemeint und überspitzt dargestellt, was passiert, wenn Entwickler die Verantwortung des Scrum Masters übernehmen. Sie verlieren Fokus, haben oft nicht die nötige Sicht von „außen“ und gehen in der Praxis oft zu tief mit in Diskussionen. 2. Interne Besetzung aus nicht Entwicklungsteams Reihen: Wird man oder will man im bestehenden Team an Entwicklern nicht fündig werden, so ist die nächste Naheliegende Reaktion, eine Person aus der Organisation für das Scrum Team zu begeis‐ tern. Dazu werden aus meiner Sicht oft Menschen vorgeschlagen, die sowieso schon Projekterfahren sind. Also erfahrene Scrum Aufbau und Funktionsweise von Scrum 45 <?page no="46"?> Master oder Personen die als PMO’s oder Projektmanager ar‐ beiten und die eher die methodischen Sichtweißen verantworte‐ ten, 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ötig den nötigen Mut um sowohl intern als auch extern des Teams, die richtigen Dinge anzusprechen und dabei in Kauf zu nehmen, eventuelle, vornehmend in großen Konzernen, politische Gemüter zu verletzten. Die‐ ser Mut kann belohnt werden. Ich habe jedoch oft erlebt, dass viele interne Scrum Master aufgrund von Angst vor Konsequenzen derartige Thematiken anzusprechen, es lieber unterlassen. - Karriere: Neben der Frage, ob solche transparenten Darstellungen von Problemen in der Organisation, die Karriere-Entwicklung be‐ flügeln oder behindern, ist die Frage nach der Karriere-Ent‐ wicklung von Scrum Mastern bis dato noch recht ungeklärt. Ja, wir leben und arbeiten in einer sehr hierarchielosen 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. Bis dato sind nächsten Schritte für die Menschen, die die Rolle des Scrum Masters übernehmen aufgrund der erst sehr kurzen Zeit der Massendurchdringung diesen Titels, noch sehr fraglich. Aus der Sicht der Agile Heroes sehen wir die nächste Ent‐ wicklungsstufe eines Scrum Masters in der Rolle des Agile Coaches. Es ist aus unserer Sicht also eher die Rolle eines Experten. - Langfristige Motivation: Eine weitere Erfahrung aus der Praxis ist die langfristige Motivation von Scrum Mastern oder anders formuliert: Die Scrum? Frag doch einfach! 46 <?page no="47"?> hohe Rotation auf diesen Stellen. Wir glauben, dass viele Scrum Master über einen Zeitraum von 1 bis 2 Jahren den Punkt erreichen, an dem ein neues Team, ein neues Projekt mit neuen Herausforderungen als sinnvoll 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 ver‐ wendet worden sind. Der Scrum Master erfährt eine gewisse Sättigung an Erfahrung und auch das Team ist in einem höchsten Zustand an Performance angekommen. - Zusatz Faktor Ausbildung (bei neuen Scrum Master): Der Aspekt Ausbildung, ist für einen erfahrenen Scrum Master weniger 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 die Rücksicht, dass das Team die höchste Geschwindigkeit erst nach einem Einbruch von Geschwindigkeit erlangen wird. Das ist ein absolut normaler Weg. Jedem Stakeholder sollte daher bei einer Verpflichtung eines internen diese normalen Einarbeitungs-Themen bewusst sein. 3. Externe Besetzung: Die oben bereits genannten Probleme und Herausforderungen sind durch einen sehr einfachen Weg zu umgehen. Die externe Besetzung eines Scrum Master, für einen befristeten Zeitraum bietet direkt viele Vorteile: - Schnell - Qualitativ - Weniger Aufwand - Externe Sicht - Keine eigene Karriere Ambitionen Aufbau und Funktionsweise von Scrum 47 <?page no="48"?> Können wir gerade die Vorteile einer externen Besetzung detaillierter betrachten? Gerne; die fünf Vorteile im Einzelnen sind Folgende: - Schnell Einen internen Mitarbeiter einzustellen, benötigt einen hohen zeitlichen - und oft auch monetären Aufwand. Ein externer Scrum Master ist oft in wenigen Tagen für das Unternehmen sofort 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 erfahrene 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 Mitarbeiter-Entwicklun‐ gen, Weiterbildungen oder Vorgesetzen 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 Herausfor‐ derungen mit einem neuen Blick anzugehen und oft auch schnell und einfach zu lösen. Außerdem bringt der externe Scrum Master in der Regel einen hohen Benchmarkt 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 Karriere Ambitionen Als weiterer Punkt sind die eigenen Karriere Ambitionen zu sehen, die ein externer Scrum Master nicht mitbringt. In der Regel sind die offenen und transparenten Kommunikationen damit völlig frei und ohne Hintergedanken zu sehen. Er kann ganz ohne Angst um seine Scrum? Frag doch einfach! 48 <?page no="49"?> eigenen Laufbahnen im Unternehmen, den Finger tief in die Wunde legen und damit eventuell auch politische Spannungen angreifen, sofern sie den Projekterfolg gefährden. Kann man hieraus eine einfache Entscheidungsregel ableiten? Nachdem alle Vor- und Nachteile der entsprechenden Besetzungsfor‐ men eines Scrum Masters dargestellt worden sind, ja. Zusammenfas‐ send 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 Projekt‐ erfolg, 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 Produktvalues erstmal 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 Marktimpact, bzw. die höchste Kundenzufriedenheit oder wie hier Scrum formuliert, den höchsten Produktvalue erzielt. Im Folgenden sind einige Verantwortungen des Product Owner dargestellt, was natürlich von Organisation zu Organisation, oder Scrum-Team zu Scrum-Team oder auch von Product Owner zu Product Owner unterschiedlich ausfallen kann. Folgende Verantwortung hat der Product Owner. Aufbau und Funktionsweise von Scrum 49 <?page no="50"?> 1. Effektive Verwaltung des Product Backlogs. Hierzu gehörten die Entwicklung und explizite Kommunikation des Produktziels (das ist übrigens erst seit dem Scrum-Guide in der Verantwortung des Product Owner, 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 dabei dem Scrum-Team oder den Entwicklern die richtigen Entscheidungen zu treffen und ein klares Verständnis über die zu liefernden Inkremente zu bekommen. 2. Der Product Owner ist auch für die Erstellung und für die klare Kommunikation der →Product Backlog-Elemente, der Product Backlog-Items, zuständig. Das bedeutet, in der Welt vor Scrum könnte man diese Product Backlog-Elemente als Anforderungen sehen, welche der Product Owner bei den entsprechenden Sta‐ keholdern, bei den richtigen Ansprechpartnern, einholt. Und auf Basis dessen, ist die Verantwortung des Product Owners, dass er diese Anforderungen in ein Product Backlog-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 Produktentwicklung ablaufen wird. Grundsätzlich gilt, dass der Product Owner accountable ist, dass die Arbeiten durch‐ gefü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 delegiert sie auch an andere. Für die Praxis ist es unabdingbar, dass die Arbeit des Product Owner von Seiten der gesamten Organisation respektiert wird. Denn nur wenn die Arbeit und die Entschei‐ dungen des Product Owner respektiert werden, ist sichergestellt, dass die Arbeit des Product Owner erfolgreich ist. Die Arbeit, die der Product Owner tätigt, ist zum einen in dem Product Backlog, Scrum? Frag doch einfach! 50 <?page no="51"?> also in der genannten To-Do-Liste sichtbar, als auch am Ende eines jeden Zyklus, in dem so genannten Sprint-Review. Oft stellt sich in der Praxis die Frage, ist der Product Owner eine Person oder kann er auch von mehreren Personen gestellt werden. Da 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 an den Product Backlog zu vollziehen. Generell ist es so, dass der Product Owner, während das Scrum-Team bzw. die Entwickler im Sprint arbeiten, sich mit dem weiteren ver‐ feinern des Product Backlogs beschäftigt. Das bedeutet, er spricht mit entsprechenden Stakeholdern und gegebenenfalls mit Kunden. Er nimmt Feedback zu dem Produkt entgegen und packt 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 nehmen 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 in den folgenden Zeilen 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. Aufbau und Funktionsweise von Scrum 51 <?page no="52"?> Aus meiner Sicht sind vor allem Menschen mit der höchsten Berufs‐ erfahrung bzw. Erfahrung im 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 verste‐ hen. Dafür brauch man Zeit und eine Menge interne Kenntnisse, die es schwer machen, externe oder neue interne Mitarbeiter anzustellen. Schwer heißt jedoch nicht unmöglich. Vor allem für den Punkt, neue Mitarbeiter für die Rolle des Product Owners anzuwerben, erachte ich als sinnvollste zweitbeste Möglichkeit. Sie bringen auch wieder externe - also neue - Sichtweisen mit, die allen helfen könnten. 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 natura 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 Organisation internes Know-how aufzubauen. In der Regel ist das in der externen Besetzung des Product Owners wenig gegeben. Daher ist der aus meiner Praxis sprechende Rat, definitiv auf eine in‐ terne Besetzung zu führen. Am besten, 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 früheren 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 Inkre‐ mentes zu erstellen. Ein →Inkrement ist im Grunde ein nutzbares Scrum? Frag doch einfach! 52 <?page no="53"?> Teilprodukt des Gesamtprodukts. Die Entwickler sind in ihrem Team selbstorganisiert, bzw. selbstgemanagt unterwegs, das heißt dass sie grundsätzlich alleine im Team 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 Software-Entwicklern, von Designern und Marketingspezialisten 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 zu dem Produkt oder dem →Inkrement leisten müssen. Ein gutes Beispiel hierfür ist der Einsatz von Beratung durch Rechts‐ anwälte. Diese würde man hier nicht den Entwicklern zuordnen, sondern als so genannte Subject-Matters-Experts welche kurzzeitig den Entwicklern bei der Umsetzung von Aufgaben unterstützt. Die Entwickler haben zudem folgende Verantwortung: Erstellung eines Plans für den Sprint. Wie und welche To-Do’s arbeiten wir im nächsten Sprint ab. Das wird im so genannten →Sprint Backlog niedergeschrie‐ ben. 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 (wird später im Buch genauer beschrieben) zu erledigen. Die Entwickler haben 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 die Frage nach dem Product Owner verkompliziert die Frage nach den perfekten Entwicklern die Antwort sehr. Geht es doch gerade in der umsetzungsstarken Rolle eines Entwicklers um eine sehr diverse und fachliche Sicht auf die Dinge. Man könnte die Frage daher Aufbau und Funktionsweise von Scrum 53 <?page no="54"?> fast umformulieren in „Wie finde ich die perfekten Teammitglieder oder Mitarbeiter? “. Die Antwort auf diese Frage ist aus meiner Sicht keine Scrum-spezi‐ fische Antwort. Der Vollständigkeit halber lasse ich in diese Antwort jedoch Erfahrungen aus meiner Zeit als Scrum Master und aus meinem Unternehmer Alltag 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 mit‐ bringen - 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 in dem Bewerbergespräch die Frage stellst, ob der Mensch glücklich ist, wirst du ziemlich schnell ziemlich große Augen sehen. Mit hoher Wahrscheinlichkeit ist die Frage deinem Gegenüber noch nicht untergekommen. Der Tiefgang dieser Frage zielt darauf ab her‐ auszufinden, 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 unseren 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 Scrum? Frag doch einfach! 54 <?page no="55"?> 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 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 identi‐ fizieren. Aber was steckt hinter der Extrameile? Hierbei geht es nicht um Überstunden. 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 schlechter wird. Dieses Mindset teilen wir nicht und versuchen wir 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 Zeit, 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 die Zeiten anders und selbstorganisiert einzuteilen. Stelle nur Menschen ein, die eine hohe Lösungskompetenz mitbringen Ein Team, auf das komplexe Anforderungen und Herausforderungen zukommen, sollte von Lösungskompetenz geprägt sein. Nichts ist hinderlicher als nur die Probleme zu diskutieren. Elon Musk, CEO von Aufbau und Funktionsweise von Scrum 55 <?page no="56"?> Tesla und SpaceX, fragt in den Bewerbungsgesprächen die Menschen nach den größten Lösungen 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 Herausfor‐ derungen. Ich bin auch dieser Überzeugung. Wenn ich an mein Team herantrete, möchte ich über mögliche Ideen und Lösungen sprechen. Ich möchte keine Probleme oder Risiken besprechen, die nicht relevant sind. Ich möchte auch, dass mein Team selbst Probleme löst und dafür nicht einen Product Owner, einen Scrum Master oder einen Geschäftsführer braucht. Auch diese Charaktereigenschaft ist für das Ziel eines 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 Werkstudenten, 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 Mitarbeiter. Es ist wichtig, Menschen einzustellen, die auf dem Gebiet dem Team aktuell überlegen sind. Nur dadurch bringen Sie das Team voran und heben es auf die nächste Stufe. Was bin ich, wenn man Projektmanager war? In der Praxis, vor allen Dingen in agilen Transformationsprojek‐ ten, erlebt man, dass alte Rollen innerhalb eines Projekts oder alte Rollen innerhalb einer Organisation in der agilen Welt eine neue äquivalente Rolle suchten. 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üh‐ rend. Das bedeutet, wenn man vormals Projektmanager war, ist diese Aufgabe in der agilen Welt grundsätzlich nach Scrum nicht Scrum? Frag doch einfach! 56 <?page no="57"?> mehr notwendig. In einem Scrum-Projekt mitzuwirken, bedeutet die Wahl zwischen der 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 infrage kommt. Bleiben also noch die Rollen eines Scrum Masters oder des Product Owners: ▸ Beschäftigt sich der Projektmanager mit dem Thema Anforde‐ rungsmanagement und kennt er das Produkt sehr gut dann wäre die Rolle des Product Owners zu empfehlen. Allerdings nur, wenn er auch bereits Fachfeinkonzepte geschrieben hat, die dann von Teilprojekten umgesetzt wurden. Dennoch müsste die Arbeitsweise angepasst werden. ▸ Sieht sich der Projektmanager eher in der Rolle eines methodi‐ schen Projektmanagers, wird er in der Rolle des Scrum Masters besser aufgehen. 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, Verant‐ wortlichkeiten und Kompetenzen. Allerdings gibt es Projekte in der agilen Welt, die einen Projektma‐ nager benötigen: in größeren agilen Projekten, in welchen es mehrere Scrum Master und Product Owner gibt. Diese sollten von einem Projektmanager koordiniert werden. Insbesondere hierarchische Or‐ ganisationen oder Großkonzerne benötigen weiterhin Projektmanager, weil vor allen Dingen Projektbudget und Ressourcenplanung an dieser Rolle hängt, 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ötz‐ lich neue 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 Aufbau und Funktionsweise von Scrum 57 <?page no="58"?> einen kurzfristigen und drastischen Organisationswandel mit allen denkbaren Folgen erfahren. Deshalb entscheiden sich viele pragma‐ tischer Weise für einen übergeordneten agilen Projektmanager als bessere Lösung. In der Praxis erhält diese Lösung auch eine höhere Akzeptanz seitens aller Beteiligter für eine agile Transformation mangelt. Eine organisch wachsende, agile Community zu schaffen und so inkrementell und bedarfsgerecht die agile Transformation heran‐ schreiten zu lassen, ist zu bevorzugen. Welche Werte gibt es in Scrum? Das Besondere am Scrum-Framework im Vergleich zu Methoden wie zum Beispiel Prince2 ist, dass es feste Werte gibt, nach denen im Scrum-Team gehandelt. Hierbei handelt es sich um fünf Werte. 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 umsetzt, 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 Teilneh‐ mern 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: Scrum? Frag doch einfach! 58 <?page no="59"?> Mut: Hierbei geht es darum, dass das →Scrum-Team mutig sein soll, neue Prozesse, Ziele oder Kommunikationsweisen auszuprobieren. Es geht darum, Veränderungen nachzugehen. Das Scrum-Team soll darüber hinaus ebenfalls den Mut haben, sich auf ein Ziel zu fixieren, welches vielleicht anspruchsvoller als das vorherige ist. Es soll Mut zur Inno‐ vation 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 Erfahrung gemacht hat und beim Lesen dieser Zeilen bestätigend nickt. Die Qualität des Arbeitsergebnisses ist vergleichsweise höher als im Fall von gleichzeitiger Bearbeitung un‐ terschiedlicher 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 sein Team nach dem Confidence-Vote abfragen. Das ist best practise, steht also nicht im Aufbau und Funktionsweise von Scrum 59 <?page no="60"?> 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 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 re‐ spektvoll 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, so ein gutes Teamklima herzustellen. 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 Herausforderungen 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 eben 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 auch Zeremonien genannt werden. Scrum? Frag doch einfach! 60 <?page no="61"?> Abb. 10 Diese ermöglicht es den Anwendern, ihr vollständiges Potenzial aus‐ zuschöpfen. Hierbei geht es im Grunde genommen immer noch darum, der Scrum-Theorie gerecht zu werden. Der Grundgedanke der jeweili‐ gen Events ist es, Transparenz herzustellen und die Gelegenheit zu nutzen, Scrum-Artefakte zu inspizieren und anzupassen. Zur Erinnerung bezüglich der Scrum-Theorie ▸ Transparency, ▸ Inspection und ▸ Adaption. Aufbau und Funktionsweise von Scrum 61 <?page no="62"?> Die Events sind speziell darauf ausgerichtet die erforderliche Trans‐ parenz 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 so genannte Timebox. Wer trägt die Verantwortung für die Timebox? Das Timeboxing ist eine Technik, die für Meetings verwendet wird und welche 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 obliegt dem gesam‐ ten 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 Meetings, die nicht in Scrum definiert sind, auch nicht anzuwenden sind. Außerdem könnte man argumentieren, dass keine Scrum Mee‐ tings bzw. Events anzuwenden 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. Scrum? Frag doch einfach! 62 <?page no="63"?> Dennoch kommt es vereinzelt vor, dass man aus Zeit- oder Effizienz‐ gründen Meetings auch einmal absagen muss. Zur Erinnerung. Jedes Meeting, jedes Event findet zur gleichen Zeit am gleichen Ort statt, um die Komplexitä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 Projekt‐ erfolg durch Effizienz sicher zu stellen. 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 Weiterentwick‐ lung/ Lesson to Learn Möglichkeit für das Team. ▸ Das Refinement bzw. Researchmeeting: Das gilt es in Klammern zu sehen Was ist ein Sprint? Der →Sprint, und so ist es sehr metaphorisch im Scrum-Guide nieder‐ geschrieben, 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, inner‐ halb 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 Aufbau und Funktionsweise von Scrum 63 <?page no="64"?> und zu einem →Inkrement erschaffen wird. Das ist jedoch nur sehr oberflächlich beschrieben. Ein neuer Sprint, also ein Zyklus innerhalb dessen wir als Team arbeiten, dauert nie länger als ein 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 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 abgeschlossen 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. Scrum? Frag doch einfach! 64 <?page no="65"?> ▸ Während des Sprints werden keine Änderungen vorgenommen, die das Sprint-Ziel gefährden. ▸ Jeder Sprint ist mit einem Sprint-Ziel, auch →Sprint Goal ge‐ nannt, bestückt. ▸ Während des Sprints ist es wichtig, dass die Qualität nicht ab‐ nimmt, sondern die Entwickler dauerhaft mit höchstem Niveau am Produkt arbeiten. ▸ Während des Sprints entwickelt das Team das Inkrement. ▸ 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 Owner 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 Unge‐ wissheit des zu entwickelten Produkts bzw. der Anforderung des Kunden für das Produkt sind, umso kürzer sollten die Sprintzyklen dauern. Wenn also ich ein neues Produkt auf den Markt gebracht werden soll, wenn nicht bekannt ist, wie dieses bei den Kunden ankommt, wenn noch nicht klar ist, welche Features dem Kunden welchen Nutzen, 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 stattfin‐ dende Scrum-Events verringern möchte, so ist ein vierwöchiger Sprint-Zyklus zu bevorzugen. Im Grunde genommen gilt die Faustregel: Je kürzer der Sprint umso stärker beschränkt man das Risiko von Kosten und drohendem Aufwand durch eine Falsch‐ entwicklung. Je sicherer man sich mit der Entwicklung ist, desto länger können die Sprints sein. Aufbau und Funktionsweise von Scrum 65 <?page no="66"?> Innerhalb eines Sprints gibt es wiederum verschiedene Möglich‐ keiten den Fortschritt des Sprints transparent zu machen. Generell hat der Stakeholder, der in der Praxis vor allen Dingen das Inter‐ esse hat, die Entwicklung eines Projekts zu beobachten, die Mög‐ lichkeit in das Sprint Backlog - also die Aufgabenliste des Sprints - hineinzuschauen. Hierfür könnte darüber hinaus weitere Prakti‐ ken 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, wie weit das Team tatsächlich ist. Eine Abbildung dafür findest du im Folgenden. 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 seinen 15 Minuten Rhythmus beste Vorausset‐ zung dazu 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. Scrum? Frag doch einfach! 66 <?page no="67"?> 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 abgebrochen bzw. beendet wird. Dies geschieht nur dann, wenn das endgültige Ziel obsolet wird. Die Entscheidung, ob ein Sprint abgebro‐ chen wird und komplett neu geplant werden müsste, obliegt dem Product Owner. Er allein hat die Autorität, den Sprint abzubrechen. Falls ein Sprint abgebrochen wird, findet automatisch ein Sprint Review statt und darauf folgend die Retrospektive und wiederum darauf das neue Sprint Planning. Ein weiterer Grund, wieso ein Sprint vorzeitig beendet werden könnte, ist die aktuelle 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 Onlineshops miteinander chatten können. Innerhalb der Coronakrise beschließt die Bundesregierung die Mehrwertsteuersen‐ kung auf 16 %. Das ist die Basis unseres Sprints, den wir betrachten: Wir berücksichtigen dies und die 16-prozentige Mehrwertsteuer 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 abzubrechen. 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 Ent‐ wicklungsteams 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 Aufbau und Funktionsweise von Scrum 67 <?page no="68"?> 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? Abb. 13 Scrum? Frag doch einfach! 68 <?page no="69"?> Warum ist dieser Sprint wertvoll? Hierbei ist es die Aufgabe des →Product Owner vorzuschlagen und vorzustellen, 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 de‐ finieren, das kommuniziert und festlegt, warum der Sprint für die Kunden und die Stakeholder wertvoll sein wird. Das Sprint-Ziel muss festgestellt werden, bevor wir mit dem Sprint Planning abschließen. Wichtig dabei ist zur Erinnerung: Ein Sprint kann immer nur dann abgebrochen seitens des Product Owner werden, wenn dieses Sprint-Ziel obsolet wird. Das Sprint-Ziel bietet außerdem dem Entwick‐ lungsteam 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 Planning kommen, 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 Priorisie‐ rung der Meinung, dass zuerst die Tapete an die Wand gehängt werden muss und erst danach diese mit Kleister versehen wird. Dann könnte der Entwickler mit einer Alternativlösung einschreiten: Stopp, unser Vorschlag ist. zuerst den Kleister auf die Tapete aufzutragen und danach diese an die Wand kleben. Offensichtlich ist der Einwand berechtigt und die Arbeit logischer und einfacher zu handhaben. Aufbau und Funktionsweise von Scrum 69 <?page no="70"?> Wie wird die gewählte Arbeit erledigt werden? Für jedes Product Backlog-Element planen die Entwickler die Arbeit, die notwendig ist, um das Inkrement, das im Grunde genommen das materialisierte Sprint-Ziel ist, zu erstellen. Wichtig hierbei ist, dass es entsprechend 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. Beispielsweise könnte 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 abgearbeitet wird, liegt allein im Ermessen der Entwickler. Nur sie legen fest, wie das Product Backlog-Element in der entsprechenden 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 das am Ende ein Sprint-Ziel mit einem für den Sprint breites 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 Scrum? Frag doch einfach! 70 <?page no="71"?> behandelt. Der Hintergrund ist, einfach: Der Product Owner muss bei Thema 3 nicht unbedingt anwesend sein. Videotipp: Die wichtigsten Aspekte des Sprint Plannings werden in diesem Kurzvideo noch einmal erklärt: ► https: / / youtu.be/ NB3LBLKa4xA Was ist ein Daily Scrum? Ein Daily Scrum ist die bekannteste Methode des Scrum-Fra‐ meworks. Es beschreibt ein täglich stattfindendes Meeting des Scrum-Teams mit Anwesenheitspflicht - jedoch nur für die Ent‐ wickler. 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 unter‐ einander 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 vor‐ nehmen. Die Stakeholder haben ebenfalls das Recht an dem Daily Scrum teilzunehmen. 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. Aufbau und Funktionsweise von Scrum 71 <?page no="72"?> 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 einen umsetzbarer Plan für den Arbeitstag erstellt wird. Das Daily Scrum sollte damit einen Fokus schaffen und dazu beitragen, dass das Team ein besseres Selbstmanagement erzeugen kann. Abb. 14 Ist das Daily Scrum sehr wichtig für die Praxis? In der Praxis erlebt man doch immer wieder, dass Daily Scrums zu Beginn sehr geringfügig von Kommunikation geprägt sind. Der Scrum Master muss in diesen Fällen dann häufig eine Kommunikation erst „anschieben“. Mit der Zeit werden die Entwickler hierbei aber 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. Scrum? Frag doch einfach! 72 <?page no="73"?> 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ög‐ lichkeit ist, an dem sie sich austauschen dürfen. Das ist so nicht richtig. Die Entwickler dürfen den ganzen Tag kommunizieren. Es ist nur die einzige von Scrum vorgegebene Zeremonie, an dem 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 finden Sie 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 und guten Mehrwert erzielt. Das Daily Scrum ist übrigens eine Methode, die es auch über Scrum hinausgeschafft 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 hin‐ stellt. Es soll dazu beitragen, dass das Meeting wirklich auch sehr kurzgehalten wird. Diese Vorgehensweise hat sich in dem Daily Scrum ebenfalls eingebürgert, weshalb in der Praxis eigentlich ausschließlich Daily Scrums im Stehen vorgenommen werden. Aufbau und Funktionsweise von Scrum 73 <?page no="74"?> Muss man sich beim Daily Scrum an einem Ort physisch treffen? Tatsächlich ist die Frage vor dem Hintergrund der Vorsichtsmaßnah‐ men in Zeiten einer Pandemie berechtigt. In der Scrum Theorie war nie angedacht, dass Meetings „remote“ stattfinden, aber man hat sich inzwischen auf die aktuelle Situation angepasst und Daily Scrums in Zeiten von Videokonferenzen funktionieren sehr gut. Am Anfang braucht jedes Team, wenn sie 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. Hierzu hat jeder die Möglichkeit zu kommen und sich die Vorstellungen des Entwicklungsteams anzuschauen. Übrigens: In der Praxis wird diese Veranstaltung auch oft „Demo“ genannt. Hieran erkennt man, dass Scrum aus der IT-Branche kommt, 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 Scrum? Frag doch einfach! 74 <?page no="75"?> 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 Stakeholder ein deutlich besseres und qualifizierteres Feedback geben können. Abb. 15 Aufbau und Funktionsweise von Scrum 75 <?page no="76"?> Warum ist das Sprint Review gerade in einem dynamischen Umfeld so wichtig? Während des Sprint Review überprüft das Scrum-Team und die Stake‐ holder, 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 Stakeholder versteht und bespricht, was als nächstes zu tun. 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-Retrospektive 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 sieht das Ganze so aus, 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 Vor‐ stände, um sich die Präsentationen anzuschauen und da ist es ein wichtiges Projektmarketingbzw. ein Teammarketing-Instrument - es empfiehlt sich, für dieses Event gut vorbereitet zu wirken. War trägt die Verantwortung für das Sprint Review? Die Vorbereitung und methodische Durchführung und auch Mode‐ ration des Meetings obliegt dem Scrum Master: Er führt mit den Entwicklern durch dieses Meeting und schreitet gerne auch ein, sollten die Teammitglieder mit den Stakeholdern in einer zu tief gehenden Diskussion landen, welche für den einen oder anderen Zuhörer nicht relevant ist. Scrum? Frag doch einfach! 76 <?page no="77"?> Neben den bereits aufgeführten Vorteilen hat das Sprint Review außerdem noch den wichtigen Aspekt der Wertschätzung. Es ist tat‐ sächlich so, dass die Entwickler gerne ihre Arbeit vorstellen und das Review bietet die Gelegenheit dann als Stakeholder oder Verantwortli‐ cher an dieser Stelle Lob auszusprechen oder die geleistete Arbeit Wert zu schätzen. Oft kommt es in der Praxis leider vor, dass eher mal 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 wichtiger Aspekt der Motivation für das Team bietet. Videotipp: In diesem Kurzvideo finden Sie 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 hinsicht‐ lich der Qualitätssteigerung in ihrem Team. Und hierbei ist nicht die Qualität ihres Produkts, was eher die B-Note betreffen würde, dieser Retrospektive, gemeint. Sondern tatsächlich die Qualität der Zusammenarbeit, die methodische 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 Prozessen, in den Tools, in der Zusammenarbeit das Team noch Möglichkeiten zur Verbesserung hat. Aufbau und Funktionsweise von Scrum 77 <?page no="78"?> Abb. 16 Scrum? Frag doch einfach! 78 <?page no="79"?> Wird 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 Stake‐ holdern, die nicht in einem Scrum-Team mitarbeiten. Sie fragen sich, ist die Retro wirklich notwendig, um bessere Ergebnisse zu erzielen oder ist die Retro reine Zeitverschwendung, ein reiner Overhead? Und wenn derartige Fragen aufkommen, ist es meist ein gutes Zei‐ chen 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, dass die Retro nicht mehr wertvoll ist. Auch Scrum Master kommen 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 finden Sie die wesentlichen Informationen zur Sprint Retrospektive: ► https: / / youtu.be/ f3QPX6zlu8Y Was ist das eigentliche Ziel der Sprint Retrospektive? Im Grunde genommen geht es hierbei darum, dass das Team sich in der Zusammenarbeit verbessern kann. Hierbei moderiert der Scrum Master die Retrospektive anhand verschiedener Retrobeispiele durch. Es gibt eine Vielzahl an Retroformaten, welche bei manchen Unternehmen Aufbau und Funktionsweise von Scrum 79 <?page no="80"?> ständig variieren. Bei anderen Unternehmen wird jede Retro im glei‐ chen Format durchgeführt. Was hier richtig oder falsch ist, muss jedes Team oder jedes Un‐ ternehmen für sich selbst entscheiden. Folgendes haben jedoch alle Formate gemeinsam: ▸ Transparenz über die aktuelle Situation herzustellen, ▸ Entwicklungsfelder zu identifizieren und ▸ diese zu verbessern oder umzusetzen. Es fällt auf, dass diese drei Schritte dem Scrum-Prozess, der empirischen Theorie entsprechen. ▸ Transparency, ▸ Inspection und ▸ Adaption werden innerhalb der Retrospektive - wie auch in allen anderen Mee‐ tings - angewendet. Man identifiziert und analysiert ein Problem und findet Verbesserungsmöglichkeiten. Wenn dies vorgenommen wurde, geht das Team her und identifiziert 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 herunter skaliert. 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 darauf direkt. Scrum? Frag doch einfach! 80 <?page no="81"?> 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 schweigend auf Haftnotizen, was das Team einerseits vorwärtsgetrieben hat, also der Wind in den Segeln war, und 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 die entsprechende Stelle des Papiers. Eine mögliche Erweiterung ist durch die Hinzunahme einer wei‐ teren Kategorie 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 anbrin‐ gen. Was ist ein Refinement? Ein Refinement ist im Scrum-Guide nicht als Scrum-Event niederge‐ schrieben. Jedoch in der Praxis wird es als absolut gängige Methode oder Technik gesehen. Aufbau und Funktionsweise von Scrum 81 <?page no="82"?> Abb. 17 Scrum? Frag doch einfach! 82 <?page no="83"?> Das Refinement ist eine Technik oder eine Meeting-Form innerhalb dessen 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 ist vollkommen unabhängig von der von Scrum vorgegebenen Meeting-Struktur. Die einzige Bedingung lautet, dass dieser 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 →Product 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 Refinement verantwortlich und was ist sein Ziel? Oft wird in der Praxis dieser Termin für ein Refinement von einem →Scrum Master begleitet. Er nimmt die Moderationsrolle ein. 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 durchzuführen. Hierbei geht es darum, ▸ die einzelnen Product Backlog-Elemente mit den Entwicklern zu besprechen, ▸ 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 Refinement. Damit könnte es auch als so genanntes Preplanning fungieren, mit der Absicht das reguläre →Sprint Planning so effizient wie möglich zu gestalten. Aufbau und Funktionsweise von Scrum 83 <?page no="84"?> 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, Trans‐ parenz für die erledigte Arbeit herzustellen und so allen beteiligten Stakeholdern die Option zu geben selbst der Scrum-Theorie des Empirismus nachzukommen. Die Transparenz wird über die →Artefakte hergestellt. Dabei hat entweder 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, und so ist es im Scrum-Guide beschrieben, ein Commitment in dessen Bezug eine Möglichkeit zu Challenges des jeweiligen Artefakts hergestellt wird. Aber zurück zur eigentlichen Frage; welche Artefakte gibt es: ▸ das Product Backlog, ▸ das Sprint Backlog und ▸ das Inkrement, das nach einem Sprint herauskommt. Scrum? Frag doch einfach! 84 <?page no="85"?> Abb. 18 Was sind die zu den Artefakten entsprechenden Commitments? Das →Product Backlog hat das Product Goal als Commitment, das →Sprint Backlog hat das Sprint Goal als Commitment und das →In‐ krement hat das Definition of Done als Commitment. Artefakt Commitment Product Backlog Product Goal Sprint Backlog Sprint Goal Inkrement Definition of Done Aufbau und Funktionsweise von Scrum 85 <?page no="86"?> Zu verstehen ist dieser Zusammenhang wir folgt. Im Beispiel aus der letzten Zeile; erst wenn das Inkrement alle Elemente von 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 Owner 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öhe‐ ren Value zuzuschreiben, gilt als höchste Anforderung an die Aufgabe des →Product Owner und somit auch an das →Product Backlog. Das Scrum? Frag doch einfach! 86 <?page no="87"?> Product Backlog ist die einzige Quelle der Arbeit für das Scrum-Team. Alles, was das 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 dieses Product Backlog-Element der so genannten und nicht in Scrum beschriebenen aber in der Praxis oft verwendeten „Definition of ready“. Sind diese Product Backlog-Ele‐ mente 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 Do‐ kument, welches in der Theorie niemals enden würde, solange das Produkt am Markt aktiv ist. Hierbei sind die Begriffe Produkt und Markt durchaus unterschiedlich zu definieren: So könnte sowohl von einem Softwareprodukt in dem klassischen Usermarkt die Rede sein als auch von einem Prozess innerhalb der Organisation. Auch in diesem Fall könnte 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 hierbei nicht auf das Gesamtprodukt bezogen, sondern lediglich auf den nächsten Sprint. Aufbau und Funktionsweise von Scrum 87 <?page no="88"?> Abb. 20 Das →Sprint Backlog beinhaltet sowohl das Warum - also das Sprint-Ziel bzw. →Sprint Goal - als auch das Was - also welche Product Backlog-Elemente im Sprint Planning herangezogen wurden - und letztlich auch das Wie - also die Art und Weise der Umsetzung der Elemente. Scrum? Frag doch einfach! 88 <?page no="89"?> Das erinnert an die drei Fragen ▸ Warum, ▸ Was und ▸ Wie. Dieses Thema 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 dabei ist, dass das Sprint Backlog jeden Tag aktualisiert wird. Arbeitet man nun mit einer Software wie Jira oder Trello, so ist dieser Plan auch jeder Zeit aktuell und für jeden sichtbar. Er kann dadurch auch von den Stakeholdern des Projekts angeschaut werden. Dieses Instrument besitzt demnach während der gesamten Arbeit im Sprint die Funktion der Transparenz. Dieses Artefakt bringt alle Beteiligten auf den aktuellen Stand der Dinge ist. Mit Hilfe des Sprint Backlog werden aufwändige Konferenzen im klassischen Projektmanagement obsolet. Durch Scrum spart man sich Bericht-, Statusmeetings und Lenkungsausschusssitzungen - zumin‐ dest im idealtypischen Ablauf. In der Realität reichen diese Mechanismen leider nicht immer aus, so dass es dennoch vorkommt, dass Entwickler und auch andere Scrum-Teammitglieder 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 erscheint häufig hilfreich, da man auf diese Weise den aktuellen Fortschritt erkennen kann. Bei dieser Vorgehensweise entsteht allerdings ein höherer Pfle‐ Aufbau und Funktionsweise von Scrum 89 <?page no="90"?> geaufwand, da man nicht nur das automatisierte Board pflegt, sondern auch das physische Board im Raum. Durch Coronasituation und der damit verbundenen virtuellen Arbeits‐ weise der Scrum-Beteiligten scheint das physische Board langsam aus‐ zusterben. Schließlich arbeiten die meisten inzwischen im Homeoffice. Wer ist für das Sprint Backlog verantwortlich? Die Verantwortlichen für das Sprit Backlog sind die Entwickler. Sie zeichnen sich für seine Umsetzung verantwortlich. Sie wählen Struktur und Methode des Sprint Backlog. Allerdings dürfen →Product Owner und →Scrum Master hier eine beratende Funktion einnehmen. Der Scrum Master kann dabei aus me‐ thodischer Sicht in der Regel mehr als es der Product Owner beitragen. Was ist ein Inkrement? Das dritte Artefakt, von dem die Sprache innerhalb der Scrum-Theorie ist, ist das Inkrement. Ein Inkrement ist dem Grunde nach eine neue Produktversion bzw. eine Weiterentwicklung. Es ist damit ein Teil des Gesamtprodukts. Scrum? Frag doch einfach! 90 <?page no="91"?> Abb. 21 Das Inkrement stellt demnach einen weiteren Schritt hin zum Produkt‐ ziel dar. Jedes Inkrement ist passgenau zu den vorherigen Inkrementen. Es ist als additive Weiterentwicklung zu sehen. Bevor das Inkrement zu den 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 jeden 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. Dies hat Trans‐ parenz des aktuellen Stands des Projekts für die Stakeholder zurfolge. Aufbau und Funktionsweise von Scrum 91 <?page no="92"?> Die Arbeit bzw. das Inkrement ist nur dann als fertig bzw. erledigt anzusehen, wenn die sogenannte Definition of Done erreicht wurde. Ist Definition of Done nicht vollständig erfüllt, kann das Inkrement nicht ausgeliefert werden und auch nicht im Sprint Review betrachtet werden, sondern es wird zurückgestellt und im nächsten Sprint voll‐ endet 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 gibt. Es ist deshalb nicht unbedingt notwendig jeden Sprintinkrement an den Kunden zu übergeben, sondern nur dann, wenn es für ihn Sinn macht. Lesetipp: Magazin; https: / / www.agile-heroes.de/ magazine/ scrum-inkremen t/ Was ist ein Commitment? Ein Commitment ist ein metaphorisch geschriebener Handschlag, eine Vereinbarung über die zu liefernden Artefakte, welche wir bereits kennengelernt haben. Es soll zum einen eine Hilfe sein, zum ande‐ ren aber auch eine Motivation 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. Und um zu überprüfen, dass die Artefakte stimmen, müssen diese transparent dargelegt und anhand der Commitments überprüft wer‐ den. 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 Scrum? Frag doch einfach! 92 <?page no="93"?> und zu vereinfachen. Es hilft aber auch dem Product Owner dabei die richtige Priorisierung innerhalb des Product Backlogs zu finden, um möglich schnell und effizient das Produktziel zu erreichen. Abb. 22 Das Produktziel wird als langfristiges Ziel beschrieben, kann sich je‐ doch im Laufe der Entwicklungszeit verändern. Die Verantwortung des Produktziels liegt bei dem Product Owner, er kann die Produktzielver‐ änderung anhand der neuen Interessen der Stakeholder durchführen und darf das Scrum-Team, die Entwickler, dann darüber informieren. Die Definition eines Produktziels ist seit November 2020 im neuen Scrum-Guide hinterlegt und entspricht, meiner Meinung nach, bereits gängiger Praxis. Es ist selbstverständlich, dass man für sein Produkt, das man inkrementell weiterentwickeln möchte, eine langfristige Pla‐ nung, ein langfristiges Ziel benötigt, um das Team zu motivieren. Das ist die Voraussetzung, um ein Commitment seitens des Teams auf die Produktentwicklung, zu schaffen. Aus diesem Grund ist das Produktziel das Commitment des Product Backlogs, anhand dessen bewertet werden kann. Aufbau und Funktionsweise von Scrum 93 <?page no="94"?> Welche Tools finden in Scrum Anwendung? Grundsätzlich sind die Tools in Scrum vor allem in Remote-Zeiten nochmal deutlich diverser geworden. Davor gab es im Grunde nur Jira und Confluence, welche neben den gängigen Office Tools genutzt wurden. Inzwischen wurden neben einem guten Videokonferenztool vor allem Miro und Scrumpanion eingesetzt. Damit haben wir nun diese vier Tools: ▸ Jira ▸ Confluence ▸ Miro ▸ Scrumpanion Was macht Jira im Hinblick auf die Nützlichkeit der Scrum-Anwendung aus? Bei Jira handelt es sich um ein Tool von der australischen Soft‐ ware-Firma Atlassian. Seit seiner Gründung im Jahr 2002 hat das Unternehmen mittlerweile über 89.000 Kunden und dazu Niederlassun‐ gen in mehr als fünf Ländern. Die Produkte von Atlassian richten sich dabei im Grunde alle an Teams und Projektmanager - so auch Jira. Seinen Namen hat das Tool dem japanischen Wort „Gojira“ zu ver‐ danken, was sich grob mit „Godzilla“, also „Monster“ übersetzen lässt. Das ist tatsächlich eine sehr passende Übersetzung, denn Jira ist ein wahres Software-„Monster“ mit vielen verschiedenen Funktionen und Facetten. Für Projektmanger und -managerinnen ist das Tool auf jeden Fall eine große Unterstützung. Jira lässt sich in drei verschiedene Produkte bzw. Varianten unter‐ teilen. Jedes dieser Produkte richtet sich an eine andere Ziel- und Aufgabengruppe: ▸ Jira Core ▸ Jira Software ▸ Jira Service Mithilfe von Jira Core lassen sich im Kern ganz einfach Projekte und Teams organisieren, Abläufe darstellen und Aufgaben verteilen. Scrum? Frag doch einfach! 94 <?page no="95"?> Gleichzeitig behält man alle Vorgänge im Auge, da sie transparent für alle sichtbar sind. Das ist gleichzeitig 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 hervor‐ ragend 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 Anwenderinnen und Anwender ganz ein‐ fach Sprints erstellen, Backlogs pflegen und planen. Ursprünglich war Jira Software eigentlich für die Softwareentwicklungsbranche geplant, doch das Programm kann ohne Probleme in allen Branchen genutzt werden. Die dritte Jira Variante nennt sich Jira Service Desk. Diese Variante ist ein Service-Management-Tool, das mithilfe eines Ticket-Systems Aufgaben in Form von „Tickets“ an die zuständigen Mitarbeiterinnen und Mitarbeiter weiterleitet. Zusammenfassend kann man sagen: Jira ist ein sehr umfangreiches Tool ▸ für Projektmanager, ▸ für Aufgabenverwaltung, ▸ Dokumenation und ▸ Service-Management. Es fördert die Flexibilität und Transparenz innerhalb von Unterneh‐ men, Teams und Projekten. Zusätzlich lässt sich Jira mithilfe von zahlreichen Plugins anpassen und erweitern, so sehr man das wünscht. Allerding ist Jira auch nicht ganz unkompliziert. Um die Software in ihrer Bestform zu verwenden, braucht 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 und die Vorteile daraus zu nutzen. Videotipp: Mehr Infos zu Jira habe ich in diesem Video zusammengefasst ► https: / / youtu.be/ 487XyapqhDo Aufbau und Funktionsweise von Scrum 95 <?page no="96"?> Was macht Confluence im Hinblick auf die Nützlichkeit der Scrum-Anwendung aus? Confluence ist ein so genanntes Enterprise-Wiki-Unternehmen und dient Teams als Plattform für den Wissensaustausch, für einfache Kommunikationswege, für Projektzusammenarbeit und zur Dokumen‐ tation. Genau wie Jira stammt Confluence aus der Feder der australi‐ schen Firma Atlassian und sammelt allein dadurch bereits Pluspunkte bei Jira-Liebhabern. Confluence kommt aus den Atlassian Reihen und lobt 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 mit der Software und sollen auch technisch „unbegabteren“ Mitarbeiterinnen und Mitarbeitern nicht zu schwerfallen. Das letzte Update des Tools, das erstmals 2014 erschienen ist, hat 2021 stattgefunden. Als „Unternehmens-Wiki“ dient Confluence in erster Linie als Wis‐ sensdatenbank. Vor allem in Bereichen mit häufigem Kundenkontakt ist es wichtig, dass Mitarbeiterinnen und Mitarbeiter auf einem Wis‐ sensstand sind und nicht unterschiedliche Informationen nach außen tragen. Für eine einfache Bedienung und schnelle Orientierung ver‐ spricht Confluence simple Such- und Filtermöglichkeiten, um schnell und gezielt an Unternehmensinformationen zu gelangen. Diese Informationsseiten können von Usern erstellt und bearbeitet werden. Zusätzlich können sie andere Dokumentationen und Produk‐ tanforderungen selbst erstellen und anderen Teammitgliedern ganz einfach zur Verfügung stellen. Auch Vorlagen stellt Confluence seinen Nutzerinnen und Nutzern zur Verfügung. Nicht zuletzt deswegen wird Confluence auch gerne als eine Art Cloud-Service bezeichnet. Hinzu kommt die Bearbeitungsmöglichkeit von Dokumenten: Meh‐ rere Mitarbeiter können somit gleichzeitig an einem Projekt arbeiten und Seiten bearbeiten. Ein persönlicher Feed gibt jedem Mitarbeiter und jeder Mitarbeiterin einen Überblick zu ihrem Arbeitsstand. In Chats können die Teams untereinander kommunizieren und sich zu Infos und anderen Neuigkeiten austauschen. Scrum? Frag doch einfach! 96 <?page no="97"?> Wie funktioniert Confluence und was sind die Vorteile dieser Anwendung? Teammitglieder können ihr persönliches Dashboard selbstständig ge‐ stalten. Sie sehen ihre und andere Aufgaben, erhalten Benachrichtigun‐ gen und Nachrichten. Das Dashboard lässt sich in fünf Bereiche aufteilen. Auf der linken Seite befinden sich die so genannten Seiten der Plattform. Hier sehen Nutzerinnen und Nutzer alle Seiten, für die sie das Recht zu Lesen 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 las‐ sen sich ganz einfach Projektpläne, Listen, Informationsseiten und vieles mehr erstellen und mit allen oder nur bestimmten Kollegen und Kolleginnen 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 Business-Welt 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 Beteiligten ganz einfach gefunden und auch nachvollzogen werden. Bei Confluence ist im Kern alles für alle sichtbar! Für viele bedeu‐ tet das womöglich erst eine Umgewöhnung. (Aber keine Angst, mit Zugriffsrechten lässt sich nach wie vor kontrollieren, wer etwas sehen darf) Speziell unter Flächen wie „All Updates“ erfährt man theoretisch von allem, 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. Aufbau und Funktionsweise von Scrum 97 <?page no="98"?> Grundsätzlich schafft es Confluence, alle wichtigen Bereiche, die für eine reibungslose Zusammenarbeit notwendig sind an einem Platz zu bringen. Anstatt viele unterschiedliche Programme und Tools für einzelne Funktionen zu verwenden, können Teams das nun alles an einem Ort machen. Vor allem remote 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. Für Teams, die sich ein Büro teilen, aber vor allem auch für die, die sich hauptsä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 Anwenderinnen und Anwendern die Arbeit; schreckt aber auch manche anderen ab. Besonders für Kolleginnen und 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. Zusammenfassen kann man sagen: Seit vielen Jahren bewährt sich Atlassians Confluence bereits am Markt und konnte viele große Kun‐ den für sich gewinnen. Auch die Umstände spielen Confluence zu: Immer mehr Teams finden sich im Homeoffice wieder. Dort sorgt das Enterprise-Wiki für Organisation, Kommunikation und vor allem Wissensaustausch. Ganz im Sinne der Agilität ist genau das wichtig, um sein Unternehmen voranzubringen. Obwohl es bereits zahlreiche andere Tools gibt, die ähnliches ver‐ sprechen, kann Confluence damit überzeugen, dass es einen Großteil deines (in vielen Fällen wohl deinen gesamten) Arbeitsplatzes an Scrum? Frag doch einfach! 98 <?page no="99"?> einen Ort bringt. Und du deine Arbeit von dort auch noch mit all deinen Kolleginnen und Kollegen teilen kannst. Für uns definitiv einen Versuch wert! Videotipp: Mehr Infos zu Confluence habe ich in diesem Video zusammenge‐ fasst ► https: / / youtu.be/ iK5zW_vacGk Was macht Miro im Hinblick auf die Nützlichkeit der Scrum-Anwendung aus? 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 „digi‐ talen Whiteboard“ zu vereinen, obwohl sie alle an unterschiedlichen Orten vor ihrem Computer sitzen. Mit zahlreichen Gestaltungsmög‐ lichkeiten lässt sich Miro zum Präsentieren von Informationen, aber auch zum Zusammenarbeiten und beispielsweise Erstellen von Mind Maps, nutzen. Dabei 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 Möglichkeit auf das Board zuzugreifen und zeitgleich daran zu arbeiten. Das Tool wird hauptsächlich im Business-Bereich verwendet und bietet seinen Nutzerinnen und 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 das zu tun und seine Gedanken bestmög‐ lich darzustellen. Aufbau und Funktionsweise von Scrum 99 <?page no="100"?> Textflächen, Post-Its, Pfeile, Zeichnungen, Kommentare zählen dabei zu den wichtigsten und beliebtesten Werkzeugen unter ihnen. Daneben gibt es außerdem noch viele Vorlagen, die man für Workshops, Mind‐ maps, Sprint Retrospektiven etc. nutzen kann. Dabei wird klar: Miro ist ein großer Unterstützer von agilem Arbeiten. Doch durch die vielen Funktionen lässt sich mit etwas Übung und Geschick wohl alles visuell darstellen. Auf dem Dashboard können Nutzerinnen und Nutzer auf ihre eige‐ nen und auf die Boards, die mit ihnen geteilt wurden, zugreifen. Dabei ist die Anzahl der Board uns 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. Um anderen etwas zu präsentieren oder eine Gruppe von Personen den Raum bieten, gemeinsam zu brainstormen: Grenzen gibt es kaum auf dem digitalen Whiteboard. Egal ob es die Mind Map, 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 anbringen und im Team daran arbeiten. Miro ist Übungssache Um wirklich gut damit umzugehen und die einzelnen Gestaltungs‐ werkzeuge zu meistern, erfordert das Tool ein wenig Übung und Geschick. Vor allem wenn gleich mehrere Personen in einem Board arbeiten, sorgt das für oft für verwirrte Gesichter. Ist eine Textblase oder andere Elemente nicht an seinem Platz fixiert, kann es schon mal schnell passieren, dass das Objekt versehentlich wegen dem Versuch, zu scrollen 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-Fak‐ tor. Die Möglichkeit in Gruppen zusammenzuarbeiten und das über Distanz hinweg ist heutzutage in den meisten Team gefragt. Bereits Scrum? Frag doch einfach! 100 <?page no="101"?> 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 am Zahn der Zeit bleiben möchten. Und die, 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 Eddingstifte ausprobieren, bis man einen funktionierenden findet! Wir empfehlen das Tool vor allem agilen Teams. Hier kommt es bei Teams beispielsweise bei einer Sprint Retrospektive zum Einsatz. Gerade hier werden oft Übungen veranstaltet für die Post-Its und Whiteboards verwendet werden. Eine solche Retrospektive remote abzuhalten, ist für viele Teams eine Herausforderung. Doch mit Hilfe 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 habe ich in diesem Video zusammengefasst ► https: / / youtu.be/ fqkAkV5eI58 Was macht Scrumpanion im Hinblick auf die Nützlichkeit der Scrum-Anwendung aus? Ein sehr hilfreiches und meiner Meinung nach immer bekannter werdendes Scrum-Tool möchte ich euch im Folgenden kurz darstellen: die App Scrumpanion. Hierbei handelt es sich um eine schlanke und intuitiv zu bedienende Applikation, die ich vor allem für das Schätzen von User Stories in den Refinement Meetings gerne nutze. Das Tool kann sowohl über eine App für mobile Endgeräte sowie über eine Browser-Version 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 Aufbau und Funktionsweise von Scrum 101 <?page no="102"?> 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. Was für mich persönlich ein entscheidender Aspekt ist, ist die Tatsache, dass wir hier kein Milliarden Unternehmen wie die Hersteller von Jira vorzuzeigen haben, sondern ein hervorragendes deutsches Startup. Diese wurde von einer kleinen Softwareentwicklungsfirma (www.be skgroup.com) in Süddeutschland entwickelt, und das sozusagen aus ei‐ ner eigenen Not heraus. Da die Entwickler der Firma auf verschiedenen Kontinenten verteilt arbeiten, gestaltete sich das Schätzen in den Refi‐ nement Meetings immer ein wenig kompliziert über Chat-Programme und mit Herunterzählen, so dass alle Teammitglieder gleichzeitig ihre Schätzung übermitteln. Wer schon remote Refinement Meetings durch‐ geführt hat, weiß wovon ich spreche. Also hat diese Scrum-begeisterte Firma angefangen 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 ich nutze die App auch gerne, wenn wir alle in einem Raum zusammensit‐ zen, so entfällt die ewige 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 untenstehenden Link Scrumpanion ProPlus, für vier Monate kostenfrei testen. Einfach den QR Code scannen und deinen Code aktivieren. Scrum? Frag doch einfach! 102 <?page no="103"?> Die Praxisumsetzung von Scrum In diesem Kapitel erfahren Sie, welche Aspekte bei der Umsetzung von Scrum in die Praxis relevant sind und wo es Grenzen der Umsetzung geben kann. <?page no="105"?> Kann Scrum auch teilweise in der Praxis umgesetzt werden? 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 arbeite ich mit meinem Team jedoch nicht „militant“. Im Gegenteil. Eher „agil-liberal“. In Anbetracht dessen, ist das auch mein größter Kritikpunkt am Scrum-Konzept. Scrum ist meines Erachtens zu radikal. Damit auch etwas widersprüchlich. Was meine ich damit? Es ist der Scum Guide, der gerne sagt: 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 Selbstma‐ nagement an den Punkt, wo es zu sagen pflegen würde: „Lass uns an dieser Stelle von Scrum abweichen, um den Produkterfolg zu maximieren,“ so greift der Scrum-Guide an dieser Stelle ein und verbietet es. Das hat etwas von orthodoxer Religion, ja fast möchte ich sagen, von Sektentum. Ich distanziere mich ganz klar von diesen Vorgaben in der Praxis. Mit meinem Team bei den Agile Heroes, erklären wir in jedem Pitch, dass wir alles für ein erfolgreiches Projekt tun. Und obwohl wir „Agile“ im Unternehmensnamen 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.“ Die Praxisumsetzung von Scrum 105 <?page no="106"?> Abb. 23 Damit erhalten wir oft auf der Theorieebene von aggressiven „Agilis‐ ten“ viel Kritik, aber von Praktikern, von unseren Kunden viel Lob. Nicht jede Organisation, nicht jedes Projekt oder Produkt ist nun mal zu 100 Prozent für Scrum bzw. zur 100 Prozent für Agilität geeignet. Hat man das verinnerlicht, so kann man mit viel weniger Druck gute Ergebnisse erzielen. Was ist ein Sprint Goal? Das Sprint Goal und das Sprint-Ziel ist, und das mag vielleicht überra‐ schend klingen, das einzige Ziel für den Sprint, obwohl das Sprint-Ziel dadurch ein Commitment, eine Verpflichtung der Entwickler auf die Erreichung der Sprintergebnisse bietet, kann es flexibel, hinsichtlich der Umsetzung, betrachtet werden. Scrum? Frag doch einfach! 106 <?page no="107"?> Abb. 24 Das Sprint-Ziel gliedert dabei das „Wie“ aus. Es wird während des Sprint Plannings erstellt und wird dann dem Sprint Backlog hinzuge‐ fü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, kom‐ men wir so unserem Ziel näher oder nicht. Bemerken sie innerhalb des Sprints, dass sich ihre Arbeit doch in eine andere Richtung entwickelt, haben sie die Möglichkeit, mit dem Product Owner den Umfang des de‐ finierten Sprint Backlogs so zu verhandeln, dass es das Sprint-Ziel nicht gefährdet. Hiermit sind meistens optionale Sprint-To-Do’s 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 abzubrechen. Nämlich dann, wenn das Sprint-Ziel obsolet wurde. Wenn das Sprint-Ziel obsolet ist, hat der Product Owner das Recht den Sprint abzubrechen und nur dann, wenn das Sprint-Ziel überflüssig wurde. Die Praxisumsetzung von Scrum 107 <?page no="108"?> Was ist eine Definition of Done? Eine Definition of Done ist im Grunde ein Commitment hinsichtlich des Inkrements. Würden wir hier in derselben Logik entlang des Scrum-Guides bleiben, könnte man auch 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 Qualitätskriterien, welche erfüllt werden müssen. Beispiele könnten Scrum? Frag doch einfach! 108 <?page no="109"?> hierbei sein, 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 Backlogitem nicht der Definition of Done entspricht, muss es zurück zum Product Backlog und in zukünftigen Sprints berücksichtigt werden. Häufig passiert es, dass es innerhalb der Organisation bereits Stan‐ dardqualitätsanforderungen gibt, diese gelten insoweit, als dass sich das Scrum-Team mindestens daranhalten muss. Es kann noch eigene Standards herbeiführen, um ihre Definition of Done zu erweitern. Aber in einer Organisation, in welcher eine Definition of Done besteht, muss sich 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 ist nicht im Scrum-Guide nicht ist, jedoch in der Praxis absolut gängig und konsequent. Die Definition of Ready beschreibt, wann ein Product Backlogitem Ready to Sprint, ist. Die Praxisumsetzung von Scrum 109 <?page no="110"?> Abb. 26 Es signalisiert, wann ein Product Backlogitem 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 Backlogitem 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 es 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 Backlogitem beschrieben werden, damit dieses bereit zur Sprintumsetzung wäre. Scrum? Frag doch einfach! 110 <?page no="111"?> 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 ge‐ hen. Diese Grenzen müssen auch seitens des Agilitätsbeauftragten, des Scrum Masters, der Agile Coaches oder den Beratern stets aufgezeigt werden. Abb. 27 Gibt es dafür ein Beispiel? Ja, gehen wir in die Stadtplanung: Wir bauen eine Reihenhaus Siedlung. 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 Wprtes - in Stein gemeißelt. Welche Vorteile für das Produkte hätte man also, nach Sprint-Rhythmen zu arbeiten, Feedback vom Kunden einzuholen Die Praxisumsetzung von Scrum 111 <?page no="112"?> 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 klassisches, 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 vor‐ herrscht. Unklarheit, über das eigentliche Endprodukt. Ist das Produktthema Scrum-fähig, fehlt lediglich noch die Bereitschaft der Organisation Scrum zu nutzen. Hier sind weitaus mehr, deutlich komplexere Voraussetzungen notwendig, um mit Scrum zu arbei‐ ten. Bleiben wir zunächst auf der Produktseite. Damit Scrum in der Produktentwicklung den vollen Umfang an Mehrwert liefern kann, sollte eine große Unsicherheit hinsichtlich der vom Kunden ge‐ wollten Anforderungen vorliegen. Jetzt könnte man sehr einfach sagen „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 Mut‐ termal 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. Scrum? Frag doch einfach! 112 <?page no="113"?> Wir könnten aber auch alternativ ein einfaches MVP entwickeln. Dies könnte innerhalb von zwei Tagen ohne Programmierkennt‐ nisse erfolgen. Unter einem MVP versteht man ein minimal varia‐ bles Produkt, das nur die Kernfunktionalität beinhaltet und so als Produkt-Start Inkrement bei einem neuen Produkt-Launch gilt. Dieses MVP wurde von mir in dem MeetUp präsentiert: Jeder konnte sein Muttermal scannen lassen. Das Feedback dieser Men‐ schen war ungleich mehr wert als die Ergebnisse einer tausendfa‐ chen Befragung. Warum? Weil sie es getestet und erlebt haben. Ein MVP sagt mehr als 1.000 Worte, könnte man hier sagen. Für eine Weiterentwicklung dieser Beispiels-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 Software-Entwicklungserfahrung innerhalb von zwei Tagen entwickeln konnte. Die Antwort ist sehr einfach: Fake it, until you make it. Die von mir dargestellte App, war natürlich keine App und hatte auch keine Big Data basierte Künstliche Intel‐ ligenz, 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 ich für den Anfang noch selbst bedient hatte, ein Foto hochladen. Dieses Foto wäre dann nicht von der KI, sondern von einem Hautarzt untersucht worden. Mit diesem einfachen Hack hätte ich im Zweifel tausende User, über Nacht über Online-Werbung auf das Produkt kommen lassen können. Sie hätten die App benutzt und hätte auch valide Auskunft erhalten. Und als Kuppelprodukt hätten wir ausreichend Feedback für die App erhalten. Aber alles eben mit manuellem Aufwand. Warum? Weil es innerhalb von zwei Tagen MVP-fähig wäre hohe Kosten eingespart hätte. Die Praxisumsetzung von Scrum 113 <?page no="114"?> Lesetipp: 8 Gründe für den Erfolg von Scrum; https: / / www.agile-heroes.de/ ma gazine/ erfolg-von-scrum/ Wie kommt man an die richtigen Mitarbeiter für Scrum-Projekte? Möchte man jetzt in seinem Unternehmen Scrum einsetzen, hat die Produkttauglichkeit bereits bewiesen, fehlt tatsächlich nur noch das Team. Hier kommen die typischen Change-Management-Me‐ thoden 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 Blockie‐ rer 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 Management-Positionen zu haben. Hier gilt es mit hoher Empathie die Angst von „ich verliere meine Macht, meine Position, mein Job“ zu nehmen und diesen 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 hier nur kurz umrissen. Scrum? Frag doch einfach! 114 <?page no="115"?> Anerkennung des Scrum-Know-hows In diesem Kapitel erfahren Sie, wie Scrum-Kenntnisse erworben werden können und welche Akzeptanz sie in der Praxis haben. <?page no="117"?> 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 hingegen als Begrifflichkeit und als Methode nicht. Daher ist der Markt der Scrum-Zertifizierungen deutlich diverser. Dennoch haben sich über die Jahre drei relevante Zertifizierungsinstitute herauskris‐ tallisiert. 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 eines der Scrum-Gründer: Ken Schwaber. Es genießt dadurch ein hohes Ver‐ trauen in der Welt der Agilität. Die Prüfungen sind sehr anspruchsvoll und bieten das Potenzial zum Durchfallen, ohne ausreichende Vorberei‐ tung. Mit meiner Firma 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 AND INNOVATION hat sich als Meta-Institut für Agile Methoden zu einem Generalisten unter den Zertifizierungsinstituten entwickelt. Hier findet man neben der Scrum-Zertifizierung auch Zertifizierungen für Design Thinking, OKR, Agile Coach oder Kanban. Das IFAAI bietet durch die PlayBook-Down‐ load-Funktion eine gute Möglichkeit sich selbstständig auf die Prüfun‐ gen vorzubereiten und mit geringeren Aufwand eine hochwertige Zertifizierung zu erlangen. Anerkennung des Scrum-Know-hows 117 <?page no="118"?> Scrum Alliance: Die Scrum Alliance hat sich als Netzwerk von Scrum-Experten über die Jahre zu einem ernstzunehmenden Zertifizierungsinstitut entwickelt. Zu beachten ist jedoch, dass man zum einen einen offiziellen Scrum Alliance-Kurs besuchen muss, um die Prüfung abzulegen 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 doch das Risiko, dass die Zertifikate am Markt anders interpretiert werden könnten. Welche Zertifizierungen gibt es? Genauso divers, wie der Markt der Anbieter ist, so divers sind die Zertifikate an sich. Orientiert man sich jedoch an den drei er‐ wä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 Folgenden sind die offiziellen Namen der Zertifzierungen, je nach Institute gegliedert. Scrum.org: Scrum Master: • Professionale Scrum Master Level 1 (PSM1): Das Ein‐ stiegslevel, für Neulinge. • Professional Scrum Master Level 2 (PSM2): Das Fortge‐ schrittenen Level für Scrum Master mit Erfahrung. • Professional Scrum Master Level 3 (PSM3): Das Level für echte Scrum Experten. Scrum? Frag doch einfach! 118 <?page no="119"?> 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. IFAAI: Scrum Master • Accredited Scrum Master Level 1 (ASM1): Das Einstiegs‐ level 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 Ein‐ stiegslevel für Product Owner • Accredited Product Owner Level 2 (ASPO2): Die Prüfung für erfahrene Product Owner Scrum Alliance: Scrum Master: • Certified Scrum Master: Das Einstiegslevel • Advanced Certified Scrum Master: Das fortgeschrittennen Level • Certified Scrum Professional - ScrumMaster Das Profi Level Product Owner: • Certified Scrum Product Owner: Das Einstiegslevel • Advanced Scrum Product Owner: Das fortgeschrittenen Level • Certified Scrum Professional - Product Owner: Das Profi Level Anerkennung des Scrum-Know-hows 119 <?page no="120"?> Wie kann ich mich auf die Zertifizierung vorbereiten? Auf diese Frage gibt es zwei Antworten. Diese unterscheiden sich, zwischen dem zeitlichen und monetären Aufwand und dem inhaltlichen Umfang. ▸ Mit diesem Buch und der folgenden Musterprüfung: ▸ Grundsätzlich reicht dieses Buch aus, um mit der folgenden Musterprüfung, die Fragen von IFAAI richtig zu beantwor‐ ten und auf diesem Weg, die Prüfung und Zertifizierung zu bestehen. Des Weiteren findest du bei IFAAI.org auch Prüfungssimulationen zur 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: ▸ Wie bereits erwähnt bin ich einer der Gründer der Agile Heroes GmbH. Wir haben 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 Zertifizierung zu bestehen. Dieser Weg kostet mehr, hat dementsprechend inhaltlich nochmal einiges mehr zu bieten, vor allem durch den aktiven Trainer Austausch. Habe ich als Leser dieses Buches einen Vorteil? Agile Heroes Trainingsrabatt: Mit dem Rabattgutschein „fragdochein‐ fach” erhält man 10 % Rabatt auf die Agile Heroes Scrum Weiterbildun‐ gen. Scrum? Frag doch einfach! 120 <?page no="121"?> Gehe hierzu einfach auf: www.agile-heroes.de/ Scrum oder scanne den folgenden QR-Code. IFAAI Zertifzierungsrabatt: Mit dem Gutschein Code „fragdochein‐ fach“ erhält man als Leser dieses Buches ein Rabatt-Gutschein in Höhe von 10% Gehe hierzu einfach auf www.ifaai.org/ Scrum oder scanne den folgenden QR Code Videotipp: Der Videokanal des Unternehmens Agile Heroes vermittelt einen guten Eindruck zum Weiterbildungsumfeld dort: ► www.youtube.com/ c/ AgileHeroes/ videos Anerkennung des Scrum-Know-hows 121 <?page no="122"?> Welche Fragen kommen in einer Scrum Muster-Prüfung auf mich zu? Die Scrum Master Muster Fragen, sind im selben Format wie bei IFAAI gestellt. Hierbei ist immer nur eine Antwort richtig. Die Lösungen findest du in Kapitel 4.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. 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 … Scrum? Frag doch einfach! 122 <?page no="123"?> 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… 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. Anerkennung des Scrum-Know-hows 123 <?page no="124"?> 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 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 manage‐ ment on the most important agile rules in project management. Scrum? Frag doch einfach! 124 <?page no="125"?> 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. 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. Anerkennung des Scrum-Know-hows 125 <?page no="126"?> C. is used by the development team to support its Manage tasks operationally. 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. 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. Scrum? Frag doch einfach! 126 <?page no="127"?> [25] The timing of the events in the SCRUM process is … A. Sprint Planning, Sprint, Daily SCRUM, Sprint Review, Sprint Retrospective. 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. 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. Anerkennung des Scrum-Know-hows 127 <?page no="128"?> 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. Scrum? Frag doch einfach! 128 <?page no="129"?> 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 Anerkennung des Scrum-Know-hows 129 <?page no="131"?> 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 Back‐ log und das Inkrement. Ziel der Artefakte ist, 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 erledigenden 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 erle‐ digenden Aufgaben in Relation zur Zeit. Burn-up Charts sind eine optionale Möglichkeit in Scrum, den Fortschritt transparent zu machen. Cumulative Flow Chart Cumulative Flow Charts zeigen den Fortschritt des noch zu schaffenden Auf-wands 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. <?page no="132"?> Daily Scrum Ein Event mit einer festgelegten Zeitdauer von maximal 15 Minuten. Es dient dem Entwicklungsteam dazu, den anstehenden Tag der Ent‐ wicklungsarbeit während eines Sprints zu planen. Änderungen und Aktualisierungen werden im Sprint Backlog eingetragen. Definition of Done zu Deutsch Definition von „Fertig“: Ein gemeinsames Verständnis über die Er-wartungen, 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 not-wendig ist, um in jedem Sprint ein auslieferungsfähiges Inkrement des Produk-tes zu erstellen. Emergence zu Deutsch Vorkommnis: Der Prozess der Entstehung oder des Be‐ kanntwerdens 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 Entschei‐ dungen auf Beobachtungen, Erfahrungen und Ausprobieren basieren. Empirie basiert auf drei Säulen: Transparenz, Überprüfung und Anpas‐ sung. Engineering standards zu Deutsch Entwicklungsstandards: Ein einheitliches Verständnis über Entwicklungs- und Technologiestandards, die vom Entwicklungsteam angewandt wer-den, um ein auslieferungsfähiges Inkrement der Soft‐ ware (oder des Produkts) zu erstellen. Glossar 132 <?page no="133"?> Forecast (of functionality) zu Deutsch Vorschau (auf Funktionalitäten): Die Auswahl von Backlog Items aus dem Product Backlog, die ein Entwicklungsteam dafür geeignet ansieht, dass sie in einem Sprint umgesetzt werden. Increment zu Deutsch Inkrement: Ein Teil einer funktionierenden Software, die zu einem bereits vorher entwickelten Inkrement hinzugefügt wird. Alle Inkremente 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, Kompetenzen und Verantwortung. Ready Zu Deutsch Bereit. Ein gemeinsames Verständnis des Product Owners und des Entwicklungsteams bezogen auf das erwartete Informations‐ level jedes Backlog Items. Das Ready wird im Rahmen des Sprint Plannings festgelegt. Glossar 133 <?page no="134"?> Scrum Ein Rahmenwerk, um Teams bei komplexen Produktentwicklungen zu unterstützen. Scrum besteht aus dem Scrum-Team und den dazu‐ gehörigen Rollen, Events, Artefakten und Regeln, so wie diese im Scrum-Guide beschrieben sind. Scrum-Guide Die Definition von Scrum, geschrieben und zur Verfügung gestellt von Ken Schwaber und Jeff Sutherland, den beiden Entwicklern beziehungsweise 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, beraten und zu schulen. Scrum-Team Ein sich selbst organisierendes Team, das aus dem Product Owner, Entwicklungsteam und dem Scrum Master besteht. Scrum Values zu Deutsch Scrum-Werte: Die grundlegenden fünf Values und Fähig‐ keiten, die das Scrum Framework ermöglichen. Die Values sind Selbst‐ verpflichtung, Fokus, Offenheit, Respekt und Mut. Self-Organization zu Deutsch Selbstorganisation: Managementprinzip, das davon aus‐ geht, dass Teams ihre Arbeit autonom und selbst organisieren. Diese Selbstorganisation erfolgt innerhalb festgelegter Grenzen auf der Basis von klar vorgegebene Rollen. Die Teams entscheiden selbst, wie sie ihre Arbeit ausführen, anstatt von jemand außerhalb des Teams angeleitet zu werden. Glossar 134 <?page no="135"?> 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 Funktionalität zu entwickeln. Das Sprint Backlog wird vom Entwicklungsteam 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 über-prü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 wer-den. 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, die Entwicklungsarbeit des Entwicklungsteams ab‐ Glossar 135 <?page no="136"?> zuschließ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 Indikation dafür, wieviel Backlog Items des Product Backlogs durch das Scrum-Team während eines Sprints in ein Inkrement des Produkts überführt wurden. Es wird vom Entwicklungsteam für das gesamte Scrum-Team getrackt. Glossar 136 <?page no="137"?> Register Adaption 40, 80 Amazon 24 Apple 24 Artefakte 84 Burn-Down-Chart 66 Coaching 42 Commitment 59, 85, 92 Confidence-Vote 59 Container 63 Cynefin 32 Daily Scrum 71 Definition of Done 43 Definition of Ready 109 Entwicklungsteam 52 Events 60 Facebook 24 Flixbus 24 Fokus 59 Framework 39 Freenow 24 Google 24 Homeoffice 90 Inkrement 90 Inkrementen 43 Inspection 40, 80 Jeff Sutherland 20 Jira 89 Ken Schwager 20 Kunde 28 Kundenwert 91 Lenkungsausschusssitzung 89 Motivation 107 Mut 59 MyTaxi 24 N26 24 Offenheit 60 Paintpoints 79 Preplanning 83 PRINCE2 32 Product Goal (Produktziel) 92 Product Owner 42 Produktvalue 49 Produktziel 91 Projektbudget 57 Projektmanagement 29 Projektmanager 57 Refinement 81, 83 Respekt 60 Ressourcenplanung 57 Retrospektive 80 Scrum-Guide 39 Scrum Master 42, 83 Scrum Meetings 62 Scrum-Theorie 61 Selbstverpflichtung 59 Sprint 63, 65 Sprint Backlog 87 Sprint Goal 106 Sprint Planning 83 Sprint Retrospektive 77 Sprint Review 74 Stakeholder 74 Subject-Matters-Experts 53 Team 114 Tesla 28 Transformation 58 <?page no="138"?> Transparency 40, 80 Transparenz 80, 89 Trello 89 Wertschätzung 77 Zertifizierungen 117 Zusammenarbeit 79 Register 138 <?page no="139"?> ,! 7ID8C5-cffcca! ISBN 978-3-8252-5522-0 Fabian Kaiser Arie van Bennekum Scrum? Klare Antworten aus erster Hand 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 diesem 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? 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-shop.de QR-Code für mehr Infos und Bewertungen zu diesem Titel Frag doch einfach! 55220 Kaiser_M-5522.indd 1 55220 Kaiser_M-5522.indd 1 06.08.21 10: 44 06.08.21 10: 44