Essential Scrum - Umfassendes Scrum-Wissen aus der Praxis

Cover

Titel

Impressum

Inhaltsverzeichnis

Vorwort von Mike Cohn

Vorwort von Ron Jeffries

Einleitung

Danksagungen

Über den Autor

Kapitel 1: Einführung

1.1 Was ist Scrum?

1.2 Die Ursprünge von Scrum

1.3 Wieso Scrum?

1.4 Ergebnisse bei Genomica

1.5 Kann Scrum Ihnen helfen?

1.5.1 Die Complex-Domäne

1.5.2 Die Complicated-Domäne

1.5.3 Die Simple-Domäne

1.5.4 Die Chaotic-Domäne

1.5.5 Disorder (Nicht-Wissen, Regellosigkeit)

1.5.6 Unterbrechungsgesteuerte Arbeit

1.6 Abschließende Bemerkungen

Teil I: Kernkonzepte

Kapitel 2: Das Scrum-Framework

2.1 Überblick

2.2 Scrum-Rollen

2.2.1 Product Owner

2.2.2 ScrumMaster

2.2.3 Das Entwicklungsteam

2.3 Scrum-Aktivitäten und Artefakte

2.3.1 Product Backlog

2.3.2 Sprints

2.3.3 Sprint-Planung

2.3.4 Sprint-Ausführung

2.3.5 Daily Scrum

2.3.6 Fertig (Done)

2.3.7 Sprint Review

2.3.8 Sprint-Retrospektive

2.4 Abschließende Bemerkungen

Kapitel 3: Agile Prinzipien

3.1 Überblick

3.2 Veränderlichkeit und Unsicherheit

3.2.1 Hilfreiche Veränderlichkeit bereitwillig annehmen

3.2.2 Iterative und inkrementelle Entwicklung nutzen

3.2.3 Ausnutzen der Veränderlichkeit durch Inspektion, Anpassung und Transparenz

3.2.4 Gleichzeitiges Reduzieren aller Formen der Unsicherheit

3.3 Vorhersage und Anpassung

3.3.1 Optionen offen halten

3.3.2 Akzeptieren, dass man es nicht gleich von Anfang an richtig machen kann

3.3.3 Einen adaptiven, untersuchenden Ansatz bevorzugen

3.3.4 Änderung auf eine ökonomisch sinnvolle Weise annehmen

3.3.5 Vorhersagende, im Voraus erfolgende Arbeit mit adaptiver, bedarfsgerechter Arbeit abwägen

3.4 Validiertes Wissen

3.4.1 Schnelles Validieren wichtiger Annahmen

3.4.2 Abwägen mehrerer gleichzeitiger Lernschleifen

3.4.3 Organisieren des Workflows für schnelle Feedbacks

3.5 Work in Process (WIP)

3.5.1 Wirtschaftlich sinnvolle Batch-Größen benutzen

3.5.2 Lagerbestände erkennen und sinnvoll verwalten

3.5.3 Auf unerledigte Arbeit konzentrieren, nicht auf untätige Arbeiter

3.5.4 Verzögerungskosten betrachten

3.6 Fortschritt

3.6.1 An Echtzeitinformationen anpassen und umplanen

3.6.2 Fortschritt messen, indem man funktionierende Güter validiert

3.6.3 Auf eine wertzentrierte Auslieferung konzentrieren

3.7 Leistung

3.7.1 Gehe schnell, aber hetze nicht

3.7.2 Baue Qualität ein

3.7.3 Mache alles ohne großes Zeremoniell

3.8 Abschließende Bemerkungen

Kapitel 4: Sprints

4.1 Überblick

4.2 Timeboxing

4.2.1 Legt ein WIP-Limit fest

4.2.2 Erzwingt eine Priorisierung

4.2.3 Demonstriert Fortschritt

4.2.4 Verhindert unnötigen Perfektionismus

4.2.5 Motiviert die Fertigstellung

4.2.6 Verbessert die Vorhersagbarkeit

4.3 Kurze Zeitdauer

4.3.1 Erleichterte Planung

4.3.2 Schnelles Feedback

4.3.3 Verbesserter Return on Investment

4.3.4 Begrenzte Fehler

4.3.5 Wiedererweckte Begeisterung

4.3.6 Häufige Checkpoints

4.4 Konsistente Dauer

4.4.1 Vorteile der Kadenz

4.4.2 Vereinfacht die Planung

4.5 Keine das Ziel beeinflussenden Änderungen

4.5.1 Was ist ein Sprint-Ziel?

4.5.2 Gegenseitige Verpflichtung

4.5.3 Änderungen versus Klärung

4.5.4 Konsequenzen einer Änderung

4.5.5 Pragmatisch sein

4.5.6 Abnormaler Abbruch

4.6 Definition von Fertig (Done)

4.6.1 Wie lautet die Definition von Fertig?

4.6.2 Die Definition von Fertig kann sich im Laufe der Zeit weiterentwickeln

4.6.3 Definition von Fertig versus Akzeptanzkriterien

4.6.4 Fertig versus Fertig-Fertig

4.7 Abschließende Bemerkungen

Kapitel 5: Anforderungen und User Stories

5.1 Überblick

5.2 Gespräche

5.3 Progressive Verfeinerung

5.4 Was sind User Stories?

5.4.1 Card (Karte)

5.4.2 Conversation (Gespräch)

5.4.3 Confirmation (Bestätigung)

5.5 Der Detaillierungsgrad

5.6 In gute Stories INVESTieren

5.6.1 Independent (unabhängig)

5.6.2 Negotiable (verhandelbar)

5.6.3 Valuable (werthaltig)

5.6.4 Estimatable (schätzbar)

5.6.5 Passende Größe (klein)

5.6.6 Testable (prüfbar)

5.7 Nichtfunktionale Anforderungen

5.8 Stories zum Wissenserwerb

5.9 Stories sammeln

5.9.1 Workshop zum Schreiben von User Stories

5.9.2 Story Mapping

5.10 Abschließende Bemerkungen

Kapitel 6: Das Product Backlog

6.1 Überblick

6.2 Product-Backlog-Elemente

6.3 Merkmale guter Product Backlogs

6.3.1 Detailed appropriately (ausreichend detailliert)

6.3.2 Emergent

6.3.3 Estimated (geschätzt)

6.3.4 Prioritized (priorisiert)

6.4 Pflege

6.4.1 Was bedeutet Pflege?

6.4.2 Wer führt die Pflege durch?

6.4.3 Wann findet die Pflege statt?

6.5 Die Definition von Bereit

6.6 Flow Management

6.6.1 Release Flow Management

6.6.2 Sprint Flow Management

6.7 Welche und wie viele Product Backlogs?

6.7.1 Was ist ein Produkt?

6.7.2 Große Produkte – hierarchische Backlogs

6.7.3 Mehrere Teams – ein Product Backlog

6.7.4 Ein Team – mehrere Produkte

6.8 Abschließende Bemerkungen

Kapitel 7: Schätzung und Velocity

7.1 Überblick

7.2 Was und wann wir schätzen

7.2.1 Schätzungen für Portfolio-Backlog-Elemente

7.2.2 Product-Backlog-Schätzungen

7.2.3 Aufgabenschätzungen

7.3 Schätzkonzepte für Product-Backlog-Elemente

7.3.1 Als Team schätzen

7.3.2 Schätzungen sind keine Verpflichtungen

7.3.3 Exaktheit versus Präzision

7.3.4 Relative Größenschätzung

7.4 Schätzeinheiten für Product-Backlog-Elemente

7.4.1 Story-Punkte

7.4.2 Idealtage

7.5 Planungspoker

7.5.1 Schätzskala

7.5.2 Wie man spielt

7.5.3 Vorteile

7.6 Was ist Velocity?

7.7 Einen Velocity-Bereich berechnen

7.8 Die Velocity vorhersagen

7.9 Die Velocity beeinflussen

7.10 Missbrauch der Velocity

7.11 Abschließende Bemerkungen

Kapitel 8: Technische Schulden

8.1 Überblick

8.2 Die Folgen technischer Schulden

8.2.1 Unvorhersehbarer Wendepunkt

8.2.2 Zunehmend verzögerte Auslieferung

8.2.3 Beträchtliche Anzahl an Defekten

8.2.4 Steigende Entwicklungs- und Support-Kosten

8.2.5 Das Produkt verkümmert

8.2.6 Schwindende Vorhersehbarkeit

8.2.7 Leistungseinbruch

8.2.8 Allgemeiner Frust

8.2.9 Sinkende Kundenzufriedenheit

8.3 Ursachen der technischen Schulden

8.3.1 Druck hinsichtlich des Erreichens einer Deadline

8.3.2 Erfolglose Versuche der Velocity-Beschleunigung

8.3.3 Gerücht: Weniger Testen kann die Velocity beschleunigen

8.3.4 Schulden bauen auf Schulden auf

8.4 Technische Schulden müssen organisiert werden

8.5 Die Zunahme technischer Schulden überwachen

8.5.1 Bewährte technische Praktiken anwenden

8.5.2 Eine starke Definition von Fertig benutzen

8.5.3 Die wirtschaftlichen Aspekte technischer Schulden richtig verstehen

8.6 Technische Schulden sichtbar machen

8.6.1 Technische Schulden auf geschäftlicher Ebene sichtbar machen

8.6.2 Technische Schulden auf der technischen Ebene sichtbar machen

8.7 Technische Schulden abbauen

8.7.1 Nicht alle technischen Schulden sollten abgebaut werden

8.7.2 Wenden Sie die Pfadfinderregel an (Bauen Sie die Schulden ab, sobald sie Ihnen begegnen)

8.7.3 Bauen Sie technische Schulden schrittweise ab

8.7.4 Bauen Sie die technischen Schulden mit den höchsten Zinsen zuerst ab

8.7.5 Technische Schulden abbauen, während man für den Kunden werthaltige Arbeit erledigt

8.8 Abschließende Bemerkungen

Teil II: Rollen

Kapitel 9: Der Product Owner

9.1 Überblick

9.2 Hauptaufgaben

9.2.1 Organisation der wirtschaftlichen Belange

9.2.2 Mitwirkung an der Planung

9.2.3 Pflege des Product Backlogs

9.2.4 Definition und Verifikation der Akzeptanzkriterien

9.2.5 Zusammenarbeit mit dem Entwicklungsteam

9.2.6 Zusammenarbeit mit den Stakeholdern

9.3 Eigenschaften/Fähigkeiten

9.3.1 Fachwissen

9.3.2 Soziale Kompetenz

9.3.3 Entscheidungsfindung

9.3.4 Verantwortung

9.4 Der Alltag eines Product Owners

9.5 Wer sollte Product Owner sein?

9.5.1 Interne Entwicklung

9.5.2 Gewerbliche Entwicklung

9.5.3 Ausgelagerte Entwicklung

9.5.4 Komponentenentwicklung

9.6 Product Owner kombiniert mit anderen Rollen

9.7 Das Product-Owner-Team

9.7.1 Product-Owner-Stellvertreter

9.7.2 Chief Product Owner

9.8 Abschließende Bemerkungen

Kapitel 10: ScrumMaster

10.1 Überblick

10.2 Wichtigste Aufgaben

10.2.1 Coach

10.2.2 »Dienende Führungskraft«

10.2.3 Prozessautorität

10.2.4 Schutz vor störenden Einflüssen

10.2.5 Beseitigung von Hindernissen

10.2.6 Berater in der Organisationsentwicklung

10.3 Eigenschaften/Fähigkeiten

10.3.1 Sachkundig

10.3.2 Neugierig

10.3.3 Geduldig

10.3.4 Teamfähig

10.3.5 Schützend

10.3.6 Transparent

10.4 Alltag

10.5 Die Rolle ausfüllen

10.5.1 Wer sollte ScrumMaster sein?

10.5.2 Ist die Rolle des ScrumMasters eine Vollzeitbeschäftigung?

10.5.3 ScrumMaster in Kombination mit anderen Rollen

10.6 Abschließende Bemerkungen

Kapitel 11: Das Entwicklungsteam

11.1 Überblick

11.2 Rollenspezifische Teams

11.3 Wichtigste Aufgaben

11.3.1 Durchführung des Sprints

11.3.2 Tägliches Untersuchen und Anpassen (»Inspect and Adapt«)

11.3.3 Pflege des Product Backlogs

11.3.4 Den Sprint planen

11.3.5 Produkt und Prozess untersuchen und anpassen

11.4 Eigenschaften/Fertigkeiten

11.4.1 Selbstorganisierend

11.4.2 Funktionsübergreifend vielseitig

11.4.3 T-förmige Fertigkeiten

11.4.4 Die Musketier-Einstellung

11.4.5 Kommunikation mit hoher Bandbreite

11.4.6 Transparente Kommunikation

11.4.7 Die richtige Größe

11.4.8 Fokussiert und verpflichtet

11.4.9 In einer nachhaltigen Geschwindigkeit arbeiten

11.4.10 Langlebig

11.5 Abschließende Bemerkungen

Kapitel 12: Die Strukturen des Scrum-Teams

12.1 Überblick

12.2 Funktionsteams versus Komponententeams

12.3 Koordination mehrerer Teams

12.3.1 Scrum of Scrums

12.3.2 Der Release-Train

12.4 Abschließende Bemerkungen

Kapitel 13: Manager

13.1 Überblick

13.2 Teams koordinieren

13.2.1 Grenzen definieren

13.2.2 Ein klares Ziel vorgeben

13.2.3 Teams bilden

13.2.4 Die Teamzusammensetzung ändern

13.2.5 Teams bevollmächtigen

13.3 Teams fördern

13.3.1 Die Mitarbeiter anspornen

13.3.2 Kompetenz entwickeln

13.3.3 Fachliche Anleitung bieten

13.3.4 Die Integrität des Teams bewahren

13.4 Die Umgebung ausrichten und anpassen

13.4.1 Agile Werte fördern

13.4.2 Organisatorische Hindernisse entfernen

13.4.3 Die internen Abteilungen ausrichten

13.4.4 Die Partner ausrichten

13.5 Den Wertschöpfungsfluss organisieren

13.5.1 Die Sichtweise des Systems annehmen

13.5.2 Die wirtschaftlichen Aspekte organisieren

13.5.3 Messungen und Berichte überwachen

13.6 Projektmanager

13.6.1 Projektmanagementaufgaben in einem Scrum-Team

13.6.2 Eine getrennte Projektmanager-Rolle bewahren

13.7 Abschließende Bemerkungen

Teil III: Planen

Kapitel 14: Scrum-Planungsprinzipien

14.1 Überblick

14.2 Gehen Sie nicht davon aus, dass im Voraus erstellte Pläne korrekt sind

14.3 Die Vorabplanung sollte hilfreich, aber nicht exzessiv sein

14.4 Halten Sie sich die Planungsoptionen bis zum letzten verantwortbaren Augenblick offen

14.5 Konzentrieren Sie sich stärker auf das Anpassen und Neuplanen als darauf, einem Plan zu genügen

14.6 Den Planungsbestand richtig organisieren

14.7 Bevorzugen Sie kleinere und häufigere Releases

14.8 Lernen Sie schnell dazu und weichen Sie vom Plan ab, wenn es nötig sein sollte

14.9 Abschließende Bemerkungen

Kapitel 15: Planung auf mehreren Ebenen

15.1 Überblick

15.2 Portfolio-Planung

15.3 Produktplanung (Visionsbildung)

15.3.1 Die Vision

15.3.2 Allgemeines Product Backlog

15.3.3 Produkt-Roadmap

15.4 Release-Planung

15.5 Sprint-Planung

15.6 Tägliche Planung

15.7 Abschließende Bemerkungen

Kapitel 16: Portfolio-Planung

16.1 Überblick

16.1.1 Das Timing

16.1.2 Teilnehmer

16.1.3 Der Prozess

16.2 Zeitplanungsstrategien

16.2.1 Optimierung der Rendite über die Lebensdauer

16.2.2 Kalkulation der Verzögerungskosten

16.2.3 Schätzungen mit Genauigkeit statt Präzision

16.3 Zuflussstrategien

16.3.1 Den wirtschaftlichen Filter anwenden

16.3.2 Zufluss- und Abflussrate ausbalancieren

16.3.3 Sich bietende Gelegenheiten schnell ergreifen

16.3.4 Planen Sie kleinere, häufigere Releases

16.4 Abflussstrategien

16.4.1 Auf unerledigte Arbeit konzentrieren, nicht auf untätige Mitarbeiter

16.4.2 Einrichten eines WIP-Limits

16.4.3 Auf ein komplettes Team warten

16.5 Strategien zur Überprüfung der in Bearbeitung befindlichen Produkte

16.5.1 Die Grenznutzenrechnung verwenden

16.6 Abschließende Bemerkungen

Kapitel 17: Visionsfindung (Produktplanung)

17.1 Überblick

17.1.1 Das Timing

17.1.2 Teilnehmer

17.1.3 Der Prozess

17.2 SR4U-Beispiel

17.3 Die Entwicklung der Vision

17.4 Erstellen eines allgemeinen Product Backlogs

17.5 Die Definition der Produkt-Roadmap

17.6 Andere Aktivitäten

17.7 Wirtschaftlich vernünftige Visionsfindung

17.7.1 Eine realistische Vertrauensschwelle anstreben

17.7.2 Konzentrieren Sie sich auf einen kurzfristigen Planungshorizont

17.7.3 Handeln Sie schnell

17.7.4 Erwerben Sie validiertes Wissen

17.7.5 Nutzen Sie eine inkrementelle Finanzierung

17.7.6 Lernen Sie schnell dazu und weichen Sie ggf. vom Plan ab (aka Schnelles Scheitern)

17.8 Abschließende Bemerkungen

Kapitel 18: Release-Planung (längerfristige Planung)

18.1 Überblick

18.1.1 Das Timing

18.1.2 Teilnehmer

18.1.3 Der Prozess

18.2 Release-Einschränkungen

18.2.1 Alles fest

18.2.2 Umfang und Termin fest

18.2.3 Fester Umfang

18.2.4 Fester Termin

18.2.5 Variable Qualität

18.2.6 Einschränkungen aktualisieren

18.3 Das Product Backlog pflegen

18.4 Die minimal freigebbaren Funktionen (Minimum Releasable Features, MRFs) verfeinern

18.5 Sprint Mapping (Einordnung der Product-Backlog-Elemente)

18.6 Release-Planung mit festem Termin

18.7 Release-Planung mit festem Umfang

18.8 Die Kosten berechnen

18.9 Kommunizieren

18.9.1 Den Fortschritt in einem Release mit festem Umfang kommunizieren

18.9.2 Den Fortschritt in einem Release mit festem Termin kommunizieren

18.10 Abschließende Bemerkungen

Teil IV: Sprints

Kapitel 19: Die Sprint-Planung

19.1 Überblick

19.1.1 Das Timing

19.1.2 Teilnehmer

19.1.3 Der Prozess

19.2 Ansätze für die Sprint-Planung

19.2.1 Zweiteilige Sprint-Planung

19.2.2 Einteilige Sprint-Planung

19.3 Die Kapazität ermitteln

19.3.1 Was ist die Kapazität?

19.3.2 Kapazität in Story-Punkten

19.3.3 Die Kapazität in Aufwandsstunden

19.4 Product-Backlog-Elemente auswählen

19.5 Zuversicht erwerben

19.6 Das Sprint-Ziel verfeinern

19.7 Die Verpflichtung finalisieren

19.8 Abschließende Bemerkungen

Kapitel 20: Die Sprint-Ausführung

20.1 Überblick

20.1.1 Das Timing

20.1.2 Teilnehmer

20.1.3 Der Prozess

20.2 Die Planung der Sprint-Ausführung

20.3 Flow-Management

20.3.1 Parallele Arbeit und Ausschwärmen

20.3.2 Welche Arbeit begonnen werden soll

20.3.3 Wie man die Arbeit an den Aufgaben organisiert

20.3.4 Welche Arbeit muss erledigt werden?

20.3.5 Wer erledigt die Arbeit?

20.4 Daily Scrum

20.5 Die Durchführung der Aufgaben – Technische Praktiken

20.6 Kommunizieren

20.6.1 Task Board

20.6.2 Das Sprint-Burndown-Chart

20.6.3 Das Sprint-Burnup-Chart

20.7 Abschließende Bemerkungen

Kapitel 21: Sprint Review

21.1 Überblick

21.2 Teilnehmer

21.3 Vorarbeiten

21.3.1 Entscheiden, wen man einlädt

21.3.2 Die Aktivität zeitlich planen

21.3.3 Bestätigen, dass die Sprint-Arbeit erledigt ist

21.3.4 Auf die Demonstration vorbereiten

21.3.5 Festlegen, wer was macht

21.4 Das Vorgehen

21.4.1 Zusammenfassen

21.4.2 Demonstrieren

21.4.3 Diskutieren

21.4.4 Ändern

21.5 Sprint-Review-Probleme

21.5.1 Abnahmen der PBIs

21.5.2 Sporadische Teilnahme

21.5.3 Umfangreiche Entwicklungsprojekte

21.6 Abschließende Bemerkungen

Kapitel 22: Die Sprint-Retrospektive

22.1 Überblick

22.2 Teilnehmer

22.3 Die Vorarbeit

22.3.1 Den Fokus der Retrospektive definieren

22.3.2 Die Übungen auswählen

22.3.3 Objektive Daten sammeln

22.3.4 Die Retrospektive strukturieren

22.4 Das Vorgehen

22.4.1 Die Atmosphäre gestalten

22.4.2 Gemeinsamer Kontext

22.4.3 Einsichten identifizieren

22.4.4 Aktionen festlegen

22.4.5 Die Retrospektive schließen

22.5 Dranbleiben

22.6 Probleme der Sprint-Retrospektive

22.7 Abschließende Bemerkungen

Kapitel 23: Der Weg nach vorn

23.1 Es gibt keinen Endzustand

23.2 Finden Sie Ihren eigenen Weg

23.3 Best Practices mit anderen teilen

23.4 Mit Scrum den Weg nach vorn finden

23.5 Immer weiter!

Anhang A: Referenzen

Anhang B: Glossar

Stichwortverzeichnis