Scrum – verstehen und erfolgreich einsetzen E-Book

Stefan Roock

• Herausgeber: dpunkt.verlag
• Kategorie: Fachliteratur
• Sprache: Deutsch

Seitenzahl: 350

Veröffentlichungsjahr: 2025

Beschreibung

Das ultimative Scrum-Handbuch¶•didaktisch sehr gut aufgebautes Grundlagenbuch¶•mit Empfehlungen der Autoren aus der Praxis für die Praxis¶•geeignet auch für Scrum-Zertifizierungskurse: Scrum Basics, Certified Scrum Master¶Scrum dient dem agilen Management innovativer Produktentwicklung mit selbstorganisierten Teams. Mit seinem iterativ-inkrementellen Ansatz führt Scrum zu mehr Transparenz und Flexibilität als klassische sequenzielle Entwicklungsmethoden.¶Die Autoren beschreiben in kompakter Form die Scrum-Grundlagen und die hinter Scrum stehenden Werte und Prinzipien. Dabei unterscheiden sie zwischen den produktbezogenen Aspekten, den entwicklungsbezogenen Aspekten und dem kontinuierlichen Verbesserungsprozess.¶Im Einzelnen werden behandelt: die Scrum-Historie sowie Vorteile und Eignung von Scrum, der Scrum-Flow und die verschiedenen Verantwortlichkeiten in Scrum (Product Owner, Entwickler:innen, Scrum Master, Scrum-Team), die Scrum-Meetings (Sprint Planning, Daily Scrum, Sprint-Review, Sprint-Retrospektive), Artefakte (Product Backlog, Sprint Backlog, lieferbares Produktinkrement), Releasemanagement und Schätzverfahren sowie die Einführung von Scrum im Unternehmen, Scrum-Skalierung, verteiltes Scrum, Vertragsgestaltung für agile Entwicklung und Leadership.¶Im Anhang werden die Elemente des Scrum-Frameworks sowie einige sehr häufig anzutreffende Praktiken noch einmal in Kurzform dargestellt.¶Die 4. Auflage wurde mit weiteren Praxistipps und in vielen einzelnen Aspekten ergänzt.

Leseprobe

Hinweise zur Benutzung

Dieses E-Book ist urheberrechtlich geschützt. Mit dem Erwerb des E-Books haben Sie sich verpflichtet, die Urheberrechte anzuerkennen und einzuhalten. Sie sind berechtigt, dieses E-Book für persönliche Zwecke zu nutzen. Sie dürfen es auch ausdrucken und kopieren, aber auch dies nur für den persönlichen Gebrauch. Die Weitergabe einer elektronischen oder gedruckten Kopie an Dritte ist dagegen nicht erlaubt, weder ganz noch in Teilen. Und auch nicht eine Veröffentlichung im Internet oder in einem Firmennetzwerk.

Copyright-Vermerk

Das vorliegende Werk ist in all seinen Teilen urheberrechtlich geschützt. Alle Nutzungs- und Verwertungsrechte liegen bei den Autor*innen und beim Rheinwerk Verlag, insbesondere das Recht der Vervielfältigung und Verbreitung, sei es in gedruckter oder in elektronischer Form.

© Rheinwerk Verlag GmbH, Bonn 2026

Nutzungs- und Verwertungsrechte

Sie sind berechtigt, dieses E-Book ausschließlich für persönliche Zwecke zu nutzen. Insbesondere sind Sie berechtigt, das E-Book für Ihren eigenen Gebrauch auszudrucken oder eine Kopie herzustellen, sofern Sie diese Kopie auf einem von Ihnen alleine und persönlich genutzten Endgerät speichern. Zu anderen oder weitergehenden Nutzungen und Verwertungen sind Sie nicht berechtigt.

So ist es insbesondere unzulässig, eine elektronische oder gedruckte Kopie an Dritte weiterzugeben. Unzulässig und nicht erlaubt ist des Weiteren, das E-Book im Internet, in Intranets oder auf andere Weise zu verbreiten oder Dritten zur Verfügung zu stellen. Eine öffentliche Wiedergabe oder sonstige Weiterveröffentlichung und jegliche den persönlichen Gebrauch übersteigende Vervielfältigung des E-Books ist ausdrücklich untersagt. Das vorstehend Gesagte gilt nicht nur für das E-Book insgesamt, sondern auch für seine Teile (z. B. Grafiken, Fotos, Tabellen, Textabschnitte).

Urheberrechtsvermerke, Markenzeichen und andere Rechtsvorbehalte dürfen aus dem E-Book nicht entfernt werden.

Die automatisierte Analyse des Werkes, um daraus Informationen insbesondere über Muster, Trends und Korrelationen gemäß § 44b UrhG (»Text und Data Mining«) zu gewinnen, ist untersagt.

Markenschutz

Die in diesem Werk wiedergegebenen Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. können auch ohne besondere Kennzeichnung Marken sein und als solche den gesetzlichen Bestimmungen unterliegen.

Haftungsausschluss

Ungeachtet der Sorgfalt, die auf die Erstellung von Text, Abbildungen und Programmen verwendet wurde, können weder Verlag noch Autor*innen, Herausgeber*innen oder Übersetzer*innen für mögliche Fehler und deren Folgen eine juristische Verantwortung oder irgendeine Haftung übernehmen.

Stefan Roock · Henning Wolf

Scrum – verstehen und erfolgreich einsetzen

4., überarbeitete und erweiterte Auflage

Wir hoffen, dass Sie Freude an diesem Buch haben und sich Ihre Erwartungen erfüllen. Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Informationen zu unserem Verlag und Kontaktmöglichkeiten finden Sie auf unserer Verlagswebsite www.dpunkt.de. Dort können Sie sich auch umfassend über unser aktuelles Programm informieren und unsere Bücher und E-Books bestellen.

Autor: Stefan Roock, Henning Wolf

Lektorat: Stephan Mattescheck, Christa Preisendanz

Buchmanagement: Julia Griebel

Copy-Editing: Roman Lehnhof

Satz: mediaService, Gerhard Alfes, Siegen

Herstellung: Stefanie Weidner, Frank Heidt

Covergestaltung: Eva Hepper, Silke Braun

Foto-Credit: Adobe Stock: 192301067©Robert Kneschke

Das vorliegende Werk ist in all seinen Teilen urheberrechtlich geschützt. Alle Rechte vorbehalten, insbesondere das Recht der Übersetzung, des Vortrags, der Reproduktion, der Vervielfältigung auf fotomechanischen oder anderen Wegen und der Speicherung in elektronischen Medien.

Ungeachtet der Sorgfalt, die auf die Erstellung von Text, Abbildungen und Programmen verwendet wurde, können weder Verlag noch Autor*innen, Herausgeber*innen oder Übersetzer*innen für mögliche Fehler und deren Folgen eine juristische Verantwortung oder irgendeine Haftung übernehmen.

Die in diesem Werk wiedergegebenen Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. können auch ohne besondere Kennzeichnung Marken sein und als solche den gesetzlichen Bestimmungen unterliegen.

Die automatisierte Analyse des Werkes, um daraus Informationen insbesondere über Muster, Trends und Korrelationen gemäß § 44b UrhG (»Text und Data Mining«) zu gewinnen, ist untersagt.

Bibliografische Information der Deutschen Nationalbibliothek:

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.dnb.de abrufbar.

ISBN Print: 978-3-98889-052-8

ISBN PDF: 978-3-98890-304-4

ISBN ePub: 978-3-98890-305-1

4., überarbeitete und erweiterte Auflage 2026

dpunkt.verlag ist eine Marke des Rheinwerk Verlags.

© Rheinwerk Verlag, Bonn 2026

Rheinwerk Verlag GmbH • Rheinwerkallee 4 • 53227 Bonn

[email protected]

Inhaltsverzeichnis

Vorwort

Zielgruppe dieses Buches

Über die Autoren: unsere Geschichte

Unsere Vision und Mission

Hinweise zur zweiten Auflage

Hinweise zur dritten Auflage

Hinweise zur vierten Auflage

Danksagung

Überblick über das Buch

Lesewege

1

Scrum: Historie, Vorteile, Eignung und Herausforderungen

1.1

Historie

1.1.1

Scrum-Teams nach Nonaka und Takeuchi

1.1.2

Erste Scrum-Projekte in der Softwareentwicklung

1.1.3

Von den ersten Artikeln bis zum Scrum Guide

1.1.4

Verbreitung von Scrum

1.2

Vorteile von Scrum

1.2.1

Kürzere Time-to-Market

1.2.2

Höhere Qualität

1.2.3

Größere Effizienz

1.2.4

Mehr Innovation

1.2.5

Größere Arbeitszufriedenheit

1.3

Eignung

1.4

Herausforderung: Denkweise (Mindset)

1.5

Das Kapitel in Stichpunkten

2

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

2.1

Scrum-Flow

2.2

Die Verantwortlichkeiten

2.2.1

Product Owner

2.2.2

Entwickler

2.2.3

Scrum Master

2.2.4

Scrum-Team

2.2.5

Kein Projektleiter in Scrum

2.3

Meetings (Events)

2.3.1

Sprint Planning

2.3.2

Daily Scrum

2.3.3

Sprint-Review

2.3.4

Sprint-Retrospektive

2.4

Der Sprint

2.5

Artefakte

2.5.1

Product Backlog

2.5.2

Sprint Backlog

2.5.3

Lieferbares Produktinkrement

2.6

Prinzipien

2.6.1

Autonomes und cross-funktionales Team

2.6.2

Inspect & Adapt (auch: empirisches Management)

2.6.3

Timeboxing

2.6.4

Return on Investment (ROI)

2.6.5

Qualität einbauen

2.6.6

Pull

2.6.7

Bewusst unterspezifiziert

2.7

Scrum-Werte

2.8

Das Kapitel in Stichpunkten

3

Scrum produktbezogen

3.1

Produktbegriff

3.1.1

Beispiel

3.1.2

Der passende Produktbegriff

3.2

Produktinkremente

3.3

Endkunden

3.3.1

Zielgruppen und Personas

3.3.2

Personas validieren

3.4

Produktvision

3.4.1

Elemente der Produktvision

3.4.2

Probleme/Bedürfnisse identifizieren

3.4.3

Produktvision kommunizieren: Storytelling

3.4.4

Weitere Hilfsmittel für Produktvisionen

3.5

Die Product-Owner-Verantwortlichkeit

3.5.1

Abhängige Produkte und Plattformen

3.5.2

Die Bedeutung von Priorisierung

3.5.3

Bevollmächtigung des Product Owners

3.6

Eigenschaften des Product Backlog

3.6.1

Das Produktziel und Business Stories

3.6.2

Organisation der Product Backlog Items

3.6.3

Größe des Product Backlog

3.7

Definition of Ready

3.8

Struktur des Product Backlog

3.8.1

Ergänzungen des Product Backlog

3.8.2

Inhomogene Product Backlog Items

3.8.3

Physikalische und elektronische Boards

3.9

Priorisierung

3.9.1

Priorisierung nach Kosten und Wert

3.9.2

Priorisierung nach Risiko und Wert

3.9.3

Priorisierung mit Verzögerungskosten (Cost of Delay)

3.9.4

Wert bzw. Verzögerungskosten ermitteln

3.9.5

Technische Product Backlog Items mit Verzögerungskosten priorisieren

3.10

Epics und User Stories

3.10.1

Satzschema für User Stories

3.10.2

Typische Fallen bei User Stories

3.10.3

Tipps zu User Stories

3.10.4

Akzeptanzkriterien

3.10.5

User Stories anhand von Akzeptanzkriterien aufspalten

3.10.6

Epics

3.11

Das komplette Produkt als Geschichte: Story Mapping

3.11.1

Story-Map-Beispiel

3.11.2

Wirkungen in Story Maps

3.11.3

Wirkungen als Business Stories, Ersatz für Epics

3.12

Weitere Techniken zur Anforderungsmodellierung

3.13

Empirisches Management produktbezogen

3.13.1

Sprint Planning und Sprint-Review

3.14

Das Sprint Planning

3.14.1

Pull-Prinzip im Sprint Planning

3.14.2

Tasks als Plan

3.14.3

Das Sprint-Ziel

3.15

Das Sprint-Review

3.15.1

Transparenz: Demonstration des lieferbaren Produktinkrements

3.15.2

Inspektion: Einholen von Feedback zum Produktinkrement

3.15.3

Adaption: Integration des Feedbacks in das Product Backlog

3.15.4

Und was ist mit der Abnahme?

3.15.5

Sprint-Abbruch

3.16

Backlog Refinement

3.16.1

Refinement im Sprint-Review

3.16.2

Refinement im Sprint Planning

3.16.3

Refinement zwischen Sprint-Review und Sprint Planning

3.16.4

Ad-hoc-Refinement-Meetings

3.16.5

Regelmäßige Refinement-Meetings

3.16.6

Refinement-Optionen im Vergleich

3.17

Das Kapitel in Stichpunkten

4

Entwicklung mit Scrum

4.1

Entwickler (Cross-Funktionalität, Autonomie, Selbstorganisation)

4.1.1

Cross-Funktionalität

4.1.2

Autonomie und Selbstorganisation

4.1.3

Entwickler nur in einem Team

4.2

Sprints

4.3

Lieferbare Produktinkremente

4.3.1

Definition of Done

4.4

Technische Herausforderungen

4.4.1

Herausforderung 1: lieferbares Produktinkrement ab dem ersten Sprint

4.4.2

Herausforderung 2: inkrementelle Architekturentwicklung

4.5

Sprint Planning: das »Wie«

4.5.1

Umfang: Forecast für den Sprint

4.5.2

Inkrementelles Ziehen in den Sprint

4.5.3

T-Shirt-Größen

4.5.4

Story Points als Größenmaß

4.5.5

Vorteile von Story Points

4.5.6

Planning Poker

®

4.5.7

Varianten des Planning Poker

®

4.5.8

Erfahrungen mit Story Points und Planning Poker

®

4.5.9

Aufwandsschätzung in Personentagen

4.5.10

Das »Wie« im Sprint Planning: Task-Breakdown

4.5.11

Architekturdiskussionen

4.5.12

Was wir nicht im Sprint Planning festlegen

4.6

Taskboard als Sprint Backlog

4.7

Sprint-Burndown-Chart

4.8

Daily Scrum

4.8.1

Umgang mit Problemen im Daily Scrum

4.8.2

Der Product Owner im Daily Scrum

4.8.3

Hindernisbearbeitung im Daily Scrum

4.9

Das Kapitel in Stichpunkten

5

Kontinuierliche Verbesserung

5.1

Scrum-Master-Verantwortung

5.1.1

Scrum-Master-Dienste für den Product Owner

5.1.2

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

5.1.3

Scrum-Master-Dienste für die Organisation

5.1.4

Der Scrum Master und die Entwickler

5.1.5

Der Scrum Master und der Product Owner

5.1.6

Der Scrum Master und die Organisation

5.1.7

Der Scrum Master und die Scrum-Meetings

5.1.8

Haltung und Einstellung des Scrum Masters

5.1.9

Braucht es einen Vollzeit-Scrum-Master?

5.1.10

Der Business Case zum Scrum Master

5.1.11

Die Super-Power des Scrum Masters

5.2

Team-Building

5.3

Hindernisbeseitigung

5.4

Retrospektiven

5.4.1

Der PDCA-Zyklus

5.4.2

Retrospektiven-Phasen

5.4.3

Moderation von Retrospektiven

5.4.4

Teilnehmer der Sprint-Retrospektive

5.4.5

Weitere Retrospektiven

5.4.6

Weitere Vertiefung

5.5

Agile Werte und Prinzipien

5.5.1

Das Agile Manifest

5.5.2

Agile Problemlösung

5.6

Scrum-Master-Reife

5.7

Das Kapitel in Stichpunkten

6

Große Vorhaben

6.1

Grenzen der Planung

6.2

Das »Warum« großer Vorhaben

6.2.1

Rendezvous-Planung

6.2.2

Beispiel: Marketing

6.2.3

Investitionsmanagement

6.3

Planung großer Vorhaben vermeiden

6.4

Schätzung mit Story Points

6.4.1

Bucket Estimation

6.5

Gesamtplanung

6.5.1

Ermitteln der Velocity

6.5.2

Probleme mit Story Points

6.5.3

Alternativen zu Story Points

6.5.4

Dauer großer Vorhaben

6.5.5

Zeitliche Container

6.6

Roadmap-Planung

6.7

Controlling großer Vorhaben

6.7.1

Burndown-Bar-Charts

6.7.2

Burnup-Charts

6.7.3

Parking-Lot-Diagramme

6.8

Festpreisverträge

6.8.1

Werkverträge ohne Festpreis

6.8.2

Alternative Vertragsformen

6.9

Das Kapitel in Stichpunkten

7

Streiflicht auf fortgeschrittenes Scrum

7.1

Scrum einführen

7.1.1

Veränderte Verhaltensweisen

7.1.2

Scrum im Unternehmen verankern

7.1.3

Kulturwandel im Unternehmen

7.1.4

Agilität mit agilen Verfahren ausbreiten

7.1.5

Globale Optimierung

7.1.6

Coaching

7.1.7

Externe Coaches auswählen

7.1.8

Interne Coaches ausbilden

7.2

Scrum mit mehreren Teams

7.2.1

Der Agile Descaling Cycle

7.2.2

Praktiken zur Reduktion von Abhängigkeiten

7.2.3

Praktiken zur Koordination von Teams

7.2.4

Innovative agile Teamkonzepte

7.3

Agile Unternehmen

7.4

OKR: Objectives and Key Results

7.5

Verteiltes Scrum

7.5.1

Vertrauen ist essenziell

7.5.2

Tools

7.6

Interventionen durch Führungskräfte

7.6.1

Selbstverständnis von Führungskräften

7.6.2

Alignment und Autonomie

7.6.3

CDE: Containers, Differences, Exchanges

7.6.4

Leadership

7.6.5

Self-Leadership

7.7

Vertragsgestaltung für agile Entwicklung

7.7.1

Scrum im Vertrag

7.7.2

Werkvertrag und Festpreis vs. Dienstvertrag und Bezahlung nach Aufwand

7.7.3

Flexibilität des Vertragswerks

7.7.4

Kosten- vs. nutzenorientierte Verträge

7.7.5

Vorgehen wichtiger als Ergebnisse

7.8

Künstliche Intelligenz

7.9

Das Kapitel in Stichpunkten

Anhang

A

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

A.1

Scrum-Master-Aufgaben

A.1.1

Teamebene

A.1.2

Teamübergreifende Organisationsebene

A.1.3

Anforderungsebene und Product Owner unterstützen

A.2

Product-Owner-Aufgaben

A.2.1

Produkteigenschaften

A.2.2

Zusammenarbeit mit dem Team

A.2.3

Kunden/Anwender

A.2.4

Management sonstiger Stakeholder

A.3

Aufgaben der Entwickler

A.3.1

Arbeitsorganisation

A.3.2

Technisch

A.3.3

Bezogen auf Stakeholder

A.3.4

Unterstützung des Product Owners

A.3.5

Verbesserung

A.4

Daily Scrum

A.5

Sprint Planning

A.6

Sprint-Review

A.7

Sprint-Retrospektive

A.8

Backlog Refinement

A.9

Gesamtplanung

A.10

Product Backlog

A.11

Sprint Backlog

A.12

Produktinkrement

A.13

Sprint-Burndown-Chart

A.14

Burnup-Chart

Literatur

Index

Vorwort

Zielgruppe dieses Buches

Der Einsatz von Scrum kann eine Reihe von Vorteilen mit sich bringen: schnellere Entwicklung, höhere Qualität, werthaltigere Features, innovativere Produkte, zufriedenere Kunden und glücklichere Mitarbeiter. Vielleicht sehen Sie Probleme in diesen Bereichen in Ihrer Softwareentwicklung. Vielleicht sehen Sie auch das Problem noch gar nicht, sollen aber Scrum ausprobieren, weil jemand anders ein Problem sieht oder sich Scrum zum Industriestandard zu entwickeln scheint.

Dann fragen Sie sich wahrscheinlich, ob Scrum Ihr Problem lösen kann und was es bedeuten würde, Scrum anzuwenden. Dieses Buch adressiert dieses Bedürfnis, indem es die Scrum-Grundlagen und die hinter Scrum stehenden Werte und Prinzipien vermittelt.

Dieses Buch richtet sich an Sie, wenn Sie verstehen wollen, wie Scrum funktioniert und wie Scrum zu den oben genannten Effekten führt.

Typische Leserinnen und Leser werden im Projektmanagement, Produktmanagement, in der Entwicklung und im unteren bis mittleren Management tätig sein. Die meisten werden aus Softwarekontexten kommen. Scrum lässt sich allerdings auch in anderen Kontexten wie Hardwareentwicklung oder Dienstleistungen anwenden.

Über die Autoren: unsere Geschichte

Unsere gemeinsame Geschichte beginnt im Kindergarten, trennt sich für die ersten sechs Schuljahre und ist seitdem eine parallele professionelle Karriere – von unseren ersten Spieleentwicklungen in der Mitte der 80er, dem Beginn des Informatikstudiums 1990, einem anschließenden Abstecher als wissenschaftliche Mitarbeiter an der Universität Hamburg, vielen gemeinsamen Entwicklungs- und Beratungsprojekten bis hin zur Gründung von it-agile Ende 2004.

Wir sind Ende der 90er an der Uni an eXtreme Programming (XP) geraten, eine von Kent Beck beschriebene agile Methode. Man sagte damals noch nicht »agil«, sondern »leichtgewichtig«. Wir waren begeistert, und wir waren sehr erfolgreich mit unseren XP-Projekten. Schon vor der Gründung von it-agile wuchs das Interesse auch an anderen agilen Methoden, insbesondere an Scrum.

Unsere Begeisterung ging so weit, dass wir unsere damaligen Jobs kündigten, weil wir uns nur noch mit agiler Entwicklung beschäftigen wollten. So gründeten wir zusammen mit anderen Kollegen Ende 2004 it-agile. Es erschien uns nur folgerichtig, die Firma selbst auch nach agilen Grundsätzen zu organisieren.

Heute schauen wir auf Erfahrungen als agile Entwickler, als klassische und agile Projektleiter, als Scrum Master und Product Owner sowie als Berater, Coaches und Trainer zurück. Wir sind beide Certified Scrum Trainer und Certified Agile Leadership Educator der Scrum Alliance und geben unser Wissen und unsere Erfahrungen auf vielfältige Art und Weise weiter: in Schulungen, bei der Beratung, durch Vorträge auf Konferenzen und User-Group-Treffen, durch das Schreiben von Artikeln und nicht zuletzt in Form dieses Buches.

Unsere Vision und Mission

Als wir Anfang der 2000er-Jahre agil Software entwickelten, hatten wir den besten Job überhaupt. Wir arbeiteten in motivierten selbstorganisierten Teams, übernahmen Verantwortung, lieferten wertvolle Software für Anwender und bekamen entsprechendes Feedback.

Nicht nur wir empfanden so. Viele der Entwickler in den Unternehmen, die wir bei der Einführung von Scrum und XP unterstützten, äußerten sich ähnlich. Und das Management und die Kunden dieser Unternehmen hatten das beste Team überhaupt.

Die Stimmungslage hat sich im Laufe der Jahre leider geändert. Heute hören wir häufig: »Mit Scrum ist es immerhin nicht mehr so schlimm wie früher.« Grauenvoll! Das ist uns zu wenig! Wir wissen, dass es besser geht. Wir haben es erlebt.

Scrum ist nicht einfach eine zusätzliche Projektmanagementmethode. Es ist nichts, was angepasst werden muss, damit es in den Konzern passt. Scrum ist eine Geisteshaltung (engl. mindset): Wir sind offen für Neues und Fehlschläge, wir experimentieren, wir verbessern kontinuierlich, wir lernen, wir vertrauen, wir sind mutig, wir finden uns nicht mit dem Status quo ab. An dieser Einstellung gibt es nichts anzupassen. Es ist nur die Frage zu klären, ob man eine solche Geisteshaltung im Unternehmen will oder nicht. Und wenn man sich dafür entscheidet, muss man das Unternehmen an diese Geisteshaltung anpassen. Punkt.

Unsere Vision ist eine Welt, in der Teams und Kunden vertrauensvoll und kooperativ zusammenarbeiten, um coole Produkte zu entwickeln, in der Entwickler erfüllt arbeiten können und gleichzeitig ihre Unternehmen erfolgreich sind.

Das wird nur gelingen, wenn wir auf Wirkungen und nicht nur auf Ergebnisse fokussieren. Das entwickelte Produkt ist ein Ergebnis. Und das entwickeln wir natürlich nicht zum Selbstzweck, sondern weil sich dadurch etwas zum Besseren ändern soll. Wir wollen etwas bewirken, normalerweise für die Kunden der Produkte und für unser Unternehmen (siehe äußerer Ring in Abbildung 1).

Abb.

1

Ergebnisse als Mittel zum Zweck, um Wirkungen zu erzielen

Die Kunden sollen in die Lage versetzt werden, etwas zu tun, was sie vorher so nicht tun konnten. Und gleichzeitig wollen wir als Unternehmen auch eine positive Wirkung spüren: größere Kundenzufriedenheit und -loyalität, höhere Umsätze, geringere Kosten etc.

Wie schnell welche Ergebnisse erzielt werden können (die dann hoffentlich zu den Wirkungen führen) hängt maßgeblich von der Leistungsfähigkeit des Teams ab (innerer Kreis in Abbildung 1). Die Leistungsfähigkeit des Teams setzt sich zusammen aus der Leistungsfähigkeit der Individuen im Team, der Art ihrer Zusammenarbeit und der Einbettung in den Kontext. Auch hier gilt, dass wir nicht beliebig in die Leistungsfähigkeit des Teams investieren, sondern ausgehend von den gewünschten Wirkungen gezielt die Leistungsfähigkeit verbessern.

Und letztlich muss sich Agilität im Allgemeinen und Scrum im Speziellen daran messen lassen, dass sich diese Wirkungen für Kunden und das eigene Unternehmen auch einstellen.

Wir wollen mit diesem Buch einen Beitrag zu dieser Vision leisten. Wir verfolgen die Mission, neben der Scrum-Mechanik auch den dazugehörenden Geist zu vermitteln: das Gefühl, das sich einstellt, wenn man wirklich mit und in Scrum arbeitet. Solange sich dieses »Mensch, ist das cool!«-Gefühl nicht einstellt, ist es noch nicht so, wie es sein soll.

Hinweise zur zweiten Auflage

Das Scrum-Framework hat sich als sehr stabil erwiesen. Was sich weiterentwickelt, ist unser Verständnis davon, welche zusätzlichen Konzepte und Techniken nützlich sind und wie Scrum didaktisch gut aufbereitet werden kann.

Die zweite Auflage dieses Buches ist unserem weiterentwickelten Verständnis geschuldet. Konkret haben wir die folgenden Änderungen und Erweiterungen vorgenommen:

■

Wir haben das Buch an die neue Fassung des

Scrum Guide

vom November 2017 angepasst.

■

Selbstorganisierte Teams, die

Probleme von Endkunden lösen

, haben wir als agilen Kernzyklus integriert und an verschiedenen Stellen zur Veranschaulichung verwendet.

■

Wir haben das Thema

Produktvision

in

Kapitel 3

stärker ausgearbeitet und insbesondere den Aspekt des Storytelling in diesem Zusammenhang thematisiert.

■

Story Mapping

verbreitet sich als Produktkonzeptionstechnik immer weiter. Wir haben daher eine Kurzeinführung in das Story Mapping in

Kapitel 3

ergänzt.

■

Ein häufiges Missverständnis zum

Sprint-Review

besteht in dem Glauben, dass es sich um ein Abnahmemeeting handelt. Dieses Missverständnis greifen wir jetzt explizit beim Sprint-Review in

Kapitel 3

auf.

■

Die Ansätze zur Aufwandsschätzung haben sich über die letzten Jahre weiterentwickelt. Entsprechend haben wir in

Kapitel 6

das Thema

Lean Forecasting

aufgenommen.

■

In vielen Unternehmen wird mit

Roadmaps

gearbeitet.

Kapitel 6

beschreibt, wie die agilen Ansätze leichtgewichtig so erweitert werden können, dass zielorientierte Roadmaps entstehen.

■

Mit der steigenden Verbreitung von Scrum wird auch immer häufiger im Auftraggeber-Dienstleister-Verhältnis agil gearbeitet.

Kapitel 7

gibt einen Überblick über mögliche

Vertragsgestaltungen

.

Hinweise zur dritten Auflage

Die vorliegende dritte Auflage dieses Buches weist die folgenden Änderungen und Erweiterungen auf:

■

Wir haben das Buch an die neue Fassung des

Scrum Guide

vom November 2020 angepasst. Die wesentlichen Änderungen:

■

Es wird nicht mehr von Rollen, sondern von Verantwortlichkeiten gesprochen. Dies macht Scrum als Rahmenwerk für Produktentwicklung noch flexibler, weil die Wahrnehmung der Verantwortlichkeiten eben nicht zwingend exklusiv mit der entsprechenden Rolle einhergehen muss.

■

Es gibt nur noch das Scrum-Team und kein Entwicklungsteam mehr. Mit der Einführung des Scrum-Teams bereits in früheren Versionen des Scrum Guide sollte die Gemeinsamkeit aller Beteiligten und insbesondere ihre gemeinsame Verantwortung gestärkt werden – gleichzeitig entstand eine begriffliche Verwirrung, weil es plötzlich zwei Teams gab, nämlich das Scrum-Team und das Entwicklungsteam. Das ist jetzt klarer.

■

Das Produktziel wurde als Teil des Product Backlog aufgenommen. Die Einführung des Produktziels ist eine Analogie zum Sprint-Ziel für das Sprint-Backlog und klärt die Verwirrung vieler Scrum-Teams, ob denn eine Produktvision oder Ähnliches für die Produktentwicklung nach Scrum nötig ist.

■

Wir haben noch mal stärker verdeutlicht, dass es darum geht, Wirkungen zu erzielen, und dass das Produkt (das Ergebnis) nur Mittel zum Zweck ist.

Hinweise zur vierten Auflage

■

Bei der Beschreibung der Produktinkremente haben wir die inkrementelle Denkweise stärker herausgestellt und mit der Technik des

Dimensional Planning

plastischer gemacht.

■

Wir haben ein

Produktmodell

integriert, das hilft, umfangreiche Produktportfolios zu strukturieren.

■

Business Stories

als mögliche Vergegenständlichung der Produktziele schaffen ein wirkungsorientiertes Bindeglied zwischen Produktvision und Product Backlog.

■

Wir haben die Beschreibung zur

Struktur des Product Backlogs

aktualisiert und geben ein vollständigeres Bild der Einbettung in Wünsche der Stakeholder und den Weg zum Produktinkrement.

■

Im Abschnitt zur Sprint-Planung haben wir die Verfahren zum Abschätzen des Sprint-Umfangs überarbeitet und die Empfehlung, leichtgewichtige Verfahren zu verwenden, noch deutlicher dargestellt.

■

Im Kapitel zur kontinuierlichen Verbesserung haben wir das

Intro

klarer dargestellt und eine Diskussion um

Scrum-Master-Reife

und die passende Besetzung der Verantwortung aufgenommen.

■

Wir haben Titel und Begrifflichkeit von

Kapitel 6

zu großen Vorhaben geändert. Bisher haben wir von

Release-Management

gesprochen. Bei einigen Unternehmen hat der Begriff aber nur eine technische Assoziation (was muss mechanisch passieren, damit eine fertiggestellte Produktversion ausgeliefert werden kann). Wir hoffen, durch die geänderte Begrifflichkeit Missverständnisse zu reduzieren.

■

Im Kapitel zu fortgeschrittenem Scrum haben wir in der Diskussion um die Arbeit mit mehreren Teams eine kurze Darstellung innovativer

Teamkonzepte

abseits des Mainstreams aufgenommen. Außerdem haben wir in diesem Kapitel die Scrum-Integration von

OKR

und

KI

ergänzt. Des Weiteren haben wir die Abschnitte zu verteilter Arbeit und Tools modernisiert und im Abschnitt zu Leadership das

Self-Leadership

ergänzt.

Danksagung

Wir haben sehr viel Glück gehabt, dass wir so vielen verschiedenen Menschen begegnet sind, mit denen wir gemeinsam agile Erfahrungen sammeln durften oder uns über agile Methoden und insbesondere Scrum austauschen konnten. Dazu gehören unsere aktuellen und ehemaligen Kollegen und Kolleginnen der it-agile GmbH.

Aber auch unseren Kunden verdanken wir enorm viel. Sie haben sich mit uns auf den Scrum-Weg eingelassen, haben mit uns gemeinsam Hindernisse überwunden und Erfolge gefeiert. Viele von ihnen sind unsere Freunde geworden.

Die Scrum-Community lebt vom gegenseitigen Austausch. Einen solchen Austausch mit anderen Scrum-Trainern und -Coaches pflegen wir auch seit Langem, und wir sind froh, dass wir uns gemeinsam und nicht in Konkurrenz weiterentwickeln.

Dem dpunkt.verlag und insbesondere unseren Lektoren Christa Preisendanz und Stephan Mattescheck danken wir für das Vertrauen in unser Können und für die steten Ermunterungen, unsere Erfahrungen auch in Buchform zu teilen.

Unser Dank gilt aber auch vielen anderen, die hier nicht erwähnt wurden, und die uns das hoffentlich nicht übel nehmen. So viele Menschen haben uns beeinflusst und beeindruckt. Dazu gehören auch die Leserinnen und Leser der vorigen Auflagen dieses Buches, die uns Feedback gegeben haben, sowie die vielen Teilnehmerinnen und Teilnehmer unserer Scrum-Schulungen.

Zum Schluss gebührt noch ein besonderer Dank Ihnen, unserem werten Leser oder unserer werten Leserin: Für Sie haben wir dieses Buch geschrieben. Danke, dass Sie es lesen. Wir freuen uns über jegliches Feedback zum Buch. Schreiben Sie uns gerne unter folgender Adresse: [email protected]

Hamburg

Stefan Roock, Henning Wolf

Überblick über das Buch

Dieses Buch hat einen etwas ungewöhnlichen Aufbau. Wir betrachten nicht die Scrum-Verantwortungen, -Meetings und -Artefakte nacheinander. Stattdessen unterscheiden wir zwischen den produktbezogenen Aspekten, den entwicklungsbezogenen Aspekten und dem kontinuierlichen Verbesserungsprozess. Wir glauben, dass so das Scrum-Mindset am besten sichtbar wird. Wir nehmen dafür in Kauf, dass es leichte Überschneidungen gibt. (Vor allem das Sprint Planning hat sowohl produktbezogene als auch entwicklungsbezogene Anteile.)

Wir beginnen in Kapitel 1 jedoch zuerst mit der Scrum-Historie. Zum Verständnis der Scrum-Mechanik ist dieses Kapitel nicht notwendig. Der Blick auf die Ursprünge von Scrum ist aber sehr hilfreich, um grundlegende Scrum-Prinzipien zu verstehen, insbesondere cross-funktionale, autonome Scrum-Teams.

Kapitel 2 liefert einen Überblick über Scrum: die Verantwortungen, die Meetings, die Artefakte, zusammengehalten durch den sogenannten Scrum-Flow. Dieses Kapitel reicht bereits aus, um einen Eindruck von der Scrum-Funktionsweise zu erhalten.

Die produktbezogene Perspektive auf Scrum nimmt Kapitel 3 ein. Hier werden das Produktinkrement, der Product Owner, die Produktziele, das Product Backlog, Wertschöpfung, Priorisierung, Sprint Planning und Sprint-Review thematisiert. In diesem Rahmen werden Personas, Business Stories, User Stories, Epics, Story Mapping, verschiedene Priorisierungstechniken und das Backlog Refinement als hilfreiche Werkzeuge eingeführt.

Kapitel 4 widmet sich den entwicklungsbezogenen Anteilen von Scrum. Dazu gehören die Entwicklerinnen bzw. Entwickler, die Sprints, das Sprint Planning und das Daily Scrum. Wir thematisieren die technischen Herausforderungen, die mit iterativ-inkrementeller Entwicklung einhergehen, denen sich die Entwickler stellen müssen.

Kontinuierliche Prozessverbesserung ist das Thema von Kapitel 5. Retrospektiven als institutionalisierter Mechanismus zur Prozessverbesserung durch das Team werden ebenso beschrieben wie die Verantwortung des Scrum Masters, der den Verbesserungsprozess vorantreibt. Nicht zuletzt befassen wir uns in diesem Kapitel mit den agilen Werten und Prinzipien, die ihre Formalisierung über das Agile Manifest erfahren. Wir haben uns aus didaktischen Gründen dafür entschieden, diesen sehr wichtigen Aspekt zu diesem Zeitpunkt im Buch zu thematisieren, weil die Prinzipien und Werte mit Rückblick auf die Scrum-Praktiken unserer Erfahrung nach konkreter werden und leichter zu verstehen sind.

Kapitel 6 beschäftigt sich mit großen Vorhaben in Scrum. Zunächst betrachten wir die Gründe für große Vorhaben und welche Optionen zur Vermeidung existieren. Dann zeigen wir die häufig verwendeten Techniken zur Planung und zum Controlling großer Vorhaben in Scrum. Wir adressieren wirkungsorientierte Roadmaps, Schätzungen mit verschiedenen Techniken sowie unterschiedliche Diagrammtypen zur Visualisierung des Fortschritts.

Ein Streiflicht auf weiterführende Themen wirft Kapitel 7. Dort wird die Einführung von Scrum in Teams und ins Unternehmen thematisiert: Wir stellen unsere langjährigen Erfahrungen mit agilen Transitionen anhand unseres eigenen Transitionsvorgehens zur Verfügung. Dabei stehen wieder die Wirkungen und ihre kontinuierliche Überprüfung im Fokus. Darüber hinaus thematisieren wir die Arbeit mit mehreren abhängigen Teams (Scrum-Skalierung), verteilt arbeitende Teams, die veränderte Rolle von Management und Führung sowie die Vertragsgestaltung für agile Entwicklung. All diese Themen können im Rahmen dieses Buches nur angerissen werden. Jedes einzelne Thema ist geeignet, um mehrere Bücher zu füllen.

In Anhang A stellen wir die Elemente des Scrum-Frameworks sowie einige sehr häufig anzutreffende Praktiken noch einmal in Kurzform dar.

Lesewege

Wer nur einen schnellen Scrum-Überblick braucht, bekommt diesen in Kapitel 2.

Wer sich primär für Product-Owner-Themen interessiert, kann sich in Kapitel 2 einen Scrum-Überblick verschaffen und dann mit Kapitel 3 und Kapitel 6 weitermachen. Der Abschnitt zur Vertragsgestaltung in Kapitel 7 kann je nach Kontext sinnvoll sein. Irgendwann zwischendurch lohnt sich sicher auch ein Blick in Kapitel 1.

Wer als Scrum Master arbeiten möchte, muss letztlich das ganze Buch lesen – von vorne bis hinten.

Wer schnell ein Scrum-Team als Scrum Master betreuen muss, findet nach der Lektüre von Kapitel 2 in Anhang A erste Hilfe und kann dann gezielt in die einzelnen Kapitel einsteigen.

Entwicklern in Scrum-Teams empfehlen wir, auf jeden Fall Kapitel 2, 4 und 5 zu lesen.

Wer als Führungskraft Scrum verstehen möchte, sollte mit Kapitel 1 beginnen und dann Kapitel 2, 5 und 7 lesen. Je nach Interesse können danach Kapitel 3 und Kapitel 6 sinnvoll sein.

1 Scrum: Historie, Vorteile, Eignung und Herausforderungen

»Everybody is on a team. There’s none of this nonsense of designers working separate.«

Jeff Sutherland, Ken Schwaber1

Die Historie von Scrum ist gut geeignet, um neue Perspektiven auf Scrum zu erlangen und die Vielgestaltigkeit von Scrum besser zu verstehen.

Wir beginnen das Kapitel mit der Frage, was Autos, Kopierer, Spiegelreflexkameras und andere Produkte aus den 1970er- und 1980er-Jahren mit Scrum zu tun haben. Über Produktinnovation und lernende Organisationen landen wir im Jahr 1993 und gelangen zu Scrum in der Softwareentwicklung. Wir sehen, wie Scrum andere Ansätze (wie eXtreme Programming) inspiriert hat und wie Scrum sich selbst immer weiter verbreitete bis zum heutigen De-facto-Standard agiler Softwareentwicklung.

Auf dieser Basis diskutieren wir, für welche Bereiche Scrum geeignet ist und welche Vorteile der Einsatz von Scrum mit sich bringen kann.

1.1 Historie

1.1.1 Scrum-Teams nach Nonaka und Takeuchi

Im Jahr 1986 veröffentlichten Hirotaka Takeuchi und Ikujiro Nonaka in der Harvard Business Review einen Artikel mit dem Titel »The New New Product Development Game« (siehe [TakeuchiNonaka1986]). In diesem Artikel beschreiben die Autoren verschiedene Fallbeispiele von Produktentwicklungen, die besonders schnell und innovativ waren: PKW bei Honda, Spiegelreflexkameras bei Canon, Kopierer bei Fuji-Xerox und bei Canon sowie Personal Computer bei NEC. Als eine wichtige Zutat wurde die Arbeit in sogenannten Scrum-Teams genannt (unseres Wissens nach taucht hier der Begriff des Scrum-Teams das erste Mal in der Literatur auf). Es verwundert daher nicht, dass vielen dieser Artikel als die Geburtsstunde von Scrum gilt. Jeff Sutherland bezieht sich immer wieder auf die Arbeiten von Nonaka und Takeuchi, wenn er über Scrum für die Softwareentwicklung spricht.

Der besagte Artikel in der Harvard Business Review stellt wesentliche Unterschiede zwischen klassischer Entwicklung und der Entwicklung in Scrum-Teams so wie in Abbildung 1.1 dar. Klassisch folgen verschiedene Phasen, wie Marktforschung, Design, Produktspezifikation, Entwicklung und Qualitätssicherung, sequenziell aufeinander. In den Phasen arbeiten die jeweiligen Spezialisten. Erst wenn eine Phase abgeschlossen ist, wird mit der nächsten begonnen. In den untersuchten Produktentwicklungen wurde von diesem strikten sequenziellen Verfahren abgewichen; es gab überlappende Phasen (siehe den Mittelteil in Abbildung 1.1). Die nächste Phase beginnt, bevor die aktuelle Phase vollständig abgeschlossen ist. Bereits diese Überlappung bringt gravierende Änderungen mit sich:

■

Die Projektbeteiligten müssen miteinander kooperieren, um die Phasenübergänge gestalten zu können.

■

Probleme mit dem Ergebnis einer Phase können während der Kooperation entdeckt und sofort gemeinsam beseitigt werden.

■

Die Time-to-Market sinkt (je nach Breite der Überlappung marginal bis erheblich).

Abb.

1.1

Klassische Entwicklung vs. Scrum

Treibt man diese Phasenüberlappung ins Extrem, finden alle Phasen gleichzeitig statt (unterer Teil in Abbildung 1.1). Die Folgen sind entsprechend auch extrem:

■

Alle Beteiligten müssen sich kontinuierlich abstimmen, damit kein Chaos ausbricht. Kooperation wird maximiert.

■

Durch die enge Zusammenarbeit der Beteiligten werden zu jedem Zeitpunkt verschiedenste Perspektiven eingebracht. Das wirkt positiv gegen Groupthink (Gruppendenken) und erhöht die Chance auf Innovation.

■

Die Time-to-Market sinkt erheblich.

Nonaka und Takeuchi vergleichen die sequenzielle Arbeitsweise mit einem Staffellauf. Jeder Läufer hat seine Strecke zu absolvieren, übergibt den Staffelstab an den nächsten Läufer und hat dann mit dem Geschehen nichts weiter zu tun.

Die dritte Variante hingegen nennen sie Scrum2 in Anlehnung an das Rugby-Spiel, weil ein Rugby-Team sich gemeinsam über das Spielfeld bewegen muss, um erfolgreich zu sein. Das wird durch die Rugby-Regeln verursacht: Die ballführende Mannschaft darf den Ball immer nur nach hinten, nie nach vorne abspielen. Ein Scrum-Team nach Nonaka und Takeuchi ist cross-funktional (interdisziplinär) besetzt, führt alle Phasen gleichzeitig aus, kooperiert eng, arbeitet autonom und organisiert sich selbst (siehe Abbildung 1.2).

Abb.

1.2

Scrum-Team

Wir bringen Scrum-Teams auf den Punkt:

Scrum-Teams

Scrum-Teams sind autonome, businessfokussierte Teams, die ihren Prozess in Besitz nehmen und die Verantwortung für ihn tragen.

Interessant ist der Vergleich der Scrum-Teams nach Nonaka und Takeuchi mit dem, was sich in der heutigen Praxis der Softwareentwicklung findet. In der Softwareentwicklung sind minimal-cross-funktionale Teams üblich, die Programmierer und Tester enthalten. Schon bei der Integration von Designern geraten viele Unternehmen ins Straucheln. Dabei ist das im Vergleich zu den Teams bei Canon, Honda, Fuji-Xerox und NEC der reinste Ponyhof. Bei Honda waren z.B. Vertrieb, Entwicklung, Qualitätssicherung und Produktion mit im Team. Bei einer so weitreichenden Abdeckung der Wertschöpfungskette hat das Team zwangsläufig direkten Endkundenkontakt. Weiterhin können wir bei innovativer Entwicklungsarbeit nicht davon ausgehen, dass die Endkunden besondere Expertise in der Produktkonzeption hätten. Das Team setzt also nicht Anforderungen um, die es von den Endkunden oder Dritten bekommt, sondern löst Probleme der Endkunden. Aus diesen beiden Aspekten resultiert der sehr einfache agile Kernzyklus aus Abbildung 1.3.

Abb.

1.3

Agile Teams lösen Probleme der Endkunden.

Wer genau mit Endkunden gemeint ist, diskutieren wir in Kapitel 3.

1.1.2 Erste Scrum-Projekte in der Softwareentwicklung

Jeff Sutherland hat 1993 bei Easel – inspiriert durch die Arbeiten von Nonaka und Takeuchi – Scrum für die Softwareentwicklung eingesetzt (siehe [Sutherland2005], [Sutherland2006], [Denning2010]). Dort war ein Projekt zur Entwicklung eines objektorientierten Designtools ins Straucheln geraten. Jeff Sutherland überzeugte den CEO, es mit einem Scrum-Team zu versuchen. Jeff Sutherland kümmerte sich um den Prozess und kann damit als erster Scrum Master gelten.

Das Team zeichnete sich durch einen hohen Grad an Selbstorganisation aus, für die das tägliche Koordinationsmeeting (Daily Scrum) eine wichtige Rolle spielte. Die Teammitglieder trafen sich jeden Werktag für maximal 15 Minuten, um Probleme aus dem Weg zu räumen und die Arbeit für den Tag gemeinsam zu planen.

Ungefähr zur gleichen Zeit experimentierte Ken Schwaber mit ähnlichen Techniken. Schwaber und Sutherland entdeckten die Gemeinsamkeiten ihrer Ansätze und schufen das heute bekannte Scrum für die Softwareentwicklung.

1.1.3 Von den ersten Artikeln bis zum Scrum Guide

Im Jahr 1997 veröffentlichte Ken Schwaber ein Paper mit dem Titel »SCRUM Development Process« auf der OOPSLA (siehe [Schwaber1997]). Dieser Artikel war die erste veröffentlichte Beschreibung von Scrum für die Softwareentwicklung. Im Jahr 1999 veröffentlichten Mike Beedle, Martine Devos, Yonat Sharon, Ken Schwaber und Jeff Sutherland auf der PLOP-Konferenz einen Artikel mit dem Titel »SCRUM: A Pattern Language for Hyperproductive Software Development« (siehe [Beedle et al. 1999]).

2000 veröffentlichte Kent Beck sein Buch »Extreme Programming Explained – Embrace Change« (siehe [Beck2000]) und begleitete die Markteinführung des Buches durch eine Reihe von Konferenzvorträgen. eXtreme Programming (XP) nahm Grundgedanken von Scrum auf und ergänzte sie um Programmiertechniken wie die testgetriebene Entwicklung und das Pair Programming. XP war für die damalige Zeit radikal und polarisierte: Der Großteil der Softwareentwicklungsbranche fand XP absurd oder utopisch. Eine kleine, aber sehr leidenschaftliche Gemeinschaft von Entwicklern sah darin jedoch einen notwendigen Paradigmenwechsel. Immer mehr Teams setzten XP erfolgreich ein, und das Interesse stieg immer weiter an. In diesem Zuge erlangte auch Scrum eine größere Bekanntheit. Die Community war sehr wissbegierig und experimentierfreudig und suchte stets nach neuen Inspirationen. So wurden weitere Ansätze mit ähnlichen Denkmodellen entdeckt oder entwickelt, wie z.B. Crystal (siehe [Cockburn2004]) und Feature Driven Development (siehe [PalmerFelsing2002]).

Diese Ansätze wurden zunächst unter dem Sammelbegriff »leichtgewichtig« zusammengefasst. Im Jahre 2001 trafen sich einflussreiche Vertreter dieser »leichtgewichtigen« Ansätze (inkl. Ken Schwaber und Jeff Sutherland) in Snowbird und definierten das Agile Manifest, das gemeinsame Werte und Prinzipien festlegte (siehe [AgileManifesto2001]). Als Werte wählten die Autoren Gegensatzpaare.

»Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

■

Individuen und Interaktionen mehr als Prozesse und Werkzeuge

■

Funktionierende Software mehr als umfassende Dokumentation

■

Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

■

Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.«

Seitdem nennen wir die genannten Ansätze nicht mehr »leichtgewichtig«, sondern agil.

Bei der Umsetzung in die Praxis erreichte Scrum die mit Abstand größte Verbreitung. Ken Schwaber und Mike Beedle veröffentlichten 2002 das erste Scrum-Buch (siehe [SchwaberBeedle2002]). Viele Scrum-Teams integrierten Entwicklungspraktiken aus XP (siehe dazu auch Kapitel 4). Die anderen Ansätze sind in der Praxis fast bedeutungslos. Vor einigen Jahren brachte David Anderson mit Kanban frischen Wind in die Szene (siehe [Anderson2010]). Während es zunächst zwischen der Scrum- und der Kanban-Community starke Abgrenzungstendenzen gab, versteht man sich heute gegenseitig besser, und in der Praxis werden sowohl Scrum als auch Kanban eingesetzt – mitunter sogar im selben Projekt.

Zuletzt veröffentlichten Ken Schwaber und Jeff Sutherland ihr erstes gemeinsames Scrum-Buch mit dem Titel »Software in 30 days«. Das Buch führt Manager in die Scrum-Denkweise ein und beleuchtet auch die Frage, wie Transitionen hin zu Scrum gestaltet werden können (siehe [SchwaberSutherland2012]).

Im Jahre 2010 veröffentlichten Ken Schwaber und Jeff Sutherland den ersten Scrum Guide, die offizielle Scrum-Definition (siehe [SchwaberSutherland2020]). Der Scrum Guide wird kontinuierlich weiterentwickelt; die aktuelle Version findet sich auf http://scrumguides.org. Dort existieren auch Übersetzungen in viele Sprachen, unter anderem ins Deutsche.

1.1.4 Verbreitung von Scrum

Scrum ist in der agilen Softwareentwicklung der De-facto-Standard. In unserer Wahrnehmung schwankt die Durchdringung mit agilen Ansätzen stark zwischen Branchen. Wo die entwickelte Software direkte Bedeutung für den Unternehmenserfolg hat und hoher Marktdruck herrscht, ist agile Entwicklung der Standardfall und sequenzielle Verfahren sind die Ausnahme. Das Paradebeispiel ist das E-Business.

Weniger stark verbreitet ist agile Entwicklung dort, wo z. B. Inhouse-Anwendungen für die Sachbearbeitung in Konzernen entwickelt werden. Ob die Entwicklung einer neuen Buchhaltungssoftware in einer Bank oder Versicherung dieses oder nächstes Jahr kommt, macht sich in den Bilanzen kaum bemerkbar. In diesen Kontexten ist der Veränderungsdruck nicht so groß, und daher sind dort agile Verfahren weniger üblich. Allerdings gibt es so gut wie kein größeres Unternehmen, das nicht mindestens agile Pilotprojekte durchgeführt hat.

Mit der zunehmenden Verbreitung agiler Verfahren hat man inzwischen herausgefunden, dass diese auch in den Bereichen einsetzbar sind, die gemeinhin als schwierig gelten: große Entwicklungen mit über 100 Beteiligten, verteilte Teams, regulierte Umfelder (z.B. Medizinbereich), Automotive, Business Intelligence, Entwicklung von Hardware etc.

In den letzten Jahren haben Scrum und andere agile Ansätze auch außerhalb der Softwareentwicklung immer weitere Verbreitung gefunden: bei der Entwicklung von Hardware (siehe [wikispeed]), für generelles Management und Unternehmensorganisation (siehe [Denning2010], [Laloux2014]), für Unternehmenstransitionen (siehe Kapitel 7), Entwicklung und Erbringung von Services sowie für Marketing und Vertrieb (siehe [Lammers2015], [Reppin2015], [vanSolingen et al. 2011]).

1.2 Vorteile von Scrum

Scrum kann viele Vorteile mit sich bringen. Relevante Vorteile werden durch das Arbeiten in kleinen Einheiten (Batches) erzeugt: kürzere Time-to-Market, höhere Qualität und größere Effizienz. In Anlehnung an Don Reinertsen (siehe [Reinertsen2009]) erklärt Abbildung 1.4 diese Vorteile.

Abb.

1.4

Scrum-Vorteile

Neben den kleinen Arbeitseinheiten wirken das cross-funktionale Team und die parallelen Phasen positiv auf die folgenden Aspekte:

■

Die parallelen Phasen verkürzen die Time-to-Market.

■

Die parallelen Phasen führen dazu, dass Probleme, Missverständnisse und Fehler früher entdeckt werden. Das führt zu kürzerer Time-to-Market sowie zu höherer Qualität.

■

Das cross-funktionale Team führt zu einer höheren Diversität bei der Arbeit, und die Wahrscheinlichkeit von Innovation steigt.

■

Durch die Arbeit im cross-funktionalen Team in parallelen Phasen sieht jedes Teammitglied seinen Beitrag zum ganzen Produkt und findet Sinn in seiner Arbeit. Das führt zu größerer Zufriedenheit und Motivation.

Wir beschäftigen uns in den folgenden Abschnitten genauer mit diesen positiven Effekten.

1.2.1 Kürzere Time-to-Market

Die Time-to-Market verkürzt sich mit Scrum aufgrund zweier Ursachen. Zunächst führt Little’s Law (siehe [Little1961]) ganz mechanisch zu kürzeren Durchlaufzeiten: Die durchschnittliche Durchlaufzeit in der Entwicklung berechnet sich aus dem durchschnittlichen Work in Progress dividiert durch den durchschnittlichen Durchsatz (siehe Abbildung 1.5).

Abb.

1.5

Weniger Work in Progress reduziert Durchlaufzeiten.

Man kann das gut an einem Fahrgeschäft in einem Vergnügungspark verdeutlichen. Der Work in Progress ist die Menge der Menschen in der Schlange und im Fahrgeschäft. Der Durchsatz ist die Menge an Menschen, die das Fahrgeschäft in einer bestimmten Zeiteinheit absolvieren können. Nehmen wir an, in der Achterbahn können 100 Menschen mitfahren. Eine Fahrt dauert 5 Minuten. Das Ein- und Aussteigen dauert zusammen noch einmal 5 Minuten. Dann beträgt der Durchsatz 100 Menschen/10 Minuten, also durchschnittlich 10 Menschen/Minute. Steigen gerade 100 Leute in die Achterbahn ein und stehen weitere 900 in der Schlange, wartet der nächste Gast, der sich an die Schlange anstellt, ca. 100 Minuten. Stehen nur 100 Menschen in der Schlange, muss er nur ca. 20 Minuten warten. Vergnügungsparks machen von dieser Erkenntnis Gebrauch und zeigen mit Schildern im Wartebereich an, wie lange man noch warten muss, wenn man das Schild erreicht hat.

Der Durchsatz in der Softwareentwicklung ist die Menge an Funktionen, die ein Team in einer Zeiteinheit (z.B. Sprint) entwickeln kann. Der Durchsatz sollte sich über die kontinuierliche Verbesserung in Scrum langfristig erhöhen. Er wird sich aber häufig nicht sprunghaft verbessern. Im Gegensatz dazu ist der Work in Progress – also die Menge der begonnenen, aber nicht abgeschlossenen Arbeit – leicht änderbar. In Scrum erreichen wir dies durch das Sprint-Konzept. Es wird nur ein kleiner Teil der für das Produkt notwendigen Funktionen für den nächsten Sprint ausgewählt und damit der Work in Progress auf diesen Anteil beschränkt.

Eine zweite wichtige Ursache für die kürzere Time-to-Market findet sich in Untersuchungen über die Verwendung von klassisch entwickelter Software. Verschiedene Analysen kommen übereinstimmend zu dem Schluss, dass der Wertbeitrag der Funktionen in Software extrem unterschiedlich ist. So präsentierte Jim Johnson auf der XP-Konferenz 2002 eine Untersuchung an vier Softwareprojekten, die ergab, dass 64 % der Funktionen selten oder nie genutzt wurden (siehe Abbildung 1.6 [Johnson2002]).

Abb.

1.6

Ein Großteil der Funktionen in Softwaresystemen wird selten oder nie genutzt.

Natürlich gibt es Funktionen, die selten benutzt werden und auf die man doch nicht verzichten kann (z. B. der Jahresabschluss in einer Finanzbuchhaltung). Allerdings kann man damit nicht den hohen Anteil (64 %) am Gesamtumfang rechtfertigen.

Arnold und Yüce berichten in [ArnoldYüce2013], dass bei einem Projekt bei Maersk Line die wertvollsten 25 % der Features 90 % der Wertschöpfung ausmachten.

Wir können also häufig die Time-to-Market allein dadurch deutlich reduzieren, dass wir nur die wirklich wertvollen Funktionen implementieren. Scrum stellt dies sicher, indem der Product Owner die Funktionen priorisiert.

1.2.2 Höhere Qualität

Zunächst mag die höhere Qualität überraschen, die mit Scrum einhergeht. Qualität steht bei Scrum aber kontinuierlich im Fokus der Betrachtung und wird nicht ans Projektende verschoben. Die Qualitätssicherung einer Funktionalität findet direkt nach ihrer Entwicklung statt. So werden Fehler bereits wenige Stunden oder Tage, nachdem sie produziert wurden, entdeckt. Dadurch sind sie um Größenordnungen leichter zu lokalisieren und zu beheben, als hätte man sie erst nach Wochen oder Monaten entdeckt. Insgesamt erhöht sich dadurch auch das Qualitätsbewusstsein bei allen Beteiligten.

Außerdem führt Scrum zu gebrauchstauglicherer Software, weil Kunden und Anwender regelmäßig Feedback zum Produkt geben.

1.2.3 Größere Effizienz

In klassischen sequenziellen Prozessen (z. B. Wasserfall) arbeiten wir mit großen Batches. Es werden erst alle Anforderungen definiert, dann wird die Architektur des ganzen Systems festgelegt, dann werden alle Funktionen programmiert und schließlich alle Funktionen getestet. Diese großen Batches bringen sehr großen Verwaltungsaufwand mit sich, der allerdings meist nicht explizit sichtbar wird: Es müssen sehr große Zeiträume überplant werden. In diesen großen Zeiträumen kumulieren sich die Unwägbarkeiten, sodass man sehr viel Aufwand in Schätzungen, Puffer und Risikomanagement stecken muss.

In Scrum planen wir nur sehr kleine Zeiträume detailliert und können daher sehr leichtgewichtig arbeiten. An vieles kann man sich einfach so erinnern, für den Rest reichen oft Haftnotizen oder Karteikarten aus.

Außerdem sind Korrekturen in Scrum ungleich billiger, wenn sie sich auf vorangegangene Aktivitäten beziehen. Stellt sich beim Vorgehen nach dem Wasserfallmodell während des Testens heraus, dass grundsätzliche Festlegungen zur Systemarchitektur ungünstig waren, entstehen erhebliche Kosten. In Scrum würde man diese Art von Problemen viel früher entdecken und kann sie deshalb kostengünstiger beseitigen.

1.2.4 Mehr Innovation