Upload
lamkhue
View
291
Download
0
Embed Size (px)
Citation preview
DE
R U
LTIM
ATIV
E S
CR
UM
GU
IDE
www.wibas.de
Der Ultimative Scrum Guide
ist für alle, die Scrum anwen-
den oder anwenden möch-
ten und ein Buch suchen,
das alle wichtigen Informati-
onen übersichtlich darstellt.
Er bietet wertvolles Wissen
in einem Layout, das Ihnen hilft, relevante
Informationen schnell zu finden. Gleichzeitig
lädt dieses Buch zum Stöbern ein. Der Ulti-
mative Scrum Guide ist ein Buch bei dem Sie
genau das lesen, was Sie interessiert. Und so
viel, wie Sie möchten.
Dies ist ein Buch zum Arbeiten. Das auf Ihrem
Schreibtisch liegt und immer zur Hand ist. In
dem Sie Notizen machen und das Sie zum
Erklären nutzen. Es ist ein ständiger Begleiter.
Mehr braucht es nicht. Deshalb nennen wir es
den Ultimativen Scrum Guide.
Und wenn dieser Scrum Guide für Sie noch
nicht ultimativ ist? Dann schreiben Sie uns.
Dieses Buch ergänzen wir ständig – machen
Sie mit. Wenn Sie einen Beitrag liefern, bekom-
men Sie ein Exemplar der nächsten Auflage
frei Haus. So, nun legen Sie mal los.
Malte FoegenGeschäftsführer wibas GmbH
DER ULTIMATIVESCRUM GUIDE
Ein Buch von
Malte Foegen
Astrid Meyser
Caroline Gansser
David Croome
Claudia Raak
Jörg Battenfeld
Anna Katharina Kröll
Christoph Fritsch-Leopoldt
Simon Porro
Manuel Dorn
Gute Praktiken für typische Fragen » 148
Der Zweck von Scrum » 12
Das große Ganze » 26
Die Rollen in Scrum » 52
Meetings zur Optimierung der Arbeit » 64
Hilfsmittel zur Optimierung der Arbeit » 92
Techniken zum Einsatz in Scrum-Projekten » 110
11
Der ultimative Scrum Guide » Der Zweck von Scrum » Agile WerteDer ultimative Scrum Guide » Der Zweck von Scrum » Agile Werte
AGILE WERTE18
Der ultimative Scrum Guide » Der Zweck von Scrum » Agile WerteDer ultimative Scrum Guide » Der Zweck von Scrum » Agile Werte
I II III IV VErmächtigung
und Selbst-
organisation
Frühe und
regelmäßige
Lieferungen
Überprüfung
und Anpassung
Transparenz Festlegung von
Zeitfenstern
Teams sind ermächtigt und verantwortlich, alle notwendigen Entschei-dungen zur Lieferung des Ergebnisses zu treffen. Sie planen ihre Arbeit selbst und entscheiden, wie sie sie am besten durchfüh-ren können. Teams sind funktionsübergreifend und interdisziplinär.
Jedes Mitglied des Teams fokussiert sich auf die inkrementelle Lieferung des Produkts. Frühe und regelmäßige Lieferungen stellen einen stetigen Fluss von Ergebnissen sicher, welcher den Teams eine kontinuierliche Über-prüfung und Anpassung ermöglicht.
Teams reflektieren regel-mäßig darüber, wie sie effektiver und effizienter werden können. Dies bezieht sich ebenso auf die fachliche Produk-tionsweise wie auf die zwischenmenschliche Zu-sammenarbeit im Team.
Teams teilen zur Förde-rung der Zusammenarbeit Informationen und Wissen miteinander, so dass jeder auf die bestmögliche Weise dazu beitragen kann, die Ziele zu erreichen.
In Scrum hat alles ein Zeitfenster, d. h. jede Akti-vität hat einen definitiven Anfang und ein definitives Ende, die nicht verscho-ben werden. Dadurch werden Disziplin, Fokus und pünktliche Lieferun-gen sichergestellt.
19
DAS GROSSE GANZE
Ist Scrum einzigartig? » 44
Scrum Praxisbeispiel » 42
Es gibt keine 42. » 50
Mit Unsicherheit intelligent umgehen. » 48
Was Scrum ist. Und was es nicht ist. » 46
Ausgewogenheit von Stabilität und Agilität » 40
Meetings » 34
Ergebnisse » 36
Rollen » 38
Der Scrum Flow » 30
Der ultimative Scrum Guide » Das große GanzeDer ultimative Scrum Guide » Das große Ganze
27
Der ultimative Scrum Guide » Das große Ganze » Der Scrum FlowDer ultimative Scrum Guide » Das große Ganze » Der Scrum Flow
EINFACHER ALS NACH HAUSE ZU FAHREN: DER SCRUM FLOW.
30
Der ultimative Scrum Guide » Das große Ganze » Der Scrum FlowDer ultimative Scrum Guide » Das große Ganze » Der Scrum Flow
31
Das Scrum Team der Bundesbehörde für Informatik und Telekommunikation in der Schweiz hat
für das Projekt sedex erfolgreich eine Balance zwischen Stabilität und Agilität gefunden.
Der ultimative Scrum Guide » Das große Ganze » PraxisbeispielDer ultimative Scrum Guide » Das große Ganze » Praxisbeispiel
EIN BEISPIEL:SCRUM IN DER PRAXIS
42
Eine bestehende IT-Lösung für die Harmonisie-rung der Statistiken bei Behörden auf Bundes-, kantonalen und kommunalen Ebenen wird optimiert und erweitert. Dies war nötig wegen der stetig steigenden Zahl der Anwender und zunehmenden Datenvolumina. Die Arbeit wurde durch eine Dienstleistungsvereinbarung (DLV) nach Aufwand beauftragt, worin ein Kostendach und der terminliche Rahmen von einem Jahr festgelegt waren.
Desweiteren regelte die DLV die Art der Zusammenarbeit und das Vorgehen:
• Eswurdevereinbart,ScrumalsVorgehen anzuwenden. Die Gesamtzeit wurde in Sprints von je 3 Wochen Länge aufgeteilt.
• DieErweiterungensollteninFormvon Patches oder Minor-Releases zusammen- gefasst werden, die mit dem Sprint- Rhythmus synchronisiert wurden.
• DieInteraktionenmitdemProductOwner wurden festgelegt: am Anfang jedes Sprints ein Planungsmeeting; nach jedem Sprint ein Review-Meeting, bei dem die erbrachten Arbeiten abgenommen werden. In den Zwischenwochen fand jeweils ein Abstim- mungsmeetingmitdemPOstatt.
• EswurdeneinEntwicklerteam,einScrum Master und ein Einsatzplan festgelegt. Die Leistung des Entwicklerteams wird nach erbrachtem Aufwand abgerechnet.
Die gesammelten Erweiterungswünsche werden in ein Product Backlog im Tool TFS (Team Foundation Server) erfasst, priorisiert und grob geschätzt. Dann erfolgt die Detailab-sprache, Planung, Umsetzung und Abnahme der anlässlich des Planningmeetings jeweilig ausgewählten Product Backlog-Einträge iterativ in den Sprints.
Nach mehreren Sprints wurde die Kommu-nikationmitdemProductOwnerunddieSchätzung / Commitment vom Team immer zuverlässiger. Folgender Arbeitsmodus hat sich etabliert:
• JedeWocheistderProductOwnerfüreinen Tag zu Besuch beim Entwicklungsteam: einmal im Sprint für den Sprint-Wechsel und zweimal während der Sprint-Arbeit, um Fragen vom Entwicklungsteam zu klären.
• KurzvordemSprint-Wechselpasstder ProductOwnerdasProductBacklogan (aktuelle Priorisierung, angepasste Stories, neue Stories) und schickt dem Scrum Master einen Vorschlag für den nächsten Sprint.
• DerSprint-Wechselwirdwiefolgtdurch- geführt: ° Vormittags Review des vergangenen Sprints ° Sprint Planung 1 nachmittags mit dem ProductOwner.Klärungderausgewählten Erweiterungen. Ergebnis: ein Protokoll der besprochenen Abweichungen zum VorschlagdesPO. ° Sprint Planung 2 nachmittags ohne Product Owner.KlärungderAufgabenimEntwick- lungsteam, Detailschätzung. Ergebnis: unterschriebener Sprint Contract mit Angaben zu den verpflichteten Arbeiten für den folgenden Sprint.
• WährendderSprint-ArbeithatderProduct OwnerdasEntwicklungsteamniemit Änderungen gestört.
Der ultimative Scrum Guide » Das große Ganze » PraxisbeispielDer ultimative Scrum Guide » Das große Ganze » Praxisbeispiel
EIN BEISPIEL:SCRUM IN DER PRAXIS
Dieses Beispiel zeigt, wie man den scheinbar gegensätzlichen Ansprüchen von Agilität und Stabilität durch einen Vertrag und eine partnerschaftliche Arbeitsweise gerecht wird.
43
Der ultimative Scrum Guide » Das große Ganze » Was Scrum ist – und was nicht.Der ultimative Scrum Guide » Das große Ganze » Was Scrum ist – und was nicht.
WAS SCRUM IST –UND WAS NICHT.Scrum bedeutet nicht
„Umsetzen ohne Plan“.
Scrum begrüßt Änderungen im Plan – auch sehr spät in der Umsetzung. Deswegen vermeidet Scrum die ver-schwenderische Detailplanung von Dingen, die weiter in der Zukunft liegen und die sich wahrscheinlich sowieso ändern.ZurlangfristigenOrientierunghatdasScrumTeam die Produktvision.
Der Realisierungsplan für das gesamte Produkt existiert in Form des Product Backlogs und des Releaseplans. Je näher die Product Backlog-Einträge rücken, desto detaillierter werden sie beschrieben und geschätzt. Epics werden in mehrere Stories gesplittet.
Für den Sprint gibt es einen detaillierten Task-Plan für das Entwicklungsteam.
Scrum bedeutet nicht
„Keine Dokumentation“.
Das Agile Manifest sagt einerseits, dass es wichtiger ist, einsetzbare Ergebnisse zu liefern als eine allumfassende Dokumentation zu erstellen und anderseits, dass die Interaktion mit Menschen wichtiger ist als der Einsatz von Tools und Verfahren. Die Betonung liegt auf der Diskussi-on, um ein gemeinsames Verständnis zwischen Product OwnerundEntwicklungsteamzuschaffen,aber:
Der generelle Dokumentationsgrad für jedes neue Feature wird gemeinsam in der „Definition of Done“ festgelegt, z. B. Bedienungsanleitung, Anwendungsfall, Testfall (ho-her Dokumentationsgrad) oder User Story mit Akzeptanz-kriterium (niedriger Dokumentationsgrad).
Die Planung kann nur auf einem Planning-Board doku-mentiert werden oder in einem Tool erfasst und gepflegt werden. Dies hängt von den Bedürfnissen des Scrum Teams ab. Häufig wird das Product Backlog in einem Tool erfasst und gepflegt, während das Sprint Backlog wegen der besseren Visualisierung an einer Wand in Form eines Sprint Boards geführt wird.
Dafür hilfreiche
Elemente in Scrum:
« Produktvision
Definition of Done »
« Product Backlog
« Releaseplan
« Sprint Backlog
Planning Board oder
Tool »
46
Der ultimative Scrum Guide » Das große Ganze » Was Scrum ist – und was nicht.Der ultimative Scrum Guide » Das große Ganze » Was Scrum ist – und was nicht.
WAS SCRUM IST –UND WAS NICHT.
Scrum bedeutet nicht
„Keine Kennzahlen“.
Für die Fortschrittsverfolgung der Sprint-Arbeit gibt es tagesaktuelle Sprint-Burndown Zahlen und eine ent-sprechende Grafik, in der die Wahrscheinlichkeit der Erreichung des geplanten Umfangs bis zum Sprint-Ende immer ersichtlich ist.
Nach dem Sprint Review wird die Anzahl der im Sprint erledigten Story-Points ermittelt – die sogenannte Velocity. Dies dient der realistischeren Planung zukünftiger Sprints.
Für die Fortschrittsverfolgung der Releases gibt es Pro-dukt- bzw. Release Burndown-Zahlen und eine entspre-chende Grafik, wo die Wahrscheinlichkeit der Lieferung der für den Release geplanten Features bis zum Release-Datum immer ersichtlich ist.
Scrum bedeutet nicht
„Kein Risikomanagement“.
Die Priorisierung der Product Backlog-Einträge berück-sichtigt das Risiko. Einträge, die das Risiko vermindern können werden höher priorisiert.
Durch den iterativen Sprint-Ansatz werden sowohl Produkt-Zwischenergebnisse beim Sprint Review als auch Arbeitsweisen bei der Sprint Retrospektive früh und regel-mäßig überprüft. Dabei werden Probleme früh erkannt und Maßnahmen eingeleitet.
Durch das Daily Scrum werden Risiken täglich besprochen und adressiert.
Ein wesentliche Aufgabe des Scrum Masters ist die Beseitigung von Hindernissen.
Dafür hilfreiche
Elemente in Scrum:
Priorisierung im
Product Backlog »
« Sprint Burndown
Sprint Review und
Sprint Retrospektive »
« Velocity
Daily Scrum »
« Release Burndown
Scrum Master »
47
DIE ROLLEN IN SCRUM
Scrum Master » 58
Entwicklungsteam » 60
Scrum Team » 62
Stakeholder » 63
Product Owner » 56
Der ultimative Scrum Guide » Die Rollen in Scrum
52
Der ultimative Scrum Guide » Die Rollen in Scrum » Product OwnerDer ultimative Scrum Guide » Die Rollen in Scrum » Product Owner
PRODUCT OWNER
Der Product Owner ist für die Merkmale und den Return On Investment
(ROI) des Produkts verantwortlich. Diese Person erstellt, ordnet und ver-
waltet die Anforderungen im Product Backlog. Der Product Owner stellt
durch die öffentliche Verfügbarkeit des Product Backlogs sicher, dass das
Entwicklungsteam aus einer geschäftlichen Perspektive heraus an den
„richtigen Dingen“ arbeitet. Er oder sie entscheidet, was in einem Sprint
fertiggestellt wurde oder nicht.
Der Product Owner ist eine Person, kein Gremium, und ist bevollmäch-
tigt, endgültige Entscheidungen über das Produkt, seine Merkmale und
die Reihenfolge der Implementierung zu treffen.
Der Product Owner ist eine Person und kein Gremium. Ein Product Owner ist eine Person mit einer natürli-chen Authorität. Product Owner sind Netzwerker
und vermitteln gerne zwischen verschiede-nen Anspruchsgrup-pen.
In ihrer Arbeitszeit sind Product Owner mindes-tens 50%, idealerweise 100% mit dem Produkt beschäftigt.
56
Der ultimative Scrum Guide » Die Rollen in Scrum » Product OwnerDer ultimative Scrum Guide » Die Rollen in Scrum » Product Owner
PRODUCT OWNERCheckliste für einen
ergebnisorientierten Product Owner Kompetenzen • Siedenkenunternehmerischundvisionär. • SieübernehmenVerantwortungfüreinProdukt. • SievermittelnzwischenihrenStakeholdernundverhandelnim Sinne des bestmöglichen Produktergebnisses.
Verantwortung • SiesindverantwortlichfürdenwirtschaftlichenErfolgdesProduktes (ROI). • SiebestimmendieReihenfolgederfertigenInkrementeundden Liefertermin des Endprodukts. • SiebildendieSchnittstellezuallenStakeholdernundvertretendie Interessen des Kunden.
Aufgaben • SiegestaltendieProduktvision. • SiedefinierendenProduktumfangunddie-eigenschaften. • SieordnendieArbeit,umdenMitteleinsatzzuoptimieren. • SieüberprüfendasErgebnisundpassenggf.dieRichtungan. • SienehmendieErgebnissefürdenSprintbzw.fürdasReleaseab. • SiekommunizierendenFortschrittund-statusandieStakeholder.
„Es war gar nicht so einfach,
mich in die neue Rolle einzufinden.
Gut, dass ich einen erfahrenen Scrum Master
an der Seite hatte, der mich bei meiner
Arbeit unterstützt hat.“
57
MEETINGS ZUR OPTIMIERUNG DER ARBEIT
Der ultimative Scrum Guide » MeetingsDer ultimative Scrum Guide » Meetings
64
MEETINGS ZUR OPTIMIERUNG DER ARBEIT Sprint Planung Zwei » 76
Daily Scrum » 80
Sprint Review » 82
Sprint Retrospektive » 84
Beispiel: Ein typischer 14-Tage-Sprint » 90
Grooming » 86
Sprint Planung Eins » 74
Plan, Do, Check, Act. » 72
Sprint » 70
Der ultimative Scrum Guide » MeetingsDer ultimative Scrum Guide » Meetings
Die Zeit in Scrum » 68 65
Der ultimative Scrum Guide » Meetings » Plan, Do, Check, Act.Der ultimative Scrum Guide » Meetings » Plan, Do, Check, Act.
72
Der ultimative Scrum Guide » Meetings » Plan, Do, Check, Act.
PLAN, DO, CHECK, ACT. PLAN – Beim Sprint Start wird
der Sprint üblicherweise in
zwei aufeinanderfolgenden
Meetings geplant: Sprint Pla-
nung Eins und Sprint Planung
Zwei.
DO – Die Sprint Arbeit um-
fasst die wesentliche Arbeits-
zeit eines Sprints. Das Scrum
Team macht die Arbeit, um die
Einträge des Sprint Backlogs
umzusetzen und das Inkre-
ment fertigzustellen. Das Team
hält jeden Tag ein Daily Scrum
ab. Dieses dient der gemein-
samen Information, Abstim-
mung und Identifikation von
Behinderungen. Das Daily
Scrum setzt den Demingkreis
auf der täglichen Ebene um.
Üblicherweise werden wäh-
rend der Sprint Arbeit ein oder
mehrere Grooming Bespre-
chungen durchgeführt, um ein
gemeinsames Verständnis des
Product Backlogs zu erreichen
und das Backlog mit Ideen aus
dem Entwicklungsteam anzu-
reichern.
CHECK & ACT – Beim Sprint
Abschluss konzentriert sich
das Team auf eine Bewertung
des vergangenen Sprints und
bereitet den nächsten vor. Zwei
Besprechungen werden beim
Sprint Abschluss durchgeführt:
beim Sprint Review fokussiert
das Scrum Team auf das um-
gesetzte Ergebnis, während
es bei der Sprint Retrospektive
die Arbeitsweise betrachtet.
Der ultimative Scrum Guide » Meetings » Plan, Do, Check, Act.
Scrum setzt den Plan-Do-Check-Act-Zyklus (Demingkreis) konsequent auf der Ebene des Sprints und eines jeden Tags um.
73
HILFREICHE TECHNIKENFÜR SCRUM-PROJEKTE
Der ultimative Scrum Guide » TechnikenDer ultimative Scrum Guide » Techniken
Sprint Burndown » 128
Magic Estimation » 126
Impediment Backlog » 146
Planning Poker » 124
Definition of Ready » 122
User Story » 118
KANO-Analyse » 120
Collocation » 116
Produktvision » 114
110
Der ultimative Scrum Guide » TechnikenDer ultimative Scrum Guide » Techniken
Retrospektiven – Aus Fehlern lernen » 130
Seestern-Retrospektive » 134
Feedback Capture Grid » 136
Zeitleiste » 138
Weitere Gedanken zu Retrospektiven » 140
Release Plan » 142
Release Burndown » 144
Fünf Phasen einer Retrospektive » 132
111
Mike Cohn (2004)
Der ultimative Scrum Guide » Techniken » User StoryDer ultimative Scrum Guide » Techniken » User Story
„User Stories ersetzen das Gespräch
zwischen Product Owner und Team nicht,
sondern dokumentieren dessen Ergebnis.“
118
Der ultimative Scrum Guide » Techniken » User StoryDer ultimative Scrum Guide » Techniken » User Story
USER STORY
User Story ist eine Technik zur
Beschreibung von Anforderungen
aus der Perspektive eines Be-
nutzers, unter Verwendung von
Alltagssprache. In Scrum werden
User Stories als Product Backlog-
Einträge verwendet.
Das Verfassen von User Stories
liegt in der Verantwortung des
Product Owners.
Eine User Story beschreibt, was
der Benutzer erreichen will und
warum.
User Stories folgen im Allgemeinen diesem Muster:
„Als NUTZER will ich ZIEL/WUNSCH damit NUTZEN.“
Eine User Story sollte kurz und präzise sein und auf eine kleine Kartei-karte passen. User Stories sind ein einfacher und leichter Weg, mit Anforderungen von Kunden umzugehen. Dabei kann es sich nicht nur um Produkt- oder Dienstleistungsanforderungen handeln, sondern auch um Lieferobjekte und nicht-funktionale Anforderungen. Das Ziel von User Stories ist es, die Anforderungen zu erfassen und sie schritt-weise zu verfeinern und aufzuschlüsseln.
Gute User Stories enthalten Anforderungen, die sich durch die INVEST-Kriterien überprüfen lassen:
[ I ] ndependent Eine User Story ist unabhängig von anderen User Stories. Eine User Story sollte möglichst nicht davon abhängen, dass zuerst eine andere User Story umgesetzt werden muss.
[ N ] egotiable User Stories sind kein in Stein gemeißeltes Gesetz. Kunden und Entwickler besprechen und präzisieren (verhandeln) sie gemeinsam.
[ V ] aluable Die User Stories sollten einen erkennbaren Nutzen liefern. Beinhaltet eine User Story keinen klaren Mehrwert, so muss sie entweder umformuliert oder gestrichen werden.
[ E ] stimable Das Entwicklungsteam muss die Arbeitsauf-wände für jede User Story schätzen können. Dazu muss die User Story klar und verständlich formuliert sein.
[ S ] mall Die User Stories sollten möglichst kurz gehal-ten werden. Als grobe Regel gilt: Die komplette Umsetzung einer User Story soll mindestens einen halben Personentag und maximal zehn Personentage erfordern.
[ T ] estable Die User Stories sollten testbar sein. Tests bilden den Maßstab ob eine User Story erfolgreich abgeschlossen wurde.
119
RETROSPEKTIVEN – FRÜH FEHLER MACHEN UND SCHNELL DARAUS LERNEN.
Der ultimative Scrum Guide » Techniken » RetrospektivenDer ultimative Scrum Guide » Techniken » Retrospektiven
130
Der ultimative Scrum Guide » Techniken » RetrospektivenDer ultimative Scrum Guide » Techniken » Retrospektiven
131Es gibt viele verschiedene Techniken,
um eine Retrospektive durchzuführen.
Wir stellen Ihnen
das Vorgehen und drei Techniken vor,
mit denen Sie gleich starten können.
Der ultimative Scrum Guide » Gute Praktiken Der ultimative Scrum Guide » Gute Praktiken
Wie läuft Scrum in Service- oder Devop-Teams ab? » 160
Wie skaliert Scrum? » 166
Funktioniert Scrum außerhalb der IT? » 158
Passen Scrum und CMMI zusammen? » 156
Wie funktioniert eine Scrum Transition? » 154
Was ist Scrum Coaching? » 152
Wie beginne ich mit Scrum? » 150148
GUTE PRAKTIKEN FÜR TYPISCHE FRAGEN
Der ultimative Scrum Guide » Gute Praktiken Der ultimative Scrum Guide » Gute Praktiken
149
Ihre Kritik ist wertvoll.
Dieses Buch entsteht in Iterationen
und Sie halten gerade die erste Version
in der Hand. Das Wissen, das Sie hier
finden, dürfen Sie natürlich behalten.
Sollten Sie aber Fehler finden, dann
geben Sie sie uns bitte zurück, damit
das nächste Inkrement wieder ein
Stückchen besser wird.
Der ultimative Scrum Guide » Ihr Beitrag
SIE SIND DRAN.
Der ultimative Scrum Guide » Ihr Beitrag
168
DE
R U
LTIM
ATIV
E S
CR
UM
GU
IDE
www.wibas.de
Der Ultimative Scrum Guide
ist für alle, die Scrum anwen-
den oder anwenden möch-
ten und ein Buch suchen,
das alle wichtigen Informati-
onen übersichtlich darstellt.
Er bietet wertvolles Wissen
in einem Layout, das Ihnen hilft, relevante
Informationen schnell zu finden. Gleichzeitig
lädt dieses Buch zum Stöbern ein. Der Ulti-
mative Scrum Guide ist ein Buch bei dem Sie
genau das lesen, was Sie interessiert. Und so
viel, wie Sie möchten.
Dies ist ein Buch zum Arbeiten. Das auf Ihrem
Schreibtisch liegt und immer zur Hand ist. In
dem Sie Notizen machen und das Sie zum
Erklären nutzen. Es ist ein ständiger Begleiter.
Mehr braucht es nicht. Deshalb nennen wir es
den Ultimativen Scrum Guide.
Und wenn dieser Scrum Guide für Sie noch
nicht ultimativ ist? Dann schreiben Sie uns.
Dieses Buch ergänzen wir ständig – machen
Sie mit. Wenn Sie einen Beitrag liefern, bekom-
men Sie ein Exemplar der nächsten Auflage
frei Haus. So, nun legen Sie mal los.
Malte FoegenGeschäftsführer wibas GmbH
DER ULTIMATIVESCRUM GUIDE
Ein Buch von
Malte Foegen
Astrid Meyser
Caroline Gansser
David Croome
Claudia Raak
Jörg Battenfeld
Anna Katharina Kröll
Christoph Fritsch-Leopoldt
Simon Porro
Manuel Dorn