Scrum – verstehen und erfolgreich einsetzen E-Book

Henning Wolf

• Herausgeber: dpunkt.verlag
• Kategorie: Fachliteratur
• Sprache: Deutsch
• Veröffentlichungsjahr: 2021

Seitenzahl: 319

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 Rollen in Scrum mit ihren Verantwortlichkeiten (Scrum Master, Entwicklungsteam, Product Owner), selbstorganisierte Teams, die Scrum-Meetings (Daily Scrum, Sprint Planning, Sprint-Review, Sprint-Retrospektive), Scrum-Artefakte (Product Backlog, Sprint Backlog, lieferbares Produktinkrement), Releasemanagement und Schätzverfahren sowie die Einführung von Scrum im Unternehmen, Scrum-Skalierung, verteiltes Scrum und Leadership.
Im Anhang werden die Elemente des Scrum-Frameworks sowie einige sehr häufig anzutreffende Praktiken noch einmal in Kurzform dargestellt.
Die 3. Auflage wurde an die neue Fassung des Scrum Guide aus November 2020 angepasst, was neben Details auch das Konzept des Produktziels umfasst. Zudem gibt es einen Ausblick auf das Konzept der wirkungsvollen Agilität.

Leseprobe

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.

Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+:

www.dpunkt.plus

Henning Wolf · Stefan Roock

Scrum –verstehen und erfolgreich einsetzen

3., überarbeitete und erweiterte Auflage

Henning [email protected]

Stefan [email protected]

Lektorat: Christa Preisendanz

Copy-Editing: Ursula Zimpfer, Herrenberg

Satz: Birgit Bäuerlein

Herstellung: Stefanie Weidner

Illustrationen: Henning Wolf, Stefan Roock und Claudia Leschik

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Bibliografische Information der Deutschen Nationalbibliothek

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

ISBN:

Print 978-3-86490-848-4

PDF  978-3-96910-538-2

ePub 978-3-96910-539-9

mobi 978-3-96910-540-5

3., überarbeitete und erweiterte Auflage 2021

Copyright © 2021 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Hinweis:

Dieses Buch wurde auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

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 Kund:innen und glücklichere Mitarbeitende. 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 Leser:innen werden Projektmanager:innen, Produktmanager:innen, Entwickler:innen und unteres bis mittleres Management 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, zum Beginn des Informatikstudiums 1990, einem anschließenden Abstecher als wissenschaftliche Mitarbeiter an der Universität Hamburg, vielen gemeinsamen Entwicklungs- und Beratungsprojekten und der 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:innen und bekamen entsprechendes Feedback.

Nicht nur wir empfanden so, viele der Entwickler:innen in den Unternehmen, die wir bei der Einführung von Scrum und XP unterstützten, äußerten sich ähnlich. Und das Management und die Kund:innen 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, wie 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 Kund:innen vertrauensvoll und kooperativ zusammenarbeiten, um coole Produkte zu entwickeln, in der Entwickler:innen 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 Kund:innen der Produkte und für unser Unternehmen (siehe äußerer Ring in Abb. 1).

Abb. 1Ergebnisse als Mittel zum Zweck, um Wirkungen zu erzielen

Die Kund:innen 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 Zufriedenheit und Loyalität der Kund:innen, 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 Abb. 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 Kund:innen 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 Endkund:innen 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 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 zur Releaseplanung 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 bestehen darin,

dass nicht mehr von Rollen, sondern

Verantwortlichkeiten

gesprochen wird (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),

dass es nur das

Scrum-Team

und kein Entwicklungsteam mehr gibt (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) und

dass das

Produktziel

als Teil des Product Backlog aufgenommen wurde (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 nochmal stärker verdeutlicht, dass es darum geht,

Wirkungen

zu erzielen, und dass das Produkt (das Ergebnis) nur Mittel zum Zweck ist.

Wir haben das Buch auf eine gendergerechtere Sprache umgestellt – auch wenn uns das sicher nicht an allen Stellen perfekt gelungen ist. Wir haben die englischen Begriffe wie Scrum Master, Product Owner und Stakeholder nicht angepasst, sprechen aber z.B. von Entwickler:innen.

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 Kolleg:innen der it-agile GmbH.

Aber auch unseren Kund:innen 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-Trainer:innen 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 unserer Lektorin Christa Preisendanz 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 uns das hoffentlich nicht übelnehmen. So viele Menschen haben uns beeinflusst und beeindruckt. Dazu gehören auch die Leser:innen der ersten und zweiten Auflage dieses Buches, die uns Feedback gegeben haben, sowie die vielen Teilnehmer:innen 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]

Henning Wolf, Stefan RoockHamburg, Mai 2021

Ü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 wie 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, 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 Entwickler:innen, die Sprints, das Sprint Planning und das Daily Scrum. Wir thematisieren die technischen Herausforderungen, die mit iterativ-inkrementeller Entwicklung einhergehen und denen sich die Entwickler:innen 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 der Releaseplanung in Scrum. Scrum selbst kennt den Begriff »Release« nicht. Allerdings besteht in so vielen Kontexten das Bedürfnis nach Releaseplanung, dass wir das Thema nicht schuldig bleiben wollten. Zunächst betrachten wir die Gründe für Releaseplanung und diskutieren, unter welchen Umständen Releaseplanung nicht notwendig ist. Dann zeigen wir die häufig verwendeten Techniken zur Release- und Roadmap-Planung in Scrum. Schätzungen mit Story Points, Velocity, Lean Forecasting, die eigentliche Releaseplanung anhand von Wirkungen und das Release-Controlling werden beschrieben.

Ein Streiflicht auf weiterführende Themen gibt Kapitel 7. Dort wird die Einführung von Scrum in Teams und ins Unternehmen thematisiert: Wir stellen unsere langjährigen Erfahrungen mit agilen Transitionen mit unserem eigenen Transitionsvorgehen 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 den 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 nach 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.

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

Wer als Manager:in 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.

Inhaltsübersicht

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

Anhang

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

B Literatur

Index

Inhaltsverzeichnis

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 den Scrum-Ablauf, die Verantwortungen, Meetings, Artefakte und Prinzipien

2.1 Scrum-Flow

2.2 Die Verantwortlichkeiten

2.2.1 Product Owner

2.2.2 Entwickler:innen

2.2.3 Scrum Master

2.2.4 Scrum-Team

2.2.5 Kein Projektleiter oder Projektleiterin 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 Endkund:innen

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 Die Bedeutung von Priorisierung

3.5.2 Bevollmächtigung des Product Owners

3.6 Eigenschaften des Product Backlog

3.6.1 Das Produktziel

3.6.2 Organisation der Product Backlog Items

3.6.3 Größe des Product Backlog

3.7 Definition of Ready

3.8 Product Backlog Board

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

3.8.2 Inhomogene Product Backlog Items

3.8.3 Physikalisches Board

3.9 Priorisierung

3.9.1 Priorisierung nach Kosten-Wert

3.9.2 Priorisierung nach Risiko-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.2.1 Nutzen wird weggelassen

3.10.2.2 Akteur:in ist zu abstrakt

3.10.2.3 Akteur:in ist der Anforderer oder die Anforderin

3.10.3 Tipps zu User Stories

3.10.3.1 Alternatives Satzschema

3.10.3.2 Persona als Akteur:in

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.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.14.3.1 Finden des Sprint-Ziels

3.14.3.2 Vorteile guter Sprint-Ziele

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.3.1 Zusätzliche und alternative Praktiken im Sprint-Review

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:innen (Cross-Funktionalität, Autonomie, Selbstorganisation)

4.1.1 Cross-Funktionalität

4.1.2 Autonomie und Selbstorganisation

4.1.3 Entwickler:innen 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 Aufwandsschätzung

4.5.2 Story Points als Größenmaß

4.5.3 Vorteile von Story Points

4.5.4 Planning Poker®

4.5.5 Varianten des Planning Poker®

4.5.6 Erfahrungen mit Planning Poker®

4.5.7 Inkrementelles Ziehen in den Sprint

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

4.5.9 Architekturdiskussionen

4.5.10 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:innen

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.9.1 Entwickler:innen als Scrum Master

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

5.1.9.3 Scrum Master für ein zusätzliches Team

5.1.9.4 Der Scrum Master als Change Agent im Unternehmen

5.1.9.5 Der richtige Weg für den eigenen Kontext

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.2.1 Set the stage (die Bühne bereiten)

5.4.2.2 Gather data (Daten sammeln)

5.4.2.3 Generate insights (Einsichten generieren)

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

5.4.2.5 Closing (Abschluss)

5.4.3 Moderation von Retrospektiven

5.4.4 Teilnehmer:innen 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 Das Kapitel in Stichpunkten

6 Releasemanagement

6.1 Grenzen der Releaseplanung

6.2 Das Warum der Releaseplanung

6.2.1 Rendezvous-Planung

6.2.2 Beispiel: Marketing

6.2.3 Investitionsmanagement

6.3 Das beste Releasemanagement ist Sprint-Management

6.4 Schätzung mit Story Points

6.4.1 Bucket Estimation

6.5 Releaseplanung

6.5.1 Ermitteln der Velocity

6.5.2 Probleme mit Story Points

6.5.3 Alternativen zu Story Points

6.5.4 Releasedauer

6.5.5 Release-Container

6.6 Roadmap-Planung

6.7 Release-Controlling

6.7.1 Release-Burndown-Bar-Charts

6.7.2 Release-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.3.1 Scrum Studio

7.1.3.2 Autonome Business Units

7.1.4 Agilität mit agilen Verfahren ausbreiten

7.1.5 Globale Optimierung

7.1.6 Coaching

7.1.6.1 Ökonomie des Coachings

7.1.7 Externe Coaches auswählen

7.1.8 Interne Coaches ausbilden

7.2 Scrum skalieren

7.2.1 Der Agile Scaling Cycle

7.2.2 Praktiken zur Reduktion von Abhängigkeiten

7.2.3 Praktiken zur Koordination von Teams

7.2.4 Die Organisation entwickeln

7.3 Agile Unternehmen

7.4 Verteiltes Scrum

7.4.1 Vertrauen ist essenziell

7.4.2 Entfernung

7.4.3 Tools

7.5 Interventionen durch Führungskräfte

7.5.1 Selbstverständnis von Führungskräften

7.5.2 Alignment und Autonomie

7.5.3 CDE: Containers, Differences, Exchanges

7.5.3.1 CDE-Beispiel

7.5.4 Leadership

7.6 Vertragsgestaltung für agile Entwicklung

7.6.1 Scrum im Vertrag

7.6.2 Werkvertrag und Festpreis vs. Dienstvertrag und Bezahlung nach Aufwand

7.6.3 Flexibilität des Vertragswerks

7.6.4 Kosten- vs. nutzenorientierte Verträge

7.6.5 Vorgehen wichtiger als Ergebnisse

7.7 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 Kund:innen/Anwender:innen

A.2.4 Management sonstiger Stakeholder

A.3 Aufgaben der Entwickler:innen

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 Releaseplanung

A.10 Product Backlog

A.11 Sprint Backlog

A.12 Produktinkrement

A.13 Sprint-Burndown-Chart

A.14 Release-Burnup-Chart

B Literatur

Index

1Scrum: 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.1Historie

1.1.1Scrum-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: Pkws 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 Abb. 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–1Klassische Entwicklung vs. Scrum

Treibt man diese Phasenüberlappung ins Extrem, finden alle Phasen gleichzeitig statt (unterer Teil in Abb. 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 nennen sie in Anlehnung an das Rugby-Spiel Scrum2, 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 Abb. 1–2).

Abb. 1–2Scrum-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:innen und Tester:innen enthalten. Schon bei der Integration von Designer:innen 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 Kontakt zu den Endkund:innen. Weiterhin können wir bei innovativer Entwicklungsarbeit nicht davon ausgehen, dass die Endkund:innen besondere Expertise in der Produktkonzeption hätten. Das Team setzt also nicht Anforderungen um, die es von den Endkund:innen oder Dritten bekommt, sondern löst Probleme der Endkund:innen. Aus diesen beiden Aspekten resultiert der sehr einfache agile Kernzyklus aus Abbildung 1–3: Das selbstorganisierte agile Team löst in kurzen Zyklen Probleme der Endkund:innen.

Abb. 1–3Agile Teams lösen Probleme der Endkund:innen.

Wer genau mit Endkund:innen gemeint ist, diskutieren wir in Kapitel 3.

1.1.2Erste 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], [Sutherland2004], [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.3Von 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 Jahre 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 Entwickler:innen 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:innen 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]). Für die Werte wählten die Autor:innen 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 Kap. 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 wie 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.4Verbreitung 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 Kap. 7), Entwicklung und Erbringen von Services sowie für Marketing und Vertrieb (siehe [Lammers2015], [Reppin2015], [vanSolingen et al. 2011]).

1.2Vorteile 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–4Scrum-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.1Kü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 Abb. 1–5).

Abb. 1–5Weniger Work in Progress reduziert Durchlaufzeiten.

Man kann sich 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 Abb. 1–6, [Johnson2002]).

Abb. 1–6Ein 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.2Hö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 Kund:innen und Anwender:innen regelmäßig Feedback zum Produkt geben.

1.2.3Größ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.4Mehr Innovation