Scrum – verstehen und erfolgreich einsetzen

Оглавление

Henning Wolf. Scrum – verstehen und erfolgreich einsetzen

Scrum – verstehen und erfolgreich einsetzen

Vorwort. Zielgruppe dieses Buches

Über die Autoren: unsere Geschichte

Unsere Vision und Mission

Hinweise zur zweiten Auflage

Hinweise zur dritten Auflage

Danksagung

Überblick über das Buch

Lesewege

Inhaltsübersicht

Inhaltsverzeichnis

1Scrum: Historie, Vorteile, Eignung und Herausforderungen

1.1Historie. 1.1.1Scrum-Teams nach Nonaka und Takeuchi

1.1.2Erste Scrum-Projekte in der Softwareentwicklung

1.1.3Von den ersten Artikeln bis zum Scrum Guide

1.1.4Verbreitung von Scrum

1.2Vorteile von Scrum

1.2.1Kürzere Time-to-Market

1.2.2Höhere Qualität

1.2.3Größere Effizienz

1.2.4Mehr Innovation

1.2.5Größere Arbeitszufriedenheit

1.3Eignung

1.4Herausforderung: Denkweise (Mindset)

1.5Das Kapitel in Stichpunkten

2Überblick über den Scrum-Ablauf, die Verantwortungen, Meetings, Artefakte und Prinzipien

2.1Scrum-Flow

2.2Die Verantwortlichkeiten

2.2.1Product Owner

2.2.2Entwickler:innen

2.2.3Scrum Master

2.2.4Scrum-Team

2.2.5Kein Projektleiter oder Projektleiterin in Scrum

2.3Meetings (Events)

2.3.1Sprint Planning

2.3.2Daily Scrum

2.3.3Sprint-Review

2.3.4Sprint-Retrospektive

2.4Der Sprint

2.5Artefakte

2.5.1Product Backlog

2.5.2Sprint Backlog

2.5.3Lieferbares Produktinkrement

2.6Prinzipien

2.6.1Autonomes und cross-funktionales Team

2.6.2Inspect & Adapt (auch: empirisches Management)

2.6.3Timeboxing

2.6.4Return on Investment (ROI)

2.6.5Qualität einbauen

2.6.6Pull

2.6.7Bewusst unterspezifiziert

2.7Scrum-Werte

2.8Das Kapitel in Stichpunkten

3Scrum produktbezogen

3.1Produktbegriff

3.1.1Beispiel

3.1.2Der passende Produktbegriff

3.2Produktinkremente

3.3Endkund:innen

3.3.1Zielgruppen und Personas

3.3.2Personas validieren

3.4Produktvision

3.4.1Elemente der Produktvision

3.4.2Probleme/Bedürfnisse identifizieren

3.4.3Produktvision kommunizieren: Storytelling

3.4.4Weitere Hilfsmittel für Produktvisionen

3.5Die Product-Owner-Verantwortlichkeit

3.5.1Die Bedeutung von Priorisierung

3.5.2Bevollmächtigung des Product Owners

3.6Eigenschaften des Product Backlog

3.6.1Das Produktziel

3.6.2Organisation der Product Backlog Items

3.6.3Größe des Product Backlog

3.7Definition of Ready

3.8Product Backlog Board

3.8.1Überführung in den »Ready for Sprint«-Bereich

3.8.2Inhomogene Product Backlog Items

3.8.3Physikalisches Board

3.9Priorisierung

3.9.1Priorisierung nach Kosten-Wert

3.9.2Priorisierung nach Risiko-Wert

3.9.3Priorisierung mit Verzögerungskosten (Cost of Delay)

3.9.4Wert bzw. Verzögerungskosten ermitteln

3.9.5Technische Product Backlog Items mit Verzögerungskosten priorisieren

3.10Epics und User Stories

3.10.1Satzschema für User Stories

3.10.2Typische Fallen bei User Stories

3.10.2.1Nutzen wird weggelassen

3.10.2.2Akteur:in ist zu abstrakt

3.10.2.3Akteur:in ist der Anforderer oder die Anforderin

3.10.3Tipps zu User Stories

3.10.3.1Alternatives Satzschema

3.10.3.2Persona als Akteur:in

3.10.4Akzeptanzkriterien

3.10.5User Stories anhand von Akzeptanzkriterien aufspalten

3.10.6Epics

3.11Das komplette Produkt als Geschichte: Story Mapping

3.11.1Story-Map-Beispiel

3.11.2Wirkungen in Story Maps

3.12Weitere Techniken zur Anforderungsmodellierung

3.13Empirisches Management produktbezogen

3.13.1Sprint Planning und Sprint-Review

3.14Das Sprint Planning

3.14.1Pull-Prinzip im Sprint Planning

3.14.2Tasks als Plan

3.14.3Das Sprint-Ziel

3.14.3.1Finden des Sprint-Ziels

3.14.3.2Vorteile guter Sprint-Ziele

3.15Das Sprint-Review

3.15.1Transparenz: Demonstration des lieferbaren Produktinkrements

3.15.2Inspektion: Einholen von Feedback zum Produktinkrement

3.15.3Adaption: Integration des Feedbacks in das Product Backlog

3.15.3.1Zusätzliche und alternative Praktiken im Sprint-Review

3.15.4Und was ist mit der Abnahme?

3.15.5Sprint-Abbruch

3.16Backlog Refinement

3.16.1Refinement im Sprint-Review

3.16.2Refinement im Sprint Planning

3.16.3Refinement zwischen Sprint-Review und Sprint Planning

3.16.4Ad-hoc-Refinement-Meetings

3.16.5Regelmäßige Refinement-Meetings

3.16.6Refinement-Optionen im Vergleich

3.17Das Kapitel in Stichpunkten

4Entwicklung mit Scrum

4.1Entwickler:innen (Cross-Funktionalität, Autonomie, Selbstorganisation)

4.1.1Cross-Funktionalität

Was tun, wenn es für jemanden im Team nichts zu tun gibt, weil er für keine der noch anstehenden Aufgaben qualifiziert ist?

Was tun, wenn wir von einer besonders intensiv und häufig benötigten Qualifikation zu wenig haben und deswegen alle anderen nicht genug zu tun haben (während einer überlastet ist)?

4.1.2Autonomie und Selbstorganisation

4.1.3Entwickler:innen nur in einem Team

4.2Sprints

4.3Lieferbare Produktinkremente

4.3.1Definition of Done

4.4Technische Herausforderungen

4.4.1Herausforderung 1: lieferbares Produktinkrement ab dem ersten Sprint

4.4.2Herausforderung 2: inkrementelle Architekturentwicklung

4.5Sprint Planning: das »Wie«

4.5.1Aufwandsschätzung

4.5.2Story Points als Größenmaß

4.5.3Vorteile von Story Points

4.5.4Planning Poker®

4.5.5Varianten des Planning Poker®

4.5.6Erfahrungen mit Planning Poker®

4.5.7Inkrementelles Ziehen in den Sprint

4.5.8Das »Wie« im Sprint Planning: Task-Breakdown

4.5.9Architekturdiskussionen

4.5.10Was wir nicht im Sprint Planning festlegen

4.6Taskboard als Sprint Backlog

4.7Sprint-Burndown-Chart

4.8Daily Scrum

4.8.1Umgang mit Problemen im Daily Scrum

4.8.2Der Product Owner im Daily Scrum

4.8.3Hindernisbearbeitung im Daily Scrum

4.9Das Kapitel in Stichpunkten

5Kontinuierliche Verbesserung

5.1Scrum-Master-Verantwortung

5.1.1Scrum-Master-Dienste für den Product Owner

5.1.2Scrum-Master-Dienste für das Scrum-Team

5.1.3Scrum-Master-Dienste für die Organisation

5.1.4Der Scrum Master und die Entwickler:innen

5.1.5Der Scrum Master und der Product Owner

5.1.6Der Scrum Master und die Organisation

5.1.7Der Scrum Master und die Scrum-Meetings

5.1.8Haltung und Einstellung des Scrum Masters

5.1.9Braucht es einen Vollzeit-Scrum-Master?

5.1.9.1Entwickler:innen als Scrum Master

5.1.9.2Scrum Master als Entwickler oder Entwicklerin in einem anderen Scrum-Team

5.1.9.3Scrum Master für ein zusätzliches Team

5.1.9.4Der Scrum Master als Change Agent im Unternehmen

5.1.9.5Der richtige Weg für den eigenen Kontext

5.1.10Der Business Case zum Scrum Master

5.1.11Die Super-Power des Scrum Masters

5.2Team-Building

5.3Hindernisbeseitigung

5.4Retrospektiven

5.4.1Der PDCA-Zyklus

5.4.2Retrospektiven-Phasen

5.4.2.1Set the stage (die Bühne bereiten)

5.4.2.2Gather data (Daten sammeln)

5.4.2.3Generate insights (Einsichten generieren)

5.4.2.4Decide what to do (entscheiden, was zu tun ist)

5.4.2.5Closing (Abschluss)

5.4.3Moderation von Retrospektiven

5.4.4Teilnehmer:innen der Sprint-Retrospektive

5.4.5Weitere Retrospektiven

5.4.6Weitere Vertiefung

5.5Agile Werte und Prinzipien

5.5.1Das Agile Manifest

5.5.2Agile Problemlösung

5.6Das Kapitel in Stichpunkten

6Releasemanagement

6.1Grenzen der Releaseplanung

6.2Das Warum der Releaseplanung

6.2.1Rendezvous-Planung

6.2.2Beispiel: Marketing

6.2.3Investitionsmanagement

6.3Das beste Releasemanagement ist Sprint-Management

6.4Schätzung mit Story Points

6.4.1Bucket Estimation

6.5Releaseplanung

6.5.1Ermitteln der Velocity

6.5.2Probleme mit Story Points

6.5.3Alternativen zu Story Points

6.5.4Releasedauer

6.5.5Release-Container

6.6Roadmap-Planung

6.7Release-Controlling

6.7.1Release-Burndown-Bar-Charts

6.7.2Release-Burnup-Charts

6.7.3Parking-Lot-Diagramme

6.8Festpreisverträge

6.8.1Werkverträge ohne Festpreis

6.8.2Alternative Vertragsformen

6.9Das Kapitel in Stichpunkten

7Streiflicht auf fortgeschrittenes Scrum

7.1Scrum einführen

7.1.1Veränderte Verhaltensweisen

7.1.2Scrum im Unternehmen verankern

7.1.3Kulturwandel im Unternehmen

7.1.3.1Scrum Studio

7.1.3.2Autonome Business Units

7.1.4Agilität mit agilen Verfahren ausbreiten

7.1.5Globale Optimierung

7.1.6Coaching

7.1.6.1Ökonomie des Coachings

7.1.7Externe Coaches auswählen

7.1.8Interne Coaches ausbilden

7.2Scrum skalieren

7.2.1Der Agile Scaling Cycle

7.2.2Praktiken zur Reduktion von Abhängigkeiten

7.2.3Praktiken zur Koordination von Teams

7.2.4Die Organisation entwickeln

7.3Agile Unternehmen

7.4Verteiltes Scrum

7.4.1Vertrauen ist essenziell

7.4.2Entfernung

7.4.3Tools

7.5Interventionen durch Führungskräfte

7.5.1Selbstverständnis von Führungskräften

7.5.2Alignment und Autonomie

7.5.3CDE: Containers, Differences, Exchanges

7.5.3.1CDE-Beispiel

7.5.4Leadership

7.6Vertragsgestaltung für agile Entwicklung

7.6.1Scrum im Vertrag

7.6.2Werkvertrag und Festpreis vs. Dienstvertrag und Bezahlung nach Aufwand

7.6.3Flexibilität des Vertragswerks

7.6.4Kosten- vs. nutzenorientierte Verträge

7.6.5Vorgehen wichtiger als Ergebnisse

7.7Das Kapitel in Stichpunkten

AÜberblick über die Verantwortungen, Meetings und Artefakte in Scrum

A.1Scrum-Master-Aufgaben

A.1.1Teamebene

A.1.2Teamübergreifende Organisationsebene

A.1.3Anforderungsebene und Product Owner unterstützen

A.2Product-Owner-Aufgaben

A.2.1Produkteigenschaften

A.2.2Zusammenarbeit mit dem Team

A.2.3Kund:innen/Anwender:innen

A.2.4Management sonstiger Stakeholder

A.3Aufgaben der Entwickler:innen

A.3.1Arbeitsorganisation

A.3.2Technisch

A.3.3Bezogen auf Stakeholder

A.3.4Unterstützung des Product Owners

A.3.5Verbesserung

A.4Daily Scrum

A.5Sprint Planning

A.6Sprint-Review

A.7Sprint-Retrospektive

A.8Backlog Refinement

A.9Releaseplanung

A.10Product Backlog

A.11Sprint Backlog

A.12Produktinkrement

A.13Sprint-Burndown-Chart

A.14Release-Burnup-Chart

BLiteratur

Index

Fußnoten. 1 Scrum: Historie, Vorteile, Eignung und Herausforderungen

2 Überblick über den Scrum-Ablauf, die Verantwortungen, Meetings, Artefakte und Prinzipien

3 Scrum produktbezogen

4 Entwicklung mit Scrum

5 Kontinuierliche Verbesserung

6 Releasemanagement

7 Streiflicht auf fortgeschrittenes Scrum

A Überblick über die Verantwortungen, Meetings und Artefakte in Scrum

Отрывок из книги

Dipl.-Inform. Henning Wolf ist Mitgründer, Trainer und Leadership-Coach bei it-agile in Hamburg. Er hat seit Ende der 90er Erfahrungen mit agilen Ansätzen. Die Verbreitung in Deutschland befördert er mit Engagement, diversen Artikeln, Büchern und Konferenzbeiträgen. Sein aktuelles Steckenpferd ist The Responsibility Process™. Sein Antrieb: Raus aus der Mittelmäßigkeit, hin zu mehr Endkunden- und Mitarbeiterbegeisterung.

Stefan Roock ist Gründungsmitglied der it-agile GmbH. Ihm ist es in seiner Beratungstätigkeit wichtig, dass sich wirklich etwas ändert – hin zu erfolgreichen Unternehmen mit zufriedenen Mitarbeitern, die sich immer neuen Herausforderungen stellen. Stefan hat seit 1999 die Verbreitung agiler Ansätze in Deutschland maßgeblich mit beeinflusst. Er ist regelmäßiger Sprecher zu agilen Themen auf Konferenzen, schreibt Zeitschriftenartikel und hat mehrere Bücher veröffentlicht.

.....

4.5.10 Was wir nicht im Sprint Planning festlegen

4.6 Taskboard als Sprint Backlog

.....