SCRUM. Agiles Projektmanagement und Scrum erfolgreich anwenden ROLAND WANNER

Transkript

1

2 SCRUM Agiles Projektmanagement und Scrum erfolgreich anwenden ROLAND WANNER

3 Kontakt zum Autor: Roland Wanner Internet: Herstellung: Amazon Media EU S.à r.l, Luxembourg Haftungsausschluss Dieses Buch enthält Informationen über Scrum und agiles Projektmanagement. Es wurde zu Informations- und zu Weiterbildungszwecken geschrieben. Für den professionellen Einsatz empfiehlt sich die Unterstützung durch eine kompetente Fachperson. Trotz größter Sorgfalt dieses Buch so vollständig und korrekt wie möglich zu machen ist nicht auszuschließen, dass es Fehler enthält, typografische oder inhaltliche. Deshalb ist dieser Text nur als genereller Leitfaden und nicht als alleinige Informationsquelle über Scrum und Agiles Projektmanagement zu verwenden. Der Autor, Herausgeber und die zitierten Quellen haften nicht für etwaige Verluste, die aufgrund der direkten oder indirekten Umsetzung der in diesem Buch verwendeten Beschreibungen und Formeln entstehen könnten. Themen in diesem Buch sind: Scrum, agiles Projektmanagement, IT und Software Projekte, Sprint, Timeboxing, Product Owner, Daily Scrum und weitere. Bei Fragen oder Anregungen kontaktieren Sie bitte: Alle Rechte, einschliesslich derjenigen des auszugsweisen Abdruckes sowie der fotomechanischen und elektronischen Wiedergabe, vorbehalten. Es wird darauf hingewiesen, dass die im Buch verwendeten Software- und Hardwarebezeichnungen sowie Markennamen und Produktbezeichnungen, wie z. B. The Scrum Guide TM, der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patenrechtlichem Schutz unterliegen. Copyright 2018 Roland Wanner ISBN: Auflage Januar 2018, (V1.3 Februar 2018) Bibliografische Information der Deutschen Bibliothek: Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar.

4 Inhalt Vorwort Agiles Projektmanagement Agiles Projektmanagement im Überblick Der Unterschied zwischen klassischen und agilen Projekten Agiles Projektmanagement für alle Projekte? Was macht Teams in der Produkteentwicklung erfolgreich?.. 21 Das Agile Manifest Agile Prinzipien Agile Methoden Die Struktur des agilen Projektmanagements Das Scrum Framework So entstand Scrum Scrum als Management Framework Die drei Säulen von Scrum Scrum im Schnellüberblick Scrum und agile Projekte in der Unternehmens-Governance Die Rollen in Scrum Der Product Owner Das Development-Team Der Scrum Master Die Aufgaben des Scrum Masters Eigenschaften und weitere Funktionen des Scrum Masters Weitere Rollen Das Scrum Team und sein Umfeld Scrum-Werte Die Scrum-Werte als Fundament Verpflichtung (Commitment)... 67

5 Mut (Courage) Fokus (Focus) Offenheit (Openness) Respekt Die Scrum-Ereignisse Übersicht Der Sprint Sprint Planning Das Daily Scrum Das Sprint Review Sprint-Retrospektive Die Scrum Artefakte Übersicht Das Product Backlog Das Sprint Backlog Das Product Increment Transparenz der Artefakte Die "Definition of Done" (DoD) Der Scrum Workflow Das Anforderungsmanagement Die Produktvision Das Product Vision Board Anforderungsmanagement in Scrum Der Anforderungsworkshop Die Merkmale guter Anforderungen User Stories Nichtfunktionale Anforderungen erfassen Der Unterschied zwischen Epic, Theme, User Story und Task Der Business Value Das Product Backlog Übersicht über das Product Backlog Das Product Backlog detaillieren Den Aufwand schätzen Das Risiko der Anforderungen bestimmen...111

6 Das Product Backlog priorisieren Priorisierung nach MoSCoW Priorisieren ist eine wiederkehrende Optimierungsaufgabe Planung in Scrum Wann startet das Projekt? Vor dem Projekt Releaseplanung Aufwandschätzung Aufwandschätzung auf zwei Ebenen Das Estimation Meeting Mit Punkten schätzen Planning Poker Magic Estimation Die optimale Sprintdauer Die Entwicklungsgeschwindigkeit bestimmen Das Sprint Planning Der Sprint-Ablauf Die Definition of Ready Die Definition of Done (DoD) Vorbereitung auf das Sprint Planning Sprint Planning Sprint Planning Die Sprint-Durchführung Artefakte und Ereignisse im Sprintablauf Das Sprint Backlog Das Scrum Taskboard Das Daily Scrum Das Daily Scrum vorbereiten und durchführen Den Sprint-Umfang anpassen Einen Sprint abbrechen Den Fortschritt überwachen Das Taskboard

7 Das Sprint Burndown Chart Der Themenpark Das Velocity Chart Das Sprint Review Das Ziel des Sprint Reviews Vorbereitung und Ablauf des Sprint-Reviews Das Resultat des Sprint Reviews Die Sprint-Retrospektive Kontinuierliche Verbesserung und stetiges Lernen Vorbereiten der Retrospektive Die Retrospektive durchführen Sicherheit schaffen Was waren die wichtigsten Ereignisse Erkenntnisse sammeln Maßnahmen definieren Maßnahmen priorisieren Scrum bei großen Projekten Ein Product Owner und Scrum Master für jedes Team Der agile Blueprint für große Projekte Der TM Guide Übersicht Der Scrum Master Cycle Der Product Owner Cycle Die Organisation großer und verteilter Projekte Die Praktiken für große Projekte anpassen Das Product Backlog bei großen Projekten Releaseplanung bei großen Projekten Den Aufwand bestimmen Projektweites Sprint Review und Retrospektive Glossar Anhang Internet-Links und empfohlene Literatur...213

8 Über den Autor Literaturverzeichnis Stichwortverzeichnis

9 Dieses Buch basiert auf The Scrum Guide TM vom November 2017 von Ken Schwaber und Jeff Sutherland

10 15 Scrum bei großen Projekten Große Projekte und verteilte Teams Im Scrum Guide TM wird nur vom Scrum-Team gesprochen, dass ein Projekt ausführt. Um große Projekte durchzuführen braucht es aber mehrere Teams. Ist denn Scrum auch für große Projekte, komplexe Anforderungen und verteilte Teams geeignet? Scrum wird in der Praxis nicht nur in kleinen Teams von fünf bis neun Personen angewendet, sondern nicht selten auch in großen Programmen mit vielen Projekten, bei denen Hardware implementiert und Software dazu entwickelt wird. Solche Programme dauern nicht selten mehrere Jahre. Solche Projektteams sind oft verteilt an mehreren Standorten oder Ländern. Dies stellt an die Zusammenarbeit und die Arbeitsorganisation im Projekt hohe Anforderungen. In diesem Kapitel erhalten Sie einen umfassenden Überblick, was Sie hier alles beachten müssen und erhalten auch eine Übersicht über Was sind große Projekte und verteilte Teams? Aus meiner Sicht ist ein Projekt groß, wenn es aus mehr als einem Scrum-Team besteht. Ab zwei Teams müssen Sie zusätzliche Praktiken einsetzen, damit Ihr Scrum-Projekt reibungslos abläuft. Bei zwei 187

11 Teams ist der Mehraufwand noch gering, wenn Sie aber mehr als fünf Teams haben wird der Koordinationsaufwand um einiges grösser. Bei großen Projekten spricht man von verteilten Teams, wenn an jedem involvierten Standort ein komplettes Scrum Team arbeitet. Unter Standort können Sie natürlich verstehen: im gleichen Gebäude, gleichen Land oder an verschiedenen Standorten auf der Welt, z.b. ein Team in Deutschland, Polen und eines in den USA. Ein Product Owner und Scrum Master für jedes Team Für jedes Team, dass Sie dem Projekt hinzufügen gelten die in den letzten Kapiteln definierten Regeln. Jedes neue Scrum-Team besteht aus den bereits bekannten Rollen, hat also einen eigenen Product Owner und einen Scrum Master, organisiert sich selbst, handelt autonom und arbeitet möglichst in einer gemeinsamen Arbeitsumgebung. Product Owner zu sein ist eine Vollzeitaktivität. Fachliche Anforderungen zu schreiben, diese zu priorisieren, mit den Stakeholdern zu verhandeln und das Backlog zu managen, und vieles mehr. Das braucht Zeit und deshalb hat jedes Scrum-Team auch seinen eigenen Product Owner. Sie kennen ja bereits die Aufgaben des Scrum Masters. Diese sind sehr umfangreich. Dazu kommt noch, dass jedes Development-Team eine andere Art von Unterstützung braucht, abhängig z. B. von dessen Reife, Größe, Abhängigkeiten oder Arbeitsinhalten. Deshalb sollte ein Scrum Master nur ein Development-Team betreuen und sich voll auf dieses konzentrieren. Wenn das Entwicklungs-Team noch nicht lange miteinander arbeitet sollte er dies in Vollzeit machen. 188

12 Der agile Blueprint für große Projekte In den letzten Jahren sind einige Frameworks für agile Großprojekte entstanden wie SAFe (Scaled Agile Framework), ScALed (Scaled Agile Lean Development) oder LeSS (Large Scale Scrum). All diese Frameworks haben zum Ziel die Ausrichtung und Zusammenarbeit sehr großer agiler Teams zu synchronisieren. SAFe nutzt dabei z.b. drei wesentliche Wissenskomponenten: Agile Software Entwicklung, schlanke Produktentwicklung und Systemdenken. Diese Frameworks umfassen unbestritten gute Vorgehensweisen für große agile Projekte und sie sind auch gut dargestellt. Es stellt sich natürlich die Frage, ob Sie ein solches Frameworks anwenden und viel dafür bezahlen wollen. Es ist nicht verwunderlich, dass diese Frameworks auch viele Kritiker in der agilen Welt haben, wie zum Beispiel Ron Jeffries, einer der 17 ersten Unterzeichner des agilen Manifests oder Ken Schwaber, der mit Jeff Sutherland Scrum entwickelt hat. Scrum ist nach deren Ansicht so einfach aufgebaut und kann deshalb auch ohne ein solches Framework skaliert werden. Studieren Sie diese Frameworks nur und klauen Sie ein paar gute Ideen, wenn sinnvoll. Scrum skalieren ist relativ einfach mit der eigenen Unternehmensorganisation- und Kultur ein großes agiles Projekt abzustimmen ist hingegen sehr anforderungsreich. 189

13 Der TM Guide Jeff Sutherland von Scrum Inc. hat sich seit vielen Jahren mit skalierten Scrum-Anwendungen beschäftigt und solche in verschiedenen Unternehmen implementiert. Auch er hat schlussendlich erkannt, dass es einen Bedarf gibt für Empfehlungen, wie Scrum einfach skaliert werden kann. Im Februar 2018 hat er deshalb den Guide veröffentlicht, als skalierbares Referenzmodell. Seine Einführung in den Guide, und warum es diesen braucht lautet so: Scrum wurde für ein einzelnes Team entwickelt, damit es in der Lage ist, mit seiner optimalen Kapazität zu arbeiten und gleichzeitig ein nachhaltiges Tempo beizubehalten. In der Praxis hat man festgestellt, dass mit zunehmender Anzahl von Scrum-Teams innerhalb einer Organisation die optimale Leistung und Geschwindigkeit dieser Teams sinkt, dies aufgrund von Problemen, wie teamübergreifenden Abhängigkeiten und Doppelarbeiten. Es zeigte sich, dass ein Rahmen für die effektive Koordination dieser Teams notwendig war, um eine lineare Skalierbarkeit zu erreichen. ist darauf ausgelegt, dieses Ziel durch seine skalierfreie Architektur zu erreichen. Den Guide könne Sie hier herunterladen: Übersicht basiert auf den gleichen Prinzipen, die auch der Scrum Guide beschreibt. Er soll jedoch das skalieren von Scrum radikal vereinfachen. In Scrum wird darauf geachtet, dass die Rechenschaftspflicht bezüglich dem WAS vom WIE getrennt wird. Dies wird auch in beachtet, so dass Zuständigkeiten und Verantwortlichkeiten ausdrücklich verstanden werden, um unnötige organisatorische Konflikte zu vermeiden, welche Teams daran hindern ihre optimale Produktivität zu erreichen. Durch die Trennung dieser beiden Zuständigkeitsbereiche enthält der zwei Zyklen: den Scrum Master Cycle (das WIE) und den Product Owner Cycle (das WAS), die sich jeweils an zwei 190

14 Punkten berühren. Zusammen ergeben diese Zyklen ein leistungsfähiges Framework mit dem die Arbeiten mehrerer Teams gemeinsam koordiniert werden können. Selbstverständlich gelten auch bei die gleichen Scrum- Werte (Offenheit, Mut, Fokus, Respekt und Kommittment), die Sie auf Seite 65 kennengelernt haben. Abbildung 32: Die Komponenten von 191

15 Der Scrum Master Cycle Der Team-Level-Prozess ist im Ihnen bereits bekannten Scrum Guide übersichtlich dargestellt. Er besteht aus den drei bekannten Artefakten, fünf Ereignissen und den drei Rollen. Die Ziele des Team-Level-Prozesses sind: Die Lieferung abgeschlossener und qualitätsgeprüfter zu Arbeiten maximieren. Die Geschwindigkeit bei jedem Sprint etwas zu erhöhen. So zu arbeiten, dass die Leistung und Zufriedenheit des Teams nachhaltig gefördert wird Das Scrum of Scrums (SoS) koordinieren das WIE Scrum of Scrums werden bei großen Projekten angewendet, um die Selbstorganisation und den Informationsaustausch zwischen den Teams zu unterstützen, aber auch, um projektweite Hindernisse zu identifizieren. Das Scrum of Scrums ist ein Team of Team (McChrystal, 2015), dass ein Scaled Daily Scrum (SDS) durchführt. Das Scaled Daily Scrum (SDS) Das Scaled Daily Scrum wird Ihnen nicht unbekannt sein, denn es handelt sich um eine Form der projektweiten Daily Scrum Meetings (siehe Seite 74). Es findet normalerweise täglich statt, zur selben Zeit am selben Ort und ist auf 15 Minuten begrenzt und fokussiert sich auf die Zusammenarbeit und Leistung des Netzwerks von Teams. Ein Scaled Daily Scrum führen Sie folgendermaßen durch: Jedes Scrum Team entsendet einen Vertreter, der am Meeting teilnimmt. Dies sind primär die Scrum Master, können aber auch (Senior) Mitglieder aus dem Development-Team sein. Am Meeting gibt jeder Teilnehmer Antworten auf folgende drei einfachen, bewährten Fragen: 1. Welche Hindernisse hat mein Team, die es daran hindert sein Sprint-Ziel zu erreichen (oder den bevorstehenden Release beeinflussen)? 192

16 2. Tut mein Team irgendetwas, was ein anderes Team daran hindern könnte sein Sprint-Ziel zu erreichen (oder den bevorstehenden Release beeinflussen)? 3. Haben wir neue Abhängigkeiten zwischen den Teams entdeckt oder einen Weg gefunden eine bestehende Abhängigkeit aufzulösen? Das Team von Scrum Masters ist ein Scrum-Team für sich selbst. Es ist am Ende jedes Sprints verantwortlich für ein vollständiges Paket von potenziell lieferbaren Produktinkrementen von allen beteiligten Teams. Es übernimmt die Funktion eines Release-Teams und muss in der Lage sein, dem Kunden direkt Mehrwert zu liefern. Das SoS- Team muss in Echtzeit auf Hindernisse reagieren, die von den teilnehmenden Teams festgestellt werden. Der Scrum of Scrums Master (SoSM) Der Scrum of Scrums Master (SoSM) ist rechenschaftspflichtig für den Release des gemeinsamen Teams. Seine Aufgaben sind: Macht das Impediment Backlog in der Organisation sichtbar. Beseitigt Hindernisse, welche die Teams nicht selber beseitigen können. Priorisiert die (Impediments) Hindernisse, mit besonderem Augenmerk auf teamübergreifende Abhängigkeiten. Verbessert die Effektivität des Scrum of Scrums. Arbeitet eng mit den Product Owners zusammen, um mindestens bei jedem Sprint ein potenziell freizugebendes Product Increment zu implementieren. Koordiniert die Deployments der Teams mit den Release-Plänen des Product Owners. Es ist sinnvoll wenn der Scrum of Scrum Master das Scrum of Scrums Meeting moderiert, denn er kann am besten Einfluss nehmen, dass projektweite Hindernisse beseitigt werden. Am Meeting selbst sollten primär die Hindernisse und Aktivitäten der Teams berichtet werden, die auch Auswirkungen auf die anderen Teams haben können 193

17 oder sonstige Informationen, welche den anderen Teams helfen ihr Ziel besser zu erreichen. Viele Projekte führen Scrum of Scrums direkt nach dem Daily Scrum der Teams durch, was einen schnellen Informationsfluss begünstigt. Dies ist natürlich nur möglich, wenn alle Teams das Daily Scrum zum gleichen Zeitpunkt abhalten, was bei verteilten Teams in verschiedenen Zeitzonen oft eine Herausforderung sein kann. Skalieren des SoS Je nach Größe der Organisation oder der Implementierung können mehrere SoS erforderlich sein, um ein komplexes Produkt zu liefern. In diesen Fällen kann ein Scrum of Scrum of Scrums (SoSoS) aus mehreren Scrums of Scrums gebildet werden. Die SoSoS ist ein organisches Muster von Scrum-Teams, das beliebig skalierbar ist. Jedes SoSoS sollte SoSoSM's und eine skalierte Version von jedem Artefakt und Ereignis haben. Die Skalierung des SoS reduziert die Anzahl der Kommunikationswege innerhalb der Organisation, so dass die Komplexität gekapselt wird. Das SoSoS ist mit einem SoS genauso verbunden wie ein SoS mit einem einzigen Scrum-Team, was eine lineare Skalierbarkeit ermöglicht. SM SM SoS SM SoSoS SM SM SoS mit 5 Teams SoSoS mit 25 Teams Abbildung 33: Skalieren des SoS 194

18 Das Executive Action Team (EAT) Das Scrum of Scrums für die gesamte agile Organisation wird Executive Action Team (EAT) genannt. Der EAT ist die Endstation für Hindernisse, welche die SoS s, nicht selbst beseitigt können. Deshalb muss das EAT aus Einzelpersonen bestehen, die politisch und finanziell befugt sind, diese zu beseitigen. Die Funktion des EAT besteht darin, mehrere SoS (oder SoSoS) zu koordinieren. Wie bei jedem Scrum-Team benötigt es eine PO und einen SM. Am besten wäre es, wenn sich das EAT täglich als Scrum-Team treffen würde. Sie müssen sich jedoch mindestens einmal pro Sprint treffen und ein transparentes Backlog führen. Lesen Sie mehr Details zum EAT im Guide Der Product Owner Cycle Das MetaScrum koordinieren das WAS MetaScrum ist ein Team von Product Ownern, oft auch als Product Owner Team bezeichnet. Die POs koordinieren selber ein Backlog, welches dann ein Scrum of Scrums speist. Zu jedem SoS gibt es ein zugehöriges MetaScrum. Ein MetaScrum stimmt die Ideen der Product Owner miteinander ab, damit diese der Produktvision entsprechen. Es gleicht die Prioritäten zwischen den Teams ab, damit diese selbst ihre Backlogs weiter koordinieren und mit ihren Stakeholdern abstimmen können. Das MetaScrum führt periodisch ein fixes Meeting durch, um seine Aktivitäten abzustimmen. Zu den Teilnehmern des Meetings gehören neben Product Ownern auch oft noch Vertriebs-, Marketing, Servicevertreter oder andere Stakeholder teil. Es sollten alle Funktionen vorhanden sein, die für die Anforderungsdefinition und die erfolgreiche Markteinführung der Software notwendig sind. Bei komplexen Projekten ist es auch sinnvoll einen Architekten mit einzubeziehen. 195

19 MetaScrums führen eine skalierte Version des Backlog Refinement durch mit folgender Charakteristik: Jeder Product Owner (oder ein Stellvertreter) nimmt am Meeting teil Dieses Ereignis ist das Forum für Leadership, Stakeholder oder Kunden, um Ihre Bedürfnisse zu besprechen Dieses Ereignis wird so oft wie nötig durchgeführt, jedoch mindestens einmal pro Sprint, um ein Ready-Backlog zu gewährleisten. Das MetaScrum Product Backlog gilt für alle Teams des SoS und umfasst größere Stories als jene für die einzelnen PO. Die Hauptfunktionen des MetaScrum sind: Schaffen einer übergreifenden Produktvision und diese für das Unternehmen sichtbar machen. Abstimmung mit den wichtigsten Stakeholdern, damit der Support für die Implementierung des Backlogs sichergestellt ist. Generieren eines einzigen, priorisierten Backlogs, um Doppelarbeiten zu vermeiden. Schaffen einer einheitlichen "Definition of Done", die für alle Teams im SoS gilt. Eliminieren von Abhängigkeiten, die durch das SoS hervorgerufen werden. Erstellen eines abgestimmten Release-Plans. Festlegen und überwachen der Metriken, die einen Einblick in das Produkt geben. MetaScrums, genau wie SoS's, agieren als Scrum-Team selbständig. Einer der Product Owner, der Chief Product Owner. 196

20 Der Chief Product Owner Die Verantwortung des Chief Product Owner im MetaScrum ist gleich wie die eines Product Owner, aber skaliert: Verantwortlich für das Gesamtprodukt, die die Produktvision und das Product Backlog Bestimmt schlussendlich die Leistungsmerkmale Erstellt die Mittelfristplanung und ist verantwortlich für den Business Value. Überwacht das Kundenfeedback und justiert das Product Backlog entsprechend PO CPO PO Meta Scrum CPO PO CPO CCPO Meta Scrum CPO PO PO CPO CPO MetaScrum mit 5 Teams SoSoS mit 25 Teams Abbildung 34: Das Product Owner Team Natürlich hat der CPO auch direkten Kundenkontakt. Um die Kontinuität sicherzustellen sollte er die Software über mehrere Versionen hinweg betreuen. Wenn das Projekt vier bis fünf Scrum-Teams umfasst, sollte der Chief Product Owner nicht mehr für ein Scrum Team zuständig sein, sondern nur noch für das Anforderungsmanagement, Stakeholdermanagement, das Releasemanagement und den Kunden. Er kümmert sich nicht mehr um die Abhängigkeiten zwischen den Teams. Dies 197

21 sollte dann durch die Product Owner der einzelnen Teams gemacht werden. Das MetaScrum kann bei großen Projekten auf verschiedene Standorte verteilt sein. Es ist aber trotzdem wichtig, dass es sich periodisch an einem Ort trifft, dort zusammenarbeitet und sich abstimmt. Das Executive MetaScrum (EMS) Die MetaScrums ermöglichen ein Netzwerkdesign von Product Ownern, dass neben den zugehörigen SoS's beliebig skalierbar ist. Das MetaScrum für die gesamte agile Organisation ist das Executive MetaScrum. Das EMS besitzt die organisatorische Vision und setzt die strategischen Prioritäten für das gesamte Unternehmen, indem es alle Teams auf gemeinsame Ziele ausrichtet. Lesen Sie mehr zum EMS im Guide 198

22 Die Organisation großer und verteilter Projekte Die Projektorganisation großer Projekte ist sehr oft verschieden. Diese ist abhängig vom Projektgegenstand selbst, aber auch wenn mehrere Scrum-Teams nicht am gleichen Standort arbeiten. Das Projekt in der folgenden Abbildung (Pichler, 2013) besteht aus vier Scrum-Teams und ist über drei Standorte verteilt. Jeder Product Owner arbeitet mit seinem Team am betreffenden Standort. Die meisten Mitglieder des Product Owner Teams befinden sich am Standort 1. Abbildung 36: Projektorganisation eines großen und verteilten Projektes Ein Product Owner ist Chief Product Owner, betreut aber gleichzeitig ein Scrum-Team. So verteilt ist eine enge Zusammenarbeit innerhalb der Scrum-Teams möglich aber auch eine gute Kommunikation zwischen den Product Ownern. Das MetaScrum-Team ist verteilt auf die Standorte und somit ein virtuelles Team. Wenn es noch mehr Scrum-Teams gegen würde, dann würde der Chief Product Owner kein eigenes Team mehr betreuen. 199

23 Die Praktiken für große Projekte anpassen Neben der passenden Projektorganisation für große und verteilte Projekte benötigen Sie auch angepasste Praktiken, um Ihr Projekt erfolgreich durchzuführen. Die Entwicklungsgeschwindigkeit bei den verschiedenen Scrum-- Teams wird unterschiedlich sein. Wenn Sie das Projekt steuern wird es eines Ihrer Ziele sein die Entwicklungsgeschwindigkeit im Projekt zu optimieren. Ihr Projekt ist meistens so schnell wie das langsamste Team. Sie sollten deshalb schauen, dass kein Team überlastet ist und wie der Scrum Master die Reife von langsameren Teams steigern kann. Das Product Backlog bei großen Projekten Grundsätzlich empfiehlt der Guide nur mit einem Product Backlog zu arbeiten auch bei mehreren Teams. In gewissen Situationen kann es trotzdem vorteilhaft sein mit mehreren Product Backlogs zu arbeiten. Dies hängt von verschieden Faktoren ab. Wenn die Teams nur an einem Produkt arbeiten, dass sich nicht gut in Teilkomponenten abgrenzen lässt, dann sollte nur mit einem Product Backlog verwendet werden. Wenn die Teams hingegen an mehreren unabhängigen Komponenten arbeiten, dann sind teamspezifische Product Backlogs sinnvoll, die der betreffende Product Owner managet. Die verschiedenen Product Backlogs synchron zu halten kann jedoch aufwändig sein. Es gibt auch die Variante, bei der teamspezifische Product Backlogs just in time vor der jeweiligen Sprint-Planungssitzung erstellt werden. Die kann sinnvoll sein, wenn die teamspezifischen Anforderungen abzuleiten nicht zu komplex und zu aufwändig ist. 200

24 Releaseplanung bei großen Projekten Es gibt nur eine Releaseplanung, auch wenn mehrere Scrum-Teams in Ihrem Projekt arbeiten. Der Releaseplan zeigt den Teams, wie die Projektziele gemeinsam erreicht werden. Sie sollten möglichst den Sprint-Anfang und das Sprint-Ende für alle Teams synchronisieren. Dies macht die Releaseplanung und die Berichterstattung einfacher und transparenter. Das heißt, alles Teams verwenden die gleiche Sprint-Länge und starten einen Sprint am gleichen Tag. Asynchrone Sprints können dann sinnvoll sein, wenn der Sprint eines Scrum-Teams dem anderen Scrum-Team als Lieferant dient. Wenn die Sprints die gleiche Dauer haben, dann müssen Sie natürlich darauf achten, dass die Teams ungefähr die gleiche Entwicklungsgeschwindigkeit aufweisen. Es wäre nicht gut, wenn ein Team überlastet ist und dem Anderen die Arbeit ausgeht. Auch müssen Sie die Abhängigkeiten zwischen den Teams identifizieren und diese im Releaseplan berücksichtigen. Den Aufwand bestimmen Es ist aus meiner Sicht wichtig, dass die verschiedenen Teams die gleichen Methoden einsetzen und dies betrifft auch das einheitliche Schätzen. Wenn Sie für den Aufwand für User Stories Story Points verwenden, dann müssen sich die Teams auf eine gemeinsame Punkteskala und deren Bedeutung verständigen. Wächst die Anzahl der Scrum-Teams, so wird die Schätzgrundlage/Referenz vom ersten Team geschaffen. Starten mehrere Teams gleichzeitig, so sollten Repräsentanten jedes Teams an der ersten Schätzklausur teilnehmen. Dies ist natürlich eine Herausforderung, wenn die Teams weit verteilt sind. Projektweites Sprint Review und Retrospektive Projektweite Sprint Reviews geben den Teams ein gemeinsames Verständnis für den Projektfortschritt und die erarbeiteten Ergebnisse. 201

25 Projektweite Sprint-Retrospektiven unterstützen ein systematisches Lernen im Projekt, sind aber auch hilfreich teamübergreifende Normen zu entwickeln. Die Zusammenarbeit in großen Projekten ist nur möglich, wenn Sie gemeinsame Vorgehensweisen und Normen haben. Stellen Sie deshalb sicher, dass das Projekt diese in den ersten Sprints erarbeitet. Einiges kann natürlich auch schon vor dem ersten Sprint definiert werden. Dies war das ganze Kapitel 15 des Buches: Scrum: Agiles Projektmanagement und Scrum erfolgreich anwenden Lesen Sie das ganze Buch! Auf über 220 Seiten das wichtigste zum agilen Projektmanagement und Scrum. Buch oder Kindle ebook kaufen bei: Amazon 9.70 / kindleunlimited (kostenlos bis April) PDF kaufen: bei Gumroad (Preisstand 16. Feb 2018) 202