<?page no="1"?> Roman Simschek, Fabian Kaiser SCRUM Das Erfolgsphänomen einfach erklärt <?page no="3"?> Roman Simschek Fabian Kaiser SCRUM Das Erfolgsphänomen einfach erklärt UVK Verlagsgesellschaft mbH · Konstanz und München <?page no="4"?> Roman Simschek und Fabian Kaiser sind die Gründer und Inhaber der )(+,#-", einer der führenden Beratungen zum Thema Projektmanagement. Sie beraten in Deutschland, Österreich und der Schweiz namhafte Unternehmen und helfen ihnen dabei, $hre Projekte erfolgreich zu managen. www..(+,#-".de Text: ©2018 Scrum.Org. http: / / scrumguide.org. Dieser Text ist lizensiert unter der Creative Commons Namensnennung. Weitergabe unter gleichen Bedingungen 4.0 International Lizenz, die unter http: / / creativecommons.org/ licenses/ by-sa/ 4.0/ legalcode zu finden ist. Bibliografische Information der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über <http: / / dnb.ddb.de> abrufbar. 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. ISBN 978-3-86764-855-4 (Print) ISBN 978-3-7398-0426-2 (E-PUB) ISBN 978-3-7398-0427-9 (E-PDF) © UVK Verlagsgesellschaft mbH, Konstanz und München 2018 Einbandgestaltung: Susanne Fuellhaas, Konstanz Printed in Germany UVK Verlagsgesellschaft mbH Schützenstr. 24 · 78462 Konstanz Tel. 07531/ 9053-0 · Fax 07531/ 9053-98 www.uvk.de <?page no="5"?> VVoorrwwo orrtt SCRUM ist ein Megatrend. Wer Projekte managt oder sich mit dem Thema Projektmanagement beschäftigt, kommt um das Thema Agilität nicht mehr herum. Und Agilität bedeutet heutzutage SCRUM. Denn in mehr als 90 Prozent aller agilen Projekte wird SCRUM angewandt. Obwohl SCRUM bereits vor mehr als 20 Jahren entwickelt wurde, erleben wir erst heute in Deutschland den wirklichen Durchbruch dieser revolutionären Methode im Projektmanagement. Es gibt aktuell in Deutschland einen regelrechten SCRUM-Boom. Wie kommt das? Nun, letztlich liegen die Grundprinzipien und Ansätze, die mit SCRUM vermittelt werden, absolut im Trend: das hierarchische Projektmanagement ist am Ende. Autonome, sich selbst managende Teams sind heute eine Selbstverständlichkeit. Themen wie Holocracy, Design Thinking zeigen ganz deutlich: die Macht liegt heute beim Team beziehungsweise den Mitarbeitern. Und dieser Trend zeigt sich auch beim Managen von Projekten. Da es SCRUM schon einige Jahre gibt, haben sich in den letzten Jahren immer mehr Autoren, Berater und Experten darangemacht, die Methodik weiterzuentwickeln, zu verändern und zu ergänzen. So entstanden viele Varianten von SCRUM. Oft war der Beweggrund dahinter wirtschaftlicher Natur, um auf den bereits sehr schnell und erfolgreich fahrenden Zug aufzuspringen. Wir als Autoren dieses Buchs sehen diese Entwicklung kritisch. Denn aus unserer Sicht funktioniert SCRUM nur, wenn es in seiner einfachsten und reinsten Form angewendet wird. So wie es von den Begründern dieser Methode auch angedacht war. Aus diesem Grunde begrüßen wir es auch sehr, dass die beiden Väter von SCRUM, Jeff Sutherland und Ken Schwaber, im Jahr 2010 den SCRUM-Guide herausgegeben haben. Dieser stellt auf wenigen Seiten den Kern und das Rahmenwerk von SCRUM klar dar und definiert die wichtigsten Regeln und Prinzipien. Aus diesem Grund ist es auch das Ziel unseres Buchs, SCRUM nicht weiter zu verfälschen oder mit eigenen Ideen zu ergänzen. Unser Maßstab ist es, das von Jeff Sutherland und Ken Schaber erdachte und über die Jahre immer <?page no="6"?> 6 $! &"! &# weiter entwickelte Rahmenwerk von SCRUM in seiner Reinheit und Klarheit, verständlich und in strukturierter Form darzustellen. Hauptfokus ist hierbei, allen, die sich auf eine Zertifizierung nach der größten Organisation für SCRUM - der SCRUM.org - die wichtigsten Inhalte in einfacher Form zu vermitteln. Dies ist es auch der Ansatz, welchen wir in unseren eigenen Trainings leben und anwenden. SCRUM in seiner Reinheit funktioniert und ist sehr erfolgreich. Grundlage ist hierbei, dass wir die Praxis von SCRUM aus unserer täglichen Beratungspraxis kennen. Das bedeutet, dass es uns bewusst ist, dass in vielen nach dem klassischen Wasserfallmodell gemanagten Projekten Elemente von SCRUM beziehungsweise aus dem Agilen Projektmanagement verwendet werden. Hiergegen ist auch grundsätzlich nichts einzuwenden. Auch wir haben oft Komponenten von SCRUM in großen und komplexen Transformationsprojekten angewandt und ausprobiert. Wichtig ist hierbei jedoch, dass es sich dann letztlich nicht mehr um SCRUM handelt. SCRUM funktioniert nur in seiner Ganzheit, ohne einzelne Komponenten wegzulassen oder zu ergänzen. Zurück zum Ziel dieses Buchs: Wir wollen dich auf eine möglichst effiziente Art und Weise fit für die Zertifizierung von SCRUM machen. Unser Buch bereitet dich hierbei jeweils auf die Stufen I des SCRUM Masters und des Product Owners vor. Dieses Vorgehen hat sich vielfach in unseren eigenen Trainings als erfolgreich erwiesen. Weshalb es auch in diesem Buch Anwendung findet. Diese Erfahrung und unser Praxiswissen haben den Aufbau und die Struktur dieses Buchs beeinflusst. Insgesamt haben wir dieses Buch in sechs Kapitel gegliedert: ! Vorwort (dieses Kapitel liest du gerade) ! Warum ist SCRUM so erfolgreich? ! Was ist SCRUM? ! Wie funktioniert SCRUM? ! Wozu ist SCRUM in der Praxis anwendbar? ! Wie funktioniert die Prüfung und Zertifizierung? <?page no="7"?> $1/ )1/ , 7 ! SCRUM-Glossar: Wichtige Begriffe werden erklärt. Das Buch beginnt mit einem allgemeinen Teil, in dem wir darauf eingehen, was die Gründe für den Erfolg von SCRUM sind. Danach beschreiben wir, was SCRUM zu SCRUM macht. In diesem Teil werden wir dir das Basiswissen vermitteln, das du benötigst, um SCRUM in seiner Grundmethodik zu verstehen und anzuwenden. Und dies auch unabhängig davon, ob du die Prüfung zum SCRUM Master, SCRUM Product Owner oder einem anderen Ausbildungslevel absolvieren willst. Die nächsten beiden Kapitel hingegen zielen konkret auf Wissen ab, das du benötigst, um die beiden Zertifizierungsstufen SCRUM Master oder SCRUM Product Owner erfolgreich zu bestehen. Diese beiden Stufen sind immer noch die am Markt am häufigsten angebotenen und nachgefragten Zertifizierungsstufen. Je nachdem, ob ihr also auf die Prüfung und Zertifizierung zum SCRUM Master oder SCRUM Product Owner lernt, solltet ihr diese beiden Kapitel intensiv durcharbeiten. Das darauffolgende Kapitel gibt euch dann einen Überblick darüber, wie ihr die Prüfung für SCRUM ablegt und welche Zertifizierungsanbieter es gibt. Hier findet ihr also alles dazu, wie ihr am besten und schnellsten zur SCRUM-Zertifizierung kommt. Der letzte Teil des Buches umfasst das SCRUM-Glossar. Es basiert auf dem Glossar der SCRUM.org. Es gibt euch einen Überblick über die Definitionen aller im Rahmen von SCRUM verwendeten Begriffe. Dieses Kapitel ist optimal, um sich vor der Prüfung nochmals einen Überblick über die wichtigsten Begriffe zu verschaffen und den eigenen Wissensstand zu kontrollieren. Dieses Buch, so wie du es in den Händen hältst, ist das erste Buch seiner Art. Es ist nicht nur ein Buch, sondern es ist ein kombinierter Vorbereitungskurs auf die Zertifizierung von SCRUM. Letztlich bieten wir mehrere Komponenten für die Vorbereitung auf die Prüfung der Zertifizierung nach SCRUM an: ! Buch (Das Buch hältst du gerade in deinen Händen) ! Präsenztraining (www..(+,#-".de) <?page no="8"?> 8 $! &"! &# ! Onlinekurs (www. SCRUM-hero.de) ! Podcast (www. SCRUM-hero.de) Dieses Buch enthält alles, was du brauchst, um für die Prüfung fit zu sein. Dennoch gibt es unter euch unterschiedliche Lerntypen. Und nicht für jeden reicht ein Buch alleine als Vorbereitung aus. Deswegen entscheide Du welchen Weg der Prüfungsvorbereitung du wählst. Dieses Buch ist einer davon. Dieses Buch und seine Aktualität und Weiterentwicklung lebt von der Kommunikation mit euch. Deswegen freuen wir uns auf eure Anregungen, Anmerkungen und Verbesserungsvorschläge. Schreibt uns jederzeit gerne eine E-Mail oder ruft uns an: Roman Simschek: rsimschek@.(+,#-".de Fabian Kaiser: fkaiser@.(+,#-".de Wir sind telefonisch erreichbar unter 06196/ 52 549 55. Oder du kommst uns einfach in unserem Büro in Frankfurt-Eschborn besuchen. Immer freitags machen wir mit ausgewählten Kunden ein Mittagslunch. Wenn du Lust hierauf hast, schreibe uns gerne eine E-Mail. Wir freuen uns darauf, dich kennenzulernen. Nun wünschen wir euch viel Spaß beim Lesen dieses Buchs und natürlich letztlich auch viel Erfolg bei der SCRUM-Prüfung. Eure Roman Simschek Fabian Kaiser Eschborn, ! %"* 2018 <?page no="9"?> Inhaltsübersicht 1 Warum ist SCRUM so erfolgreich? ....................................................................................... 15 2 Was ist SCRUM? .......................................................................................................................... 29 3 Wie funktioniert SCRUM? ........................................................................................................ 53 4 Wozu ist SCRUM in der Praxis anwendbar? ....................................................................141 5 Wie funktionieren die Prüfung und die Zertifizierung? .............................................153 6 Lösungen zu den Übungsfragen .......................................................................................159 7 Glossar: Welche Begriffe sind wichtig? ............................................................................165 8 Gute Informationsquellen und Literatur.........................................................................173 Index .......................................................................................................................................................175 <?page no="11"?> Inhalt Vorwort.......................................................................................................................................................5 1 Warum ist SCRUM so erfolgreich? ...............................................................................15 1.1 Wasserfall versus Agile ......................................................................................................... 18 2 Was ist SCRUM? .....................................................................................................................29 2.1 Der Begriff SCRU M ........ ..... ..... ..... ..... ..... ..... .... ......... ........ ..... ..... ..... ..... .... .......... ......... ....... ... .. 29 2.2 Die SCRUM-Theorie: Die drei Säulen ............................................................................... 31 2.3 Die fünf Werte von SCRUM ................................................................................................. 33 2.4 Agiles Manifest als Basis der SCRUM-Prinzipien ......................................................... 36 2.5 SCRUM Framework ................................................................................................................ 42 2.6 SCRUM-Guide........................................................................................................................... 45 3 Wie funktioniert SCRUM? .................................................................................................53 3.1 SCRUM-Prozess........................................................................................................................ 53 3.2 Rollen .......................................................................................................................................... 62 3.3 Meetings .................................................................................................................................... 87 3.4 Artefakte ..................................................................................................................................116 3.5 Zusammenführung der Komponenten von SCRUM ...............................................138 <?page no="12"?> 12 Inhalt 4 Wozu ist SCRUM in der Praxis anwendbar? ......................................................... 141 4.1 Fortschritts-Monitoring bezogen auf das Gesamtziel ............................................141 4.2 Fortschritts-Monitoring im Rahmen des Sprints.......................................................145 5 Wie funktionieren die Prüfung und die Zertifizierung? ................................ 153 5.1 Wie kann man zertifiziert werden? ................................................................................153 5.2 Welche Prüfungen gibt es? ...............................................................................................156 5.3 Wie läuft die Prüfun g ab? ...... ....... .......... ......... ........ ..... ..... ..... .... ......... ........ ..... ..... ..... ..... .. 15 6 5.4 Aufbau Prüfungsfragen SCRUM......................................................................................157 6 Lösungen zu den Übungsfragen ............................................................................... 159 7 Glossar: Welche Begriffe sind wichtig? .................................................................. 165 8 Gute Informationsquellen und Literatur............................................................... 173 Index .................................................................................................................................................... 175 <?page no="13"?> Abbildungsverzeichnis Abb. 1 Was macht SCRUM so erfolgreich? ............................................................................ 18 Abb. 2 Klassisches Projektmanagement................................................................................ 20 Abb. 3 Agiles Projektmanagement ......................................................................................... 22 Abb. 4 Hybrides Projektmanagement.................................................................................... 24 Abb. 5 SCRUM Framework.......................................................................................................... 30 Abb. 6 Theorie des Empirismus ................................................................................................ 33 Abb. 7 Die fünf Werte von SCRUM........................................................................................... 35 Abb. 8 Wertepaare des Agilen Manifests .............................................................................. 37 Abb. 9 Prinzipien des Agilen Manifests.................................................................................. 41 Abb. 10 Komponenten des SCRUM Framework .................................................................. 42 Abb. 11 Fragen des Projektmanagements.............................................................................. 44 Abb. 12 SCRUM-Guide .................................................................................................................... 46 Abb. 13 SCRUM-Prozess ................................................................................................................. 55 Abb. 14 Sprints und Releases ....................................................................................................... 56 Abb. 15 SCRUM Rollen im Überblick ......................................................................................... 63 Abb. 16 SCRUM-Team und Stakeholder .................................................................................. 66 Abb. 17 Beschreibung SCRUM-Rollen....................................................................................... 68 Abb. 18 SCRUM Product Owner .................................................................................................. 71 Abb. 19 SCRUM Master................................................................................................................... 73 Abb. 20 Unterstützung des SCRUM Masters .......................................................................... 76 Abb. 21 SCRUM-Entwicklungsteam........................................................................................... 78 Abb. 22 Optimale Teamgröße ..................................................................................................... 81 <?page no="14"?> 14 Abbildungsverzeichnis Abb. 23 SCRUM Meetings.............................................................................................................. 89 Abb. 24 Dauer der Meetings......................................................................................................... 92 Abb. 25 Phasen des Sprint Plannings........................................................................................ 94 Abb. 26 Daily SCRUM.....................................................................................................................100 Abb. 27 Sprint Review...................................................................................................................102 Abb. 28 Sprint Retrospektive......................................................................................................103 Abb. 29 Transparenz in der Sprint Retrospektive ...............................................................105 Abb. 30 Product Backlog Refinement .....................................................................................108 Abb. 31 Definition of Ready........................................................................................................109 Abb. 32 Zusammenführung Meetings und Rollen ............................................................110 Abb. 33 Übersicht Artefakte .......................................................................................................116 Abb. 34 Darstellung Sprint Backlog.........................................................................................121 Abb. 35 Schätzung des Backlogs ..............................................................................................124 Abb. 36 Sprint-Ziel .........................................................................................................................127 Abb. 37 Sprint Ziel Charakteristik .............................................................................................128 Abb. 38 Definition of Done .........................................................................................................129 Abb. 39 Zusammenführung Artefakte und Rollen.............................................................132 Abb. 40 Zusammenführung SCRUM-Prozess und Rollen................................................138 Abb. 41 Gesamtüberblick Komponenten von SCRUM .....................................................139 Abb. 42 Burn-down Chart............................................................................................................142 Abb. 43 Burn-up Chart ..................................................................................................................143 Abb. 44 Cumulative Flow Diagram ..........................................................................................144 Abb. 45 Task Board.........................................................................................................................146 <?page no="15"?> 1 Warum ist SCRUM so erfolgreich? Mehr als 90 Prozent aller Projekte, die agil gemanagt werden, nutzen SCRUM. Agilität ist im Trend - und SCRUM ist es umso mehr. Weltweit nutzen mehr als 12 Millionen Menschen SCRUM als Methode im Projektmanagement. Was für eine beeindruckende Zahl. Man kann heute sagen: Agilität bedeutet SCRUM. Letztlich ist SCRUM nicht neu, auch wenn es in den letzten Jahren sicherlich seinen Höhepunkt erreicht hat. Mehr als 20 Jahre gibt es nun bereits SCRUM. Was also macht SCRUM so erfolgreich? Was ist das Geheimnis hinter dem Erfolg von SCRUM? Die folgenden Gründe spiegeln unsere Meinung als Autoren und Fans von SCRUM wider: SCRUM ist einfach … SCRUM besteht aus nur sehr wenigen Regeln und ist somit sehr einfach. Konkret besteht es aus nur drei Rollen, fünf Meetings und drei Artefakten. Diese Einfachheit ist aus unserer Sicht der Hauptfaktor für den Erfolg von SCRUM. Denn oft wird versucht, die Komplexität unserer Zeit und unserer Umwelt durch entsprechend komplexe Ansätze und Methoden zu managen. Doch genau das funktioniert aus unserer Sicht nicht. Zu oft haben wir in der Praxis feststellen müssen, dass dies nicht funktioniert. Hohe Komplexität kann deswegen nur mit einfachen Methoden und Ansätzen entgegnet und gemanagt werden. Und SCRUM ist einfach … sehr einfach. Dies zeigt sich auch darin, dass die von Jeff Sutherland und Ken Schwaber veröffentlichte SCRUM-Bibel/ der SCRUM-Guide, alles was SCRUM als Framework ausmacht, auf lediglich 16 Seiten (beziehungsweise 20 Seiten in der deutschen Version) beschreibt. Mehr hierzu finden Sie auch auf SCRUM.org oder in Abschnitt 2.6. <?page no="16"?> 16 1 Warum ist SCRUM so erfolgreich? SCRUM ist agil ... Und agil bedeutet SCRUM. Keine andere Methodik, kein anderer Ansatz, keine andere Technik hat sich im Rahmen von Agilen Projekten so erfolgreich durchgesetzt wie SCRUM. Wie schon beschrieben, setzen 90 Prozent aller agil gemanagten Projekte SCRUM ein. Von Marktführerschaft zu sprechen wäre hier schon untertrieben. Zumal man davon ausgehen kann, dass die 10 Prozent, die von sich behaupten, dass sie nicht SCRUM einsetzen, zumindest teilweise SCRUM verwenden. So hat sich beispielsweise ein Daily Stand up in so gut wie allen agilen Projekten als Standard durchgesetzt. SCRUM ist h ierarchielos ... SCRUM gibt einen großen Teil der „Macht“ zum Managen und Organisieren an das Team zurück. Einen Projektmanager im klassischen Sinne gibt es nicht mehr. 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 detaillierten Projektplan und ganz ohne jemanden, der ihnen sagt, wann sie was genau zu tun haben. Es gibt in einem SCRUM-Projektteam kein Hierarchiegefälle, sondern lediglich klar definierte Rollen. Jeder respektiert jeden als gleichwertig und kennt seine Rolle ganz genau. So funktioniert SCRUM. SCRUM ist pragmatisch ... SCRUM kommt mit so wenig Administration wie möglich aus. Denkt man daran, wie viel Energie bei nach der klassischen Wasserfall-Methode gemanagten Projekten in Projektplanung, Budgetmanagement und Statusreports anstatt in das eigentlichen Management des Projekts 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 <?page no="17"?> 1.1 Wasserfall versus Agile 17 Form von langen E-Mails, E-Mail-Ketten und Powerpoint-Präsentationen statt, sondern direkt von Angesicht zu Angesicht, ohne Medienbrüche, von Mensch zu Mensch. Probleme werden nicht über Ampeln kommuniziert, sondern direkt mit dem Betroffenen besprochen. SCRUM ist also sehr effizient und verzichtet auf fast alles, was nicht direkt mit dem Projektziel beziehungsweise dem Endprodukt zu tun hat, auf ein Minimum. Und was effizient ist, setzt sich in Zeiten knapper Budgets und immer schneller zu liefernden Ergebnissen einfach durch. SCRUM funktioniert … Oft beschreiben die Väter von SCRUM, Jeff Sutherland und Ken Schwaber, SCRUM mit sehr plakativen Aussagen wie beispielsweise „Wie Sie mit SCRUM in der Hälfte der Zeit doppelt so viel erreichen können“. Diese Aussagen sind sicherlich etwas überspitzt. Dennoch kann man neidlos eingestehen, dass die Methodik von SCRUM aufgrund der bereits oben beschriebenen Merkmale sehr effektiv und effizient ist - und deswegen einfach funktioniert. Andernfalls wäre es nicht möglich, dass SCRUM so erfolgreich ist und seit über 20 Jahren weltweit immer größere Verbreitung findet. Dass SCRUM funktioniert, zeigt sich auch daran, dass es relativ wenige Veröffentlichungen zu Kritik und Problemen beim Einsatz von SCRUM gibt. Oft ist es so, dass, wenn eine Methode sehr erfolgreich wird - und damit verbunden natürlich „alte“ Methoden verdrängt - sich sehr schnell Kritiker finden, die sich in ihrem angestammten Terrain angegriffen fühlen. Sie würden mit umfangreichen Artikeln, Studien oder Veröffentlichungen reagieren, die die neue Bedrohung dann klein reden oder deren Nachteile hervorheben. Dies ist bei SCRUM kaum bzeiehungseise nicht der Fall. Letztlich ist SCRUM sicherlich nicht für alle Arten von Projekten gleich gut geeignet. Dennoch ist SCRUM zwischenzeitlich beim agilen Projektmanagement zu einer Art von DNA geworden, ohne die Agilität nicht mehr existieren würde. Insofern wünschen wir dir viel Spaß und Erfolg beim Lesen der nächsten Seiten und der Anwendung von SCRUM. <?page no="18"?> 18 1 Warum ist SCRUM so erfolgreich? Abb. 1: Was macht SCRUM so erfolgreich? In diesem Abschnitt gehen wir darauf ein, woher SCRUM kommt. Wer der Vater oder wer die Väter des Denkmodells von SCRUM sind - und wieso sich SCRUM so stark, insbesondere gegenüber klassischen Methoden des Projektmanagements durchgesetzt hat. 1.1 Wasserfall versus Agile Wenn man von Agilem Projektmanagement spricht, kommt man selten daran vorbei, dass Aussagen fallen wie „Die Wasserfall-Methode ist doch veraltet“ oder „Wie… ihr managt immer noch nach der Wasserfall-Methode? “. ^Xb.d ,K+SU n,'O&A0 ^Xb.d ,K+SU &M,G ^Xb.d ,K+SU 0,n? &? A0,nG]K ^Xb.d ,K+SU B? &M)&+,KA0 ^Xb.dSU O='H+,]',n? + <?page no="19"?> 1.1 Wasserfall versus Agile 19 Wir wollen an dieser Stelle kurz die Unterschiede zwischen den beiden Methoden darstellen und auf ihre jeweiligen Vor- und Nachteile eingehen. Aus unserer Sicht ist es, wenn man sich mit SCRUM beschäftigt, wichtig zu wissen, welche anderen grundsätzlichen Prinzipien und Methoden des Projektmanagements es gibt. So kann man besser verstehen, was der Kern oder auch was das „Revolutionäre“ an SCRUM ist. Wichtig ist uns hierbei keine vergleichende Bewertung der beiden Modelle Wasserfall-Methode und SCRUM vorzunehmen. Aus unserer Sicht haben beide Modelle ihre Daseinsberechtigung. Jedes der beiden Modelle hat seine spezifischen Charakteristika und Einsatzbereiche. Oft ist es so, dass Anhänger von SCRUM die Wasserfall-Methode als „alt“ beziehungsweise „überholt“ betrachten. Dieser Meinung wollen wir uns nicht anschließen. Es handelt sich einfach um sehr unterschiedliche Ansätze, die jeweils ihre spezifischen Vor- und Nachteile haben. Was also ist der Unterschied zwischen der klassischen Methodik des Projektmanagements und SCRUM? Klassisches Projektmanagement nach der Wasserfall-Methode Das Projektmanagementnach der Wasserfall-Methode erfolgt in mehreren Phasen. Dies bedeutet, dass ein Projekt in mehrere, sich von den jeweiligen Aufgaben unterscheidenden Phasen unterteilt wird. Hierbei folgt jede Phase auf eine andere, sprich eine Phase beginnt erst dann, wenn die vorherige Phase vollkommen abgeschlossen ist. Die Planung und inhaltliche Ausgestaltung dieser Phasen erfolgt bereits zu Beginn des Projektes. Phasen werden erst dann gestartet, wenn die vorherige Phase abgenommen und dann abgeschlossen wurde. Ein weiteres Charakteristikum ist, dass die geplanten Phasen, so wie sie geplant wurden, auch sehr starr durchgeführt werden. Dies bedeutet auf der einen Seite eine relativ hohe Planungssicherheit, auf der anderen Seite hingegen auch eine gewisse mangelnde Flexibilität. Gerade bei sehr großen, komplexen und umfangrei- <?page no="20"?> 20 1 Warum ist SCRUM so erfolgreich? chen Projekten ist es notwendig, diese Planungssicherheit zu haben und entsprechend auch nach der Wasserfall-Methode vorzugehen. Dies ist darin begründet, dass das Projekt einerseits eventuell international über mehrere Länder verteilt ist, und auch verschiedenste fachliche Bereiche im Projekt berücksichtigt werden. Ein wesentlicher Nachteil der Wasserfall-Methode ist, dass sich Fehler in der Umsetzung im Rahmen des Projektes erst sehr spät in der Projektlaufzeit zeigen. Hier kann es dann durchaus sein, dass im Rahmen der abgelaufenen Projektlaufzeit bereits Budget und Ressourcen investiert wurden, die, wie sich später herausstellt, nicht wirklich zielführend waren. Dieser Kritikpunkt ist auch einer der wesentlichen Treiber, der zu der Entwicklung Agiler Methoden im Projektmanagement geführt hat. Abb. 2: Klassisches Projektmanagement j]'; nB+,]' DnK,M' .)Kn+; ='M 3nK+ b]GGN]=+ <?page no="21"?> 1.1 Wasserfall versus Agile 21 Im Kern kann man sagen, dass im klassischen Projektmanagement sehr viel Wert auf Struktur, jedoch weniger Wert auf Flexibilität gelegt wird. Gerade in hierarchischen Unternehmensstrukturen ist es deshalb weiterhin sehr angesagt, Projekte nach klassischen Projektmanagementmethoden zu managen. Agile Methoden wie SCRUM legen hingegen weniger Wert auf Struktur und setzen mehr auf Flexibilität. Abbildung 2 zeigt beispielhaft einen Phasenplan eines nach der klassischen Methode strukturierten und geplanten Projekts. Agiles Projektmanagement mit SCRUM Agiles Projektmanagement setzt im Wesentlichen auf kurze und regelmäßige Entwicklungszyklen. So kann auf Veränderungen, insbesondere auch bezüglich der Anforderungen, die der Kunde an das Endprodukt stellt, schnell reagiert werden. Zudem kann schnell und kurzfristig angepasst werden. Diese einzelnen Entwicklungszyklen nennt man bei SCRUM einen Sprint. Letztlich erfolgt die Umsetzung der gesamten Produktentwicklung eines Produkts in mehreren Sprints. Die wesentliche Vorgabe für den Sprint ist seine Dauer und ein Anforderungskatalog, welcher im SCRUM Product Backlog, beziehungsweise bezogen auf den Sprint dann Sprint Backlog, genannt wird. Zudem ist eine fortlaufende und regelmäßige informelle Kommunikation innerhalb eines Sprints vorherrschend. Es geht weniger darum, vorgegebene Reporting-Templates und Statusberichte auszufüllen, sondern in einer persönlichen, direkten, interaktiven und regelmäßigen Kommunikation auf Probleme, Hindernisse oder Herausforderungen zu reagieren. Der Fokus liegt also mehr darauf, schnell zu reagieren als zu dokumentieren. Agilität beziehungsweise der Einsatz von SCRUM bedeutet demnach, weniger Wert auf Strukturen zu legen, sondern mehr Flexibilität in einem Projekt zuzulassen. Dabei liegt die Annahme zu Grunde, dass das Projektteam soweit befähigt und motiviert ist, dass es mit dieser Flexibilität sehr gut umgehen kann und trotz Flexibilität des Projektziel beziehungsweise das Ziel eines Sprints nicht aus den Augen verliert. Agiles Projektma- <?page no="22"?> 22 1 Warum ist SCRUM so erfolgreich? nagement ist wenig hierarchisch und setzt darauf, dass Teams sich selbst organisieren und selbst am besten wissen, wie die vorgegebenen Projektziele erreicht werden. Abbildung 3 zeigt den typischen Aufbau eines Agilen Projektes. Abb. 3: Agiles Projektmanagement Hybrides Projektmanagement Gibt es auch Zwischenformen zwischen Klassischem Projektmanagement und Agilem Projektmanagement? Die Antwort ist ein klares Ja: man nennt dies Hybrides Projektmanagement. Beim Hybriden Projektmanagement geht man davon aus, dass sowohl im Agilen Ansatz des Projektmanagements als auch im klassischen Modell (? ]#=A+ [&AHG]M D&,GQ ^+&'# =B ^B ? ,'+ ^B? ,'+ 8 ^B ? ,'+ 7 ^B? ,'+ 5 ^B? ,'+ [&AHG]M (? ]#=A+ [&AHG]M ! ! ! ! ! <?page no="23"?> 1.1 Wasserfall versus Agile 23 (Wasserfall-Methode) Aspekte vorhanden sind, die das Managen eines Projektes erfolgreich machen. Insofern bedient man sich beim Hybriden Projektmanagement mit Elementen aus beiden Methoden. Quasi das Beste aus beiden Welten. So ist in der Praxis insbesondere zu beobachten, dass in klassisch, also nach der Wasserfall-Methode gemanagten Projekten, agile Elemente insbesondere aus SCRUM integriert werden. Ein typisches Agiles Element, das gerne in diesen Projekten umgesetzt wird, ist das Daily Stand up. In SCRUM wird dieses Meeting dann Daily SCRUM genannt. Seltener ist es der Fall, dass in agilen Projekten Elemente aus dem Klassischen Projektmanagement eingesetzt werden. Dies kommt daher, dass einer der Grundsätze von SCRUM - als wichtigste und am weitesten verbreitete Methode des Agilen Projektmanagements - ist, dass „SCRUM nur SCRUM ist, wenn es SCRUM ist“. Was wollen wir hiermit sagen? In der Bibel zu SCRUM, dem SCRUM-Guide beschreiben die beiden Väter von SCRUM, Jeff Sutherland und Ken Schwaber, dass SCRUM nur dann sein maximal erfolgreiches Potenzial ausschöpft, wenn seine Elemente und Komponenten (wie beschrieben im SCRUM Framework, mehr hierzu in Abschnitt 2.5) unverändert und in Gänze zum Einsatz kommen. Jede Veränderung, Ergänzung oder jedes Weglassen der Komponenten von SCRUM wäre somit nicht mehr SCRUM. Halten wir also fest: hybrides Projektmanagement ist eine Mischform aus klassischen und agilem Projektmanagement. Es ist quasi der Versuch, das Beste aus beiden Welten in einer Methode zu vereinen. Wir sehen, dass dies sehr oft in der Praxis angewandt wird. Oft auch mit Erfolg. Wie man beide Ansätze kombiniert, hängt dabei von der Art des Projekts, aber auch von seiner Projektphase ab. Die Abbildung 4 zeigt die Zusammenhänge von klassischen Projektmanagement und Agilem Projektmanagement. <?page no="24"?> 24 1 Warum ist SCRUM so erfolgreich? Abb. 4: Hybrides Projektmanagement jG&KK,KA0nK (? ]LnH+)&'&Mn)n'+ TQC? ,#nK (? ]LnH+)&'&Mn)n'+ 4M,GnK (? ]LnH+)&'&Mn)n'+ _ &K Kn? O& GGN dn+0]#n d,KA0 O]? ) ^Xb.d <?page no="25"?> Übungsfragen 25 Übungsfragen zum Kapitel: „Warum ist SCRUM so erfolgreich? “ Hinweis: Es können eine oder mehrere Antworten richtig sein. Die Auflösung findest du in Abschnitt 5.5. [1] SCRUM ist eine Methode des … " Klassischen Projektmanagements " Hybriden Projektmanagements " Agilen Projektmanagements " Wasserf all-Proje ktmana gements [2 ] Der Fokus im Klassis chen Projek tmana gement li egt auf: " Flexibilität und Anpassung " Kundenbedürfnisse frühzeitig erkennen " Planung und Struktur " regelmäßige und kurzfristige Reaktion auf Veränderungen [3] Der Fokus des Agilen Projektmanagement ist: " Planung nach Projektphasen " hierarchische Projektstruktur " Flexibilität und Eigenorganisation " Planung und Struktur <?page no="26"?> 26 1 Warum ist SCRUM so erfolgreich? [4] Die Wasserfall-Methode ist charakterisiert durch: " Ablauf in aufeinanderfolgenden Phasen " hierarchische Projektstrukturen " Fokussierung auf Planung und Strukturen " kurze und regelmäßige Entwicklungszyklen [5] Agiles Projektmanagement ist charakterisiert durch: " kurze und regelmäßige Entwicklungszyklen " schnelle Reaktion auf Veränderungen " direkte und informelle Kommunikation i m Team " Fokus auf Flexibilität und Eigenorganisation [6] Hybrides Projektmanagement ist eine Mischform aus " Wasserfall-Methode und dem klassischen Projektmanagement " Agilem Projektmanagement und SCRUM " Agilem Projektmanagement und klassischem Projektmanagement " Keine der aufgeführten Möglichkeiten [7] Gemäß den Vätern von SCRUM sollte… " SCRUM durch andere Methoden ergänzt werden " SCRUM mit klassischen Methoden gemischt werden " SCRUM nur in seiner reinen Form angewendet werden " SCRUM nicht durch Weglassen oder Ergänzen verfälscht werden <?page no="27"?> Übungsfragen 27 [8] SCRUM ist … " die einzige aus heutiger Sicht erfolgreiche Methode des Projektmanagements " unbedingt jeder anderen Form des Projektmanagements vorzuziehen " nicht die einzige erfolgreiche Methode des Projektmanagements " eine der führenden Methoden des agilen Projektmanagements [9] Ein guter Projektmanager sollte … " sich auf SCRUM fokussieren, denn es ist die Methode der Zukunft im Projektmana geme nt. " sollte SCRUM nicht weiter verfolgen, denn es handelt sich nur um ei nen aktuellen Tr end, der nicht weiter von Relevanz sein wird. " sowohl agile als auch klassische Methoden des Projektmanagements beherrschen, um flexibel auf unterschiedliche Rahmenbedingungen zu reagiere n. " Keine der Antwortmöglichkeiten. [10] SCRUM ist … " bisher nur in Nordamerika verbreitet. Im Europäischen Raum findet es kaum Anwendung. " bei mehr als 90% aller agilen Projekten weltweit im Einsatz. " notwendig, um Projekte in Phasen zu strukturieren und zu planen. " Keine der Antwortmöglichkeiten ist richtig. <?page no="29"?> 2 Was ist SCRUM? Jetzt habt ihr bereits mehrere Seiten zu SCRUM gelesen, die sich mit dem Erfolg von SCRUM beschäftigt haben. Und dennoch ist eine Frage immer noch offen: Was ist SCRUM? Eine Methode, ein Tool, eine Technik, ein Prozess? Keines von allem. Fangen wir damit an, woher der Begriff SCRUM kommt … 2.1 Der Begriff SCRUM Der Begriff SCRUM lässt sich auf die beiden japanischen Wirtschaftswissenschaftler Nonaka und Takeuchi zurückführen. Sie schreiben in ihrem im Jahr 1986 erschienenen Artikel „The New Product Development Game" über den von ihnen so genannten "Rugby-Approach". Dieser bedient sich einer Analogie aus dem Rugby. Sie gehen davon aus, dass einer der außergewöhnlichsten Erfolgsfaktoren von sehr erfolgreichen Produktentwicklungsteams die Nähe des Teams während der Entwicklungsarbeit ist. So wie bei dem aus Rugby stammende Gedränge, welches SCRUM genannt wird und bei dem viele Spieler eng zusammenstehen. Denn auch diese Teams arbeiten als kleine und selbstorganisierte Einheiten. Sie bekommen von außen nur eine grobe Richtung vorgegeben. Es bleibt in der Umsetzung jedoch ihnen überlassen, wie sie ihr gemeinsames Ziel erreichen. Und diese Art der Zusammenarbeit soll auch Projekte erfolgreich machen. Dieser Rugby-Approach wurde dann mehr als zehn Jahre später von den Vätern von SCRUM, Jeff Sutherland und Ken Schwaber, zu einem Rahmenwerk für Softwareentwicklungsprojekte weiterentwickelt: Und dieses Rahmenwerk nannten sie mit einem entsprechenden Verweis auf den Artikel von Nonaka und Takeuchi: SCRUM. Letztlich ist SCRUM also ein Rahmenwerk für agiles Projektmanagement. SCRUM als Rahmenwerk setzt sich aus drei Komponenten zusammen: <?page no="30"?> 30 2 Was ist SCRUM? ! SCRUM-Werte (Abschnitt 2.3) ! SCRUM-Prinzipien (Abschnitt 2.4) ! SCRUM-Praktiken oder Regeln (Kapitel 3) Die Basis für diese drei Komponenten stellt die SCRUM-Theorie dar, welche sich in den drei Komponenten von SCRUM manifestiert. Diese stellen wir im folgenden Abschnitt dar. Abb. 5: SCRUM Framework ^Xb.d b&0)n'in? H ^Xb.d 30n]? ,n ^ Xb.d _n? +n ^Xb.d (? ,'; ,B,n' ^Xb.d bnMnG' ='# (? &H+,Hn' <?page no="31"?> 2.2 Die SCRUM-Theorie: Die drei Säulen 31 2.2 Die SCRUM-Theorie: Die drei Säulen Die wissenschaftliche Basis von SCRUM ist die Theorie der empirischen „Prozesssteuerung“, kurz auch „Empirie“ genannt. Die Empirie besagt, dass Wissen auf Erfahrung basiert. Und dass Entscheidungen auf der Basis von diesem bestehenden Wissen erfolgen. SCRUM stellt durch seinen iterativen und inkrementellen Ansatz sicher, dass in regelmäßigen und kurzen Abständen die Möglichkeit zur Überprüfung und Anpassung besteht. So werden regelmäßig Erfahrungen in Wissen transferiert. Dieses Wissen wiederum wir dann genutzt, um immer wieder Entscheidungen zu treffen. Je mehr Erfahrung, je mehr Wissen, und umso bessere Entscheidungen können getroffen werden. Durch dieses Vorgehen können Risiken minimiert, frühzeitig erkannt und auch gegengesteuert werden. Die SCRUM-Theorie basiert insofern auf drei wesentlichen Säulen: ! Transparency - Transparenz: Offene Kommunikation und das Teilen von Wissen ist die Grundlage für Transparenz. Zudem sollten das gesamte Vorgehen beziehungsweise der Prozess in einem SCRUM-Projekt für alle Beteiligten transparent sein. Dies umfasst insbesondere auch die verwendeten Begriffe in einem Projekt. Jeder sollte unter den verwendeten Begriffen das gleiche verstehen. Hierzu ein Beispiel: Stellen Sie all Ihren Projektteammitgliedern die Aufgabe, die Augen zu schließen und an einen Hund zu denken. Danach soll jeder auf ein weißes Blatt Papier diesen Hund malen. Legt man die gezeichneten Hunde nebeneinander, so wird schnell deutlich, dass jeder einen anderen Hund gemalt haben wird. Der Eine malt einen kleinen lieben Dackel. Der andere einen bellenden Schäferhund. Der nächste einen Schlittenhund vor einem Hundeschlitten in Sibirien. Wer hat jetzt den richtigen Hund gezeichnet? Alle. Oder keiner? Jeder hat den für ihn richtigen Hund gemalt, eben das, was er unter einem Hund versteht. In einem Projekt ist es jedoch wichtig, dass alle unter „Hund“ den einen und <?page no="32"?> 32 2 Was ist SCRUM? gleichen Hund verstehen, der auch gemeint ist beziehungsweise der als Produkt oder Projektergebnis erwartet wird. Insofern ist es wichtig, für alle wesentlichen Begriffe oder Hunde ein einheitliches Verständnis zu haben. Als ein typisches Beispiel in einem Projekt zu nennen ist, dass es ein einheitliches Verständnis von „Done“ - also wann etwas erledigt ist - gibt. An welchen genauen Kriterien festzumachen ist, dass etwas erledigt ist. Mehr hierzu unter Abschnitt 2.4. ! Inspection - Überprüfung: Inspection bedeutet, dass alle Vorgehensweisen und Arbeitsergebnisse regelmäßig überprüft werden. In einem nach SCRUM gemanagten Projekt bedeutet dies, dass das SCRUM-Team in regelmäßigen Abständen die Artefakte dahingehend überprüft, ob diese und ihre Ausgestaltung geeignet sind, um das jeweilige SCRUM-Sprint-Ziel zu erreichen. Die Überprüfung darf jedoch nicht so oft stattfinden, dass sie die eigentliche Projektarbeit behindert. Sie muss stets effizient bleiben. Die Überprüfungen müssen in einer Weise stattfinden, dass auch sie einen Mehrwert für die Projektarbeit darstellen. ! Adaption - Anpassung: Adaption bedeutet das Anpassen an die Rahmenbedingungen, um schneller und besser zu werden und das Ziel effizient zu erreichen. Wenn im Rahmen einer Überprüfung festgestellt wird, dass das Vorgehen oder die Arbeitsergebnisse ein nicht akzeptables Limit überschreitet, müssen Anpassungen vorgenommen werden. Diese Anpassungen müssen möglichst kurzfristig, ohne unnötigen Zeitverzug entschieden werden, um unnötige weitere Abweichungen zu verhindern. Fassen wir dies also nochmals zusammen: Die Voraussetzung um Wissen auf der Basis von Erfahrungen in einem Projekt aufzubauen ist Transparenz. Transparenz schafft Wissen. Und eine offene Kommunikation ermöglicht es zudem, dieses Wissen im SCRUM-Team zu teilen. Zudem ist es eine wichtige Säule von SCRUM, dass regelmäßig das aktuelle Handeln und Vorgehen hinterfragt beziehungsweise überprüft werden. Maßstab hierbei ist stets, ob die aktuellen Aktivitäten dazu geeignet sind, dieses Ziel zu erreichen. Und letztlich ist es natürlich auch erforderlich, dass, <?page no="33"?> 2.3 Die fünf Werte von SCRUM 33 wenn das SCRUM-Team im Rahmen der Überprüfung Abweichungen feststellt, das gewählte Vorgehen so angepasst wird und entsprechende Entscheidungen getroffen werden, damit das Ziel auf eine effiziente Weise erreicht wird. Abb. 6: Theorie des Empirismus 2.3 Die fünf Werte von SCRUM Ken Schwaber, einer der beiden Väter von SCRUM, hat zusammen mit Mike Beedle fünf Werte als Fundament für SCRUM entwickelt. Wenn ein SCRUM-Team diese fünf Werte verinnerlicht und umsetzt, ist SCRUM in der Praxis auch erfolgreich. 30n]? ,n #nK >)B,? ,K)=K 3 b 4 c ^ ( 4 b > c E * [ > b ( b * " . c m 4 c ( 4 ^ ^ . c m <?page no="34"?> 34 2 Was ist SCRUM? Denn die fünf Werte sorgen dafür, dass die drei Säulen von SCRUM gelebt werden. Die fünf Werte sind: ! Courage - Mut ! Focus - Fokussierung ! Commitment - Selbstverpflichtung ! Respect - Respekt ! Openness - Offenheit Wir beschreiben diese fünf Werte im Folgenden kurz - in Anlehnung an den SCRUM- Guide. Viele Autoren haben diese Werte näher im Detail beschrieben und konkretisiert. Wir wollen hier jedoch nicht zu viele Vorgaben machen und es dadurch jedem SCRUM-Team selbst überlassen, wie konkret es diese Werte für sich definiert, lebt und umsetzt. Diese Vorgehensweise folgt der grundsätzlichen Logik von SCRUM, einfach zu sein, wenige Regeln aufzustellen und die Ausgestaltung im Sinne der Flexibilität dem Projektteam zu überlassen. Grundsätzlich ist es auch so, dass SCRUM zwar klare Regeln aufsetzt. Im Sinne von Überprüfung und Anpassungen können die Regeln jedoch für jedes Projekt im Detail so konkretisiert werden, dass sie auf das jeweilige Projekt und für das jeweilige Projektumfeld passen. Trotz sehr klarer und eindeutiger Regeln bietet SCRUM demnach Raum zur individuellen Ausgestaltung. Courage - Mut Die Mitglieder des SCRUM-Teams haben den Mut, die richtigen Dinge zu tun und an den Herausforderungen und Problemen im Projekt zu arbeiten. Focus - Fokussierung Jeder fokussiert sich auf die Arbeit des aktuellen Sprints und auf die Ziele des SCRUM-Teams. <?page no="35"?> 2.3 Die fünf Werte von SCRUM 35 Commitment - Selbstverpflichtung Jeder verpflichtet sich, persönlich die Ziele des SCRUM-Teams zu unterstützen und zu erreichen. Respect - Respekt Die Mitglieder des SCRUM-Teams respektieren sich und befähigen sich gegenseitig, kompetente und unabhängige Individuen zu sein. Openness - Offenheit Das SCRUM-Team und seine Stakeholder einigen sich darauf, bezogen auf die Arbeit und die mit dieser verbundenen Herausforderungen offen zu sein. Abb. 7: Die fünf Werte von SCRUM X]=? &Mn 6 d=+ "]A=K 6 "]H=KK,n? ='M X])),+)n'+ 6 ^nGCK+kn? BOG,A0+='M bnKBnA+ 6 bnKBnH+ IBn''nKK 6 IOOn'0n,+ ^Xb.d 3n&) 7 = R <?page no="36"?> 36 2 Was ist SCRUM? 2.4 Agiles Manifest als Basis der SCRUM-Prinzipien Wer sich mit Agilem Projektmanagement beschäftigt, hat sicherlich schon einmal vom „Agilen Manifest“ gehört. Das Agile Manifest ist quasi der gemeinsame Nenner, auf den sich verschiedenste Vertreter von Softwareentwicklungsmethoden im Jahre 2001 geeinigt haben. Insgesamt 17 von ihnen haben hierin ihre gemeinsame Vorstellung bezüglich Agiler Softwareentwicklung zusammengetragen. Zu diesen gehörten auch die SCRUM-Erfinder Jeff Sutherland und Ken Schwaber. Insofern ist in das Agile Manifest auch der Spirit von SCRUM mit eingeflossen. Im Kapitel 8 findest du einen Link zum Agilen Manifest. Das Agile Manifest umfasst insgesamt vier sich gegenseitig gegenübergestellte Wertepaare und zwölf einzelne Prinzipien. Die vier Wertepaare des Agilen Manifests Die Wertepaare des agilen Manifests stellen jeweils zwei Wertepaare paarweise gegenüber. Letztlich schätzen die Verfasser des Agilen Manifests alle diese Werte als wichtig ein. Jedoch werden die Werte auf der linken Seite der Grafik (Abbildung 8) also noch wichtiger als die auf der rechten Seite eingeschätzt. Es ist also eine unterschiedliche Gewichtung vorhanden. Individuen und Interaktionen über Prozesse und Werkzeuge Oft wird in Projekten versucht, Kommunikation oder Fortschritt-Tracking anhand von Tools oder Prozessen zu implementieren. Man versucht also quasi Kommunikation zu organisieren oder auch Prozesse im Projekt zu standardisieren. Mit dem Hintergedanken, dass, wenn alles eindeutig mit Prozessen definiert ist und die richtigen Tools eingesetzt werden, das Projekt erfolgreich sein muss. Die Annahme ist: Der Mensch hat sich also diesen Prozessen und Tools zu „unterwerfen“ - und wenn er dies tut, dann macht dies auch das Projekt erfolgreich. <?page no="37"?> 2.4 Agiles Manifest als Basis der SCRUM-Prinzipien 37 Ab b. 8: Wertepaare des Agilen Manifests Im Gegensatz hierzu geht man im Rahmen des Agilen Manifests davon aus, dass persönliche Kommunikation und Interaktion zwischen Menschen beziehungsweise Projektteammitgliedern immer einer Lösung zuträglich ist. Es werden also quasi weniger ein Tool oder ein Prozess in den Vordergrund gestellt, sondern der Mensch selbst mit seinen ganzen kommunikativen Fähigkeiten und seiner Motivation. Hier geht man davon aus, dass dies ausreicht, um effektiv und erfolgreich in der Projektarbeit zu sein. I3; Q0Q; J93 J3; I3+9! 1O+QF393 5)9! 8 (? ]; nKKn ='# _n? H; n=Mn 6J3O+QF3Q9! 93; 9 NFM+.1! 9 5)9! 8 =)O&KKn'#n? D]H=)n'+&+,]' GFF'9! 1+QF3 4Q+ ; 94 GJ3; 93 5)9! 8 ` n? +? &M Kk n? 0 &' #G =' Mn ' P9 1O+QF 3 1JM : 9 ! D 3; 9! J3A 5) 9! 8 (G &'n? O$GG='M <?page no="38"?> 38 2 Was ist SCRUM? Funktionierende Software über umfassender Dokumentation Letztlich fasst dieses Wertepaar zusammen, dass es letztlich darum geht, ein funktionierendes Produkt beziehungsweise eine funktionierende Software zu entwickeln. Oft wird im Projekt insbesondere in der Fachkonzeption viel Wert auf Dokumentation gelegt. Es werden extrem viele Dokumente wie beispielsweise Fachkonzepte, Fachspezifikationen etc. produziert, die letztlich nur indirekt benötigt werden oder final auch nicht ins Endprodukt eingehen. Das Agile Manifest stellt mit diesem Wertepaar sicher, dass es letztlich nicht um Zwischenberichte, sondern rein um das Endprodukt geht. Und nicht um mehr. Alles andere ist zwar schönes Beiwerk, jedoch nicht primäres Projektziel beziehungsweise Hauptendprodukt des Projektes. Insofern wird hierauf so viel wie möglich verzichtet. Kooperation mit dem Kunden über Vertragsverhandlungen Oft ist es in Rahmen von IT-Projekten so, dass alle Leistungen, die in ein Produkt oder eine Software einfließen müssen, auch vertraglich festgehalten werden. Es geht hierbei auch viel Zeit in die Verhandlung und beispielsweise das nachgelagerte Servicelevel und Servicemanagement. Oft wird gerade bei Dienstleisterbeziehungen mehr darüber diskutiert, welche Leistungen und Produkteigenschaften in einem Vertrag festgehalten werden und welche nicht. Gerade in Projekten der App- und Softwareentwicklung ist so oft viel Zeit in vertragliche und rechtliche Diskussionen geflossen, anstatt einfach weiter am Produkt zu arbeiten beziehungsweise diese Zeit direkt ins Produkt zu investieren. Das Agile Manifest löst sich von dieser sehr vertraglichen und rechtlichen Sicht auf die Produktentwicklung und der Bereitstellung von Dienstleistungen. Es stellt vielmehr den Kunden in den Mittelpunkt. Das oberste Ziel ist, auf pragmatische Weise Lösungen mit dem Kunden zu erarbeiten. Der Maßstab ist absolute Kundenzufriedenheit. Diese wird als höher und wichtiger angesehen als rechtliche Verträge beziehungsweise Vertragsverhandlungen. <?page no="39"?> 2.4 Agiles Manifest als Basis der SCRUM-Prinzipien 39 Reaktion auf Veränderung über Planerfüllung Planung ist ein essenzieller Bestandteil des klassischen Projektmanagements. Es wird viel Zeit mit Projektplanung verbracht, und damit die genaue Erfüllung dieser Pläne. Diese Sicht ist, wenn man die agile „Brille“ aufzieht, sehr starr. Im Rahmen von Agilen Projekten steht die kurzfristige Anpassung und Adaption auf sich verändernde Rahmenbedingungen absolut im Vordergrund. Flexibel zu reagieren hat absoluten Vorrang vor Planerfüllung. Deswegen werden insbesondere in SCRUM auch keine detaillierten Projektpläne für die gesamte Projektlaufzeit erstellt. Vielmehr werden jeweils einzelne Etappen beziehungsweise Sprints „auf Sicht“ geplant, und es erfolgt immer nach einer Etappe iterativ eine Reflektion des Erreichten. Erst danach wird besprochen, welche Ziele in der nächsten Etappe angegangen werden. Die 12 Prinzipien des Agilen Manifests Die 12 Prinzipien im Agilen Manifest konkretisieren die Botschaften aus den vier Wertepaaren. Die in der Abbildung 8 dargestellten Prinzipien wurden dem Agilen Manifest entnommen und so dargestellt, wie du diese auch im Netz finden kannst. Mehr hierzu in Kapitel 8. Wir wollen die Prinzipien an dieser Stelle unkommentiert lassen. Sie stehen so, wie sie formuliert sind, für sich und bedürfen aus unserer Sicht keiner weiteren Konkretisierung oder Interpretation. Kundenzufriedenheit Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen. Anforderungsänderungen als Wettbewerbsvorteil Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen! Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden. <?page no="40"?> 40 2 Was ist SCRUM? Regelmäßige Auslieferung in kurzen Zeitspannen Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne! Tägliche Zusammenarbeit im Projekt Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten. Teams aus motivierten Individuen Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen, und vertraue darauf, dass sie die Aufgabe erledigen! Kommunikation von Angesicht zu Angesicht Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht. Funktionierende Software Funktionierende Software ist das wichtigste Fortschrittsmaß. Nachhaltigkeit Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können. Technische Exzellenz Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität. Einfachheit Einfachheit: die Kunst, die Menge nicht getaner Arbeit zu maximieren, ist essenziell. <?page no="41"?> 2.4 Agiles Manifest als Basis der SCRUM-Prinzipien 41 Selbstorganisierende Teams Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams. Regelmäßige Reflektion und Anpassung In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an. Abb. 9: Prinzipien des Agilen Manifests Quelle: Agiles Manifest (Details siehe Kapitel 8) RQ3 M1 (" "9Q + G J3 ; 93* JM! Q9 ; 93 "9Q + G F4 4 J3 Q O1 +QF 3 0F 3 $3A 9H Q(" + *J $3 A9 HQ(" + ! 9A9K4D>QA9 $JHKQ9M9! J3A Q3 OJ! *93 L9Q+H'13393 <1(""1K+QAO9Q+ ! 9A9K4D>QA9 P9MK9O+QF3 J3; $3'1HHJ3A H9K)H+F! A13QHQ9! 93; 9 ,914H MJ3O+QF3Q9! 93; 9 NFM+.1! 9 +9("3QH("9 RC*9KK93* +DAKQ("9 LJH144931! )9Q+ <?page no="42"?> 42 2 Was ist SCRUM? 2.5 SCRUM Framework Das SCRUM Framework ist quasi die Gesamtheit all dessen, was SCRUM in Summe ausmacht. Wir hatten ja bereits erwähnt, dass es sich bei SCRUM um ein Rahmenwerk handelt. Konkret umfasst das SCRUM-Rahmenwerk fünf Themen, von denen jedes einen bestimmten Zweck im Rahmen eines nach SCRUM gemanagten Projekts erfüllt. Abb. 10: Themen des SCRUM Framework b] GG n' 4? +nO&H+n dnn+,'MK 7 = R ^Xb.d 3n&) P9 A9K3 <?page no="43"?> 2.5 SCRUM Framework 43 ! Team: Gesamtheit aller Personen, die im Rahmen des Projekts nach den Regeln von SCRUM arbeiten. Jedes Teammitglied nimmt eine bestimmte Rolle ein. ! Rollen: Rollen regeln die Aufgaben jedes einzelnen Teammitglieds, je nachdem, zu welcher Rolle es gemäß den nach SCRUM definierten Rollen gehört. Jede Rolle hat konkrete Aufgaben, Rechte und Pflichten. ! Artefakte: Dies sind bestimmte Tools und Techniken, die die Anwendung von SCRUM erfolgreich machen und notwendig sind, den Projektablauf effizient zu gestalten. ! Meetings: Sie regeln Form, Frequenz und Inhalte der Kommunikation zwischen den Rollen und den Mitgliedern im Projekt. ! Regeln: Regeln bestimmen das Zusammenspiel und die Wechselwirkungen der Rollen, Artefakte und Meetings. Letztlich geben die fünf Themen Antworten auf die wesentlichen Fragen im Rahmen des Projektmanagements: ! Artefakte: Sie spiegeln die Produktsicht in SCRUM wider, beziehungsweise die Antwort auf die Frage: Was ist zu tun? ! Rollen: Sie spiegeln die Ressourcensicht in SCRUM wider, beziehungsweise die Antwort auf die Frage: Wer hat es zu tun? ! Meetings: Sie spiegeln die kommunikative Sicht in SCRUM wider, beziehungsweise die Antwort auf die Frage: Wann ist es zu tun? ! Regeln: Sie spiegeln die methodische Sicht in SCRUM wider, beziehungsweise die Antwort auf die Frage: Wie ist es zu tun? <?page no="44"?> 44 2 Was ist SCRUM? Abb. 11: Fragen des Projektmanagements Dieses SCRUM-Rahmenwerk beziehungsweise SCRUM Framework ist in dieser Form auch im von Jeff Sutherland und Ken Schwaber veröffentlichten SCRUM-Guide so beschrieben. Alle weiteren Komponenten und Elemente, die über diese hier genannten Komponenten hinausgehen, wurden von anderen Autoren und von Praktikern im Laufe der Jahre zu SCRUM ergänzt. Es ist absolut nicht zu empfehlen, dass SCRUM durch die Ergänzung anderer Elemente verfälscht wird. Zumindest wenn man ein Projekt rein agil managen will. Elemente aus SCRUM in das klassische Projektmanagement zu übernehmen kann aus unserer praktischen Sicht durchaus Sinn machen. Im Folgenden gehen wir kurz auf den SCRUM-Guide ein. 6! 1A9 79! H'9O+Q09 N? P&= _&K ,K+ ; = +='% (? ]#=H+K,A0+ 4? +nO&H+n _n? 0&+ nK ; = +='% bnKK]=? An'K,A0+ b]GGn' _ &' ' ,K + nK ; = += '% j]))=',H&+,]'KK,A0+ dnn+,'MK _,n ,K+ nK ; = +='% dn+0]#n'K,A0+ bn MnG' <?page no="45"?> 2.6 SCRUM-Guide 45 2.6 SCRUM-Guide Bevor wir uns im nächsten Kapitel damit beschäftigten werden, wie SCRUM funktioniert, wollen wir abschließend an dieser Stelle auf das Thema SCRUM-Guide eingehen. Da die Anfänge von SCRUM schon mehr als 20 Jahre zurückliegen und SCRUM immer erfolgreicher geworden ist, haben sich immer mehr SCRUM-Varianten entwickelt. Dies liegt daran, dass viele Autoren, Berater und Experten von dem immer weiterwachsenden SCRUM-Kuchen ihren wirtschaftlichen Anteil abhaben wollten. So wurde der Kern dessen, was SCRUM ausmacht, immer stärker verfälscht. Dieses Problem haben auch die beiden Väter von SCRUM, Jeff Sutherland und Ken Schwaber, erkannt und aus diesem Grunde im Jahr 2010 den SCRUM-Guide veröffentlicht. Dieser wurde letztmalig in Jahr 2017 überarbeitet. Er fasst den Kern und das Grundverständnis von SCRUM nach Sutherland und Schwaber zusammen. Wir empfehlen jedem, der sich auf die SCRUM Prüfung und Zertifizierung vorbereitet, den SCRUM-Guide durchzulesen. Der SCRUM-Guide ist zwischenzeitlich nicht nur in englischer Sprache erhältlich, sondern auch in mehreren anderen, so auch in deutscher Sprache. Da die Prüfung in englischer Sprache stattfindet, empfehlen wir den SCRUM-Guide in englischer Sprache für die Prüfungsvorbereitung durchzulesen. Aus unserer Sicht ist der SCRUM-Guide sozusagen die Bibel des Agilen Projektmanagements. <?page no="46"?> 46 2 Was ist SCRUM? Abb. 12: SCRUM-Guide SCRUM Guide Table of Contents Purpose of the SCRUM Guide Definition of SCRUM Use of SCRUM SCRUM Theory The SCRUM Team SCRUM Events SCRUM Artefacts Artifact Transparency End Note Acknowledgements Download auf www.scrumguide.com <?page no="47"?> Übungsfragen 47 Übungsfragen zum Kapitel: Was ist SCRUM? - Grundlagen Hinweis: Es können eine oder mehrere Antworten richtig sein. Die Auflösung findest du in Abschnitt 5.5. [11] Der Begriff SCRUM geht zurück auf … " die Wirtschaftswissenschaftler Nonaka und Takeuchi " eine Spielformation auf dem Rugby " einen Spielmodus aus dem American Football " Kei ne der Ant wortm öglic hkei ten ist richt ig [12] Di e Vä t er v on SCRUM sind … " Jeff Schwaber und Ken Sutherland " Ken und Jeff Schwaber " Jeff Sutherland und Ken Schwaber " beide Japaner [13] SCRUM steht für eine Spielformation, bei der … " die Spieler im Rugby nahe zusammenkommen " die Spieler im Rugby eine Doppelspirale bilden " der Trainer den Spielern Instruktionen gibt " der Kapitän den Spielern Instruktionen gibt <?page no="48"?> 48 2 Was ist SCRUM? [14] Entstanden ist SCRUM als ein … " Tool, um Software zu testen " Rahmenwerk für Softwareentwicklungsprojekte " Rahmenwerk für Frameworks " Rahmenwerk, um Prozesse zu optimieren [15] Das SCRUM Rahmenwerk besteht aus: " Werten, Prinzipien, Praktiken und Regeln " nur Prinzipien und Regeln " nur Too ls und W erk ze ugen " Keine der Antwortmöglichkeiten ist richtig [16] Die Theoretische Basis für SCRUM ist die … " Wasserfall-Methode " Theorie der Empirie " Empire of SCRUM " Keine der aufgeführten Möglichkeiten [17] Die Theorie der Empirie besagt, dass … " Wissen auf Erfahrung basiert und Entscheidungen auf Basis von Wissen getroffen werden. " Transparenz die Voraussetzung für Überprüfung ist. " Überprüfung die Voraussetzung für Anpassung ist. " Keine der aufgeführten Antwortmöglichkeiten. <?page no="49"?> 2.*4#-%/ 0#'4 49 ['8] Die Theorie der Empirie basiert auf drei Schritten: " Üben, lernen, üben " Transparenz, Intransparenz, Entscheidungen " Transparenz, Überprüfung und Anpassung " Transparency, Inspection und Adaption ['9] Die fünf Werte nach SCRUM sind … " Mut, Fokus, Glück, Selbstverpflichtung, Respekt " Mut, Fokus, Selbstverpflichtung, Respekt, Offenheit " Courage, Focus, Commitment, Respect, Openness " Keine der Antwortmöglichkeiten ist richtig [&0] Das Agile Manifest … " wurde von verschiedensten Vertretern von Softwareentwicklungsmethoden gemeinsam entwickelt " besteht aus sich gegenübergestellten Wertepaaren " besteht aus Wertepaaren von denen eines jeweils als wichtiger als das andere angesehen wird " Keine der Antwortmöglichkeiten ist richtig [&1] Es gibt fünf Komponenten im SCRUM Framework. Diese sind: " Rollen, Artefakte, Meetings, Regeln und das SCRUM-Team <?page no="50"?> 50 2 Was ist SCRUM? " Product Owner, SCRUM Master, Product Master, SCRUM Owner und Entwicklungsteam " Sprint, Sprint Planning, Daily SCRUM, Sprint Review, Sprint Retrospektive " Keine der Antwortmöglichkeiten ist richtig [&2] Die Komponenten geben Antworten auf die folgenden wichtigen Fragen im Projektmanagement: " Artefakte: Was ist zu tun? " Rollen: Wer hat es zu tun? " Meeting: Wann ist es zu tun? " Regeln: Wie ist es zu tun? [&3] Der SCRUM-Guide … " ist die Zusammenfassung dessen, was die SCRUM-Väter Jeff Sutherland und Ken Schwaber unter SCRUM verstehen " ist ein von allen Vertretern des Agilen Managements verfassten Manifest zu den wichtigsten Agilen Regeln im Projektmanagement " wurde erstmalig im Jahr 2010 veröffentlicht " wurde zuletzt im Jahr 2018 aktualisiert [&4] Der SCRUM-Guide … " ist nur in englischer Sprache verfügbar " ist in mehreren Sprachen auch autorisiert verfügbar " ist ein Glossar der wichtigsten Begriffe von Agilität <?page no="51"?> 2.*4#-%/ 0#'4 51 " Keine der Antwortmöglichkeiten ist richtig [&5] Wichtige Wertepaare gemäß dem Agilen Manifest sind … " funktionierende Software " Individuen und Interaktionen " Kooperation mit dem Kunden " Reaktion auf Veränderung <?page no="53"?> 3 Wie funktioniert SCRUM? Im Folgenden erklären wir, wie SCRUM funktioniert, also welche Methoden und Techniken im Rahmen das SCRUM Frameworks zum Einsatz kommen. Der Kern von SCRUM ist aus unserer Sicht der SCRUM-Prozess. Dieser Begriff stammt nicht von den Vätern von SCRUM, sondern wurde von uns aus didaktischen Gründen definiert. Im Rahmen des SCRUM-Prozesses wird im Wesentlichen dargestellt, welche Meetings und welche Artefakte wie zusammenspielen und in welchem zeitlichen Verlauf erfolgen. Letztlich zeigt der SCRUM-Prozess, wann welche Meetings stattfinden und welche Artefakte wann zum Einsatz kommen. Die einzelnen Rollen gemäß SCRUM stehen während des gesamten SCRUM-Prozesses in Interaktion. Um einen Gesamtüberblick von Artefakten und Meetings der jeweils zum jeweiligen Zeitpunkt eingebundenen Rollen zu bekommen, haben wir den SCRUM Framework-Überblick erstellt. Diesen findest du in Abschnitt 3.5. Er umfasst einen Gesamtüberblick über das Zusammenspiel dieser drei Elemente und geht insbesondere darauf ein, wie die Rollen im Rahmen des Prozesses jeweils aktiv werden. Diese Übersicht eignet sich auch optimal für die Prüfungsvorbereitung. 3.1 SCRUM-Prozess Der SCRUM-Prozess beginnt, wenn ein oder einige Stakeholder ein Produkt benötigen. Was die Stakeholder von SCRUM-Team unterscheidet, ist in Abschnitt 3.5 nachzulesen. Die Anforderungen an das Produkt werden dann in einem so genannten Product Backlog gesammelt. Das Product Backlog ist also die Zusammenfassung aller Produkteigenschaften, die das finale Produkt umfassen sollte. Nachdem das Product Backlog vollständig ist, beginnt man mit der Sprint-Planung. <?page no="54"?> 54 3 Wie funktioniert SCRUM? Hier wird geplant, welche Produktfeatures im kommenden Sprint umgesetzt werden sollen. Diese Teilmenge der Produkteigenschaften wird dann in ein Sprint Backlog überführt. Das Sprint Backlog umfasst somit alle Produkteigenschaften die im kommenden Sprint umgesetzt werden sollen. Diese sind sozusagen das Sprint-Ziel. Danach beginnt der Spint. Der Sprint ist die eigentliche Phase der Produktentwicklung. Im Rahmen der Produktentwicklung erfolgt dann ein täglicher Austausch des SCRUM-Teams im Rahmen des Daily SCRUM. Nach Abschluss des Sprints sollten als Ergebnis neue Produkteigenschaften für das Produktinkrement hervorgebracht werden. Ein Produktinkrement ist hierbei ein fertiger Teil des Gesamtproduktes. Nach dem Sprint besteht die Möglichkeit des Überprüfens und Anpassens in Form eines Sprint-Reviews. Hierbei wird das Produkt, das entwickelt wird, überprüft und gegebenenfalls angepasst. So besteht einerseits die Möglichkeit für alle, die nicht selbst am Entwicklungsprozess beteiligt waren, Informationen über den aktuellen Entwicklungsstand zu erhalten, wie beispielsweise die Stakeholder. Alle diejenigen, die an der Entwicklung direkt beteiligt waren, erhalten so das Feedback, inwiefern sie sich mit der Arbeit im letzten Sprint bezogen auf die Produkteigenschaften des gesamten Produkts angenähert haben. Die folgende Übersicht bringt die im Rahmen des SCRUM Prozesses beschriebenen Artefakte (A) und Meetings (M) in eine Zeitliche Reihenfolge: ! Product Backlog (A) ! Sprint Planning (M) ! Sprint Backlog (A) ! Sprint (M) ! Daily SCRUM ! Sprint Review (M) ! Inkrement (A) ! Sprint Retrospektive (M) <?page no="55"?> 3.1 SCRUM-Prozess 55 Abb. 13: SCRUM-Prozess Sprint SCRUM zeichnet sich durch sein iteratives beziehungsweise zyklisches Vorgehen aus. Die Umsetzung und Entwicklung der einzelnen Elemente des Gesamtproduktes - oder wie man im SCRUM sagt: Produktinkremente - erfolgt jeweils im Rahmen eines Sprints. Ein Sprint ist demnach eine Iteration. Innerhalb eines Sprints arbeitet das Entwicklungsteam daran, eine bestimmte Anzahl von Eigenschaften des Produkts abzuarbeiten und umzusetzen. Der Sprint ist somit quasi das Herz von SCRUM. Was genau ein Sprint ist, und wie genau ein Sprint funktioniert, werden wir im Abschnitt 3.3 beschreiben. PFKK93 =99+Q3AH $! +9 M 1O+ 9 7! F; J(+ #.39! R3+.Q(OKJ3AH+914 N? P&= =1H+9! N'! Q3+ N'! Q3+ 7K133Q3A %1QKB N? P&= N'! Q3+ P90Q9. N'! Q3+ P9+! FH'9O+Q09 7! F; J(+ @1(OKFA I3 O! 9493+ N'! Q3+ @1(OKFA 2 / 2 7! F; J(+ @1(OKFA N'! Q3+ @1(OKFA I3O! 9493+ N'! Q3+ N'! Q3+ 7K133Q3A %1QKB N? P&= N' ! Q 3+ P9 0Q 9. N'! Q3+ P9+! FH'9O+Q09 <?page no="56"?> 56 3 Wie funktioniert SCRUM? Releases Stakeholder haben oft einen anderen Anspruch an die über den Entwicklungsfortschritt zur Verfügung gestellten Informationen als das Projektteam. Stakeholder haben eher einen aggregierten gesamthaften Blick auf das Produkt. Im Rahmen der Information an die Stakeholder ist es deshalb notwendig, eine andere Granularität zu verwenden, als sie in Sprints vorzufinden sind. Stakeholder haben meist weniger ein Interesse an den einzelnen Sprint-Zielen beziehungsweise einzelnen Einträgen im Product Backlog, die in einem Sprint umgesetzt werden. Sie haben mehr ein Interesse an gesamten Funktionen und Funktionsgruppen. Insofern ist es notwendig, in der Kommunikation gegenüber Stakeholdern die einzelnen Sprints zu mehreren Releases zusammenzufassen. Abbildung 14 zeigt, wie diese aussehen kann. Abb. 14: Sprints und Releases 6J3O+QF393 N'! Q3+ LQ9K 7! F; J(+ @1(OKFA I+94H P9K91H9 P9K91H9 P9K91H9 N'! Q3+ N'! Q3+ N'! Q3+ N'! Q3+ N'! Q3+ N'! Q3+ <?page no="57"?> 3.1 SCRUM-Prozess 57 Diese Releases sollten dann nach Funktionen oder Funktionsgruppen strukturiert werden. Diese wiederum sollten auf einer Zeitachse dargestellt werden, so dass die Stakeholder nachvollziehen können, welche Features mit welchem zeitlichen Horizont umgesetzt werden. Diese Sicht der Releases ist so nicht in SCRUM selbst definiert, jedoch eine gängige gelebte Praxis in Projekten. <?page no="58"?> Übungsfragen zum Kapitel: „Wie funktioniert SCRUM? - SCRUM Prozess“ Hinweis: Es können eine oder mehrere Antworten richtig sein. Die Auflösung findest du in Abschnitt 5.5. [26] Der SCRUM Prozess beschreibt … " die Rollen, die in SCRUM relevant sind. " welche Tools im Sprint Planning verwendet werden. " das Zusammenspiel von Meetings und Artefakten. " Keine der Antwortmöglichkeiten ist richtig. [27] Der SCRUM Prozess beginnt … " wenn das Daily SCRUM beendet wurde. " immer mit jedem Kalenderjahr. " wenn Stakeholder ein Produkt fordern oder das Projekt initiieren. " möglichst an einem Montag. [28] Elemente des SCRUM-Prozesses sind: " Artefakte, Rollen und Meetings. " nur Sprint Planning und Sprint Review. " nur Artefakte und Meetings. " die beiden Rollen: Product Owner und SCRUM Master. [29] Die Meetings und Artefakte des SCRUM-Prozesses … " dienen dazu, fortlaufend Transparenz zu schaffen, um zu überprüfen und anzupassen. " sind alle in der Verantwortung des Product Owners. " werden alle vom SCRUM Master gepflegt und organisiert. " Keine der Antwortmöglichkeiten ist richtig. 5% 3 Wie funktioniert SCRUM? <?page no="59"?> 2.*4#-%/ 0#'4 59 [30] Als ersten Schritt im SCRUM-Prozess … " nimmt der Product Owner die Anforderungen der Stakeholder auf und erstellt das Product Backlog. " führt der Product Owner den Sprint Review durch. " wird ein erstes Daily SCRUM als Kick off durchgeführt. " Keine der Antwortmöglichkeiten ist richtig. [31] Das Product Backlog … " wird vom Product Owner gemanagt und enthält alle wesentlichen Produktf ea tur es. " wird vom SCR UM-Tea m gepflegt, um immer aktuelle Transpare nz sicherz ustellen. " wird im Sprint dazu verwendet, die einzelnen Tasks im Sprint zu managen. " Keine der aufgeführten Möglichkeiten. [32] Das Sprint Backlog … " wird vom SCRUM Master gemanagt und erstellt. " dient dem Entwicklungsteam dazu, während des Sprints seine Aufgaben operativ zu managen. " ersetzt dauerhaft das Product Backlog, nachdem dieses einmalig und initial erstellt wurde. " Keine der aufgeführten Antwortmöglichkeiten. [33] Im Rahmen des Sprints … " erfolgt einmal täglich das Daily SCRUM, damit sich das Entwicklungsteam abstimmen und synchronisieren kann. <?page no="60"?> 60 3 Wie funktioniert SCRUM? " erfolgt täglich der Sprint Review, um den Projektfortschritt zu messen. " ist nur das Entwicklungsteam in die Meetings eingebunden, um nicht in der Entwicklungsarbeit gestört zu werden. " Keine der Antwortmöglichkeiten ist richtig. [34] Nachdem die Entwicklungsarbeit im Sprint durchgeführt wurde, … " erfolgt der Sprint Review, um zu überprüfen, was im letzten Sprint erreicht wurde. " erfolgt ein erneutes Sprint Planning, um den Plan auf dem neuen Entwicklu ngss ta nd zu a ktual is ier en. " wird weiterhin ein Daily SCRUM durchgeführt, um regelmäßig Feedback zu m ab gela uf en en Entw ickl ung spr ozes s zu s amm eln. " Keine der Antwortmöglichkeiten ist richtig. [35] Die Sprint Retrospektive … " dient dazu, die aktuelle Qualität des Produkts zu überprüfen. " dient dazu, Feedback zum Entwicklungsprozess zu sammeln. " dient dazu, Verbesserungsmaßnahmen zu erarbeiten. " Keine der Antwortmöglichkeiten ist richtig. [36] Der Sprint Prozess ist: " der zeitliche Ablauf von Meetings und dem Einsatz von Artefakten. " in der Verantwortung des Product Owners. " in der Verantwortung der Stakeholder. " Keine der Antwortmöglichkeiten ist richtig. <?page no="61"?> 3.1 SCRUM-Prozess 61 [37] Meetings im Rahmen des SCRUM-Prozesses sind: " nur Daily SCRUM und der Sprint " nur Sprint Planning und Sprint Review " Sprint Planning, Sprint, Daily SCRUM, Sprint Review und Sprint Retrospektive " immer maximal 15 Minuten lang [38] Der zeitliche Ablauf der Meetings im SCRUM Prozess ist … " Sprint Review, Sprint Planning, Sprint, Sprint Retrospektive " Spri nt Pla nni ng, Spri nt, D aily SCR UM, Spr int Re view, Sp rin t Ret ros pek tive " Sprint Planning, Daily SCRUM, Sprint Retrospektive, Sprint, Sprint Review " Sprint Retrospektive, Sprint Planning, Sprint, Daily SCRUM, Sprint [39] Die Artefakte im Rahmen des Sprint Prozesses werden in folgendem zeitlichen Ablauf relevant … " Inkrement, Daily SCRUM, Product Backlog " Sprint Backlog, Inkrement, Product Backlog " Daily SCRUM, Inkrement, Product Backlog " Product Backlog, Sprint Backlog, Inkrement [40] Releases … " bestehen immer aus je einem Sprint. " bestehen aus mindestens einem Sprint. " bestehen unbedingt aus mehr als einem Sprint. " können aus einem oder aus mehreren Sprints bestehen. <?page no="62"?> 3.2 Rollen SCRUM kennt eine sehr einfache und übersichtliche Definition der unterschiedlichen Rollen im Rahmen des SCRUM-Frameworks. Für jede dieser Rollen ist ganz klar beschrieben, was ihre Aufgaben sind und welche Kompetenzen und Verantwortungen sie haben. Es ist wichtig, dass jedes Mitglied des SCRUM-Teams weiß, welche Rolle es hat und welche Erwartungen an diese Rolle gestellt werden. Dies ist notwendig, um SCRUM erfolgreich umzusetzen. Gelten die Werte nach SCRUM für alle Mitglieder des SCRUM-Teams einerseits, so definieren die Rollen für jedes einzelnes Teammitglied andererseits ganz konkret und individuelle pro Rolle deren Aufgaben. SCRUM-Team Das SCRUM-Team arbeitet sehr selbstorganisiert und interdisziplinär. Letztlich geht man gemäß SCRUM davon aus, dass das SCRUM-Team hoch motiviert ist und selbstständig entscheiden kann, wie es das jeweilige Ziel erreicht. Es erledigt seine Arbeit, ohne dabei auf Personen von außerhalb des SCRUM-Teams angewiesen sein zu müssen. Zudem sind SCRUM-Teams interdisziplinär. Interdisziplinär bedeutet hierbei, dass die Teams interdisziplinär bezüglich ihrer Fähigkeiten und Fertigkeiten gemischt sind. Oft werden in Projekten, die nicht nach SCRUM gemanagt werden, einzelne Teilprojekte nach Funktionsträgern oder Fachbereichen gebildet. Ein Beispiel hierfür ist ein Teilprojekt für die Produktstrategie und ein Teilprojekt für die IT-Umsetzung. In SCRUM werden diese einzelnen Personen und Themen alle gemeinsam in einem Team vereint. Eine Trennung in Teilprojekte gibt es so nicht mehr. Im SCRUM-Team gibt es eine klare Rollendefinition. Jedes Teammitglied weiß genau, welche Rolle es ausführen soll. '( 3 Wie funktioniert SCRUM? <?page no="63"?> 3.2 Rollen 63 Abb. 15: SCRUM Rollen im Überblick Charakteristika von Teams Teams gemäß SCRUM haben ganz spezielle Charakteristika, die aus unserer Sicht einen der wesentlichsten Unterscheidungsmerkmale gegenüber Teams in einer klassischen oder hierarchischen Projektmanagementmethodik darstellen. Wie die Teams arbeiten und sich organisieren, weicht wesentlich von der Wasserfall- Methode ab. Voraussetzungen Product Owner klare Rollendefinition SC RU M M as te r interdisziplinär En t w ic k lun gs te am selbstorganisierend autonomes Arbeiten Rollen SCRUM Team P M E <?page no="64"?> 64 3 Wie funktioniert SCRUM? Selbstorganisation SCRUM-Teams organisieren sich selbst. Das bedeutet, dass sie nicht wie beim klassischen Projektmanagement durch einen Projektleiter gesteuert oder koordiniert werden. Es erfolgt keinerlei steuernder Eingriff in das Team von außerhalb. Innerhalb des Sprints trifft das Team alle wesentlichen Entscheidungen selbst, insbesondere dahingehend, wie es seine Aufgaben am besten erledigt. Das oberste Ziel ist hierbei das Ziel des Sprints zu erreichen und die im Sprint Backlog aufgeführten Backlog Items abzuarbeiten und zu entwickeln. Interdisziplinarität In der Vergangenheit wurden Projektteams oft nach Stelle oder nach Titel zusammengestellt. So wurden Projektteams oft in einer Weise kombiniert, dass das gesamte Management im Rahmen eines Lenkungsausschusses seinen Input innerhalb des Projektteams gibt. Alternativ wurden Projekte in Teilprojekte gegliedert - und zwar nach Themen wie „Konzeption“, „Vertrieb“, „Umsetzung“ und „Testing“. Hierdurch entstand jeweils eine wechselseitige Abhängigkeit der Teilprojekte, so dass das gesamte Projekt nur vorankam, wenn auch Koordination und Kommunikation zwischen den Teilprojekten stattfinden, beziehungsweise organisiert werden. Bei SCRUM setzt sich das Team selbst bereits aus unterschiedlichen Funktionsträgern zusammen, die alle zusammen die Projektarbeit erledigen können, ohne dass auf Kompetenzen außerhalb des SCRUM-Teams zurückgegriffen werden muss. Optimierung von Flexibilität, Kreativität und Produktivität SCRUM-Teams werden so konzipiert, dass sie in ihrer Zusammenarbeit die Flexibilität, Kreativität und Produktivität optimieren. SCRUM-Teams sind nicht nur innerhalb von agilen Projekten effektiv, sondern auch in anderen Kontexten und komplexer Arbeit. SCRUM-Teams arbeiten iterativ und inkrementell, um die Möglichkeit von <?page no="65"?> 3.2 Rollen 65 Feedback zu maximieren. Das bedeutet, dass es immer wieder Abstimmungen gibt, um Anpassungen vorzunehmen. Klare Rollendefinition Innerhalb des SCRUM-Teams gibt es eine klare Rollendefinition. Das bedeutet, dass sich jede Rolle von der anderen Rolle klar durch eindeutig festgelegte Aufgaben, Kompetenzen und Verantwortung abgrenzt. Jeder in einem SCRUM-Team weiß, welche der drei Rollen - SCRUM Product Owner, SCRUM Master und Entwicklungsteam - er hat und was seine damit verbundenen Erwartungen sind. SCRUM Stakeholder Das SCRUM-Framework kennt insgesamt drei Rollen, diese werden in ihrer Gesamtheit als SCRUM-Team bezeichnet. Alle diejenigen, die nicht Teil des SCRUM-Teams sind, jedoch ein Interesse an der Entwicklung des Produktes bzw. Wissen über das Produkt haben, werden Stakeholder genannt. Stakeholder sind also nicht Teil des SCRUM-Teams selbst. Und dennoch nehmen sie am SCRUM-Prozess in jeweils unterschiedlicher Weise teil. Typische Stakeholder in SCRUM-Projekten sind: ! Kunden ! Benutzer ! Management ! Projektleiter (Projektleiter anderer Projekte, die nicht Teil des SCRUM-Teams sind) Weitere Rollen kennt SCRUM im Kern nicht. Dennoch gibt es für das Management größerer Einheiten und mehrerer Teams, andere Frameworks, wie beispielsweise das Scaled Agile Framework oder das Large Scale SCRUM. Diese stellen Weiterentwicklungen von SCRUM dar und gehen nur teilweise auf die Väter von SCRUM zurück. Wie gesagt sind diese Frameworks nicht Kern der eigentlichen Methode <?page no="66"?> 66 3 Wie funktioniert SCRUM? SCRUM. Deswegen werden wir auf diese auch nicht weiter an dieser Stelle eingehen. In SCRUM gibt es lediglich drei Rollen, welche sich auch absolut als ausreichend zum Management eines SCRUM Projekts erwiesen haben. Abb. 16: SCRUM-Team und Stakeholder Der Product Owner ist das Bindeglied zwischen den Stakeholdern und dem SCRUM-Team. Er repräsentiert die Anforderungen der Stakeholder im SCRUM Team und stellt so die Lieferung eines anforderungsgerechten Produkts sicher. E M P Benutzer Kunden Management SCRUM Team Stakeholder Lieferung Repräsentation <?page no="67"?> 3.2 Rollen 67 Überblick der drei Rollen von SCRUM SCRUM kennt im Kern nur drei Rollen. Den Product Owner, den SCRUM Master und das Entwicklungsteam. Die Hauptaufgaben dieser Rollen sind die folgenden: ! Product Owner: Er vertritt die Interessen des Auftraggebers oder des Kunden. Er ist verantwortlich für den geschäftlichen Erfolg des Produkts. Wir sprechen in diesem Zusammenhang gerne auch vom „Chefproduktentwickler“. Mehr hierzu später. ! SCRUM Master: Er ist die dienende Führungsperson und verantwortlich für die Implementierung der SCRUM-Regeln. Wir sprechen hier gerne vom Regelhüter, Moderator und Coach. In englischer Sprache wir oft von "Servant Leader" gesprochen. ! Entwicklungsteam: Dieses entwickelt das Produkt. Es ist verantwortlich dafür, sich selbst so zu organisieren, um das jeweilige Ziel des Sprints zu erreichen. Das Entwicklungsteam ist das Herz von SCRUM. Es ist für den wichtigsten Teil im Rahmen eines SCRUM-Projektes zuständig: das Entwickeln des Produktes. Die konkreten Aufgaben, Kompetenzen und Verantwortlichkeiten werden im Nachfolgenden vorgestellt. An dieser Stelle wollen wir kurz die Unterschiede zwischen diesen drei Themen darstellen: ! Aufgaben: In einer Rolle nach SCRUM werden dauerhaft bestimmte Aufgaben zur Ausführung der Projekt und Entwicklungsarbeit gebündelt. Jede Rolle ist also für den gesamten Zeitraum des Projekts für einen bestimmten Aufgabenbereich zuständig. ! Kompetenzen: Als Kompetenzen werden die einer Rolle zugewiesenen Rechte und Befugnisse bezeichnet. Die Rolle hat also das Recht, während des Projektes bestimmte Entscheidungen zu treffen oder auch bestimmte Themen umzusetzen. <?page no="68"?> 68 3 Wie funktioniert SCRUM? ! Verantwortung: Unter Verantwortung versteht man die Pflicht der Rolle, für die Folgen ihrer Entscheidungen und Handlungen einzustehen. Im Projekt hat die Rolle während der gesamten Laufzeit die Pflicht hierfür Verantwortung zu übernehmen. Dieses Thema hat eine große Überschneidung mit den Aufgaben. Eine Abgrenzung zwischen Aufgaben und Verantwortung ist nur schwer möglich. Abb. 17: Beschreibung SCRUM-Rollen 7! F; J(+ #.39! N? P&= =1H+9! R3+.Q(OKJ3AH+914 N ? P& = ,914 7 = R = R 7 2 ? "9M 7! F; JO+93+.Q(OK9! 2 : 9! 13+.F! +KQ(" M5! A9H("DM+KQ("93 R! MFKA ; 9H 7! F; JO+ 2 N9! 013+ E91; 9! 2 : 9! 13+.F! +KQ(" M5! I4'K9493+Q9! J3A ; 9! N? P&= P9A9K3 2 7! F; JO+93+.Q(OKJ3A 2 : 9! 13+.F! +KQ(" M5! N9K)H+F! A13QHQ9! +9H $! )9Q+93 14 7! F; JO+ <?page no="69"?> 3.2 Rollen 69 Product Owner Der Produkt Owner ist für das „Was“ zuständig. Was wird umgesetzt, um den Wert des Produktes zu maximieren? Er hat die folgenden Aufgaben, Verantwortungen und Kompetenzen: Aufgaben des Product Owners Der Product Owner ist während des gesamten SCRUM-Prozesses sehr aktiv eingebunden. Er hat zu Beginn des SCRUM-Prozesses die Aufgabe, in Abstimmung mit den Stakeholder die Ausstattungsmerkmale des zu entwickelnden Produktmerkmale abzustimmen. Zudem hat er diese Produktmerkmale dann entsprechend auch strukturiert in Form eines Product Backlogs zu managen. Sein wesentliches Werkzeug ist das Product Backlog. Während der Produktentwicklung selbst zieht er sich etwas zurück und überlässt die wichtigsten Entscheidungen dem Entwicklungsteam selbst. Nach einem Sprint beziehungsweise zum Ende des Sprints wird er wieder aktiver in der Form, dass er seinen Blick darauf lenkt, ob im Rahmen der Entwicklungsarbeit die wichtigsten Product Backlog Items abgearbeitet wurden. Konkret hat er die folgenden Aufgaben: ! Wertmaximierung des Produkts ! Wert der Arbeit des Entwicklungsteams optimieren ! Product Owner kann diese Aufgaben alleine erfüllen oder delegieren ! Product Owner bleibt jedoch verantwortlich ! Hat eine Vision für das Produkt und brennt für das Produkt Kompetenzen des Product Owners Der Product Owner hat die Kompetenz für die folgenden Themen: <?page no="70"?> 70 3 Wie funktioniert SCRUM? ! Er hat die Kompetenz, als einziger im SCRUM-Team dem Entwicklungsteam Aufgaben zu übertragen. Die Verantwortung zum Management des Product Backlogs bleibt zu jeder Zeit bei ihm. ! Er handelt im Sinne der Stakeholder, wie beispielsweise des Kunden und des Managements, beziehungsweise er vertritt deren Interessen im Rahmen des SCRUM-Prozesses. Er hat alle Vollmachten vom Kunden und vom Management. ! Dem Product Owner „gehört“ quasi das Produkt. Im Idealfall ist er auch derjenige, der über das Budget verfügt, das notwendig ist, um das Produkt zu entwickeln. ! Er ist Eigentümer des Product Backlogs und legt die Kompetenz die Backlog Items im Product Backlog fest bzw. priorisiert sie. Verantwortung des Product Owners Der Product Owner ist verantwortlich für die folgenden Themen: ! Verantwortung für den finanziellen Erfolg des Produktes ! Wertmaximierung des Produktes allgemein und in jedem Sprint ! Arbeit des Entwicklungsteams ! Management und Pflege des Product Backlogs ! Einträge im Product Backlog müssen klar formuliert werden ! Einträge im Product Backlog sollen so sortiert werden, dass Ziele und Missionen optimal erreicht werden ! Die gesamte Organisation muss den Product Owner respektieren ! Entscheidungen des Product Owner müssen in Inhalt und Reihenfolge des Product Backloks sichtbar sein. ! Der Product Owner ist eine Rolle im SCRUM-Team, die nur von einer einzelnen Person durchgeführt werden darf. Dies hat den Grund, dass nur so sichergestellt werden kann, dass es immer eine eindeutige Priorisierung der Backlog Items <?page no="71"?> 3.2 Rollen 71 gibt. Zudem gibt es so stets klare Antworten auf Fragen sowohl des Entwicklungsteams als auch der Stakeholder. Er hat zudem die Verantwortung, die Ziele und Anforderungen der Stakeholder zu bündeln und im Rahmen der Entwicklungsarbeit zu vertreten. Abb. 18: SCRUM Product Owner ! Aus diesem Grund hat der Product Owner quasi zwei Gesichter; eines, das den Stakeholdern zugewandt ist: Hier geht es darum, fortlaufend die Anforderungen der Stakeholder zu verstehen, zu sortieren und bündeln. Und ein weiteres Gesicht, das dem Entwicklungsteam zugewandt ist: Hier ist seine Aufgabe, die Entwicklungsarbeit durch klare Vorgaben im Product Backlog effizient zu gestal- • Chef-Produktentwickler • Zuständig für das Was ist zu tun? • Wie kann Wert maximiert werden? • Verantwortlich für geschäftlichen Erfolg des Produktes Product Owner Aufgaben P • Abstimmung mit Stakeholdern • Produkteigenschaften priorisieren • Product Backlog managen • Entwicklungsarbeit abnehmen Kompetenzen • Übertragung Aufgaben Entwicklungsteam • Alle Vollmachten bezogen auf Produkt • Eigentümer des Produkts mit Budget • Pflege des Product Backlogs Verantwortung • Finanzieller Erfolg des Produktes • Wertmaximierung in jedem Sprint • Arbeit des Entwicklungsteams • Management und Pflege Product Backlog <?page no="72"?> 72 3 Wie funktioniert SCRUM? ten. Und auch Entwicklungsergebnisse nach klar definierten „Definition of Done“ zu bewerten beziehungsweise abzunehmen. ! Nach dem Sprint nimmt der Product Owner im Sprint Review die Ergebnisse nach vorher definierten Kriterien ab (Definition of Done) SCRUM Master Der SCRUM Master ist quasi für alles, was ein SCRUM-Projekt zu einem SCRUM- Projekt charakteristisch macht, verantwortlich: die SCRUM-Regeln. Er stellt sicher, dass alles während des Sprints nach den Regeln von SCRUM abläuft. Die wichtigsten dieser Regeln sind im SCRUM-Guide zusammengefasst (siehe Abschnitt 2.6). Aufgaben des SCRUM Master Der SCRUM Master wird auch als „Servant Leader“ bezeichnet. Übersetzt heißt dies, dass er eine „dienende Führungskraft“ ist. Was bedeutet das? In SCRUM gibt es keinen mit Führungskompetenzen ausgestatteten Projektleiter beziehungsweise Projektmanager. Jedoch hat der SCRUM Master viele Aufgaben, die sonst einen klassischen Projektmanager zugesprochen würden. Denn er hat den gesamten Prozess und seine Kommunikations- und Meetingstrukturen nach den Regeln von SCRUM zu gestalten. Hierbei ist seine Rolle die eines Coachs beziehungsweise eines Moderators. Er hat die Aufgabe, die anderen Teammitglieder im SCRUM-Team dazu zu befähigen die Regeln von SCRUM für eine möglichst effiziente Projektarbeit anzuwenden. Er hat auch dafür Sorge zu tragen, allen, die nicht Teil des SCRUM-Teams sind, zu vermitteln, wie die Interaktion mit dem SCRUM-Team erfolgreich sein kann. Zudem unterstützt er alle dabei, diese Interaktionen so zu gestalten, dass sie einen maximalen Wert der Arbeit des SCRUM-Teams sicherstellen. <?page no="73"?> 3.2 Rollen 73 Abb. 19: SCRUM Master Verantwortung des SCRUM Master Der SCRUM Master hat für die folgenden Themen Verantwortung: ! Er ist dafür verantwortlich, dass alle Beteiligten die SCRUM-Theorie, Praktiken, Regeln und Werte verstehen. ! Botschafter innerhalb der Organisation für alles rund um das Thema SCRUM ! Er ist dafür zuständig, die Zusammenarbeit zu optimieren, so dass der generierte Wert des SCRUM-Teams maximiert wird. • Servant Leader • Regelhüter nach SCRUM • Zuständig für die Regeleinhaltung • Moderator und Coach SCRUM Master Aufgaben M • Effiziente Anwendung der SCRUM Regeln • Initiierung Kommunikation und Meetings • Befähigung zu Erfolgreicher Interaktion mit allen außerhalb des SCRUM Teams Kompetenzen • Hinweis bei Nichtanwendung Regeln • Maßnahmen zu ergreifen die das Wissen über die SCRUM Regeln und ihre Anwendung verbessern Verantwortung • Botschafter für SCRUM in der Organisation • Verständnis Werte, Regeln und Praktiken im SCRUM Team schaffen • Zusammenarbeit im Team optimieren <?page no="74"?> 74 3 Wie funktioniert SCRUM? Kompetenzen des SCRUM Master Der SCRUM Master hat die folgenden Themen als Kompetenz: ! Der SCRUM Master hat die Kompetenz, alle SCRUM-Teammitglieder darauf hinzuweisen, wenn SCRUM-Regeln nicht richtig angewendet wurden. ! Zudem hat er die Kompetenz, jederzeit Maßnahmen zu ergreifen, die dazu notwendig sind, das Verständnis der SCRUM-Regeln im SCRUM-Team zu stärken und so auch deren Anwendung zu verbessern. Da der SCRUM Master diese unterstützende Funktion im Rahmen des SCRUM- Prozesses hat, werden seine Aufgaben im Folgenden so strukturiert, dass deutlich wird, welche Aufgaben er unterstützend für die anderen Rollen innerhalb des SCRUM-Teams hat und welche auch für alle außerhalb des SCRUM-Teams. Grundsätzliche Aufgaben des Masters Der SCRUM Master ist somit der Regelhüter im Rahmen des SCRUM-Prozesses. Er hat zu jedem Zeitpunkt im Rahmen der Entwicklungsarbeit, der Meetings etc. sicherzustellen, dass alle Beteiligten sich an die Regeln gemäß SCRUM-Guideline halten, und auch alle Meetings in der entsprechenden Form stattfinden. Er fungiert hierbei als Moderator und Coach. Dies bedeutet, dass er zu keiner Zeit als Projektmanager oder Projektleiter agiert; seine Aufgabe ist lediglich unterstützend im SCRUM-Prozess. Sein Ziel ist es, dass er das SCRUM-Team befähigt, nach den Regeln von SCRUM zu arbeiten und effizient zu sein. Aufgaben des Masters für den Product Owner Der SCRUM Master unterstützt den Product Owner wie folgt: ! Er stellt sicher, dass jeder im SCRUM-Team die Ziele, den Umfang und den Anwendungsbereich des Produktes versteht. <?page no="75"?> 3.2 Rollen 75 ! Er unterstützt durch Anwendung von Techniken und Methoden, damit der Product Owner das Product Backlog effektiv managen kann. ! Unterstützung des SCRUM-Teams, den Nutzen und die Notwendigkeit von klar definierten Product Backlog Items zu verstehen. ! Er schafft Verständnis, dass die Produktplanung ein empirischer Prozess ist. ! Er stellt sicher, dass der Product Owner weiß, wie man das Product Backlog so managt, dass es einen maximalen Wert stiftet. ! Verständnis und Anwendungsraum für Agilität schaffen. ! SCRUM-Meetings initiieren, sofern es notwendig oder angemessen ist. Aufgaben des Masters für das Entwicklungsteam Der SCRUM Master unterstützt das Entwicklungsteam wie folgt: ! Coaching des Entwicklungsteams bezüglich Selbstorganisation und Interdisziplinarität. ! Unterstützung des Entwicklungsteams, hochwertige Produkte zu schaffen. ! Beseitigung von Hindernissen, die den Fortschritt des Entwicklungsteams behindern. ! SCRUM-Meetings initiieren, sofern es notwendig oder angemessen ist. ! Coaching des Entwicklungsteams bei organisatorischen Bereichen, in denen SCRUM noch nicht voll verstanden oder angewendet wurde. Aufgaben des Masters für die Organisation Der SCRUM Master unterstützt die Organisation auf verschiedene Weisen: ! Führung und Coaching der Organisation bei der Anwendung von SCRUM. ! Planung von SCRUM-Umsetzungen innerhalb der Organisation. <?page no="76"?> 76 3 Wie funktioniert SCRUM? ! Unterstützung von Mitarbeitern und Stakeholdern SCRUM zu verstehen und anzuwenden und grundsätzlich empirische Produktentwicklung zu leben. ! Veränderungen anstoßen, die die Produktivität des SCRUM-Teams steigern. ! Zusammenarbeit mit anderen SCRUM Mastern, um die Effektivität bei der Anwendung von SCRUM in der Organisation zu steigern. Abb. 20: Unterstützung des SCRUM Masters M SCRUM Master unterstützt SCRUM Team und Organisation bei… Unterstützung für Product Owner • Befähigung zur Steigerung Produktwert mit Product Backlog • Effektives Management des Product Backlog • Nutzen von detailliertem Product Backlog vermitteln • Verständnis: Produktplanung ist empirischer Prozess • SCRUM Meeting initiieren falls angemessen und nötig Unterstützung Entwicklungsteam • Coaching zu Selbstorganisation und Interdisziplinarität • Unterstützung ein hochwertige Produkte zu schaffen • Beseitigung von Hindernissen die Fortschritt behindern • SCRUM Meetings initiieren falls notwendig oder angemessen • Coaching organisatorische Bereiche ohne SCRUM Anwendung Unterstützung Organisation • Planung von SCRUM Umsetzungen innerhalb Organisation • Verständnis der Mitarbeiter und Stakeholder von SCRUM • Veränderungen anstoßen zur Steigerung Produktivität • Zusammenarbeit mit anderen SCRUM Mastern • Führung und Coaching Organisation bei Anwendung von SCRUM P E <?page no="77"?> 3.2 Rollen 77 Entwicklungsteam Das Entwicklungsteam ist für das „Wie“ verantwortlich: Wie wird das Produkt entwickelt und umgesetzt? Charakteristiken des Entwicklungsteams Entwicklungsteams nach SCRUM haben ganz spezielle Charakteristika, die den Spirit von SCRUM ausmacht. Diese werden im Folgenden beschrieben. Teamgröße Das Entwicklungsteam besteht aus einer Anzahl von drei bis neun Teammitgliedern. Es werden sieben Personen als optimal angesehen. Im Rahmen dieser Berechnung werden der SCRUM Master und der SCRUM Product Owner nicht mitgezählt. Sie sind zwar Mitglieder des SCRUM-Teams, jedoch nicht des Entwicklungsteams. Selbstorganisierend Entwicklungsteams haben keine Projektleiter oder Teilprojektleiter. Sie organisieren sich selbst. Es ist die Aufgabe der Organisation beziehungsweise des Unternehmens, alles dafür zu tun, dass das Entwicklungsteam sich selbst organisieren und managen kann. Es sorgt für alle Kompetenzen und Ressourcen, die hierzu erforderlich sind. Die einzige Vorgabe, die das Entwicklungsteam von Product Owner bekommt, ist die Art und die Priorität der Produkteigenschaften, die in allen Sprints umgesetzt werden sollen. Diese sind im so genannten Product Backlog gespeichert. Wie das Team die Produkteigenschaften des Sprint Backlogs und die Ziele des Sprints erreicht, ist allein den Teams überlassen. Interdisziplinär Wie in Abschnitt 3.5 beschrieben, arbeiten die Entwicklungsteams interdisziplinär. Das bedeutet, dass verschiedene Kompetenzen und Fähigkeiten innerhalb des Teams vorhanden sind. <?page no="78"?> 78 3 Wie funktioniert SCRUM? Abb. 21: SCRUM-Entwicklungsteam Keine Titel Innerhalb von Entwicklungsteams gibt es keine Titel. Die Rollen innerhalb des Entwicklungsteams sind alle gleichrangig. Titel sind damit nicht relevant. Das bedeutet jedoch nicht, dass es nicht unterschiedliche Aufgabenverteilungen innerhalb des Teams gibt. Diese Aufgabenverteilung ist jedoch stets durch die jeweilige Aufgabe definiert und manifestiert sich nicht durch die Vergabe eines Titels innerhalb des Teams. ? "1! 1O+9! QH+QO1 R3+.Q(OKJ3AH+914 3n&)M? ZFn l 5 ='# o f KnGCK+]? M&',K,n? n'# ,'+n? #,K; ,BG,'\? Hn,'n 3,+nG ,) 3n&) Hn ,'n in ,+ n? n .' +n ? M G,n#n? ='M $JMA1)93 2 (? ]#=H+ C&=n' C; iU n'+i,AHnG' 2 HG&? n 4=OM&Cn'kn? +n,G='M ,) 3n&) 2 O]H=KK,n? +n 4? Cn,+ )ZMG,A0K+ &' n,'n) 3&KH 2 n,Mn'kn? &'+i]? +G,A0n 4=OM&Cn'kn? +n,G='M GF4'9+93*93 2 >,Mn'+$)n? #nK ^B? ,'+ [&AHG]MK 2 4? Cn,+n' &GK n,'; ,Mn &) P'H? n)n'+ 2 >'+KA0n,#='M #&? $Cn? i,nk,nG ,) ^B? ,'+ =)MnKn+; + i,? # ,) b&0)n' ^B? ,'+ (G&'','M : 9 ! 1 3+ .F ! + J3A 2 >' +i ,AH G=' M &H +=n GGnK P' H? n) n' + 2 (? ,]? ,K,n? ='M 4=OM&Cn' >'+i,AHG='MK+n&) 2 I? M&',K&+,]'W 3n,G'&0)n ='# gn,+='M #nK D&,GQ ^Xb.d '&A0 ^Xb.d bnMnG' 2 "]? +KA0? ,++K+? &AH,'M ,) ^B? ,'+ MnK&)+0&O+n `n? &'+i]? +='M <?page no="79"?> 3.2 Rollen 79 Keine weitere Untergliederung im Entwicklungsteam Anders als in klassisch gemanagten Projekten werden die Teams nicht weiter in „Unterteams“ oder beispielsweise in „Teilprojekte“ untergliedert. Das Entwicklungsteam ist das Entwicklungsteam ohne eine weitere Unterscheidung von Rollen in diesem Team. Das bedeutet, dass alle Teammitglieder auf Augenhöhe arbeiten. Es gibt weder eine weitere fachliche Untergliederung noch eine hierarchische Untergliederung. Entwicklungsteam bleibt als Ganzes verantwortlich Das Entwicklungsteam kann zwar Aufgaben innerhalb des Teams mit unterschiedlichen Kompetenzen organisieren, dennoch bleibt es immer als Ganzes für die Erreichung des Ziels eines Sprints verantwortlich. Keiner im Entwicklungsteam trägt mehr oder weniger Verantwortung als ein anderer im Team. Das Team ist immer insgesamt als Team verantwortlich für den Erfolg. Aufgaben des Entwicklungsteams Die Hauptaufgabe des Entwicklungsteams ist es, das Produkt richtig zu bauen beziehungsweise zu entwickeln. Die Mitglieder des Entwicklungsteams sind die einzigen, die am Inkrement arbeiten. Alle anderen Aufgaben des Entwicklungsteams haben sich dieser Hauptaufgabe unterzuordnen und sind lediglich unterstützend, um dies während des Sprints sicherzustellen. Es ist wichtig, dass die einzelnen Aufgaben beziehungsweise Tasks an die verschiedenen Mitglieder des Entwicklungsteam übertragen werden. Die Aufgabenverteilung innerhalb des Entwicklungsteams nimmt das Entwicklungsteam selbst vor. Im Idealfall arbeiten möglichst viele Mitglieder des Entwicklungsteams immer an einem Backlog Item. Es sollte vermieden werden, dass zu viele Mitglieder des Entwicklungsteams an zu vielen unterschiedlichen Backlog Items parallel arbeiten. Es gilt also das Prinzip der Fokussierung und der priorisierten Abarbeitung nacheinander. <?page no="80"?> 80 3 Wie funktioniert SCRUM? Auch bei der Verteilung unterschiedlicher Aufgaben auf verschiedene Mitglieder des Entwicklungsteams bleibt die Verantwortlichkeit beim gesamten Team. Verantwortung des Entwicklungsteams Das Entwicklungsteam hat die folgenden Themen zu verantworten: ! Verantwortung für die Entwicklung des aktuellen Inkrements ! Priorisierung der Aufgaben im Entwicklungsteam ! Organisation des Daily SCRUM (Räume etc.) ! Tägliche Teilnahme und Mitwirkung im Daily SCRUM ! Leitung des Daily SCRUM nach den Regeln von SCRUM ! Tracking des Fortschritts im Sprints inklusive Aktualisierung der Tools die hierfür verwendet werden (bspw. Taskboard, Sprint Burn-down Chart, etc.) Kompetenzen des Entwicklungsteams Die folgenden Themen gehören zu den Kompetenzen des SCRUM-Teams: ! Eigentümer des Sprint Backlogs. Nur das Entwicklungsteam darf Veränderungen am Sprint Backlog vornehmen. Dies darf sonst niemand anderes im SCRUM- Team. ! Entscheidungskompetenz darüber, „wieviel“, also Menge und Umfang im Rahmen des Sprint Plannings Optimale Teamgröße des Entwicklungsteams Optimal sind zwischen drei und neun Teammitglieder. Bei weniger als drei Teammitgliedern besteht die Gefahr, dass eine Lücke bei den Fähigkeiten entsteht. Teams, die größer als neun Personen sind, haben einen sehr hohen Koordinationsaufwand. Bei diesen Berechnungen werden der SCRUM Master und der SCRUM Product Owner nicht einberechnet. Diese werden nur dann mitgezählt, wenn Sie auch <?page no="81"?> 3.2 Rollen 81 bei der Abarbeitung der Backlog Items mitwirken. Während des gesamten SCRUM- Prozesses sollte das Entwicklungsteam möglichst aus denselben Personen bestehen. Grund hierfür ist, dass sich im Rahmen des SCRUM-Prozesses so eine bessere Lernkurve darstellen lässt. Zudem kann das Gelernte im Rahmen der Interaktion der Teammitglieder besser fortgeführt werden. Abb. 22: Optimale Teamgröße Team < 3 optimale Teamgröße Team > 9 1 • Lücke an Fähigkeiten wahrscheinlich • geringer Koordinationsaufwand • optimale Verfügbarkeit an Fähigkeiten • optimaler Koordinationsaufwand • hoher Koordinationsaufwand • hoher Verfügbarkeit von Fähigkeiten 2 3 4 5 6 7 8 9 10 11 <?page no="82"?> Übungsfragen zum Kapitel: „Wie funktioniert SCRUM? - Rollen“ Hinweis: Es können eine oder mehrere Antworten richtig sein. Die Auflösung findest du in Abschnitt 5.5. [41] In SCRUM gibt es … " genau fünf Rollen " genau vier Rollen " genau drei Rollen " Keine der Ant wort mögl ichke ite n ist richti g [42] Die Rollen im SCRUM-Team sind … " Benutzer, Kunden, Management " Product Owner, SCRUM Master, Entwicklungsteam " Stakeholder, Product Owner, SCRUM Master " Keine der Antwortmöglichkeiten ist richtig [43] Das SCRUM-Team … " ist dadurch definiert, dass jedem Teammitglied eine Rolle zugewiesen ist. " steht in enger Abstimmung mit den Stakeholdern durch den SCRUM Master. " hat die Regeln und Prinzipien von SCRUM anzuwenden. " umfasst auch die Stakeholder, die ein Interesse an dem zu entwickelnden Produkt haben. %( 3 Wie funktioniert SCRUM? <?page no="83"?> 2.*4#-%/ 0#'4 83 [44] Die Stakeholder … " sind Teil des SCRUM-Teams. " werden durch den Product Owner im SCRUM-Team vertreten. " nehmen an allen Meetings des SCRUM-Teams teil. " können alle sein, die ein Interesse an der Entwicklung des Produkts haben. [45] Ein SCRUM-Team charakterisiert … " Selbstorganisation " dass jede r ein e best immt e Ro lle im Team ha t " Interdisziplinarität " Keine der Antwortmöglichkeiten ist richtig [46] Welche der folgenden Aussagen ist richtig? " Der Product Owner ist quasi der Chef-Produktentwickler " Der SCRUM Master ist Servant Leader " Das Entwicklungsteam ist für die Entwicklung des Produktes verantwortlich " Keine der aufgeführten Antwortmöglichkeiten [47] Der Product Owner … " managt das Product Backlog " entscheidet über die Priorisierung der Backlog Items " nimmt das Inkrement ab " kommuniziert mit den Stakeholdern <?page no="84"?> 84 3 Wie funktioniert SCRUM? [48] Welche der folgenden Aussagen ist richtig? " Der Product Owner sollte alle Kompetenzen bezogen auf das Produkt haben. " Der Product Owner ist der Projektleiter in einem SCRUM-Team. " Der Product Owner ist während eines SCRUM-Projektes Vorgesetzter der Mitglieder des Entwicklungsteam. " Der Product Owner koordiniert und managt die operative Arbeit des Entwicklungsteams während des Sprints. [49] De r SC RUM Mast er … " ist für die Einhaltung der SCRUM-Regeln zuständig. " ist Projektleiter im Rahmen eines nach SCRUM gemanagten Projektes. " trifft wichtige Projektentscheidungen. " ist Moderator und Coach, um das SCRUM zu befähigen, optimal und effizient zu arbeiten. [50] Welche der folgenden Aussagen ist richtig? " Der SCRUM Master ist Stellvertreter des Product Owners " Der SCRUM Master ist bei allen SCRUM-Meetings anwesend " Der SCRUM Master ist für die Zeiteinhaltung der Meetings nach SCRUM zuständig " Keine der Antwortmöglichkeiten ist richtig <?page no="85"?> 2.*4#-%/ 0#'4 85 [51] Das Entwicklungsteam … " ist für die Entwicklung des Produktes zuständig " kann aus einer oder mehreren Personen bestehen " managt und pflegt das Sprint Backlog " Keine der Antwortmöglichkeiten ist richtig [52] Welche der folgenden Aussagen ist richtig? " Das Entwicklungsteam organisiert sich selbst " Das Entwic klun gsteam ist d em Produ ct O wner un ters tell t " Das Entwicklungsteam wird von SCRUM Master geführt " Keine der Antwortmöglichkeiten ist richtig [53] Welche der folgenden Aussagen ist richtig? " Das Entwicklungsteam entscheidet, was im kommenden Sprint umgesetzt wird. " Der Product Owner entscheidet darüber, was das Entwicklungsteam im kommenden Sprint umzusetzen hat. " Der SCRUM Master erstellt die Planung für die Arbeit des kommenden Sprints. " Keine der Antworten ist richtig. <?page no="86"?> 86 3 Wie funktioniert SCRUM? [54] Welche der folgenden Aussagen ist falsch? " Das Entwicklungsteam hat keine Titel im Team " Das Entwicklungsteam trifft sich täglich zum Daily SCRUM " Das Entwicklungsteam trägt gesamthaft die Verantwortung für die Entwicklungsarbeit " Das Entwicklungsteam besteht nur aus Entwicklern [55] Die optimale Größe des Entwicklungsteams … " ist nicht in SCRUM definiert " ist unterschiedlich je nach Anforderung des Projektes " liegt zwischen drei und neun Personen " beträgt mindestens neun Personen <?page no="87"?> 3.3 Meetings 87 3.3 Meetings Meetings gemäß SCRUM finden immer in persönlicher Form statt. Sie erfolgen regelmäßig, um kontinuierlich überprüfen und anpassen zu können. Alle Meetings haben ein festes Zeitfenster. Das bedeutet, dass für jedes Meeting ein Zeitrahmen vorgegeben ist, der auf jeden Fall eingehalten wird. Gibt es dennoch mehr Themen als es die Zeit des Meetings hergibt, so werden diese Themen auf das nächste Meeting verschoben. Abbildung 23 gibt dir einen Überblick über die wesentlichen Eigenschaften von Meetings nach SCRUM und einen Überblick darüber, welche Meetings es gibt. Charakteristik von Meetings Meetings nach SCRUM haben eine ganz spezielle Charakteristik, die Meetings nach SCRUM „typisch“ SCRUM werden lassen. Diese lassen sich wie folgt beschreiben. Regelmäßigkeit Um den iterativen Charakter von SCRUM sicherzustellen, finden die Meetings bei SCRUM regelmäßig statt. Es gibt eine feste Frequenz, in denen die Meetings stattfinden. Diese Frequenz wird nicht verändert oder angepasst. Sie wird während des gesamten Projekts konsequent verfolgt. Auch der Ort der jeweiligen Meetings sollte immer der gleiche sein. Diese Regelmäßigkeit und die klare Definition von Frequenz und Ort stellen den Fluss und die Effizienz des SCRUM-Prozesses sicher. Fester Zeitrahmen Für jedes Meeting ist ein fester Zeitrahmen vorgegeben. Das bedeutet, dass für jedes Meeting vorher ein Zeitfenster festgelegt wurde. Dieses wird auf jeden Fall eingehalten. Wenn das Zeitfenster abgelaufen ist, ist das Meeting beendet. Es gibt kei- <?page no="88"?> 88 3 Wie funktioniert SCRUM? ne Verlängerung des Meetings. Themen, die noch offen sind, werden dann im nächsten Meeting besprochen beziehungsweise auf das nächste Meeting verschoben. Zudem finden die Meetings gemäß SCRUM immer zum gleichen Zeitpunkt, also bezogen auf die Uhrzeit und den Wochentag, statt. Dies vermindert den koordinativen Aufwand der Meeting-Organisation. Eine Verschiebung von Meetings oder immer wieder neue Festlegung des Zeitpunkts von Meetings ist bewusst nicht vorgesehen. Sprint ist eine wesentliche Klammer Es gibt insgesamt fünf Meetings nach SCRUM. Der Sprint ist einer dieser Meetings. Der Sprint nimmt jedoch eine Sonderposition der Meetings ein. Dies aus zwei Gründen. Auf der einen Seite kann man den Sprint quasi als das Herz oder den Kern des SCRUM-Projektes beziehungsweise der Entwicklungsarbeit beschreiben. Auf der anderen Seite stellt der Sprint wiederum quasi die Klammer um mehrere weitere Meetings dar. Als Sprint wird gemäß SCRUM-Guide die Summe aller Meetings beziehungsweise des gesamten SCRUM-Prozess beschrieben. In der Praxis wird als Sprint jedoch die eigentliche Entwicklungsarbeit bezeichnet. Sprint-Zeitdauer ist fix zu halten Die Dauer eines Sprints beziehungsweise der Sprints wird zu Beginn eines nach SCRUM gemanagten Projektes festgelegt. Das bedeutet, dass der Zeitrahmen, der für einen Sprint festgelegt ist, nicht geändert wird. Wenn am Anfang eines Projektes festgelegt wird, dass ein Sprint vier Wochen dauert, so wird auch jeder Sprint während des Projektes vier Wochen dauern. Die Dauer wird also während des gesamten Projektes fix gehalten. <?page no="89"?> 3.3 Meetings 89 Abb. 23: SCRUM Meetings Überblick über die fünf Meetings von SCRUM Nach SCRUM gibt es genau fünf Meetings, die im Rahmen eines nach SCRUM gemanagten Projektes stattfinden. Weitere Meetings sind nicht zugelassen. Es ist jedoch wichtig zu erwähnen, dass dies nicht bedeutet, dass es keine Kommunikation außerhalb der SCRUM-Meetings geben darf. Nur die Art und Anzahl der Meetings selbst ist klar vorgeben. Dennoch haben in den letzten Jahren mehrere Autoren und Praktiker in ihren Veröffentlichungen weitere Meetings für sinnvoll erkannt. Diese sind jedoch nicht Teil von SCRUM und werden aus diesem Grund nicht in diesem Buch vorgestellt. Es ist uns wichtig, zu erwähnen, dass die beiden Begründer von ^B? ,'+ : F! 1JHH9+*J3A93 bnMnG)\F,MHn,+ K,A0n? K+nGGn' ^B? ,'+ (G&'','M OnK+n En,+On'K+n? D&,GQ ^Xb.d ^B? ,'+ ,K+ n,' X]'+&,'n? D&=n? ^B? ,'+ ,K+ OnK+; =0&G+n' *Cn? K,A0+ ^Xb.d dnn+,'MK ^B? ,'+ bnk,ni ^B? ,'+ bn+? ]KBnH+,kn <?page no="90"?> 90 3 Wie funktioniert SCRUM? SCRUM Ken Schwaber und Jeff Sutherland betonen, dass jede Abwandlung und Ergänzung des von ihnen definierten „Kerns“ von SCRUM den Erfolg und die Effizienz der Methode mindern. Hier nun ein Überblick über die fünf Meetings gemäß SCRUM: ! Sprint ! Sprint Planning ! Daily SCRUM ! Sprint Review ! Sprint Retrospektive Die fünf Meetings von SCRUM werden wir dann in der folgenden Struktur beschreiben. ! Was ist das Ziel des jeweiligen Meetings? ! In welcher Form wird das Meeting abgehalten? ! Wer nimmt an dem jeweiligen Meeting teil? ! Wer moderiert das Meeting? ! Was ist die Agenda des Meetings? ! Was sind die Aufgaben der jeweiligen Rollen im Rahmen des Meetings? ! Was sind die Ergebnisse dieses Meetings? ! Wie lange dauert das Meeting? ! Wie oft findet das Meeting statt? Sprint Das Ziel des Sprints ist es, die jeweiligen Ziele beziehungsweise das jeweilige Ziel, das der Product Owner für den jeweiligen Sprint vorgegeben hat, zu erreichen. Konkret sind die im Rahmen des Sprints umzusetzenden Produkteigenschaften in Sprint Backlog festgehalten. Der Sprint selbst ist kein eigenständiges Meeting, sondern die <?page no="91"?> 3.3 Meetings 91 Klammer um mehrere Meetings, die innerhalb des Sprints stattfinden. Insofern gibt es keine konkrete Form, wie der Sprint selbst stattfindet. Die Meetings, die innerhalb des Sprints stattfinden, sind: Sprint Planning, Daily SCRUM, die Entwicklungsarbeit, der Sprint Review und der Sprint Retrospektive. Teilnehmer innerhalb des Sprints sind der Product Owner, der SCRUM Master, das Entwicklungsteam und die Stakeholder. Der Sprint selbst wird nicht moderiert, da er wie schon erwähnt eine Klammer um mehrere Meetings darstellt. Insofern gibt es auch keine Agenda des Meetings selbst. Während des Sprints werden keine Änderungen vorgenommen, die das Sprint-Ziel gefährden. Der Anspruch an die Qualität der Arbeit darf nicht geändert werden. Der Scope des Sprints darf zwischen dem Product Owner und dem Entwicklungsteam verhandelt werden, wenn er dem Lernen dient. Die Agenda des Sprints ist quasi die Abarbeitung des Sprint Backlogs. Innerhalb des Sprints haben die beteiligten Rollen die Aufgaben, Kompetenzen und Verantwortung, die ihnen auch grundsätzlich gemäß ihrer Rollendefinition zukommen. Das Ergebnis des Sprints ist die Abarbeitung der für den Sprint vorgesehen Produkteigenschaften gemäß dem Product Backlog. Die Dauer des Sprints ist unterschiedlich. Ein Sprint kann wenige Tage gehen bis hin zu einem Monat. Die maximale Dauer des Sprints sind vier Wochen beziehungsweise ein Monat. Wichtig ist, dass die Sprints immer die gleiche Dauer haben. Hintergrund ist, dass es sich erwiesen hat, dass die Leistungsfähigkeit der Sprint-Teams am Höchsten ist, wenn die Dauer jeweils gleich lange ist. Grundsätzlich kann man sagen, dass Sprints immer so kurz wie nur möglich sein sollten. Wenn ein Sprint zu Ende ist, beginnt schon der nächste Sprint. Es gibt demnach quasi keine Pause zwischen den einzelnen Sprints. Auf jeden Sprint folgt sofort der nächste Sprint. Wie viele Sprints innerhalb eines SCRUM-Projektes stattfinden, kommt darauf an, wie viele Sprints innerhalb das Sprint Plannings geplant wurden. Die Struktur inner- <?page no="92"?> 92 3 Wie funktioniert SCRUM? halb eines Sprints ist auch immer die gleiche. Ein Sprint beginnt immer mit dem Sprint Planning. Abb. 24: Dauer der Meetings Abbruch eines Sprints Ein Sprint kann jederzeit - bevor das Ende der jeweiligen Zeit erreicht ist - abgebrochen werden. Der Sprint kann jedoch nur vom Product Owner abgebrochen werden. Er ist der einzige, der die Entscheidung über den Abbruch treffen kann, auch wenn er hierzu von Stakeholdern, dem SCRUM Master oder dem Entwicklungsteam bewegt wurde beziehungsweise von diesen Rollen hierhingehend beeinflusst wurde. ^B? ,'+ (? ]# =A + Ii 'n? >'+i,AHG='MKN +n&) ^ Xb.d d&K+n? ^+&Hn0]G#n? ^B? ,'+ bn+? ]KBnH+,kn ^B? ,'+ bnk,ni D&,GQ ^Xb.d >'+i,AHG='MKN &? Cn,+ / ^B? ,'+- ^B? ,'+ (G&'','M (? ]# =A + Ii 'n ? >'+i,AHG='MKN +n&) ^X b.d d&K+n? ^+&Hn0]G#n? (? ]# =A + Ii' n? >'+i,AHG='MKN +n&) ^X b.d d&K+n? ^+&Hn0]G#n? ( ? ] #= A+ Ii'n ? >'+i,AHG='MKN +n&) ^Xb .d d&K+n? ^+&Hn0]G#n? (? ] #= A+ Ii' n? >'+i,AHG='MKN +n&) ^X b.d d&K+n? ^+&Hn0]G#n? )&R,)&G 2 _]A0n' )& RU h 0 &C0\' M,M k]) 4=Oi&'# )& RU 81 d, 'U ) &R U 2U 0 ) &RU 5 0 8 7 5 2 1 <?page no="93"?> 3.3 Meetings 93 Voraussetzung für einen solchen Abbruch ist, dass das Sprintziel obsolet geworden ist. Sobald es also keine Notwendigkeit mehr für einen Sprint gibt, kann er abgebrochen werden. Die Gründe hierfür können vielfältig sind: Änderungen in der Unternehmensstrategie, Veränderungen im Markt oder technologische Veränderungen. Da die Dauer von Sprints jedoch so kurz wie möglich zu wählen ist, wird der Abbruch eines Sprints in den wenigsten Fällen Sinn machen. Wenn ein Sprint dennoch abgebrochen wird, werden alle bereits fertig gestellten Backlog Items nochmals überprüft. Backlog Items, die bereits fertiggestellt sind und die grundsätzlich releast werden können, werden meist vom Product Owner angenommen und akzeptiert. Alle anderen Backlog Items, die noch nicht fertiggestellt wurden, werden zurück ins Product Backlog gestellt. Die Arbeit, die an diesen Items bereits getätigt wurde, wird quasi abgeschrieben, und der Aufwand für die weitere Arbeit an diesen Items muss aufs Neue geschätzt werden. Sprint Planning Das Ziel des Sprint Plannings ist, den jeweils anstehenden Sprint zu planen. Der Sprint erfolgt in Form eines Präsenzmeetings, das immer als allererstes Meeting eines Sprints stattfindet. Das Sprint Planning findet einmal pro Sprint statt. Jeder Sprint beginnt damit. Am Sprint Planning nimmt das gesamte SCRUM-Team teil, also der Product Owner, der SCRUM Master und das Entwicklungsteam. Das Sprint Planning dauert bei einem Sprint von vier Wochen maximal acht Stunden. Dauert der Sprint weniger als vier Wochen, so passt sich die Dauer des Sprint Plannings auch entsprechend an und ist kürzer. Der SCRUM Master ist dafür verantwortlich, dass das Sprint Planning stattfindet und dass alle Mitglieder des SCRUM-Team verstehen, was das Ziel des Meetings ist. Er ist <?page no="94"?> 94 3 Wie funktioniert SCRUM? zudem dafür verantwortlich, dass das Sprint Planning im vereinbarten Zeitfenster bezüglich der Dauer bleibt. Das Sprint Planning ist in zwei Teile gegliedert. Abb. 25: Phasen des Sprint Plannings 1. Teil: Was kann im kommenden Sprint umgesetzt werden? Der erste Teil umfasst die Vorstellung der Backlog Items, die notwendig sind, um das Sprint-Ziel zu erreichen. Dies erfolgt durch den Product Owner gegenüber dem Entwicklungsteam. Die Items, die umgesetzt werden sollen, hat der Product Owner bereits priorisiert, also nach Priorität der Abarbeitung geordnet. Das Product Back- (? ]#=A+ [&AHG]M 8U 3n,G ^B? ,'+ (G&'','M _&K% 7U 3n,G ^B? ,'+ (G&'','M _,n% _&K H&'' ,' H]))n'#n' ^B? ,'+ MnGn,K+n+ in? #n'% _,n HZ''n' #,n 4=OM&Cn' MnGn,K+n+ in? #n'% [&AHG]M P+n) 3&KHK 3&KHK 4 3 &KH K [ 3&KHK X [&AHG]M P+n) 3& KH V 2 3&KHK K,'# 4=OM&Cn' #,n ']+in'#,M K,'# =) n,' [&AHG]M P+n) &C; =&? Cn,+n' 2 3&KHK K,'# ']+in'#,M =) #,n 4? Cn,+ #nK >'+i,AHG='MK+n&)K ; = ]Bn? &+,]'&G,K,n? n' 2 >,' 3&KH G\KK+ K,A0 ,' )&R,)&G n,'n) 3&M n? Gn#,Mn' <?page no="95"?> 3.3 Meetings 95 log enthält demnach alle Items, die umgesetzt werden sollen, um das Gesamtprodukt zu entwickeln. Es geht darum, das „WAS“ zu besprechen; also darum, „WAS“ im kommenden Sprint umgesetzt werden kann. Der Product Owner stellt in einem ersten Schritt dem Sprint-Team das Sprint-Ziel und die notwendigen Backlog Items vor. Hierbei kann das Entwicklungsteam dann die Fragen stellen, die es beantwortet wissen muss, um abzuschätzen, welche der Backlog Items es im nächsten Sprint umsetzen kann. Hierbei erstellt das Entwicklungsteam eine Schätzung bezüglich des Aufwands und der Arbeit beziehungsweise den Tasks, die zu erledigen sind, um das Sprint-Ziel zu erreichen. Wichtig ist hierbei, dass das gesamte Sprint-Team zusammenarbeitet mit dem Ziel, ein gemeinsames Verständnis der Aufgaben des kommenden Sprints zu haben. Hierbei ist es auch wichtig zu definieren, wann die Aufgaben beziehungsweise die Backlog Items fertig sind. Dazu dient ein gemeinsames Verständnis der „Definition of Done“. Der Input für dieses Meeting ist das Product Backlog, in dem alle Produkteigenschaften zusammengefasst sind. Zudem auch der letzte Stand des Produktinkrements (liegt ab dem ersten Sprint vor beziehungsweise nach dem ersten Sprint), die geschätzte Kapazität des Sprint-Teams im kommenden Sprint. Und zusätzlich noch die vergangene Performance des Sprint-Teams. Diese Input-Parameter erlauben es abzuschätzen, „was“ im kommenden Sprint geleistet werden kann. Die Entscheidung darüber, wie viele Items für das Sprint Backlog ausgewählt werden, liegt ganz alleine beim Entwicklungsteam. Nur das Entwicklungsteam kann abschätzen, was im vorliegenden Sprint geleistet werden kann. Während des Sprint Plannings formuliert das SCRUM-Team ein Sprint- Ziel. Das Sprint-Ziel ist ein Ziel, das erreicht wird, wenn alle Product Backlog Items im Laufe des Sprints geleistet wurden. Es gibt den Entwicklungsteam eine Orientierung dafür, warum es das Produktinkrement entwickelt. Eine ausführliche Beschreibung des Sprint-Ziels findest du in Abschnitt 3.4. Das Ergebnis dieses ersten Teils des <?page no="96"?> 96 3 Wie funktioniert SCRUM? Sprint Plannings ist also, dass das Sprint-Ziel festgelegt wurde und dass die im kommenden Sprint zu leistenden Items festgelegt wurden. 2. Teil: Wie wird die gewählte Arbeit erledigt? Im zweiten Teil des Sprint Plannings geht es darum, wie zu leistende Arbeit im kommenden Sprint erledigt wird. Ziel dieses Teilschritts im Rahmen des Sprint Plannings ist, festzulegen, ob die ausgewählten Backlog Items geeignet sind, im kommenden Sprint auch wirklich geleistet zu werden. Hauptergebnis beziehungsweise Artefakt des Sprint Plannings Meetings ist das Sprint Backlog. Das Sprint Backlog umfasst die aus den Product Backlog für den Sprint ausgewählten Backlog Items und eine Planung, wie diese im Rahmen des Sprints umgesetzt werden. Es geht also um das „WIE“ wird im Rahmen des Sprints das umgesetzt, was umgesetzt werden muss? Hierfür werden für jedes Backlog Item Aufgaben beziehungsweise Tasks definiert. Diese Aufgaben dienen dazu, jedes einzelne Backlog Item so zu konkretisieren, dass das Entwicklungsteam genau weiß, welche Aufgaben und Tätigkeiten zu Erledigung des jeweiligen Backlog Items zu erfüllen sind. Die Tasks sind notwendig, um die operative Arbeit des Entwicklungsteams nach Beendigung des Sprint Plannings zu ermöglichen. Hierbei ist es wichtig, dass jeder Task so definiert beziehungsweise formuliert wird, dass er an maximal einen Tag erledigt werden kann. Wäre eine Aufgabe zu groß für einen Tag, so muss sie gemäß SCRUM in weitere Unteraufgaben unterteilt werden, so lange, bis diese an einem Tag erfüllt werden können. Zudem sollten die Tasks so formuliert werden, dass für jedes Mitglied des Entwicklungsteams ganz eindeutig ist, WAS zu tun ist. Und dies unabhängig davon, wer im Entwicklungsteam diese Aufgabe letztendlich übernehmen wird. Wenn für alle Backlog Items des Product Backlogs Tasks formuliert wurden, dann erfolgt eine <?page no="97"?> 3.3 Meetings 97 Schätzung, wieviel Aufwand für die Abarbeitung eines Tasks notwendig ist. Diese Schätzung erfolgt meist in der Einheit Stunden. Dies kommt daher, dass ein Task an maximal einem Tag zu leisten ist. Es wäre grundsätzlich auch möglich, die Einheit Minuten zu wählen, jedoch hat es sich in der Praxis gezeigt, dass dies wiederum zu detailliert wäre. Nach dieser Abschätzung, welcher Aufwand notwendig ist, können die Schätzungen aggregiert und mit der Kapazität, die dem Entwicklungsteam im Sprint zur Verfügung steht, abgeglichen werden. Dies dient dazu, zu vergleichen, mit welcher Kapazität das Development-Team im Sprint zur Verfügung steht, und wie dies im Verhältnis zu dem zu erwartenden Aufwand steht. Ist mehr Kapazität zur Verfügung als geplant, können weiterem Backlog Items in den Sprint aufgenommen werden. Wenn zu wenige Kapazitäten vorhanden sind, müssen einige Backlog Items aus dem Sprint genommen werden, so lange, bis die Kapazitätsgrenze des Sprints gerade erreicht ist. Es hat sich in der Praxis als hilfreich erwiesen, einen gewissen Kapazitätspuffer zu belassen. Aus unserer Erfahrung sollte dieser jedoch nicht mehr als 10 Prozent der Gesamtkapazität eines Sprints betragen. Das Ergebnis des zweiten Teils des Sprint Plannings ist also das Sprint Backlog. Dieses enthält alle Backlog Items des Product Backlogs, die im kommenden Sprint bearbeitet werden sollen. Zudem enthält es die Planung für den Sprint, wie diese Backlog Items in Form von Tasks abgearbeitet werden. Daily SCRUM Nachdem das Spring Planning abgeschlossen wurde, beginnt das Entwicklungsteam seine Arbeit. Konkret bedeutet dies, dass es die Aufgaben, die im Sprint Planning definiert wurden, im Team selbstorganisiert bearbeitet. Wichtig ist hierbei, dass das Entwicklungsteam die Aufgaben nacheinander abarbeitet und im Idealfall gemeinsam und gleichzeitig am gleichen Backlog Item arbeitet. Während dieser Ent- <?page no="98"?> 98 3 Wie funktioniert SCRUM? wicklungsarbeit trifft sich das SCRUM-Team physisch einmal am Tag zum Daily SCRUM. Dieses findet immer zur gleichen Zeit am gleichen Ort statt. Grund hierfür ist, dass die organisatorische Arbeit der Meetingplanung und die Komplexität reduziert werden soll. Die Dauer des Daily SCRUM ist auf maximal 15 Minuten beschränkt. Das Ziel des Daily SCRUM ist, dass sich das Entwicklungsteam abstimmt und synchronisiert. Bei jedem Daily SCRUM wird die Entwicklungsarbeit für die nächsten 24 Stunden geplant. Hierbei werden immer zuerst die Arbeit der letzten 24 Stunden transparent gemacht und ein Ausblick auf die Aufgaben der nächsten 24 Stunden gegeben. Das Entwicklungsteam verprobt hierbei den Fortschritt der letzten 24 Stunden bezüglich des Sprint-Ziels. Zudem analysiert es, wie der Fortschritt bezogen auf die Backlog Items, die im Sprint Backlog sind, ist. Hauptziel des Daily SCRUM ist es, die Wahrscheinlichkeit zu maximieren, dass das Entwicklungsteam das Sprint-Ziel auch erreicht. Die Agenda des Meetings wird vom Entwicklungsteam selbst festgelegt. Es gibt keine konkreten Vorgaben gemäß SCRUM, wie das Daily SCRUM strukturiert werden soll, so lange alles darauf abzielt, dass das Sprint-Ziel erreicht wird. Es gibt Entwicklungsteams, die strukturierte Fragen nutzen. wie die folgenden: ! Was habe ich gestern für das Entwicklungsteam getan, um das Sprint-Ziel zu erreichen? ! Was werde ich heute für das Entwicklungsteam tun, um das Sprint-Ziel zu erreichen? ! Gibt es irgendwelche Hindernisse, die mich oder das Entwicklungsteam daran hindern, das Sprint-Ziel zu erreichen? Andere Entwicklungsteams hingegen nutzen den Daily SCRUM für ausführliche Diskussionen. Die genaue Agenda des Daily SCRUM ist dem SCRUM-Team letztlich <?page no="99"?> 3.3 Meetings 99 freigestellt, so lange es darum geht, das Sprint-Ziel zu erreichen und die maximale Dauer von 15 Minuten einzuhalten. Da das Daily SCRUM auf 15 Minuten festgelegt ist, ist es in der Praxis oft so, dass sich das Entwicklungsteam nach dem Daily SCRUM noch dazu trifft, um tiefere fachliche Diskussionen zu führen oder um Neuplanungen der restlichen Sprint-Arbeit durchzuführen, oder auch um Anpassungen vorzunehmen. Der SCRUM Master hat die Verantwortung, dass das Daily SCRUM stattfindet. Das Meeting selbst wird jedoch rein von Entwicklungsteam durchgeführt. Der SCRUM Master hat also eine passive Rolle im Rahmen des Daily SCRUMs, so lange die SCRUM-Regeln angewendet werden. Der SCRUM Master ist auch dafür verantwortlich, dass der Daily SCRUM das Zeitfenster von 15 Minuten nicht überschreitet. Der Daily SCRUM ist also quasi ein internes Meeting des Entwicklungsteams. Falls andere Teilnehmer am Meeting anwesend sind, stellt der SCRUM Master sicher, dass diese Teilnehmer das Meeting nicht stören und nicht sprechen. Alle Teilnehmer am Daily SCRUM außer dem Entwicklungsteam haben eine passive Rolle. Eine aktive Rolle haben nur die Mitglieder des Entwicklungsteams selbst. Das Daily SCRUM ist ein wesentlicher Bestandteil der Überprüfung und Anpassung im Rahmen des SCRUM-Prozesses. Denn es sorgt dafür, dass … ! die Kommunikation des Entwicklungsteams verbessert wird; ! andere Meetings nicht mehr notwendig oder überflüssig sind; ! Hindernisse identifiziert und/ oder aufgelöst werden; ! Entscheidungsbedarf erkannt wird und Entscheidungen getroffen werden; ! der Wissensstand des Entwicklungsteams verbessert wird. <?page no="100"?> 100 3 Wie funktioniert SCRUM? Abb. 26: Daily SCRUM Sprint Review Der Sprint Review findet immer am Ende jedes Sprints statt. Er dient dazu, die wichtigsten Ergebnisse aus dem Sprint zu präsentieren und um zu überprüfen und gegebenenfalls anzupassen. So kann der neueste Stand des Produktinkrements transparent gemacht werden, und das Product Backlog kann entsprechend aktualisiert werden. Der Sprint Review findet in Form eines physischen Meetings statt. Der Product Owner lädt zu dem Meeting ein. Das gesamte SCRUM-Team ist beim Sprint Review an- #! A13QH1+QF3 ; 9H %1QKB N? P&= 2 dnn+,'M O,'#n+ +\MG,A0 K+&++U mGn,A0n .0? ; n,+ ='# MGn,A0n? I? +U 2 (0QK,KA0nK dnn+,'M #nK MnK&)+n' >'+i,AHG='MK+n&)KU 2 E,nG ,K+ 4CK+,))='M ='# ^Q'A0? ]',K,n? ='M ,) >'+i,AHG='MK+n&)U 2 D&=n? ,K+ )&R,)&G 81 d,'=+n'U 2 4Mn'#& ='# d]#n? &+,]' #=? A0 >'+i,AHG='MK+n&) KnGCK+U ,DAKQ("9 6! 1A93 Q4 =99+Q3A 2 _&K 0&Cn ,A0 MnK+n? ' O$? #&K >'+i,AHG='MK+n&) Mn+&' =) #&K ^B? ,+ E,nG ; = n? ? n,A0n'% 2 _&K in? #n ,A0 0n=+n +=' =) #&K ^B? ,+ E,nG ; = n? ? n,A0n'% 2 m,C+ nK ,? Mn'#inGA0n T,'#n? ',KKnW #,n ),A0 ]#n? #&K >'+i,AHG='MK+n&) #&? &' 0,'#n? 'W #&K ^B? ,'+ E,nG ; = n? ? n,A0n'% : F! +9QK9 ; 9H %1QKB N? P&= 2 D, n j] ))= ', H& +, ]' #n K >'+ i ,A HG = 'M K+ n&) K i, ? # kn ? C nK Kn ? + U 2 4'#n? n dnn+,'MK K,'# ',A0+ )n0? ']+in'#,M ]#n? $Cn? OG$KK,MU 2 T,'#n? ',KKn in? #n' ,#n'+,O,; ,n? + ='# ]#n? &=OMnGZK+U 2 >'+KA0n,#='MKCn#&? O i,? # n? H&''+W >'+KA0n,#='Mn' Mn+? ]OOn'U 2 D&K _,KKn'KK+&'# #nK >'+i,AHG='MK+n&)K i,? # kn? CnKKn? +U D&,GQ ^Xb.d <?page no="101"?> 3.3 Meetings 101 wesend. Zudem sind auch die Stakeholder mit eingeladen. So erhalten sie einen Überblick über den neuesten Stand der Entwicklungsarbeit und können dem Entwicklungsteam gleichzeitig Feedback geben. Dies ermöglicht es, dass das Produkt überprüft und angepasst werden kann. Der Sprint Review ist ein informelles Meeting und nicht mit einem Statusmeeting zu verwechseln. Die Präsentation der Ergebnisse des Sprints dient im Wesentlichen dazu, Feedback zu ermöglichen und die Zusammenarbeit zu fördern. Der Sprint Review dauert maximal vier Stunden bei einem Sprint, der vier Wochen dauert. Wenn die Dauer des Sprints kürzer ist, dann sollte auch der Sprint Review entsprechend angepasst werden. Der SCRUM Master ist dafür verantwortlich, dass das Meeting stattfindet und dass alle den Grund des Meetings kennen. Zudem unterstützt der SCRUM Master dabei, dass jeder, der am Meeting teilnimmt, dazu beiträgt, dass das Meeting in dem festgelegten Zeitrahmen bleibt. Der Sprint Review hat typischerweise die folgende Agenda: ! Der Product Owner erläutert, welche Items des Product Backlog erledigt, also „Done“ sind und welche nicht. ! Das Entwicklungsteam diskutiert, was während des Sprints gut gelaufen ist, welche Probleme aufgetaucht sind und wie diese Probleme gelöst wurden. ! Das Entwicklungsteam stellt die Arbeit vor, die erledigt, „Done“ ist und beantwortet Fragen über das Produktinkrement. ! Der Product Owner diskutiert das Product Backlog in seinem aktuellen Stand. Er gibt einen Ausblick auf künftige Lieferdaten und Ziele basierend auf dem aktuellen Fortschritt (sofern dies notwendig ist). ! Die gesamte Gruppe (SCRUM-Team und Stakeholder) arbeitet zusammen daran, was als nächstes getan werden sollte, so dass der Sprint Review einen wertvollen Input für das nächste Sprint Planning liefert. <?page no="102"?> 102 3 Wie funktioniert SCRUM? ! Überprüfung, wie sich der Markt oder der potenzielle Einsatzbereich des Produkts geändert haben könnte bezogen darauf, was der beste nächste Schritt wäre. ! Überprüfung des Zeitplans, des Budgets, der potenziellen Ressourcen und des Markt für das nächste anstehende Release bezüglich der Funktionen und Capabilities des Produkts. Das Ergebnis des Sprint Reviews ist ein überarbeitetes Product Backlog, welches die potenziellen Product Backlog Items für den nächsten Sprint ableitet. Das Product Backlog kann auch grundlegend angepasst werden, wenn sich neue Möglichkeiten ergeben. Abb. 27: Sprint Review #! A1 3Q H1 +Q F3 ; 9 H N'! Q3 + P9 0Q 9.H 2 ^B? ,'+ bnk,ni O,'#n+ &) >'#n n,'nK ^B? ,'+K K+&++U 2 E,nG ,K+ #,n >? MnC',KKn #nK ^B? ,'+K ; = $Cn? B? $On' ='# &'; =B&KKn'U 2 Dn? ^B? ,'+ bnk,ni ,K+ n,' B0QK,KA0nK dnn+,'MU 2 >,'MnG&#n' ,K+ #&K MnK&)+n ^Xb.d 3n&) ='# #,n ^+&Hn0]G#n? U 2 D&=n? + )&R 2 ^+='#n' Cn, 2 iZA0,Mn' ^B? ,'+ C; iU H$? ; n? U 2 ^Xb.d d&K+n? ,K+ #&O$? kn? &'+i]? +G,A0 #&KK #&K dnn+,'MU K+&++O,'#n+ ='# &GGn $Cn? Kn,'n' m? ='# CnKA0n,# i,KKn'U 2 ^Xb.d d&K+n? ,K+ &=A0 #&O$? kn? &'+i]? +G,A0 #&KK #&K dnn+,'M ,) MnBG&'+n' En,+? &0)n' CGn,C+U LQ9K9 ; 9H =99+Q3AH 2 Dn? (? ]#=A+ Ii'n? n? G\=+n? + inGA0n P+n)K #nK (? ]#=A+ [&AHG]M n? Gn#,M+ &GK] 9D]'n< K,'# ='# inGA0n ',A0+U 2 D&K >'+i,AHG='MK+n&) #,KH=+,n? + i&K i\0? n'# #nK ^B? ,'+K M=+U MnG&=On' ,K+ ='# inGA0n (? ]CGn)n &=OMn+&=A0+ K,'#U 2 >'+i,AHG='MK+n&) K+nGG+ #,n 4? Cn,+ k]? #,n n? Gn#,M+ ,K+U 2 (? ]#=A+ Ii'n? K+nGG+ &H+=nGGn (? ]#=A+ [&AHG]M k]? Kn,'n) &H+=nGGn' ^+&'#U 2 *Cn? B? $O='M d&? H+ ]#n? >,'K&+; Cn? n,A0 #nK (? ]#=H+ Mn\'#n? +U 2 *Cn? B? $O='M En,+BG&'KW [=#Mn+KW bnKK]=? An' ='# #nK d&? H+U ^B? ,'+ bnk,ni <?page no="103"?> 3.3 Meetings 103 Sprint-Retrospektive Das Ziel der Sprint-Retrospektive ist, Feedback einzuholen, um den Entwicklungsprozess organisatorisch und strukturell zu verbessern. Es geht also nicht um Feedback bezogen auf die erzielte Arbeit wie beim Sprint Review, sondern um die Arbeitsweise, wie sie war und was verbessert werden kann. Im Kern geht es darum, dass Verbesserungspotenzial bezogen auf Menschen, Interaktionen, Prozess und Wertzeuge identifiziert wird. Abb. 28: Sprint Retrospektive #! A13QH1+QF3 ; 9! N'! Q3+ P9+! FH'9O+Q09 2 d nn +, 'M O, '#n+ &GK (? \Kn'; ) nn +, 'M K+& ++ U 2 D,n D&=n? ,K+ 5 ^+='#n' Cn, n,'n) 5 iZA0,Mn' ^B? ,'+ C; iU H$? ; n? U 2 ",'#n+ '&A0 #n) Gn+; +n' ^B? ,'+ bnk,ni ='# k]? #n) H]))n'#n' ^B? ,'+ (G&'','M K+&++U 2 >K ',))+ #&K MnK&)+n ^Xb.d 3n&) &) dnn+,'M +n,GU 2 ^Xb.d d&K+n? ,K+ O$? #,n I? M&',K&+,]' ; =K+\'#,MU 2 ^Xb.d d&K+n? ',))+ +n,GW #&K nK #&K i,A0+,MK+n dnn+,'M ,K+ =) "nn#C&AH ; =) >,'0&G+n' #n? ^Xb.d bnMnG' ; = n? 0&G+n'U 2 ^Xb.d d&K+n? 0&+ ^]? Mn ; = +? &Mn' #&KK #&K dnn+,'M B? ]#=H+,k ='# B]K,+,k kn? G\=O+U 2 ^Xb.d d&K+n? H$))n? + K,A0 #&? =)W #&KK #&K dnn+,'M ,) MnBG&'+n' En,+? &0)n' CGn,C+U LQ9K9 ; 9H =99+Q3AH 2 E,nG ,K+ nK "nn#C&AH n,'; =0]Gn' ; =) >'+i,AHG='MKB? ]; nKKU 2 *Cn? B? $O='M i,n #n? Gn+; +n ^B? ,'+ MnG&=On' ,K+ ),+ "]H=K &=O #,n dn'KA0n'W [n; ,n0='Mn'W (? ]; nKKn ='# 3]]GKU 2 P#n'+,O,H&+,]' ='# ^+? =H+=? ,n? ='M #n? 30n)n' #,n M=+ MnG&=On' K,'# ='# B]+n'; ,nGGn? `n? CnKKn? ='MKOnG#n? U 2 >? K+nGG='M (G&'K ; =? .)Kn+; ='M #n? `n? CnKKn? ='MKOnG#n? U ^B? ,'+ bn+? ]KBnH+,kn mG&# ^&# d&# <?page no="104"?> 104 3 Wie funktioniert SCRUM? Das Meeting findet immer nach dem letzten Sprint Review und vor den kommenden Sprint Planning statt. Das Meeting erfolgt in Form eines Präsenzmeetings. An dem Meeting nehmen das gesamte SCRUM-Team, nicht jedoch die Stakeholder teil. Dies liegt daran, dass die Sprint Retrospektive sich auf eine Verbesserung der Entwicklungsarbeit bezieht, also die Art und Weise, wie das Entwicklungsteam inklusive dem Rest des SCRUM-Teams zusammengearbeitet hat. Der Fokus der Stakeholder liegt jedoch auf dem Ergebnis dieses Prozesses, also dem Produkt. Die Dauer des Meetings ist auf maximal drei Stunden begrenzt bei einem Sprint von einer Dauer von vier Wochen. Bei einem kürzeren Sprint dauert die Sprint Retrospektive entsprechend kürzer. Der SCRUM Master ist für die Organisation des Meetings zuständig. Zudem muss er dafür sorgen, dass alle Teilnehmer den Grund des Meetings kennen. Er nimmt an dem Meeting teil, da er für die Einhaltung der SCRUM-Regeln verantwortlich ist. Die Sprint-Retrospektive ist eines der wesentlichsten Meetings, in denen der SCRUM Master die Einhaltung der SCRUM-Regeln überprüfen und eventuell coachend aktiv werden kann. Er hat auch dafür Sorge zu tragen, dass das Meeting produktiv und positiv verläuft. Zudem sollte er alle Teilnehmen dazu anhalten, dass das Meeting im geplanten Zeitrahmen bleibt. Die folgenden Ziele des Meetings bestimmen seine Agenda: ! Überprüfung, wie der letzte Sprint gelaufen ist, mit Fokus auf die Menschen, Beziehungen, Prozesse und Tools. ! Identifikation und Strukturierung der Themen, die gut gelaufen sind, und potenzieller Verbesserungsfelder. ! Erstellung eines Plans, wie die Verbesserungsfelder umgesetzt werden können, so dass das SCRUM-Team seine Arbeit am besten erledigen kann. Im Rahmen der SCRUM-Retrospektive können Tools sehr einfach genutzt werden, um Feedback einzuholen. Die einfachste Art und Weise ist es, eine Metaplanwand in <?page no="105"?> 3.3 Meetings 105 drei Felder zu teilen: Glad, Sad, Mad. Jedes Mitglied des SCRUM-Teams schreibt auf eine Metaplankarte, was ihm zu diesen drei Punkten einfällt, und pinnt es an die Wand. Der SCRUM Master moderiert dann das, was an die Wand gepinnt wurde, und erarbeitet mit dem Team die Verbesserungspotenziale und einen Plan, wie diese umgesetzt werden können. Für die Verbesserungsmaßnahmen ist im Ergebnis immer entweder das Entwicklungsteam oder der SCRUM Master zuständig. Auch die erarbeiteten Verbesserungsmaßnahmen sollten priorisiert werden, so dass ganz klar ist, welche dieser Maßnahmen zuerst und von wem umgesetzt werden sollten. Abb. 29: Transparenz in der Sprint Retrospektive MG&# K&# )&# <?page no="106"?> 106 3 Wie funktioniert SCRUM? Der SCRUM Master nimmt im Rahmen der Sprint-Retrospektive eine zentrale Rolle ein. So ermuntert er das Team dazu, sich zu verbessern, indem es den SCRUM Framework, den SCRUM-Prozess und den Entwicklungsprozess nutzt, um noch effektiver und mit hoher Motivation zu arbeiten. Im Rahmen jeder Sprint Retrospektive plant das SCRUM-Team die Produktqualität zu verbessern, indem es seine Arbeitsprozesse verbessert und die Definition of Done anpasst. Dies natürlich nur, wenn es angemessen ist und nicht im Konflikt zu Produktstandards oder Unternehmensstandards steht. Das Ergebnis der Sprint-Retrospektive sind identifizierte Verbesserungsmaßnahmen, die im kommenden Sprint umgesetzt werden sollen. Wenn diese Verbesserungsmaßnahmen umgesetzt werden, setzt das SCRUM-Team die Anpassung um, die durch seine eigene Überprüfung erfolgt ist. Das SCRUM-Team verbessert also sich und seine eigene Arbeit selbst. Grundsätzlich können Verbesserungen natürlich zu jeder Zeit im Rahmen des SCRUM-Prozesses vorgenommen werden. Dennoch bietet die Sprint Retrospektive eine formale Möglichkeit, sich auf Überprüfungen und Verbesserungen im SCRUM-Team zu fokussieren. Weitere Prozesse Die bisher vorgestellten Meetings stellen den Kern von SCRUM dar, so wie es von Jeff Sutherland und Ken Schwaber auch im SCRUM-Guide dargestellt wurde. Zudem wird ein Prozess im SCRUM-Guide beschrieben, der Product Refinement genannt wird. Hierbei handelt es sich um einen fortlaufenden Prozess, der im Rahmen des SCRUM-Prozesses durchgeführt wird. Product Backlog Refinement Beim Product Backlog Refinement handelt es sich um die Detaillierung und Konkretisierung der Product Backlog Items. Konkret geht es darum, die Product Backlog Items um die Details wie Beschreibungen, Schätzungen und Priorisierung zu ergän- <?page no="107"?> 3.3 Meetings 107 zen. Die Features, Funktionen, Erwartungen und Änderungen des Produkts, die im Product Backlog aufgezählt sind, werden also näher beschrieben. Die Durchführung des Product Backlog Refinements erfolgt zwischen dem Product Owner und dem Entwicklungsteam. Das Product Backlog Refinement hat keinen festen beziehungsweise bestimmten Zeitpunkt im Rahmen des SCRUM Prozesses. Das Product Backlog Refinement erfolgt fortlaufend. Die Entscheidung, wann und wie es durchgeführt wird, liegt beim SCRUM-Team. Der Aufwand für das Product Backlog Refinement sollte insgesamt nicht mehr als 10 Prozent der gesamten Entwicklungsarbeit ausmachen. Im Rahmen des Product Backlog Refinements werden die einzelnen Product Backlog Items überprüft und angepasst. Die Product Backlog Items selbst können jederzeit von Product Owner oder auf seine Anweisung hin angepasst werden. Die Entscheidung über die Anpassung der Product Backlog Items liegt also beim Product Owner, die Entscheidung über den Zeitpunkt der Durchführung des Product Backlog Refinements liegt beim SCRUM-Team. Die Detaillierung und Granularität der Product Backlog Items sind durchaus unterschiedlich. Grundsätzlich sind alle Product Backlog Items vom Product Owner in eine Rangfolge gebracht worden. Die Rangfolge beschreibt hierbei, welches aus Sicht des Product Owners die wichtigsten Funktionen sind, die als nächstes vom Entwicklungsteam umgesetzt werden sollten. Hierbei stehen Product Backlog Items, die als nächstes umgesetzt werden sollten, ganz oben im Product Backlog, und Items, die später umgesetzt werden sollten, weiter unten. Die Backlog Items, die als nächstes anstehen, sind hierbei klarer beschrieben und detaillierter als die Items, die erst für eine spätere Umsetzung anstehen. Hierbei ist wichtig, dass die Items, die potenziell für den nächsten Sprint vorgesehen sind, so ausreichend detailliert sind, dass jedes Mitglied des SCRUM-Teams auch versteht, was zu tun ist und was die Anforderungen bezüglich des „Done“ sind. Die Voraussetzung, dass ein Backlog Item aus dem Product Backlog ins Sprint Backlog übergeht und somit im Sprint um- <?page no="108"?> 108 3 Wie funktioniert SCRUM? gesetzt werden kann, ist also, dass dieses Backlog Item so detailliert wurde, dass es in dem anstehenden Zeitfenster des kommenden Sprints auch umgesetzt werden kann. Wenn ein Backlog Item vom Entwicklungsteam innerhalb eines Sprints erledigt („Done“) werden kann, wird es als bereit („Ready“) für die Auswahl für den nächsten Sprint und damit für das Sprint Backlog gesehen. Für die Schätzungen ist immer das Entwicklungsteam zuständig. Der Product Owner kann Einfluss auf das Entwicklungsteam nehmen und ihm helfen, die Schätzungen durchzuführen und Abwägungen und Trade offs vorzunehmen. Dennoch bleiben die Entscheidung und die finale Durchführung der Schätzung beim Entwicklungsteam. Abb. 30: Product Backlog Refinement PD [n; n,A0'='M [nKA0? n,C='M (? ,]? ,+\+ ^A0\+; ='M -BB 4CAC99&(S* A(! .C<(? T><A J8? *( TC? ? M89; ,#(! ? ,>*( ! @ .C<(? T><A (! ? $(A(? D L! (<*8<,# Q! <* (! ? 6><#(< *(&! ? ! (<9(< 4CAC99 $(QV#<9D - +B # +"U -B' )W+ P j? ,+n? ,n' ]O D]'n 4CAC99&(S* TC? ? A(&HSS9 Q(<*(? 4CAC99 Q! <* C8; 4CAC99; 9C&&(S A(<(,#? (9 P (? ]#=A+ [&AHG]M bnO,'n)n'+V 2 D,n (? ]#=A+ [&AHG]M P+n)K in? #n' ,) b&0)n' #nK (? ]#=A+ [&AHG]M bnO,'n)n'+K K] #n+&,GG,n? + #&KK K,n i\0? n'# #n? >'+i,AHG='MK&? Cn,+ ,) ^B? ,'+ Cn&? Cn,+n+ in? #n' HZ''n'U 2 E=#n)in? #n' ^,n (? ,]? ,K,n? + K]W #&KK n,'#n=+,M ,K+W inGA0n [&AHG]M P+n)K ; =n? K+ #=? A0 #&K >'+i,AHG='MK+n&) Cn&? Cn,+n+ in? #n'U 2 E=#n)i,? # n,'n ^A0\+; ='M #n? [&AHG]M P+n)K k]? Mn']))n'W K] #&KK n,' "]? +G&=On'#nK "]? +KA0? ,++K)]',+]? ,'M )ZMG,A0 ,K+U <?page no="109"?> 3.3 Meetings 109 Definition of Ready Die Voraussetzung, dass ein Backlog Item vom Entwicklungsteam entwickelt werden und jemals den Zustand des „Done“ erreichen kann, ist, dass es ausreichend detailliert beschrieben wurde. Nur wenn das Backlog Item priorisiert, geschätzt und verstanden ist, ist es bereit, aus dem Product Backlog ins Sprint Backlog überführt zu werden. Die „Definition of Ready“ beschreibt also, wie detailliert ein Backlog Item beschrieben werden muss beziehungsweise welche Kriterien es erfüllen muss, damit es so „bereit“ ist, dass es im anstehenden Sprint vom Entwicklungsteam auch umgesetzt werden kann. Abb. 31: Definition of Ready PD [n ; n ,A 0' =' M [n KA 0? n, C= 'M (? , ]? ,+ \+ ^A0 \+ ; ='M -BB 4CA C99&(S* A(! .C<(? T><A J8? *( TC? ? M89; ,#(! ? ,>*( ! @ .C<(? T><A (! ? $(A(? D L! (<*8<,# Q! <* (! ? 6><#(< *(&! ? ! (<9(< 4CAC99 $(QV#<9D - +B # +"U -B' )W+ P j? ,+ n? , n' ]O D]'n 4CAC99&(S* TC? ? A(&HSS9 Q(<*(? 4CAC99 Q! <* C8; 4CAC99; 9C&&(S A(<(,#? (9 P Dn O,',+,]' ]O bn&#QV Dn+&,GG,n? ='M K] #&KK [&AHG]M P+n)KV B? ,]? ,K,n? +W kn? K+\'#G,A0 ='# MnKA0\+; + K,'#U DnO,',+,]' ]O D]'nV "nK+GnM='M k]' 4C'&0)nH? ,+,n? n' <?page no="110"?> 110 3 Wie funktioniert SCRUM? Zusammenführung von Rollen und Meetings Letztlich stellt sich die Frage, welche Rollen an welchen Meetings teilnehmen. Denn es ist nicht grundsätzlich so, dass alle Rollen an allen Meetings teilnehmen. Jede Rolle darf nur an bestimmten Meetings teilnehmen. Auch die Stakeholder dürfen nur an bestimmten Meetings teilnehmen. Und oft ist es für unsere Seminararteilnehmer auch überraschend, dass die Stakeholder überhaupt an Meetings teilnehmen dürfen. Denn gemäß Definition sind die Stakeholder ja gar keine Mitglieder des SCRUM-Teams. Letztlich dürfen die Stakeholder nur an den Meetings Daily SCRUM und am Sprint Review teilnehmen. Auch bei diesen beiden Meetings haben sie ganz spezifische Rollen. Die folgende Übersicht gibt dir einen Blick darauf, welche Rollen in welchen Meetings teilnehmen. Abb. 32: Zusammenführung Meetings und Rollen dnn+,'M (? ]#=A+ Ii'n? d&K+n? >'+i,AHG='MKN +n&) ^+&Hn0]G#n? ^B? ,'+ (G&'','M ! ! ! ^B? ,'+! / ! - / ! - ! / ! - D&,GQ ^Xb.d ! [n]C&A0+n? ! [n]C&A0+n? ! d,+i,? H='M ! [n]C&A0+n? ^B? ,'+ bnk,ni ! ! ! ! ^B? ,'+ bn+? ]KBnH+,kn ! ! ! / #3.I+H= B2. #3.I+H IGH 2I+ 94+H'I+2.@ 82. '%%2 D22HI+JG F,5'GGH: B2++46" EI.8 82. 2IJ2+H%I6"2 #3.I+H 45H '%G 82. -2E2I%IJ2 ; 2JI++ 82. ? +HEI6*%F+JG'.72IH 72)2I6"+2H: <?page no="111"?> 2.*4#-%/ 0#'4 111 Übungsfragen zum Kapitel: „Wie funktioniert SCRUM? - Meetings“ Hinweis: Es können eine oder mehrere Antworten richtig sein. Die Auflösung findest du in Abschnitt 5.5. [56] Meetings in SCRUM sind dadurch charakterisiert, … " dass sie Regelmäßigkeit sicherstellen. " dass sie regelmäßig die Chance zu Überprüfung und Anpassung geben. " dass sie einen festen Zeitrahmen haben. " Keine der Ant wortmögl ichkeiten ist richtig. [57] D ie D auer von SCRUM Meetings ist … " maximal vier Wochen für einen Sprint " maximal acht Stunden für die Sprint Retrospektive " maximal vier Stunden für den Sprint Review " maximal drei Stunden für die Sprint Retrospektive [58] Für die Zeiteinhaltung der Meetings in SCRUM … " sind die Stakeholder zuständig " ist der SCRUM Master zuständig " ist das Entwicklungsteam zuständig " ist der Product Owner zuständig. [59] Meetings in SCRUM sind … " Product Backlog, Sprint Backlog, Inkrement. <?page no="112"?> 112 3 Wie funktioniert SCRUM? " Sprint-Ziel, Product Backlog Refinement. " Sprint Planning, Sprint Review, Sprint, Daily SCRUM und Sprint-Retrospektive. " Keine der Antwortmöglichkeiten. [60] Der Sprint … " ist ein Container aus mehreren Meetings. " ist in seiner Dauer fix. " wird nur einmal durchgeführt. " Keine der Antwortmöglichkeiten ist richtig. [61] Das Sprint Planning … " ist im zeitlichen Ablauf das erste Meeting in einem Sprint. " ist in zwei Teile aufgegliedert. " dient dazu, den kommenden Sprint zu planen. " Keine der aufgeführten Möglichkeiten. [62] Welche der folgenden Aussagen ist richtig? " Im Sprint Planning sind das SCRUM-Team und die Stakeholder anwesend. " Das Sprint Planning umfasst die Fragen, WAS im kommenden Sprint WIE umgesetzt wird. " Das Sprint Planning ist einmal pro Sprint durchzuführen. " Beim Sprint Planning erstellt der Product Owner alleine einen Plan für den anstehenden Sprint. <?page no="113"?> Übungsfragen 113 " wird jeden Tag zur gleichen Zeit am gleichen Ort durchgeführt. " dauert immer maximal 15 Minuten. " ist das Meeting des Entwicklungsteams, bei dem auch nur das Entwicklungsteam spricht. " ist ein Meeting des gesamten SCRUM-Teams, bei dem jeder Teilnehmer aktiv sein sollte, [64] Im Daily SCRUM beantworten die Teilnehmer die folgenden Fragen: " Was habe ich gestern für das Entwicklungsteam getan, um das Sprint-Ziel zu erreichen? " Was werde ich heute für das Entwicklungsteam tun, um das Sprint-Ziel zu erreichen? " Welche Hindernisse hindern mich daran, das Entwicklungsteam dabei zu unterstützen, das Sprint-Ziel zu erreichen? " Wie kann das Entwicklungsteam den Product Owner unterstützen, das Sprint Backlog zu aktualisieren? [65] Teilnehmer im Daily SCRUM sind … " nur die Stakeholder und das Entwicklungsteam. " nur das Entwicklungsteam und der Product Owner. " nur der SCRUM Master und das Entwicklungsteam. " das SCRUM-Team und die Stakeholder. [63] Das Daily SCRUM … <?page no="114"?> 114 3 Wie funktioniert SCRUM? " wird jeweils nach dem Sprint beziehungsweise der Entwicklungsarbeit durchgeführt. " dient dazu, dass der Product Owner das aktuelle Product Backlog vorstellt. " dient dazu, dass das Entwicklungsteam den aktuellen Stand der Entwicklungsarbeit vorstellt. [67] Welche der folgenden Aussagen sind richtig? " Am Sprint Review nehmen das gesamte SCRUM-Team und die Stakeholder teil. " Der Fokus des Sprint Reviews ist das Produkt und sein aktueller Umsetzungsstand. " Der Sprint Review kann entfallen, wenn alle Backlog Items des Sprint Backlogs vollumfänglich umgesetzt wurden. " Der Product Owner stellt im Sprint Review vor, welche Backlog Items des Sprints er abgenommen hat und welche nicht. [68] Die Sprint-Retrospektive … " bedeutet, dass das gesamte SCRUM-Team Feedback zum Entwicklungsprozess gibt. " dient dazu, Feedback zu Menschen, Interaktionen, Prozessen und Werkzeugen zu sammeln. " ermöglicht, Verbesserungsmaßnahmen zu erarbeiten. " ermöglicht, eine Planung für die Verbesserungsmaßnahmen durchzuführen. [66] Der Sprint Review … " dient dazu, den aktuellen Stand der Entwicklungsarbeit zu präsentieren. <?page no="115"?> Übungsfragen 115 " Backlog Items beschrieben, priorisiert und geschätzt werden. " das Entwicklungsteam eine Schätzung der Backlog Items vornimmt. " Keine der Antwortmöglichkeiten ist richtig. [70] Definition of Ready bedeutet, dass … " Kriterien zur Abnahme des Inkrements definiert sind. " Backlog Items „Ready“ für das Sprint Backlog sind. " Backlog Items detailliert beschrieben, priorisiert und geschätzt werden. " ein Backlog Item bereit ist, in das Sprint Backlog übernommen zu werden und bestimmte Kriterien erfüllt. [69] Product Backlog Refinement bedeutet, dass … " die Backlog Items des Product Backlog detailliert werden. <?page no="116"?> 3.4 Artefakte SCRUM arbeitet mit wenigen Artefakten. Artefakte sind quasi die Tools, die helfen, neben den definierten Rollen und Meetings die Arbeit zu organisieren. Gemäß dem SCRUM-Guide werden nur drei Artefakte beschrieben. Zusätzlich erwähnt der SCRUM-Guide noch das „Sprint-Ziel“ und die „Definition of Done“. Da diese weder Rollen noch Meetings sind, beschreiben wir auch diese beiden an dieser Stelle in unserem Buch. Letztlich handelt es sich hierbei um zwei wesentliche Elemente, die beim Einsatz der drei Artefakte dabei helfen, Transparenz zu schaffen, auf deren Basis Überprüfung und Anpassung möglich sind. Abb. 33: Übersicht Artefakte : F! 1JHH9+*J3A93 ( ? ]#=A+ [&AHG]M MGn,A0nK `n? K+\'#',K #nK 4? +nO&H+K ^B? ,'+ [&AHG]M 3? &'KB&? n'; k]' P'O]? )&+,]'n' )&R,),n? n' P'H? n)n'+ bnB? \Kn'+,n? n' 4? Cn,+ ,0? n' _n? + dZMG,A0Hn,+ ; =? *Cn? B? $O='M ='# 4'B&KK='M *Cn? K,A0+ 4? +nO&H+n 11' 3 Wie funktioniert SCRUM? <?page no="117"?> 3.4 Artefakte 117 Es ist uns sehr wichtig, in diesem Buch einerseits den Kern von SCRUM gemäß Jeff Sutherland und Ken Schwaber vorzustellen und auf der anderen Seite auch in der Praxis erprobte Konkretisierungen und Ergänzungen der Methodik vorzustellen. Charakteristika von Artefakten Es gibt bestimmte Voraussetzungen, die gegeben sein sollten oder die die Basis der Effektivität vom Einsatz der Artefakte im Rahmen der SCRUM-Methodik darstellen. Repräsentation der Arbeit und ihres Werts Bisher haben wir die Rollen und Meetings nach SCRUM beschrieben. Beides sind quasi die weichen Faktoren von SCRUM. Die Rollen stellen die jeweiligen Akteure im einem Projekt beziehungsweise einer Produktentwicklung dar. Die Meetings beschreiben dann, wie die Kommunikation im SCRUM-Prozess zwischen diesen Individuen erfolgt. Die Artefakte hingegen beschreiben konkret, wie der aktuelle Stand der Arbeit des SCRUM-Team steht. Also welche Aufgaben zu erfüllen sind, um das Produkt mit seinen gewünschten Funktionen zu erschaffen. Zudem macht es den Wert dieser Arbeit zu jedem Zeitpunkt des Projekts transparent. Die Artefakte fassen die Erwartungen an das zu erstellende Endprodukt zusammen und konkretisieren sie zudem. So ist es jederzeit möglich zu wissen, wie der aktuelle Umsetzungsstand der Entwicklung und was das Ziel aller Entwicklungsarbeit ist. Maximale Transparenz der Information Ein wesentliches Ziel des Einsatzes von Artefakten ist es, eine maximale Transparenz bezüglich der für die Entwicklung des Produkts notwendigen Arbeiten zu schaffen. Diese maximale Transparenz ist die Basis dafür, fortlaufend zu überprüfen und anzupassen. Transparenz ist das wichtigste Kriterium, das an Artefakte gestellt wird. Denn alle <?page no="118"?> 118 3 Wie funktioniert SCRUM? Entscheidungen bezüglich Werte oder Risiken werden auf Basis der Artefakte getroffen. Deswegen müssen diese die maximale Transparenz sicherstellen. Wenn die Transparenz nicht vollständig ist, ist die Basis für diese Entscheidungen unsicher und nicht verlässlich. Das Ergebnis könnte ein Rückgang im Produktwert oder ein Anstieg der Risiken sein, was auf jeden Fall zu verhindern ist. Das gesamte SCRUM-Team muss daran arbeiten, dass jederzeit Transparenz der Informationen in den Artefakten gewährleistet ist. Der SCRUM Master hat hierbei die Aufgabe, das SCRUM-Team zu befähigen, mangelnde Transparenz zu erkennen und zu beheben. Es ist seine Aufgabe, mit dem SCRUM-Team und der Organisation zusammenzuarbeiten, dass die Transparenz der Artefakte fortlaufend zunimmt. Diese Transparenz kann nicht von vorneherein vollumfänglich gegeben sein. Es ist vielmehr ein Weg, den das ganze Team während des SCRUM-Prozesses gehen muss. Aufgabe des SCRUM Masters ist hierbei zu lernen, zu überzeugen und zu verändern. Transparenz ist kein Zustand, sondern ein Weg, den das SCRUM-Team nur gemeinsam gehen kann. Möglichkeit zur Überprüfung und Anpassung Durch die durch die Artefakte geschaffene Transparenz über das zu entwickelnde Produkt und seine Funktionen ist es möglich, diese fortlaufend zu überprüfen und anzupassen. So kann fortlaufend überprüft und angepasst werden, „WAS“ entwickelt wird. Zudem beinhalten die Artefakte auch Informationen darüber, „WIE“ das Produkt entwickelt wird. Auch der Prozess der Entwicklung und der Zusammenarbeit im SCRUM-Team werden also fortlaufend angepasst. Gleiches Verständnis Es ist wichtig, dass alle Mitglieder des SCRUM-Teams inklusive der Stakeholder ein einheitliches Verständnis darüber haben, was entwickelt und wie dieses Ziel erreicht werden soll. Dieses Verständnis ist nur dann möglich, wenn das Produkt, das erstellt <?page no="119"?> 3.4 Artefakte 119 werden soll, mit all seinen Funktionen allen Teammitgliedern bekannt ist. Zudem sollen alle Teammitglieder verstehen, was mit diesen Funktionen konkret gemeint ist. Nur dieses gemeinsame Verständnis ermöglicht eine effiziente und effektive Entwicklungsarbeit. Überblick der 3 Artefakte von SCRUM Wie bereits erwähnt, gibt es nach SCRUM drei Artefakte. Diese sind die folgenden: ! Product Backlog ! Sprint Backlog ! Inkrement Diese drei Artefakte werden wir im Folgenden vorstellen. Im Rahmen der Vorstellung werden wir immer diese Fragen beantworten: ! Warum ist das Artefakt notwendig? ! Was ist das Ziel des Artefakts? ! Wer ist für das Artefakt zuständig? ! Wofür wird das Artefakt eingesetzt? ! Wo im SCRUM-Prozess kommt es zur Anwendung? Product Backlog Was ist das Ziel des Product Backlogs? Das Product Backlog ist eine Auflistung aller Produktfeatures, die das Produkt, wenn es entwickelt ist, enthalten soll. Die Produktfeatures im Product Backlog werden Product Backlog Items genannt. Sie sind in einer bestimmten Reihenfolge nach Priorität geordnet. Es stellt die einzige Quelle aller Anforderungen an das Produkt und aller Änderungen, die am Produkt vorgenommen werden, dar. <?page no="120"?> 120 3 Wie funktioniert SCRUM? Das Product Backlog ist nie vollständig, es lebt während des gesamten Entwicklungsprozesses und wird ständig überprüft und angepasst. Die erste Version des Product Backlogs zeigt die anfänglich nach besten Wissen und Gewissen bekannten Anforderungen. Das Product Backlog verändert sich im Zeitverlauf in dem Maße, wie sich der Einsatzbereich des Produkts und auch das Produkt selbst ändert. Das Product Backlog ist also sehr dynamisch. Es verändert sich ständig, um festzustellen, was das Produkt erfordert, um angemessen, wettbewerbsfähig und nützlich zu sein. Wenn ein Produkt existiert, existiert auch ein Product Backlog. So ist die Welt von SCRUM. Das Product Backlog beinhaltet also langfristig alle ! Features, ! Funktionen, ! Anforderungen, ! Verbesserungen, ! Änderungen, die in künftigen Releases des Produkts enthalten beziehungsweise umgesetzt werden sollten. Jeder dieser Einträge im Product Backlog wird Product Backlog Item genannt. Jedes Product Backlog Item hat mehrere Attribute: Beschreibung, Priorisierung, Schätzung und Wert. Meist enthalten Product Backlog Items auch eine Beschreibung der Kriterien, die im Rahmen der Abnahme durch den Product Owner das „Done“ definieren. Wer ist für das Product Backlog zuständig? Für das Product Backlog ist der Product Owner zuständig. Er hat die Verantwortung, das Product Backlog zu erstellen und es während des gesamten Prozesses zu pflegen. Er ist insbesondere für seinen Inhalt, seine Struktur, die Priorisierung der Backlog Items und seine Verfügbarkeit zuständig. <?page no="121"?> 3.4 Artefakte 121 Wie im SCRUM-Prozess kommt das Product Backlog zur Anwendung? Das Product Backlog kommt während des gesamten SCRUM Prozesses zur Anwendung. Es stellt zu jeder Zeit die Basis bezüglich der Transparenz des zu entwickelnden Produktes dar. Das Product Backlog ist die Sammlung mehrerer Backlog Items, die letztlich in ihrer Gesamtheit alle Funktionen, die das zu entwickelnde Produkt umfasst. Im ersten Schritt ist ein Product Backlog Item nur die Bezeichnung einer Funktion wie beispielsweise „Warenkorb“. Weitere Details der Funktion werden dann im Product Backlog Refinement ergänzt. Abb. 34: Darstellung Sprint Backlog P D [n ; n ,A 0'= 'M [ nK A0 ? n ,C =' M (? ,] ? , +\+ ^A0\ +; =' M -BB 4CAC99&(S* A(! .C<(? T><A J8? *( TC? ? M89; ,#(! ? ,>*( ! @ .C<(? T><A (! ? $(A(? D L! (<*8<,# Q! <* (! ? 6><#(< *(&! ? ! (<9(< 4CAC99 $(QV#<9D - +B # +" U -B' )W+ P j? ,+n? ,n' ]O D]'n 4CAC99&(S* TC? ? A(&HSS9 Q(<*(? 4CAC99 Q! <* C8; 4CAC99; 9C&&(S A(<(,#? (9 P <?page no="122"?> 122 3 Wie funktioniert SCRUM? Sprint Backlog Was ist das Ziel des Sprint Backlogs? Das Ziel des Sprint Backlogs ist, dem Entwicklungsteam transparent zu machen, welche Backlog Items im Rahmen des Sprints wie umgesetzt werden sollen. Zudem gibt es zu jedem Zeitpunkt des Sprints Auskunft über den aktuellen Stand der Entwicklungsarbeit des Entwicklungsteams und darüber, welche Aufgaben noch zu erledigen sind, um das Sprint-Ziel zu erreichen. Um eine kontinuierliche Verbesserung sicherzustellen, enthält es auch mindestens eine Verbesserungsmaßnahme, die im Rahmen der letzten Sprint Retrospektive als wichtig beziehungsweise als von hoher Priorität identifiziert wurde. Das Sprint Backlog ist letztlich eine Teilmenge der Backlog Items aus dem Product Backlog. Die Auswahl dieser Backlog Items aus dem Product Backlog für das Sprint Backlog erfolgt im Rahmen des Sprint Plannings. Wer ist für das Sprint Backlog zuständig? Die Verantwortung für das Sprint Backlog liegt einzig beim Entwicklungsteam. Alle Anpassungen und Veränderungen am Sprint Backlog dürfen nur durch das Entwicklungsteam durchgeführt werden. Die Voraussetzung dafür, dass ein Backlog Item in das Sprint Backlog überführt wird, ist erstens, dass es ausreichend detailliert ist. So detailliert, dass das Entwicklungsteam alle Informationen transparent hat, die notwendig sind, um das Backlog Item im Rahmen des Sprints abzuarbeiten. Und zweitens muss das Backlog Item vom Entwicklungsteam für den anstehenden Sprint ausgewählt worden sein, so dass dieses das Item als umsetzbar bezüglich ihrer eigenen verfügbaren Kapazität während des Sprints einschätzt. Wie im SCRUM Prozess kommt das Sprint Backlog zur Anwendung? Das Sprint Backlog enthält einen Plan, wie das Inkrement geliefert und damit das Sprint-Ziel erreicht wird. Konkret enthält das Sprint Backlog eine Planung des Ent- <?page no="123"?> 3.4 Artefakte 123 wicklungsteams, welche Funktionalität das nächste Produktinkrement sein wird, und über die Entwicklungsarbeit, die erforderlich ist, um die Funktionalität in ein „Done“ zu überführen. Dieser Plan muss so detailliert sein, dass er auch im Daily SCRUM genutzt und verwendet werden kann. In der Praxis wird hierfür oft ein Taskboard verwendet (siehe hierzu Abschnitt 4.1). Das Sprint Backlog wird während des Sprints durch das Entwicklungsteam immer weiter überarbeitet, so dass sich das Sprint Backlog hinsichtlich Klarheit und Konkretisierung im Laufe des Sprints immer mehr herausbildet. Dies liegt daran, dass, je länger das Entwicklungsteam am Sprint Backlog arbeitet, es immer mehr von der zu erledigenden Arbeit versteht, die notwendig ist, das Sprint-Ziel zu erreichen. Dieses Wissen wiederum fließt dann im Rahmen der fortlaufenden Überprüfung und Anpassung in das Sprint Backlog ein. Im Laufe des Sprints kann es vorkommen, dass das Entwicklungsteam feststellt, dass grundsätzliche Änderungen im Sprint Backlog notwendig sind. Die drei folgenden grundsätzlichen Gründe können es erforderlich machen, das Sprint Backlog anzupassen: ! Zusätzliche Aufgaben sind erforderlich: Wenn das Entwicklungsteam bemerkt, dass zusätzlich Aufgaben zu erledigen sind, ergänzt es diese Aufgaben im Sprint Backlog. ! Aufgaben können nicht umgesetzt werden: Es kann sein, dass im Laufe des Sprints bemerkt wird, dass manche Aufgaben nicht im Laufe des Sprints erledigt werden können. Die Gründe hierfür können vielfältig sein. Wenn dies so ist, dann werden diese gestrichen. ! Aufgaben sind erledigt: Wenn Aufgaben erledigt sind, werden diese auch so markiert, und für die noch offenen Aufgaben erfolgt eine erneute Schätzung. <?page no="124"?> 124 3 Wie funktioniert SCRUM? Wichtig ist hierbei, dass es nur dem Entwicklungsteam erlaubt ist, Anpassungen am Sprint Backlog durchzuführen. Es ist jederzeit für alle Mitglieder des Entwicklungsteams einsehbar. Es ist ein Echtzeit-Monitor bezüglich der anstehenden Aufgaben des Entwicklungsteams, um das Sprint-Ziel zu erreichen. Abb. 35: Schätzung des Backlogs Inkrement Das Inkrement ist ein auslieferbarer Bestandteil des Produkts. Es beinhaltet alle die Backlog Items, die in einem Sprint umgesetzt wurden. [&AHG]M P+n) ^B? ,'+ 8 ^B? ,'+ 7 ^B? ,'+ 5 3&KH mnKA0\+; +n? 3&KH ^A0\+; ='M mnKA0\+; +nK [&AHG]M P+n) 8 1 0 3&KHK 4 3&KHK [ 3&KHK X 5 1 0 1 0 3& KH K 4 3&KHK [ 3& KH K X 8 1 0 51 0 1 0 1 1 0 1 1 0 21 0 h: 0 8: 0 4CKA0\+; ='M #nK 4=Oi&'#K B? ] [&AHG]M P+n) 4 CMGn,A0 4=Oi&'# [&AHG]M P+n)K ),+ j&B&; ,+\+ >'+i,AH='MK+n&) j&B&; ,+\+ >'+i,AHG='MK+n&) 78: 0 l &GK MnBG&'+n? 4=Oi&'# 8 7 7: : 0 ! <?page no="125"?> 3.4 Artefakte 125 Was ist das Ziel des Inkrements? Das Inkrement wird oft auch Produktinkrement genannt. Es umfasst alle Product Backlog Items, die im Rahmen der vergangenen Sprints umgesetzt wurden. Zudem umfasst es den Wert aller Inkremente, die in den vorherigen Sprints umgesetzt wurden. Das Inkrement ist quasi immer das aktuelle Produkt in seinem letzten Release- Zustand. Das Inkrement stellt einen wichtigen Bestandteil und Anteil zur Erreichung des Projektziels oder der Produktvision dar. Wer ist für das Inkrement zuständig? Das Entwicklungsteam ist für die Erstellung eines übergabefähigen Inkrements zum Ende jedes Sprints verantwortlich. Nach dessen Fertigstellung ist das Inkrement an den Product Owner zu übergeben. Der Product Owner ist dafür zuständig, die Entscheidung zu treffen, ob er das Inkrement releasen beziehungsweise in Betrieb nehmen möchte. Wie im SCRUM-Prozess kommt das Inkrement zur Anwendung? Am Ende jedes Sprints übergibt das Entwicklungsteam seine Arbeit in Form des auslieferfähigen Inkrements an den Product Owner. Wichtige Voraussetzung der Übergabe ist, dass das Inkrement auslieferfähig ist. Hierzu gehört, dass es einerseits der „Definition of Done“ des SCRUM-Teams entspricht und auch in einem potenziell auslieferbaren Zustand ist. Diese Überprüfung sollte bei einem gut eingespielten SCRUM-Team nicht erst bei Übergabe des Inkrements an den Product Owner erfolgen, sondern schon im Rahmen des Sprints durchgeführt werden. Das Inkrement muss grundsätzlich bereit sein in Betrieb genommen zu werden, unabhängig davon, ob der Product Owner es hierfür geeignet hält. <?page no="126"?> 126 3 Wie funktioniert SCRUM? Weitere Werkzeuge als Ergänzung der Artefakte Die drei Artefakte sind so von Ken Schwaber und Jeff Sutherland definiert worden. Zusätzlich zu diesen Artefakten haben sich in den letzten Jahren noch weitere Werkzeuge als hilfreich erweisen, die wir im Folgenden darstellen wollen. ! Sprint-Ziel ! Definition of Done Diese Werkzeuge stellen wir anhand der folgenden Fragen vor: ! Was ist das Ziel des Einsatzes des jeweiligen Werkzeugs? ! Wer ist für den Einsatz des Werkzeuges zuständig? ! Wie wird das Werkzeug im SCRUM-Prozess eingesetzt? Sprint-Ziel Ein Sprint kann durch ein Sprint-Ziel zusammengefasst werden. Die Backlogelemente dienen dann wiederum dazu, das Sprint-Ziel zu konkretisieren. Und die einzelnen Elemente des Backlogs werden wiederum in Tasks gegliedert. Das Sprint- Ziel ist ein Ziel, das für den Sprint definiert wurde, um mit der Umsetzung des Product Backlogs erreicht zu werden. Das Sprint-Ziel ist quasi die Leitlinie für den Sprint. Es gibt dem Entwicklungsteam Führung bezüglich dem „Warum“ es das Produktinkrement umsetzt. Man könnte es auch das Schlagwort oder das Motto nennen, unter dem der aktuelle Sprint steht. Beispiel: „Rabattfunktion für die Sommeraktion“. Das Sprint-Ziel wird während des jeweiligen Sprint Planning Meetings festgelegt. <?page no="127"?> 3.4 Artefakte 127 Abb. 36: Sprint-Ziel Die Product Backlog Items, die für den Sprint ausgewählt wurden, liefern meist eine gemeinsame Funktion des Produkts; diese kann das gewählte Sprint-Ziel sein. Das Sprint-Ziel kann auch jede andere Gemeinsamkeit umfassen, die dazu führt, dass das Sprint-Team zusammenarbeitet anstatt an unterschiedlichen Initiativen zu arbeiten. Immer wenn das Entwicklungsteam bei der Arbeit ist, hat es das Sprint-Ziel vor Augen. Um das Sprint-Ziel zu erreichen, setzt das Entwicklungsteam Funktionen und Technologien um. ^B? ,'+ E,nG 3&KHK (? ]#=A+ [&AHG]M _nGA0nK E,nG kn? O]GM+ #,n .)Kn+; ='M #nK ^B? ,'+ [&AHG]MK% _nGA0n 4=OM&Cn' K,'# ; = n? O$GGn'W =) #,n [&AHG]M P+n)K ; = Gn,K+n'% _nGA0n [&AHG]M P+n)K K,'# O$? #n' ^B? ,'+ ? nGnk&'+% (? ]#=A+ [&AHG]M 3&KHK 4 3&KHK [ 3&KHK X $,G2H)F+J 82. ('7'HH'*HI4+ 5! . 82+ *4"2+82+ #4"2. ^B? ,'+ [&AHG]M 3&KHK D 3&KHK > 3&KHK " 3&KHK m 3& KHK T 3&KHK P ^B? ,'+ E,nG <?page no="128"?> 128 3 Wie funktioniert SCRUM? Abb. 37: Sprint Ziel Charakteristik Definition of Done Ziel der Definition of Done ist es sicherzustellen, dass am Ende eines Sprints ein potenziell auslieferbares Inkrement an den Product Owner übergeben wird, das den Anforderungen der Stakeholder entspricht. Voraussetzung hierfür ist es, dass das SCRUM-Team ein gemeinsames Verständnis (Definition) davon hat, was es bedeutet, dass ein Backlog Item erledigt beziehungsweise fertiggestellt, also „Done“ ist. Hauptziel der Definition of Done ist es, jederzeit Transparenz für das ganze SCRUM- Team zu schaffen, wann etwas Done ist und wann nicht. Diese Definition of Done kann sich beziehen auf: E=K&))n'O&KK='M #nK E,nGK #nK ^B? ,'+K Mn)n,'K&)n gn,+G,',n O$? >'+i,AHG='MKN +n&)i\0? n'# #nK ^B? ,'+K OZ? #n? + #,n E=K&))n'&? Cn,+ ,''n? 0&GC #nK >'+i,AHG='MK+n&)K j G&) )n ? =) #,n [&A HG ]M P+ n) KW #, n =)MnKn+; + in? #n' K]GG+n' i,? # ,) b&0)n' #nK ^B? ,'+ (G&'','MK =)MnKn+; + C; iU #nO,',n? + ^ B? ,' + E, nG <?page no="129"?> 3.4 Artefakte 129 ! Inkrement ! Backlog Item ! Task Es kann sein, dass es eine allgemein gültige Definition of Done für alle drei dieser Elemente gibt, oder dass es jeweils eine spezifische Definition of Done gibt. Das kommt immer darauf an, worauf sich das SCRUM-Team verständigt. Denn wie die Definition of Done genau festgelegt wird, ist von SCRUM-Team zu Team unterschiedlich. Wichtig ist jedoch, dass sich alle Mitglieder des SCRUM-Teams möglichst frühzeitig im SCRUM-Prozess auf ein einheitliches Verständnis festlegen. Abb. 38: Definition of Done [&AH G]M P+n) ^B ? ,' + / >'+i,AHG='MK&? Cn,+- ^ B? ,' + (G&'','M [& AHG]M P+n) (? ]#=A+ [&AHG]M ^B ? ,'+ [&AHG]M 8 7 ^B ? ,' + bnk,ni [& AHG]M P+n) (? ]#=A+ [&AHG]M 5 DnO,',+,]' ]O 9bn&#Q<V [&AHG]M P+n) ,K+S 2 B? ,]? ,K,n? + 2 kn? K+\'#G,A0 2 MnKA0\+; + DnO,',+,]' ]O 9D]'n<V [&AHG]M P+n) n? O$GG+ #,n j? ,+n? ,n'V 2 HG&? #nO,',n? +n j? ,+n? ,n'W i&'' n,' [&AHG]M P+n) &GK D]'n M,G+ 2 j? ,+n? ,n'in? #n' ,) ^B? ,'+ (G&'','M #nO,',n? + ! ! `]? &=KKn+; ='M O$? n? O]GM? n,A0n .)Kn+; ='M ,) &'K+n0n'#n' ^B? ,'+ `]? &=KKn+; ='M O$? 4C'&0)n #nK P'H? n)n'+K #=? A0 #n' (? ]#=A+ Ii'n? ! ! ! ! ! ! <(2'8KC <B4+2C <?page no="130"?> 130 3 Wie funktioniert SCRUM? Letztlich ist das gesamte Entwicklungsteam für die Definition of Done zuständig. Es hat dafür Sorge zu tragen, dass eine Definition of Done entwickelt und diese auch gepflegt wird, und dafür, dass möglichst früh im Prozess eine einheitliche Definition of Done entworfen wird. Es ist zu empfehlen, dies auf jeden Fall im Rahmen des Sprint Plannings durchzuführen - bevor der erste Sprint gestartet wird. Denn nur wenn das Entwicklungsteam ein einheitliches Verständnis des „Done“ hat, kann die Entwicklungsarbeit effektiv und effizient sein. So sollte auch nach jedem Sprint eine Überprüfung und Anpassung der Definition of Done stattfinden. Die Definition of Done lebt also über den ganzen SCRUM-Prozess hinweg. Im Sinne der Transparenz ist es wichtig, dass die jeweils aktuelle Definition of Done für jedermann im SCRUM-Team zugänglich und einsehbar ist. Es ist zu erwarten, dass sich die Definition of Done im Laufe des SCRUM-Prozesses mehr und mehr verfeinert, da das SCRUM-Team lernt, welche Definition of Done für das zu entwickelnde Produkt sinnvoll ist und wie diese mit immer stringenteren Kriterien beschrieben werden kann. Ziel dieser Verbesserung und Konkretisierung sollte stets sein, dass im Ergebnis eine höhere Produktqualität erzielt wird. Es ist durchaus möglich, dass die Tatsache, dass im Laufe des Sprint-Prozesses eine konkreter werdende Definition of Done Arbeit aufdeckt, die getan werden muss, weil die bisherige Definition of Done zu unkonkret war. Je konkreter die Definition of Done und je früher diese konkret ist, umso besser für die Inkremente als Ergebnis des Entwicklungsprozesses. Aus der Praxis: Letztlich sollte jedes Produkt oder jedes System über eine Definition of Done verfügen, die als Standard für alle Arbeiten, die daran vollzogen werden, dienen. In vielen Entwicklungsorganisationen oder -teams gibt es eine einheitliche Definition of Done, die als Minimum für alle Arbeiten in diesem Teams gilt. In diesem Fall haben auch alle SCRUM-Teams diese Definition of Done anzuwenden. Ist dies nicht <?page no="131"?> 3.4 Artefakte 131 der Fall, gibt es also keine einheitlich gültige Definition of Done, und gibt es zwei unterschiedliche Möglichkeiten: ! Es gibt ein SCRUM-Team: Wenn es keine einheitliche Definition of Done gibt, muss das Entwicklungsteam im SCRUM-Team eine Definition of Done definieren, die für das zu entwickelnde Produkt angemessen und passend ist. ! Mehrere SCRUM-Teams arbeiten an einem Produkt: In diesem Fall müssen sich die unterschiedlichen SCRUM-Teams auf eine gemeinsame Definition of Done festlegen. Da alle Teams an einem Produkt oder System arbeiten, darf es auch nur eine Definition of Done geben. Es ist noch wichtig zu erwähnen, dass jedes Inkrement eine Ergänzung aller bisherigen Inkremente darstellt und dass es in der Form getestet sein muss, dass es mit den anderen bereits ausgelieferten Inkrementen funktioniert. Zusammenführung von Artefakten und Rollen Letztlich stellt sich nun - nachdem wir uns mit den Artefakten beschäftigt haben - die Frage, welche Rollen für welche Artefakte zuständig sind. Denn es sollte immer mindestens eine Rolle für ein Artefakt zuständig sein. Andernfalls würde das Artefakt in der Praxis ja keinen Einsatz finden und niemand würde sich für das Artefakt zuständig fühlen. Die Abbildung 39 zeigt, welche Rolle für welches Artefakt zuständig ist. Es zeigt, dass die Stakeholder keine Verantwortung für ein Artefakt haben. Dies hat damit zu tun, dass die Stakeholder selber ja nicht teil des SCRUM-Teams sind. Insofern können sie selbst auch keine Verantwortung für ein Artefakt haben. <?page no="132"?> 132 3 Wie funktioniert SCRUM? Abb. 39: Zusammenführung Artefakte und Rollen 4? +nO&H+n (? ]#=A+ Ii'n? d&K+n? >'+i,AHG='MKN +n&) ^+&Hn0]G#n? ^B? ,'+ E,nG! ! `n? &'+i]? +='M ! d,+i,? H='M ! I! 9Q! <T8? $ DnO,',+,]' ]O D]'n! ! / (<C? 9Q><98? $ ! d,+i,? H='M ! (? ]#=A+ [&AHG]M ! `n? &'+i]? +='M ! d,+i,? H='M ! d,+i,? H='M ! d,+i,? H='M ^B ? ,' + [& AH G]M ! d ,+ i, ? H ='M ! / (<C? 9Q><98? $ P'H? n)n'+ ! / (<C? 9Q><98? $ &H< R<$(A? ! ; ! d,+i,? H='M ! / (<C? 9Q><98? $ &H< R? 9Q! ,TS8? $ / B'G #3.I+H &I2% F+8 8I2 B25I+IHI4+ 45 B4+2 GI+8 *2I+2 1.H25'*H2 J2,0A #9($D: #I2 "'72+ '72. 2I+2 F+H2.GH! H)2+82 (4%%2 I, ('",2+ 82. 1.H25'*H2 F+8 E2.82+ 82GE2J2+ '+ 8I2G2. #H2%%2 'F6" 'F5J2)0"%H: <?page no="133"?> 2.*4#-%/ 0#'4 133 Übungsfragen zum Kapitel: „Wie funktioniert SCRUM? - Artefakte“ Hinweis: Es können eine oder mehrere Antworten richtig sein. Die Auflösung findest du in Abschnitt 5.5. [71] Artefakte sind dadurch charakterisiert, dass … " sie maximale Transparenz schaffen. " ein gleiches Verständnis der Artefakte im Team notwendig ist. " sie eine Möglichkeit zur Überprüfung und Anpassung sind. " die Arbeit un d ihren Wert reprä sent iere n. [72] In S CRUM gibt es insges amt … " drei Artefakte " fünf Artefakte " sieben Artefakte " neun Artefakte [73] Artefakte nach SCRUM sind … " Product Backlog, Sprint Backlog, Inkrement " Sprint-Ziel, Product Backlog Refinement " Product Owner, Product Backlog, Product Refinement " Keine der Antworten ist richtig [74] Das Product Backlog … " ist eine Teilmenge des Sprint Backlogs. <?page no="134"?> 134 3 Wie funktioniert SCRUM? " umfasst alle Backlog Items, die umgesetzt werden sollten. " umfasst alle Features, Funktionen, Anforderungen, Verbesserungen und Änderungen des Produktes. " wird vom Product Owner initial erstellt, gemanagt und gepflegt. [75] Welche der folgenden Aussagen sind richtig? " Das Product Backlog wird von den Stakeholdern erstellt. " Alle Anforderungen der Stakeholder sollten sich im Product Backlog wiederf in den. " Das Product Backlog wird fortlaufend vom Product Owner gepflegt. " Keine der Antwortmöglichkeiten ist richtig. [76] Das Sprint Backlog … " umfasst alle Backlog Items, die im Rahmen des Sprints umgesetzt werden s ollen. " dient dem Entwicklungsteam für Transparenz im Rahmen des Sprints. " wird vom Entwicklungsteam gepflegt. " Keine der aufgeführten Möglichkeiten. [77] Welche der folgenden Aussagen ist richtig? " Das Sprint Backlog ist eine Teilmenge des Product Backlogs. " Voraussetzung, dass Backlog Items ins Sprint Backlog übergehen ist, dass sie „Ready“ sind. <?page no="135"?> 2.*4#-%/ 0#'4 135 " Das Sprint Backlog hat in jedem Sprint den gleichen Inhalt und wird nur jeweils aktualisiert. " Keine der aufgeführten Antwortmöglichkeiten. [78] Das Inkrement … " wird auch Produktinkrement genannt. " muss betriebsfertig und auslieferbar sein. " wird im Sprint Back log einget ragen . " sollte bereits getestet und mit allen anderen Komponenten des Produkts kompa tibel sein. [79] Welche der folgenden Aussagen sind richtig? " Das Entwicklungsteam ist für die Entwicklung des Inkrements zuständig. " Der Product Owner nimmt das Inkrement ab und entscheidet, ob er es releasen möchte. " Das Inkrement wird von SCRUM Master abgenommen. Er entscheidet, ob das Inkrement released wird. " Keine der Antwortmöglichkeiten ist richtig. [80] Das Sprint-Ziel ist … " eine gemeinsame Leitlinien für das Entwicklungsteam im Rahmen des Sprints. " die Zusammenfassung dessen, was in einem Sprint umgesetzt werden sollte. <?page no="136"?> 136 3 Wie funktioniert SCRUM? " die Zeitdauer, die maximal für einen Sprint zu Verfügung steht. " Keine der Antwortmöglichkeiten ist richtig. [81] Das Sprint-Ziel wird … " im Rahmen des Sprint Plannings festgelegt. " im Rahmen des Sprint Reviews festgelegt. " im Rahmen der Sprint-Retrospektive festgelegt. " Keine der Antwortmöglichkeiten ist richtig. [82] Welche der folgenden Aussagen ist richti g? " Das Sprint-Ziel wird vom Product Owner festgelegt. " Das Sprint-Ziel wird von Entwicklungsteam und vom Product Owner festgelegt. " Das Sprint-Ziel wird von SCRUM Master festgelegt. " Keine der Antworten ist richtig. [83] Die Definition of Done … " ist notwendig, um die maximale Zeitdauer eines Tasks festzulegen. " beschreibt, welche Kriterien ein Backlog Item erfüllen muss, damit er als „fertig“ bezeichnet werden kann. " Die Festlegung der Definition of Done erfolgt durch den Product Owner und das Entwicklungsteam gemeinsam. " Der Product Owner entscheidet anhand der Definition of Done, ob er das Inkrement abnimmt oder nicht. <?page no="137"?> 2.*4#-%/ 0#'4 137 [84] Eine Definition of Done kann erstellt werden für … " Inkrement " Task " Backlog Item " Keine der Antwortmöglichkeiten ist richtig [85] Welche der folgenden Aussagen sind richtig? " Die Definition of Done wird im Rahmen des Sprint Plannings festgelegt. " Die Definit ion of Done wird von SCRUM Maste r vorgeg eben. " Die Definition of Done wird im Rahmen des Sprint Reviews definiert. " Keine der Aussagen sind richtig. <?page no="138"?> 138 3 Wie funktioniert SCRUM? 3.5 Zusammenführung der Komponenten von SCRUM Bisher haben wir viele Begriffe rund um SCRUM verwendet: Werte, Prinzipien, SCRUM-Team, Rollen, Artefakte, Meetings, SCRUM-Prozess und viele mehr. Doch wie spielen diese ganzen Komponenten zusammen? Wir wollen an dieser Stelle gar nicht zu viel Text schreiben. Wir haben in der folgenden Abbildung alles Wesentliche zusammengestellt. Diese Übersicht ist übrigens auch eine optimale Vorbereitung auf die SCRUM-Prüfung beziehungsweise Zertifizierung. Abb. 40: Zusammenführung SCRUM-Prozess und Rollen <?page no="139"?> 3.5 Zusammenführung der Komponenten von SCRUM 139 Abb. 41: Gesamtüberblick Komponenten von SCRUM dnn+,'Me Dn+&,GK 4? +nO&H+ne _n? H; n=Mn D&=n? "? n@=n'; >? MnC',K ^B? ,'+ (G&'','M 7(&! ? ! 9! >? >& 7>? ( 3=<! ? 9 G! (S 5<>*8,9 : C,TS>$ W # A(! ' .>,#(? 3=<! ? 9 - N =<> 3=<! ? 9 7(&! ? ! 9! >? >& 7>? ( 3=<! ? 9 G! (S 3=<! ? 9 : C,TS>$ ^B? ,'+ D&,GQ ^Xb.d 1C; TA>C<* O><9SC8&(? *(; I>? ! 9><! ? $ -% I! ? 89(? - N 9V$S! ,# 1C; TA>C<* CT98CS! ; ! (<9 I>? ! 9><! ? $ *8<,#$(&H#<9 ^B ? , '+ bnk,ni 7 (& ! ? ! 9 ! > ? >& 7> ? ( K? T<(@(? 9 O><9SC8&(? *(; I>? ! 9><! ? $ ' # A(! ' .>,#(? 3=<! ? 9 - N =<> 3=<! ? 9 5<>*8,9 : C,TS>$ CT98CS! ; ! (<9 K? T<(@(? 9 ^B ? ,'+ bn+? ]KBnH+,kn O((*AC,T : >C<* ) # A(! ' .>,#(? 3=<! ? 9 - N =<> 3=<! ? 9 / (<A(; ; (<8? $; E @C0? C#@(? ! ? TS8; ! 6( 5SC? 8? $ ( ! ! ! ! ! > ! ! ! ! ! d ! ! ! ! ! ^ N ! ! ! E b]GGn <?page no="141"?> 4 Wozu ist SCRUM in der Praxis anwendbar? Alles, was wir in den vorherigen Kapiteln vorgestellt haben, ist der Kern von SCRUM, so wie er auch im SCRUM-Guide beschrieben wird. Es haben sich zusätzlich weitere Tools in der Praxis als sinnvoll und hilfreich erwiesen. Diese werden im SCRUM- Guide nur kurz erwähnt. Und wir werden diese aus diesem Grund im Folgenden nur kurz erläutern. Der Kern dieser Tools dient dazu, Transparenz im SCRUM-Team bezüglich des aktuellen Fortschritts, bezogen auf den Umsetzungsstand, zu schaffen. Fast jedem, der sich schon einmal mit Agilem Projektmanagement oder mit SCRUM beschäftigt hat, werden diese Begriffe und Tools schon einmal begegnet sein. 4.1 Fortschritts-Monitoring bezogen auf das Gesamtziel Es muss zu jedem Zeitpunkt während des SCRUM-Prozesses möglich sein, die gesamte Arbeit, die noch zu erledigen ist, um das Gesamtziel zu erreichen und die noch notwendig ist, transparent zu machen. Für diese Transparenz ist der Product Owner zuständig. Er monitort diese gesamte Arbeit, die noch zu tun ist. Dies sollte spätestens jedes Mal beim Sprint Review durchgeführt werden. Der Product Owner vergleicht diese gesamte Arbeit, die noch zu leisten ist, mit der Arbeit, die bereits geleistet ist. So kann er abschätzen, wie realistisch der aktuelle Zeitplan für die Auslieferung des Produktes ist. Diese Information sollte allen Stakeholdern zur Verfügung gestellt werden. Für die Umsetzung dieses Monitoring haben sich verschiedenste Tools und Werkzeuge in der Praxis etabliert. Die folgenden drei Werkzeuge sind hier sicher die am meisten verwendeten: ! Burn-down Chart ! Burn-up Chart ! Cumulative Flows Diagram <?page no="142"?> 142 4 Wozu ist SCRUM in der Praxis anwendbar? Burn-down Chart Der Burn-down Chart ist ein Chart, in dem der Fortschritt des verbleibenden Aufwands gegen die Zeit abgetragen ist. Die Y-Achse ist also der verbleibende Aufwand und die X-Achse stellt die Zeit dar. Üblicherweise wird der verbleibende Aufwand in Stunden angegeben. Die Zeit wird üblicherweise in Tagen angegeben. Dies hat den Grund, dass der Burn-down Chart meist auch jeden Tag im Daily SCRUM für die Fortschrittmessung genutzt wird. Gemäß dem SCRUM-Guide sind Burn-down Charts ein optionales Element, das angewendet werden kann, um den Fortschritt transparent zu machen. Bei einem Burn-down Chart ist die X-Achse immer die Zeit. Hingegen wird die Y-Achse in unterschiedlichen Projekten auch unterschiedlich eingesetzt: So Abb. 42: Burn-down Chart L9Q+ PK+ (G&' ,1 HO H <?page no="143"?> 4.1 Fortschritts-Monitoring bezogen auf das Gesamtziel 143 kann auf der Y-Achse beispielsweise die Summe der restlichen Stunden für die noch zu erledigende Entwicklungsarbeit oder die Anzahl der noch abzuarbeitenden Tasks angetragen werden. Burn-up Chart Ein Burn-up Chart ist eine Grafik, die den Fortschritt des Anstiegs bezogen auf die Zeit zeigt. Auf der Y-Achse wird in diesem Chart der Anstieg in der entsprechenden Einheit angezeigt. Auf der X-Achse ist entsprechend die Zeit abgetragen. Der Burnup Chart ist quasi eine Inversion des Burn-down Charts. Burn-up Charts sind gemäß Abb. 43: Burn-up Chart L9Q+ PK+ (G&' ,1HOH <?page no="144"?> 144 4 Wozu ist SCRUM in der Praxis anwendbar? dem SCRUM-Guide ein optionales Werkzeug, um den Fortschritt transparent zu machen. Cumulative Flows Diagram Während ein Burn-down Chart nur besagt, wie viel Arbeit beispielsweise im aktuellen Sprint noch zu erledigen ist, ist ein Cumulative Flow Diagram viel aussagekräftiger. Er gibt auch die Information, wie viele Anforderungen sich zu welchem Zeit- Abb. 44: Cumulative Flow Diagram L9Q+ [&AHG]M P' [n&? Cn,+='M $3MF! ; 9! J3A P' (? $O='M n? Gn#,M+ <?page no="145"?> 4.2 Fortschritts-Monitoring im Rahmen des Sprints 145 punkt in welchem Umsetzungsstand befinden. Umsetzungszustände können beispielsweise sein: „Im Backlog“, „In Umsetzung“, „In Prüfung“ und „Erledigt“. Diese Zustände können wiederum weiter untergliedert werden in „Unterstände“. Dieses Tool hat den Mehrwert, dass diese Informationen auf einen Blick dargestellt werden und mögliche Projektrisiken frühzeitig erkannt werden. Auf der X-Achse wird wieder die Zeit angetragen. Auf der Y-Achse wird die Anzahl oder der Aufwand der Anforderungen, die noch zur Entwicklung anstehen, abgetragen. Alle diese Werkzeuge sind sehr hilfreich für das Fortschritts-Monitoring. Dennoch ersetzen sie nicht den Empirismus beziehungsweise die Realität. In einem komplexen Umfeld ist das, was in Zukunft passieren wird, immer unbekannt. Aus diesem Grund sollte nur das, was in der Vergangenheit schon passiert ist, dafür verwendet werden, auf die Zukunft gerichtete Entscheidungen zu treffen. 4.2 Fortschritts-Monitoring im Rahmen des Sprints Es sollte zu jedem Zeitpunkt des Sprints möglich sein, die noch zu erledigende Arbeit im Rahmen des Sprints transparent zu machen. Das Entwicklungsteam ist dafür verantwortlich, diese Transparenz jeden Tag im Rahmen des Daily SCRUM herzustellen. Hierbei sollte zudem die Wahrscheinlichkeit ermittelt werden, dass in der verbleibenden Zeit mit den verbleibenden Kapazitäten das Sprint-Ziel erreicht wird. Die noch ausstehende Arbeit transparent zu machen ist der beste Weg für das Entwicklungsteam, den eigenen Fortschritt zu managen. In der Praxis werden hierfür entweder die schon im letzten Abschnitt beschriebenen Burn-down oder Burn-up Charts verwendet. Oder was am häufigsten zum Managen des Fortschritts verwendet wird, ist ein Taskboard. Dieses wird oft auch SCRUM- Board genannt. Das Task Board macht die aktuellen Backlog Items des aktuellen Sprints transparent. Diese sind in ihrer Rangfolge aufgelistet und absteigend sor- <?page no="146"?> 146 4 Wozu ist SCRUM in der Praxis anwendbar? tiert. Jedem Backlog Item sind seine entsprechenden Tasks zugeordnet. Die Tasks werden dann in mehrere Felder aufgegliedert, wie beispielsweise: Backlog Item, Todo, In Bearbeitung, In Prüfung, und Erledigt bzw. „Done“. Die Tasks wandern demnach von der linken Seite des Task Boards auf die rechte Seite, folgend ihrem aktuellen Fortschritt. Je nachdem, wie umfangreich und komplex der Sprint ist, kann diese Form des Fortschritts-Monitoring schon ausreichend sein, um abzuschätzen ob die verbleibende Zeit oder Kapazität ausreichend ist. Das Task Board wird im Rahmen des Daily SCRUM aktualisiert. Für die Aktualisierung ist das gesamte Entwicklungsteam zuständig. Die Abbildung 45 verdeutlicht beispielhaft, wie ein Taskboard aussieht. Abb. 45: Task Board [& AHG]M P+ n) ,' [n &? C n,+=' M ,' (? $O= 'M n? G n# ,M + 3] #] <?page no="147"?> 2.*4#-%/ 0#'4 147 Übungsfragen zum Kapitel: „Wozu ist SCRUM in der Praxis anwendbar? “ Hinweis: Es können eine oder mehrere Antworten richtig sein. Die Auflösung findest du in Abschnitt 5.5. [86] Ein Fortschrittstracking ist in SCRUM … " grundsätzlich nicht notwendig, da SCRUM einen sehr iterativen Charakter hat und deswegen kein Monitoring benötigt. " in Form eines Projektplanes mit Projektphasen durchzuführen. " zu empfehlen, wobei es keine genaue Vorgabe dazu gibt, welche Tools hie rfür verwend et w erden s olle n. " Mögliche Tools sind Burn-down Charts, Burn-up Charts und Cumulative Flow Diagrams. Welches dieser Tools verwendet werden sollte, ist in SCRUM jedoc h nicht vorgeschrieben [87] Das Hauptziel von Fortschrittstracking in SCRUM ist … " einzelnen Projektmitgliedern die ihnen zugewiesene Verantwortung deutlich zu machen und ihr Verhalten zu tracken. " Transparenz zu schaffen. " einen möglichen zeitlichen Projektverzug im Nachhinein dokumentiert zu haben. " Keine der Antwortmöglichkeiten ist richtig. [88] Als mögliche Tools des Fortschrittstracking in SCRUM gelten … " Task Boards <?page no="148"?> 148 4 Wozu ist SCRUM in der Praxis anwendbar? " Burn-down Charts " Burn-up Charts " Cumulative Flow Diagrams [89] Im Kern geht es bei dem Fortschrittstracking in SCRUM darum, … " den aktuellen Budgetverbrauch transparent zu machen. " einzelne Milestones gegenüber den Stakeholdern transparent zu machen. " eine zeitliche Abweichung zwischen geplanten Tasks und tatsächlich abgearbeiteten Tasks transparent zu machen. " per Ampel status dem Management frühzeitig zu si gnalisiere n, dass es Entscheidungsbedarf gibt. [90] Ein Burn-down Chart … " trägt auf der X-Achse die Zeit ab. " trägt auf der Y-Achse die Aufgaben oder Tasks ab. " hat einen fallenden Verlauf mit ablaufender Zeit. " Keine der Antwortmöglichkeiten ist richtig. [91] Aus einem Burn-down Chart kann man ablesen, … " wieviel Zeit der Sprint dauern wird. " wie viele Tasks in einer bestimmten Zeit abgearbeitet werden sollten. " wie viele Tasks in einer bestimmten Zeit abgearbeitet wurden. " Keine der aufgeführten Möglichkeiten. <?page no="149"?> 2.*4#-%/ 0#'4 149 [92] Ein Burn-up Chart … " trägt auf der X-Achse die Zeit ab. " trägt auf der Y-Achse die Aufgaben oder Tasks ab. " hat einen steigenden Verlauf mit ablaufender Zeit. " Keine der Antwortmöglichkeiten ist richtig. [93] Aus einem Burn-up Chart kann man ablesen, … " wieviel Zeit der Sprint dauern wird. " wie viele Tasks in eine r bestimmte n Zeit a bg earbeit et wer den soll ten. " wie viele Tasks in einer bestimmten Zeit abgearbeitet wurden. " Keine der aufgeführten Möglichkeiten. [94] Das Cumulative Flow Diagram … " kumuliert alle Tasks oder Anforderungen, die im Zeitverlauf umgesetzt wer den sollten. " zeigt an, in welchem Stadium sich die einzelnen Tasks oder Anforderungen gerade befinden. " kann die Tasks oder Anforderungen beispielsweise in die Stadien „Backlog“, „Todo“, „In Bearbeitung“, „In Prüfung“ und „Erledigt“ gliedern. " Keine der Antwortmöglichkeiten ist richtig. [95] Welche der folgenden Aussagen ist richtig? " Das Burn-down Chart dient dazu, die Abarbeitung von einzelnen Tasks im Zeitverlauf zu zeigen. " Der Burn-up Chart ist die Inversion des Burn-up Charts. <?page no="150"?> 150 4 Wozu ist SCRUM in der Praxis anwendbar? " Das Cumulative Flow Diagram hat im Gegensatz zu Burn down und Burnup Charts den Vorteil, dass es Informationen über die unterschiedlichen Stati der Tasks oder Anforderungen gibt. " Keine der Antwortmöglichkeiten ist richtig. [96] Ein Task Board … " dient dazu, den Umsetzungsstand der Tasks transparent zu machen. " ermöglicht es, dem Entwicklungsteam immer visuell zu machen, welche Task noch bearbeitet werden und welche in welchem Stadium sind. " sollte vom Entwicklungsteam regelmäßig und selbstständig aktualisiert werden. " Keine der Antwortmöglichkeiten ist richtig. [97] Fortschrittstracking … " ist alleinige Aufgabe des SCRUM Masters. " ist alleinige Aufgabe des Product Owners. " ist alleinige Aufgabe des Entwicklungsteams. " Keine der Antwortmöglichkeiten ist richtig. [98] Fortschrittstracking … " stellt den wesentlichen Kern von SCRUM dar. " ist notwendig, um sich gegenüber den Stakeholdern zu rechtfertigen. " sollte nur solange stattfinden und durchgeführt werden, so lange es der Transparenz dient und einen Mehrwert schafft. <?page no="151"?> 2.*4#-%/ 0#'4 151 " Keine der Antwortmöglichkeiten ist richtig. [99] Welche der folgenden Aussagen ist richtig? " Alle Tools zum Fortschrittstracking können auf SCRUM.org heruntergeladen werden. " SCRUM ist nur dann erfolgreich, wenn die Tools zum Fortschritsstracking so angewandt werden, wie im SCRUM-Guide beschrieben. " Nur autorisierte Tools sollten für ein erfolgreiches SCRUM-Projekt angewendet werden. " Keine der Antwortmöglichkeiten ist richtig. [100] SCRUM … " macht keine konkreten Vorgaben, welche Tools für das Monitoring und Track ing angewandt werden sollten. " hat als oberstes Ziel Transparenz, um zu überprüfen und anzupassen. " hat als Maßstab, dass alle Tools, die eingesetzt werden, nur solange sinnvoll sind, wie sie einen Mehrwert bieten, der in einem angemessenen Verhältnis zum Aufwand steht. " Keine der Antwortmöglichkeiten ist richtig. <?page no="153"?> 5 Wie funktionieren die Prüfung und die Zertifizierung? 5.1 Wie kann man zertifiziert werden? Es gibt insgesamt mehr als sechs Organisationen, bei denen man sich in Deutschland nach SCRUM zertifizieren lassen kann. Die folgende Übersicht zeigt diese überblicksmäßig. Wir wollen die Zertifizierungen nach der Organisation der beiden Väter von SCRUM, der SCRUM.org, im Detail vorstellen, da sie aus unserer Sicht weltweit, sowohl was die Methodik als auch die Marktabdeckung anbelangt, führend ist: ! SCRUM.org (www.SCRUM.org) ! SCRUM Alliance (www.SCRUMalliance.org) ! EXIN (www.exin.com) ! PMI (www.pmi.org) ! AXELOS/ PRINCE2 (www.axelos.com) ! Itemo/ TÜV Süd (http: / / www.itemo.org) Im Folgenden fokussieren wir uns auf die Darstellung der Prüfung und Zertifizierung nach SCRUM.org. SCRUM.org ist der weltweit führende Anbieter und Zertifizierer von SCRUM. Zertifizierung nach SCRUM.org Es gibt nach SCRUM.org die folgenden vier Zertifizierungsstufen. Diese orientieren sich zu allererst an den drei Rollen gemäß SCRUM: SCRUM Master, Product Owner und Entwicklungsteam. Das Zertifikat zum Scaled Professional SCRUM dient dazu, mehrere SCRUM-Teams parallel zu managen: <?page no="154"?> 154 5 Prüfung und Zertifizierung ! Professional SCRUM Master (PSM): für die Rolle des SCRUM Master ! Professional SCRUM Product Owner (PSPO): für die Rolle des Product Owners ! Professional SCRUM Developer (PSD): für die Rolle des Entwicklungsteams ! Scaled Professional SCRUM (SPS) Für die einzelnen Rollen und Zertifizierungsstufen gibt es wiederum mehrere Ausbildungslevel. Diese werden im Folgenden beschrieben. PPr roof fees sssi ioonnaall SSC CR RUUMM MMaasstte er r ((P PM MSS)) Es gibt drei Ausbildungslevels für den Professional SCRUM Master (Grundlagen, Fortgeschritten und Profi). Diese bewerten und zertifizieren das entsprechende SCRUM-Wissen und seine praktische Anwendungsfähigkeit. Auf dem Level PSM I attestiert das Zertifikat Grundlagenkenntnisse von SCRUM. Das bedeutet, dass der Zertifikatsinhaber über Grundlagenkenntnisse verfügt, wie sie im SCRUM-Guide vermittelt werden und wie deren Anwendung funktioniert. Zudem verfügt man als SCRUM Master Level 1 über ein einheitliches Verständnis von SCRUM und verwendet eine einheitliche Sprache. Im Rahmen der PSM II-Stufe lernt der Trainingsteilnehmer fortgeschrittene Kenntnisse von SCRUM. Hierzu gehören die grundlegenden Prinzipien, die SCRUM ausmachen, und die Fähigkeit, diese in einer komplexen und realen Welt anzuwenden. PSM III Level-Zertifikatsinhaber haben ein tiefgründiges Verständnis von der Anwendung von SCRUM und der Werte von SCRUM in einer Vielzahl von komplexen Team- und Unternehmenssituationen. <?page no="155"?> 5.1 Wie kann man zertifiziert werden? 155 PPrroof feessssiio onnaall SSCCRRU UMM PPr roodduucctt OOwwn neerr ((PPSSPPOO)) Im Rahmen der Zertifizierung zum Professional SCRUM Product Owner gibt es zwei Stufen: Die Fortgeschrittenen-Stufe und die Profi-Stufe. Sie bewerten und zertifizieren das Wissen des SCRUM Product Owners und seiner Fähigkeit, dieses Wissen anzuwenden. Auf der Stufe I weist der Zertifikatsinhaber nach, dass er das SCRUM Framework verstanden hat und wie dieses dazu verwendet wird, um den Wert des Produktes, das entwickelt wird, zu maximieren. Es zeichnet sich dadurch aus, dass es eine fortlaufende professionelle Produktentwickung ermöglicht. Zudem ist es mit einem hohen Grad an Selbstverpflichtung in ihrem Anwendungsfeld verbunden. Die Stufe PSPO I ist das niedrigste Level an Wissen, das ein Professional SCRUM Product Owner nachweisen sollte. Das Level II attestiert zudem Wissen auf Profiniveau zum SCRUM Framework. PPrrooffeessssi ioonnaal l SSCCRRUUM M DDeevveel looppeerr Die Stufe des Professional SCRUM Developer ist so aufgebaut, dass der Zertifikatsinhaber nachweist, dass er das Wissen und die Anwendungskenntnis zu den Techniken hat, die notwendig sind, um eine komplexe Software als Teil eines SCRUM Teams zu entwickeln, und der Fähigkeit, dieses Wissen anzuwenden. SSccaalleedd PPrrooffeessssiioonnaall SSCCRRUUMM Die Scaled Professional SCRUM-Prüfung bewertet und zertifiziert das Wissen. wie man Scaled SCRUM anwendet und wie man das Nexus-Framework verwendet. Zudem weist es das entsprechende Anwendungswissen der Nexus Software nach. <?page no="156"?> 156 5 Wie funktionieren die Prüfung und die Zertifizierung? 5.2 Welche Prüfungen gibt es? Grundsätzlich muss für jede Zertifizierungsstufe auch eine eigene Prüfung abgelegt werden. Eine Anrechnung von Prüfungsleistungen zwischen den einzelnen Stufen erfolgt nicht. Man kann sich also merken: pro Zertifikat eine Prüfung. Wie die Prüfungen ablaufen, wird im Folgenden erklärt. 5.3 Wie läuft die Prüfung ab? Die Prüfung bei der SCRUM.org erfolgt als Onlineprüfung. Das bedeutet, dass man sich auf der Homepage von www. SCRUM.org zur Prüfung anmeldet. Den Zeitpunkt der Prüfung kann jeder selbst bestimmen. Es gibt keine festen Prüfungszeiten. Für die Prüfung zum SCRUM Master Level I und Product Owner Level I hat man 60 Minuten Zeit. Insgesamt bekommt man 80 Fragen gestellt. Die Fragen werden sowohl im Single-Choice-Modus als auch im Multiple-Choice-Modus gestellt. Das bedeutet, dass eine oder mehrere Antwortmöglichkeiten richtig sein können. Insgesamt müssen mindestens 85 Prozent richtig beantwortet sein, um die Prüfung zu bestehen. Es besteht auch die Möglichkeit, vorab auf SCRUM.org Probefragen zu üben. Gehe hierzu einfach auf SCRUM.org auf den Menüpunkt "Open Assessments". Die Prüfung erfolgt als Open Book Prüfung, das bedeutet, dass man alles Lernmaterial, das man zur Verfügung hat, in der Prüfung verwenden darf. Man sollte jedoch beachten, dass insgesamt 80 Fragen in nur 60 Minuten bearbeitet werden müssen, so dass wenig Zeit besteht, lange in den Lernmaterialien nachzublättern. <?page no="157"?> 5.4 Aufbau Prüfungsfragen SCRUM 157 5.4 Aufbau Prüfungsfragen SCRUM Wir haben in diesem Buch nach jedem Kapitel Übungsfragen aufgeführt, die sehr nahe an den originalen Prüfungsfragen sind. Als Lernempfehlung: Arbeite die einzelnen Kapitel durch und überprüfe nach jedem Kapitel dein Wissen mit den pro Kapitel aufgeführten Fragen. Die Prüfungsfragen sind so aufgebaut wie diese Beispielfrage: Wer gehört zum SCRUM-Team? " SCRUM Master " Prod uct O wner " Entwicklungsteam " Stakeholder Lösung: Richtig wären hier die ersten drei Antworten. Die vierte Antwort wäre nicht anzukreuzen, denn die Stakeholder gehören nicht zum SCRUM-Team. <?page no="159"?> 6 Lösungen zu den Übungsfragen Im Folgenden findest du die Auflösung der 100 Übungsfragen, die wir nach jedem Kapitel eingefügt haben. Lösung Übungsfragen Kapitel: Warum ist SCRUM so erfolgreich? (Seite 25) Die richtigen Antworten sind: Frage 1: 3 Frage 2: 3 Frage 3: 3 Frage 4: 1, 2, 3 Frage 5: 1, 2, 3, 4 Frage 6: 3 Frage 7: 3, 4 Frage 8: 3, 4 Frage 9: 3 Frage 10: 2 Lösung Übungsfragen Kapitel: Was ist SCRUM? - Grundlagen (Seite 47) Die richtigen Antworten sind: Frage 11: 1, 2 Frage 12: 3 Frage 13: 1 <?page no="160"?> 160 6 Lösungen zu den Übungsfragen Frage 14: 2 Frage 15: 1 Frage 16: 2 Frage 17: 1, 2, 3 Frage 18: 3, 4 Frage 19: 2 Frage 20: 1, 2, 3 Frage 21: 1 Frage 22: 1, 2, 3, 4 Frage 23: 1, 3, 4 Frage 24: 2 Frage 25: 1, 2, 3, 4 Lösung Übungsfragen Kapitel: Wie funktioniert SCRUM? - SCRU- Prozess (Seite 58) Die richtigen Antworten sind: Frage 26: 3 Frage 27: 3 Frage 28: 3 Frage 29: 1 Frage 30: 1 Frage 31: 1 Frage 32: 2 Frage 33: 1 Frage 34: 1 Frage 35: 2, 3 Frage 36: 1 Frage 37: 3 <?page no="161"?> 3(-*4#'4 "* +'4 2.*4#-%/ 0#'4 161 Frage 38: 2 Frage 39: 4 Frage 40: 4 Lösung Übungsfragen Kapitel: Wie funktioniert SCRUM? - Rollen (Seite 82) Die richtigen Antworten sind: Frage 41: 3 Frage 42: 2 Frage 43: 1, 3 Frage 44: 2, 4 Frage 45: 1, 2, 3 Frage 46: 1, 2, 3 Frage 47: 1, 2, 3, 4 Frage 48: 1 Frage 49: 1, 4 Frage 50: 2, 3 Frage 51: 1, 2, 3 Frage 52: 1 Frage 53: 1 Frage 54: 4 Frage 55: 3 <?page no="162"?> 162 6 Lösungen zu den Übungsfragen Lösung Übungsfragen Kapitel: Wie funktioniert SCRUM? - Meetings (Seite 111) Die richtigen Antworten sind: Frage 56: 1, 2, 3 Frage 57: 1, 2, 3, 4 Frage 58: 2 Frage 59: 3 Frage 60: 1, 2 Frage 61: 1, 2, 3 Frage 62: 1, 2, 3 Frage 63: 1, 2, 3 Frage 64: 1, 2, 3 Frage 65: 4 Frage 66: 1, 2, 3, 4 Frage 67: 1, 2, 4 Frage 68: 1, 2, 3 Frage 69: 1, 2, 3 Frage 70: 2, 3, 4 Lösung Übungsfragen Kapitel: Wie funktioniert SCRUM? - Artefakte (Seite 133) Frage 71: 1, 2, 3 Frage 72: 1 Frage 73: 1 Frage 74: 2, 3, 4 Frage 75: 2, 3 Frage 76: 1, 2, 3 <?page no="163"?> 3(-*4#'4 "* +'4 2.*4#-%/ 0#'4 163 Frage 77: 1, 2 Frage 78: 1, 2, 4 Frage 79: 1, 2 Frage 80: 1, 2 Frage 81: 1 Frage 82: 2 Frage 83: 2, 3, 4 Frage 84: 1, 2, 3 Frage 85: 1 Lösung Übungsfragen Kapitel: Wozu ist SCRUM in der Praxis anwendbar? - Fortschritts-Monitoring (Seite 147) Die richtigen Antworten sind: Frage 86: 3, 4 Frage 87: 2 Frage 88: 1, 2, 3, 4 Frage 89: 3 Frage 90: 1, 2, 3 Frage 91: 1, 2, 3 Frage 92: 1, 2, 3 Frage 93: 1, 2, 3 Frage 94: 1, 2, 3 Frage 95: 1, 2, 3 Frage 96: 1, 2, 3 Frage 97: 4 Frage 98: 3 Frage 99: 4 Frage 100: 1, 2, 3 <?page no="165"?> 7 Glossar: Welche Begriffe sind wichtig? Im Folgenden haben wir die wichtigsten Begriffe zu SCRUM zusammengefasst. Die Sammlung basiert auf dem SCRUM-Glossar. Es kann in Netz unter folgenden Link eingesehen werden: https: / / www. SCRUM.org/ SCRUM-glossary Wir haben die englischen Texte jeweils übersetzt und auch teilweise ergänzt. Wenn du diese Begriffe alle erklären kannst, dann bist du gut für die Prüfung vorbereitet. Insofern empfehlen wir dir, die einzelnen Wörter zu lernen und sicherzustellen, dass du weißt, was sie bedeuten. Artefact zu Deutsch Artefakt: Artefakte sind das Product Backlog, Sprint Backlog 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 erledigenden Aufgaben in Relation zur Zeit. Burn-up Charts sind eine optionale Möglichkeit in SCRUM, den Fortschritt transparent zu machen. <?page no="166"?> 166 7 Glossar: Welche Begriffe sind wichtig? Cumulative Flow Chart Cumulative Flow Charts zeigen den Fortschritt des noch zu schaffenden Aufwands als Anstieg inklusive verschiedener Detailinformationen bezogen auf den aktuellen Status in Relation zur Zeit. Cumulative Flow Charts sind eine optionale Möglichkeit in SCRUM, den Fortschritt transparent zu machen. Daily SCRUM Ein Meeting mit einer festgelegten Zeitdauer von maximal 15 Minuten. Es dient dem Entwicklungsteam dazu, den anstehenden Tag der Entwicklungsarbeit während eines Sprints zu planen. Änderungen und Aktualisierungen werden im Sprint Backlog eingetragen. Definition of Done zu Deutsch Definition von „Fertig“: Ein gemeinsames Verständnis über die Erwartungen, die die Software (oder das zu entwickelnde Produkt) erfüllen muss, um ausgeliefert werden zu können. Sie wird vom Entwicklungsteam gemanagt. Development Team zu Deutsch Entwicklungsteam: Das Entwicklungsteam ist die Rolle im SCRUM-Team, die dafür verantwortlich ist, all die Entwicklungsarbeit zu leisten, die notwendig ist, um in jedem Sprint ein auslieferungsfähiges Inkrement des Produktes zu erstellen. Emergence zu Deutsch Vorkommnis: Der Prozess der Entstehung oder des Bekanntwerdens eines neuen Fakts oder des Wissens über ein Faktum, oder das Wissen über einen Fakt, der unerwartet auftritt. <?page no="167"?> Glossar 167 Empiricism zu Deutsch Empirie: Ein Vorgehen zur Prozesskontrolle, in dem nur die Vergangenheit als sicher angenommen wird und in dem Entscheidungen auf Beobachtungen, Erfahrungen und Ausprobieren basieren. Empirie basiert auf drei Säulen: Transparenz, Überprüfung und Anpassung. Engineering standards zu Deutsch Entwicklungsstandards: Ein einheitliches Verständnis über Entwicklungs- und Technologiestandards, die vom Entwicklungsteam angewandt werden, um ein auslieferungsfähiges Inkrement der Software (oder des Produkts) zu erstellen. Forecast (of functionality) zu Deutsch Vorschau (auf Funktionalitäten): Die Auswahl von 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 funktionierender 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 Backlog wird vom Product Owner gemanagt. <?page no="168"?> 168 7 Glossar: Welche Begriffe sind wichtig? 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 Informationslevel jedes Backlog Items. Das Ready wird im Rahmen des Sprint Plannings festgelegt. SCRUM Ein Rahmenwerk, um Teams bei komplexen Produktentwicklungen zu unterstützen. SCRUM besteht aus dem SCRUM-Team und den dazugehörigen Rollen, Meetings, Artefakten und Regeln, so wie diese im SCRUM-Guide beschrieben sind. <?page no="169"?> Glossar 169 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, Meetings, 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 Werte und Fähigkeiten, die das SCRUM Framework ermöglichen. Die Werte sind Selbstverpflichtung, Fokus, Offenheit, Respekt und Mut. Self-Organization zu Deutsch Selbstorganisation: Managementprinzip, das davon ausgeht, dass Teams ihre Arbeit autonom und selbst organisieren. Diese Selbstorganisation erfolgt innerhalb festgelegter Grenzen auf der Basis von klar vorgegebene Rollen. Die Teams <?page no="170"?> 170 7 Glossar: Welche Begriffe sind wichtig? entscheiden selbst, wie sie ihre Arbeit ausführen, anstatt von jemand außerhalb des Teams angeleitet zu werden. Sprint Ein zeitlich festgelegtes „Meeting“ mit einer maximalen Dauer von 30 Tagen. Es dient als „Container“ für andere SCRUM Meetings 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 Meeting mit einer maximalen Dauer von acht Stunden. Es findet zu Beginn jedes Sprints statt. Es dient dem SCRUM-Team dazu, zu überprüfen, welche Arbeit aus dem Product Backlog am besten dafür geeignet ist, als nächstes erledigt zu werden, um dann ins Sprint Backlog übertragen zu werden. <?page no="171"?> Glossar 171 Sprint Retrospective zu Deutsch Sprint-Retrospektive: Eine zeitlich begrenztes Meeting 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 Meeting mit einer maximalen Dauer von vier Stunden. Ziel ist, die Entwicklungsarbeit des Entwicklungsteams abzuschließen. Es dient dem SCRUM-Team und den Stakeholdern dazu, das Inkrement des Produkts, das aus dem Sprint geliefert wurde, zu überprüfen. Stakeholder Eine externe Person, die nicht Teil des SCRUM Teams ist. Sie verfügt über ein besonderes Interesse an oder über Wissen zu dem zu entwickelnden Produkt. Die Stakeholder werden im SCRUM-Team über den Product Owner repräsentiert. Aktiv eingebunden werden die Stakeholder im Sprint Review. Velocity zu Deutsch Geschwindigkeit: Eine optionale, jedoch oft verwendete 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. <?page no="173"?> 8 Gute Informationsquellen und Literatur Informationsquellen im Netz: ! SCRUM.org: http: / / www. SCRUM.org ! SCRUM Kompakt: https: / / improuv.com/ content/ SCRUM-kompakt ! SCRUM-Guide: http: / / www. SCRUMguides.org/ index.html ! SCRUM-Glossar: https: / / www. SCRUM.org/ SCRUM-glossary ! Agile Atlas: https: / / improuv.com/ publication/ agile-atlas-core- SCRUM ! Agiles Manifest Principles: http: / / agilemanifesto.org/ iso/ de/ principles.html ! Agiles Manifest. http: / / agilemanifesto.org/ iso/ de/ manifesto.html Literatur: ! SCRUM - kurz & gut - von Rolf Dräther und Holger Koschek, erschienen in O'Reillys Taschenbibliothek 2013 ! SCRUM: The Art of Doing Twice the Work in Half the Time - von Jeff Sutherland - Random House Business 2015 ! Essential SCRUM: Die wesentlichen Aspekte von SCRUM zum Lernen und Nachschlagen - von S. Rubin Kenneth, erschienen in mitp Professional 2014 <?page no="175"?> Index A Adaption 32, 39, 49 Agiles Projektmanagement 6, 21, 22, 26 Anpassung 25, 31, 32, 39, 41, 48, 49, 99, 106, 107, 111, 116, 118, 123, 130, 133, 167 Artefact 165 Artefakt 96, 119, 131, 165 Artefakte 32, 43, 49, 50, 53, 54, 58, 61, 116, 117, 118, 119, 126, 131, 132, 133, 138, 162, 165 Aufgaben 19, 43, 59, 62, 64, 65, 67, 68, 69, 70, 72, 74, 75, 79, 80, 90, 91, 95, 96, 97, 117, 122, 123, 124, 148, 149, 165, 168 B Backlog Item 79, 96, 97, 107, 109, 115, 120, 121, 122, 128, 129, 136, 137, 146 Budgetmanagement 16 Burn-down Chart 80, 141, 142, 144, 148, 149, 165 Burn-up Chart 141, 143, 149, 165 C Commitment 34, 35, 49 Courage 34, 49 Cumulative Flow Chart 166 Cumulative Flows Diagram 141, 144 D Daily SCRUM 23, 49, 54, 58, 59, 60, 61, 80, 86, 90, 91, 97, 98, 100, 110, 112, 113, 123, 142, 145, 166 Daily Stand up 16 Definition of Done 72, 95, 106, 116, 125, 126, 128, 129, 130, 131, 136, 137, 166 Design Thinking 5 <?page no="176"?> 176 Index E Empiricism 167 Empirie 31, 48, 167 Engineering standards 167 Entwicklung 20, 39, 40, 54, 55, 65, 80, 83, 85, 117, 118, 135, 145 Entwicklungsarbeit 60, 67, 69, 71, 74, 86, 88, 91, 98, 101, 104, 107, 114, 117, 119, 122, 123, 130, 143, 166, 170, 171 Entwicklungsteam 49, 55, 59, 60, 65, 67, 69, 70, 71, 75, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 91, 92, 93, 94, 96, 97, 98, 99, 101, 104, 105, 107, 109, 111, 113, 114, 115, 122, 123, 124, 125, 126, 127, 130, 131, 134, 135, 136, 145, 150, 153, 157, 166, 167, 168, 169, 170, 171 F Focus 34, 49 Fokus 21, 25, 26, 34, 49, 104, 114, 169 Forecast 167 Framework 15, 23, 30, 42, 44, 49, 53, 65, 106, 155, 169 H Holocracy 5 hybrides Projektmanagement 22 I Increment 167 Inspection 32, 49 J Jeff Sutherland 5, 15, 17, 23, 29, 36, 44, 45, 47, 50, 90, 106, 117, 126, 169, 173 K Ken Schwaber 5, 15, 17, 23, 29, 33, 36, 44, 45, 47, 50, 90, 106, 117, 126, 169 Kompetenzen 16, 62, 64, 65, 67, 69, 74, 77, 79, 80, 84, 91, 168 M Meeting 23, 50, 87, 90, 93, 95, 99, 100, 104, 112, 113, 166, 170, 171 Meetings 15, 43, 49, 53, 54, 58, 60, 61, 74, 75, 83, 84, 87, 88, 89, 90, 91, 92, 93, 96, 98, 99, 100, 104, 106, 110, 111, 112, 116, 117, 126, 138, 162, 168, 169, 170 <?page no="177"?> ! 4+'& 177 Methode 5, 15, 17, 18, 20, 23, 25, 27, 29, 40, 65, 90 Mut 34, 49, 169 N Nonaka 29, 47 O Offenheit 34, 35, 49, 169 Openness 34, 35, 49 P Phase 54 Planung 19, 25, 26, 39, 53, 75, 85, 96, 97, 114, 122 Planungssicherheit 19 Prinzipien 19, 30, 36, 39, 41, 48, 82, 138, 154 Product Backlog 21, 53, 54, 59, 61, 69, 70, 71, 75, 83, 91, 93, 95, 96, 101, 102, 106, 108, 109, 111, 112, 114, 115, 119, 120, 121, 122, 125, 127, 133, 134, 165, 167, 168, 170 Product Owner 7, 49, 58, 59, 65, 67, 69, 70, 71, 72, 74, 75, 77, 80, 82, 83, 84, 85, 90, 92, 93, 94, 100, 101, 107, 111, 112, 113, 114, 120, 125, 128, 133, 134, 135, 136, 141, 153, 154, 155, 156, 157, 167, 168, 169, 171 Produkteigenschaften 38, 53, 90, 95 Produktentwicklung 21, 38, 54, 69, 76, 117 Produktinkrement 54, 95, 101, 123, 125, 126, 135 Projekt 21, 31, 32, 34, 36, 38, 40, 43, 44, 58, 64, 67, 68, 72, 117, 151 Projektlaufzeit 20, 39 Projektmanagement 5, 15, 17, 18, 19, 21, 22, 24, 25, 26, 27, 29, 36, 44, 50, 64, 141 Projektplan 16 Projektplanung 16, 39 Projektteam 16, 21, 34, 56 Prozess 29, 31, 37, 53, 55, 58, 59, 60, 61, 65, 72, 74, 75, 103, 106, 117, 118, 119, 121, 122, 125, 126, 129, 130, 138, 160, 166 Prüfung 6, 7, 8, 45, 138, 145, 146, 149, 153, 155, 156, 165 Prüfungsfragen 157 <?page no="178"?> 178 Index R Rahmenwerk 5, 29, 42, 44, 48, 168 Ready 108, 109, 115, 134, 168 Regeln 15, 30, 34, 43, 48, 49, 50, 67, 72, 73, 74, 80, 82, 84, 99, 104, 168, 169 Respect 34, 35, 49 Respekt 34, 35, 49, 169 Role 168 Rolle 16, 43, 62, 65, 67, 68, 70, 72, 82, 83, 99, 106, 110, 131, 154, 166, 168, 169 Rollen 15, 16, 43, 49, 50, 53, 58, 62, 63, 65, 67, 68, 74, 78, 82, 90, 91, 92, 110, 116, 117, 131, 132, 138, 153, 154, 161, 168, 169 Rugby 29, 47 S SCRUM Master 7, 49, 58, 59, 65, 67, 72, 73, 74, 75, 77, 80, 82, 83, 84, 85, 91, 92, 93, 99, 101, 104, 105, 111, 113, 118, 135, 136, 137, 153, 154, 156, 157, 169 SCRUM Values 169 SCRUM.org 6, 7, 15, 151, 153, 156, 165, 173 SCRUM-Board 145 SCRUM-Guide 5, 15, 23, 34, 44, 45, 46, 50, 72, 106, 116, 141, 151, 154, 168, 169, 173 SCRUM-Prinzipien 5 SCRUM-Regeln 5 Selbstorganisation 64, 75, 83, 169 Selbstverpflichtung 34, 35, 49, 155, 169 Self-Organization 169 Sprint 21, 32, 49, 53, 54, 55, 56, 58, 59, 60, 61, 64, 69, 70, 72, 77, 80, 85, 88, 90, 92, 93, 94, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 109, 110, 111, 112, 113, 114, 115, 116, 119, 121, 122, 123, 124, 126, 127, 128, 130, 133, 134, 135, 136, 137, 141, 144, 145, 148, 149, 165, 166, 167, 168, 170, 171 Stakeholder 35, 53, 56, 57, 58, 59, 60, 65, 66, 69, 70, 71, 82, 83, 91, 101, 104, 110, 111, 112, 113, 114, 118, 131, 134, 157, 171 <?page no="179"?> ! 4+'& 179 T Takeuchi 29, 47 Taskboard 80, 123, 145, 150 Team 5, 16, 22, 26, 32, 33, 34, 35, 41, 43, 49, 53, 59, 62, 64, 65, 66, 70, 72, 74, 77, 79, 80, 82, 83, 84, 86, 93, 95, 97, 98, 100, 101, 104, 105, 106, 107, 112, 113, 114, 117, 118, 125, 128, 129, 130, 131, 133, 138, 141, 154, 157, 166, 168, 169, 170, 171 Technik 16, 29 Teilprojekte 62, 64, 79 Tool 29, 37, 48 Transparency 31, 49 Transparenz 31, 32, 48, 49, 58, 59, 105, 116, 117, 118, 121, 128, 130, 133, 134, 141, 145, 147, 150, 151, 167 U Überprüfung 31, 32, 33, 34, 48, 49, 99, 102, 104, 106, 111, 116, 118, 123, 125, 130, 133, 167 Übungsfragen 25, 47, 58, 82, 111, 133, 147, 157, 159, 160, 161, 162, 163 V Velocity 171 Verantwortung 58, 60, 65, 68, 70, 71, 73, 79, 80, 86, 91, 99, 120, 122, 131, 147, 168 W Wasserfall-Methode 16, 18, 19, 23, 26, 48, 63 Werte 30, 33, 34, 35, 49, 62, 73, 118, 138, 154, 169 Z Zertifizierung 6, 7, 45, 138, 153, 155 <?page no="180"?> www.uvk.de Der richtige Umgang mit Menschen im Beruf und Alltag Nello Gaspardo Von harten Hunden und hyperaktiven Affen Der richtige Umgang mit Menschen im Beruf und Alltag 2017, 158 Seiten, Hardcover ISBN 978-3-86764-834-9 Jeder Mensch ist einzigartig! Das ist fraglos richtig. Dessen ungeachtet finden Sie bei Ihren Mitmenschen wiederkehrende Charaktereigenschaften, mit denen Sie im Beruf und im Alltag umgehen müssen. Denken Sie nur an den harten Hund aus der Chefetage, den cleveren Fuchs aus dem Controlling oder den zappeligen, aber vor Ideen sprühenden Affen aus der Marketingabteilung. Der Kommunikations- und Verhandlungsexperte Nello Gaspardo skizziert neun solcher Typen anhand von Tierbildern. Er zeigt deren Stärken und Schwächen auf und verrät Ihnen pointiert, was Sie im Umgang mit diesen Menschen unbedingt wissen sollten und wie Sie mit diesen Typen richtig kommunizieren. Das Buch ist ein unverzichtbarer Ratgeber für alle, die im Beruf und im Alltag gemeinsam mit anderen Menschen schnell und harmonisch Ziele erreichen möchten.