Scrum – verstehen und erfolgreich einsetzen - Stefan Roock - E-Book

Scrum – verstehen und erfolgreich einsetzen E-Book

Stefan Roock

0,0

Beschreibung

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. Neu hinzugekommen sind in der 2. Auflage Techniken wie Storytelling, Story Mapping, Roadmap Planning sowie Lean Forecasting. Außerdem wurde das Buch an die neue Fassung des Scrum Guide vom November 2017 angepasst.

Sie lesen das E-Book in den Legimi-Apps auf:

Android
iOS
von Legimi
zertifizierten E-Readern

Seitenzahl: 308

Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:

Android
iOS



Dipl.-Inform. Stefan Roock ist Gründungsmitglied der it-agile GmbH und hat seit 1999 die Verbreitung agiler Ansätze in Deutschland maßgeblich mit beeinflusst. Zunächst hat er als Entwickler, später als Scrum Master und Product Owner in Scrum-Teams gearbeitet. Er hat erlebt, dass Teammitglieder und Kunden in den Anfangsjahren begeistert von der agilen Arbeitsweise waren. Heute findet sich in vielen Scrum-Implementierungen statt dieser Begeisterung eher ein »immerhin ist es nicht mehr so schlimm wie früher«-Gefühl. Stefan hat selbst erlebt, dass es besser geht, und arbeitet weiterhin daran, mit Agilität Mitarbeiter und Endkunden zu begeistern. Dazu gibt er seine Erfahrung als Berater und Trainer weiter und hilft Unternehmen dabei, agiler zu werden. Neben seiner Beratungstätigkeit für it-agile ist er regelmäßiger Sprecher zu agilen Themen auf Konferenzen, schreibt Zeitschriftenartikel und hat mehrere Bücher veröffentlicht.

Dipl.-Inform. Henning Wolf ist Mitgründer, Geschäftsführer und Senior-Berater bei der it-agile GmbH in Hamburg. Er hat seit über fünfzehn Jahren Erfahrung mit agilen Methoden und hat diese in diversen Artikeln, Büchern und Konferenzbeiträgen aufgearbeitet. Die letzten Veröffentlichungen waren »Die Kraft von Scrum« sowie die Übersetzung des Buches von David J. Anderson »Kanban – Evolutionäres Change Management für IT-Organisationen«. Er berät Unternehmen bei der Einführung agiler Methoden wie Scrum und Kanban.

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

Stefan Roock · Henning Wolf

Scrum –verstehen und erfolgreich einsetzen

2., aktualisierte und erweiterte Auflage

Stefan Roock

[email protected]

Henning Wolf

[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:

Print978-3-86490-590-2

PDF978-3-96088-522-1

ePub978-3-96088-523-8

mobi978-3-96088-524-5

2., aktualisierte und erweiterte Auflage 2018

Copyright © 2018 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

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 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 Leser werden Projektmanager, Produktmanager, Entwickler und unteres bis mittleres Management der Softwareentwicklung sein.

Ü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 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 Kunden und bekamen entsprechendes Feedback.

Nicht nur wir empfanden so, viele der Entwickler unserer Kunden, die wir bei der Einführung von Scrum und XP unterstützten, äußerten sich ähnlich. Und das Management und die Kunden unserer Kunden 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 Softwareentwicklungsteams 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.

Wir wollen mit diesem Buch einen Beitrag zu dieser Vision leisten. Wir verfolgen die Mission, neben der Scrum-Mechanik den 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 vorliegende 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 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.

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 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 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 der ersten Auflage dieses Buches, die uns Feedback gegeben haben, sowie die vielen 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]

Stefan Roock, Henning Wolf

Hamburg, Juni 2018

Überblick über das Buch

Dieses Buch hat einen etwas ungewöhnlichen Aufbau. Wir betrachten nicht die Scrum-Rollen, -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 Entwicklungsteams.

Kapitel 2 liefert einen Überblick über Scrum: die Rollen, 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 Produktvision, 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 das Entwicklungsteam, die Sprints, das Sprint Planning und das Daily Scrum. Wir thematisieren die technischen Herausforderungen, die mit iterativinkrementeller Entwicklung einhergehen und denen sich das Entwicklungsteam stellen muss.

Kontinuierliche Prozessverbesserung ist das Thema von Kapitel 5. Retrospektiven als institutionalisierter Mechanismus zur Prozessverbesserung durch das Team werden ebenso beschrieben wie die Rolle 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, 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. 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.

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

Wer als Manager 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

1Scrum: Historie, Vorteile, Eignung und Herausforderungen

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

3Scrum produktbezogen

4Entwicklung mit Scrum

5Kontinuierliche Verbesserung

6Releasemanagement

7Streiflicht auf fortgeschrittenes Scrum

Anhang

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

BLiteratur

Index

Inhaltsverzeichnis

1Scrum: Historie, Vorteile, Eignung und Herausforderungen

1.1Historie

1.1.1Scrum-Teams nach Nonaka und Takeuchi

1.1.2Erste Scrum-Projekte in der Softwareentwicklung

1.1.3Von den ersten Artikeln bis zum Scrum Guide

1.1.4Verbreitung von Scrum

1.2Vorteile von Scrum

1.2.1Kürzere Time-to-Market

1.2.2Höhere Qualität

1.2.3Größere Effizienz

1.2.4Mehr Innovation

1.2.5Zufriedenere Mitarbeiter

1.3Eignung

1.4Herausforderung: Denkweise (Mindset)

1.5Das Kapitel in Stichpunkten

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

2.1Scrum-Flow

2.2Die Rollen

2.2.1Product Owner

2.2.2Entwicklungsteam

2.2.3Scrum Master

2.2.4Scrum-Team

2.2.5Kein Projektleiter in Scrum

2.3Meetings

2.3.1Sprint Planning

2.3.2Daily Scrum

2.3.3Sprint-Review

2.3.4Sprint-Retrospektive

2.4Der Sprint

2.5Artefakte

2.5.1Product Backlog

2.5.2Sprint Backlog

2.5.3Lieferbares Produktinkrement

2.6Prinzipien

2.6.1Autonomes und cross-funktionales Team

2.6.2Inspect & Adapt (auch: empirisches Management)

2.6.3Timeboxing

2.6.4Return on Investment (ROI)

2.6.5Qualität einbauen

2.6.6Pull

2.6.7Chronisch unterspezifiziert

2.7Scrum-Werte

2.8Das Kapitel in Stichpunkten

3Scrum produktbezogen

3.1Produktbegriff

3.1.1Beispiel

3.1.2Der passende Produktbegriff

3.2Produktinkremente

3.3Endkunden

3.3.1Zielgruppen und Personas

3.3.2Personas validieren

3.4Produktvision

3.4.1Elemente der Produktvision

3.4.2Probleme/Bedürfnisse identifizieren

3.4.3Produktvision kommunizieren: Storytelling

3.4.4Weitere Hilfsmittel für Produktvisionen

3.5Die Product-Owner-Rolle

3.5.1Die Bedeutung von Priorisierung

3.5.2Bevollmächtigung des Product Owners

3.6Eigenschaften des Product Backlog

3.6.1Größe des Product Backlog

3.7Ready State und Definition of Ready

3.8Product Backlog Board

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

3.8.2Inhomogene Product Backlog Items

3.8.3Physikalisches Board

3.9Priorisierung

3.9.1Priorisierung nach Kosten-Wert

3.9.2Priorisierung nach Risiko-Wert

3.9.3Priorisierung mit Verzögerungskosten (Cost of Delay)

3.9.4Wert bzw. Verzögerungskosten ermitteln

3.9.5Technische Product Backlog Items mit Verzögerungskosten priorisieren

3.10Epics und User Stories

3.10.1Satzschema für User Stories

3.10.2Typische Fallen bei User Stories

3.10.2.1Nutzen wird weggelassen

3.10.2.2Akteur ist zu abstrakt

3.10.2.3Akteur ist der Anforderer

3.10.3Tipps zu User Stories

3.10.3.1Alternatives Satzschema

3.10.3.2Persona als Akteur

3.10.4Akzeptanzkriterien

3.10.5User Stories anhand von Akzeptanzkriterien aufspalten

3.10.6Epics

3.11Das komplette Produkt als Geschichte: Story Mapping

3.11.1Story-Map-Beispiel

3.11.2Wirkungen in Story Maps

3.12Weitere Techniken zur Anforderungsmodellierung

3.13Empirisches Management produktbezogen

3.13.1Sprint Planning und Sprint-Review

3.14Das Sprint Planning

3.14.1Pull-Prinzip im Sprint Planning

3.14.2Tasks als Plan

3.14.3Das Sprint-Ziel

3.14.3.1Finden des Sprint-Ziels

3.14.3.2Vorteile guter Sprint-Ziele

3.15Das Sprint-Review

3.15.1Transparenz: Demonstration des lieferbaren Produktinkrements

3.15.2Inspektion: Einholen von Feedback zum Produktinkrement

3.15.3Adaption: Integration des Feedbacks in das Product Backlog

3.15.3.1Zusätzliche und alternative Praktiken im Sprint-Review

3.15.4Und was ist mit der Abnahme?

3.15.5Sprint-Abbruch

3.16Backlog Refinement

3.16.1Refinement im Sprint-Review

3.16.2Refinement im Sprint Planning

3.16.3Refinement zwischen Sprint-Review und Sprint Planning

3.16.4Ad-hoc-Refinement-Meetings

3.16.5Regelmäßige Refinement-Meetings

3.16.6Refinement-Optionen im Vergleich

3.17Das Kapitel in Stichpunkten

4Entwicklung mit Scrum

4.1Entwicklungsteam (cross-funktional, autonom, selbstorganisiert)

4.1.1Cross-Funktionalität

4.1.2Autonom und selbstorganisiert

4.1.3Entwickler nur in einem Team

4.2Sprints

4.3Lieferbare Produktinkremente

4.3.1Definition of Done

4.4Technische Herausforderungen

4.4.1Herausforderung 1: lieferbares Produktinkrement ab dem ersten Sprint

4.4.2Herausforderung 2: inkrementelle Architekturentwicklung

4.5Sprint Planning: das Wie

4.5.1Aufwandsschätzung

4.5.2Story Points als Größenmaß

4.5.3Vorteile von Story Points

4.5.4Planning Poker®

4.5.5Varianten des Planning Poker®

4.5.6Erfahrungen mit Planning Poker®

4.5.7Inkrementelles Ziehen in den Sprint

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

4.5.9Architekturdiskussionen

4.5.10Was wir nicht im Sprint Planning festlegen

4.6Taskboard als Sprint Backlog

4.7Sprint-Burndown-Chart

4.8Daily Scrum

4.8.1Umgang mit Problemen im Daily Scrum

4.8.2Der Product Owner im Daily Scrum

4.8.3Hindernisbearbeitung im Daily Scrum

4.9Das Kapitel in Stichpunkten

5Kontinuierliche Verbesserung

5.1Scrum-Master-Rolle

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

5.1.2Scrum-Master-Dienste für das Entwicklungsteam

5.1.3Scrum-Master-Dienste für die Organisation

5.1.4Der Scrum Master und das Team

5.1.5Der Scrum Master und der Product Owner

5.1.6Der Scrum Master und die Organisation

5.1.7Der Scrum Master und die Scrum-Meetings

5.1.8Haltung und Einstellung des Scrum Masters

5.1.9Braucht es einen Vollzeit-Scrum-Master?

5.1.9.1Scrum Master als Mitglied im eigenen Team

5.1.9.2Scrum Master als Mitglied in einem anderen Team

5.1.9.3Scrum Master für ein zusätzliches Team

5.1.9.4Der Scrum Master als Change Agent im Unternehmen

5.1.9.5Der richtige Weg für den eigenen Kontext

5.1.10Der Business Case zum Scrum Master

5.1.11Die Super-Power des Scrum Masters

5.2Team-Building

5.3Hindernisbeseitigung

5.4Retrospektiven

5.4.1Der PDCA-Zyklus

5.4.2Retrospektiven-Phasen

5.4.2.1Set the stage (die Bühne bereiten)

5.4.2.2Gather data (Daten sammeln)

5.4.2.3Generate insights (Einsichten generieren)

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

5.4.2.5Closing (Abschluss)

5.4.3Moderation von Retrospektiven

5.4.4Teilnehmer der Sprint-Retrospektive

5.4.5Weitere Retrospektiven

5.4.6Weitere Vertiefung

5.5Agile Werte und Prinzipien

5.5.1Das Agile Manifest

5.5.2Agile Problemlösung

5.6Das Kapitel in Stichpunkten

6Releasemanagement

6.1Grenzen der Releaseplanung

6.2Das Warum der Releaseplanung

6.2.1Rendezvous-Planung

6.2.2Beispiel: Marketing

6.2.3Investitionsmanagement

6.3Das beste Releasemanagement ist Sprint-Management

6.4Schätzung mit Story Points

6.4.1Bucket Estimation

6.5Releaseplanung

6.5.1Ermitteln der Velocity

6.5.2Probleme mit Story Points

6.5.3Alternativen zu Story Points

6.5.4Releasedauer

6.5.5Release-Container

6.6Roadmap-Planung

6.7Release-Controlling

6.7.1Release-Burndown-Bar-Charts

6.7.2Release-Burnup-Charts

6.7.3Parking-Lot-Diagramme

6.8Festpreisverträge

6.8.1Werkverträge ohne Festpreis

6.8.2Alternative Vertragsformen

6.9Das Kapitel in Stichpunkten

7Streiflicht auf fortgeschrittenes Scrum

7.1Scrum einführen

7.1.1Veränderte Verhaltensweisen

7.1.2Scrum im Unternehmen verankern

7.1.3Kulturwandel im Unternehmen

7.1.3.1Scrum Studio

7.1.3.2Autonome Business Units

7.1.4Agilität mit agilen Verfahren ausbreiten

7.1.5Globale Optimierung

7.1.6Coaching

7.1.6.1Ökonomie des Coachings

7.1.7Externe Coaches auswählen

7.1.8Interne Coaches ausbilden

7.2Scrum skalieren

7.2.1Der Agile Scaling Cycle

7.2.2Praktiken zur Reduktion von Abhängigkeiten

7.2.3Praktiken zur Koordination von Teams

7.2.4Die Organisation entwickeln

7.3Agile Unternehmen

7.4Verteiltes Scrum

7.4.1Vertrauen ist essenziell

7.4.2Entfernung

7.4.3Tools

7.5Interventionen durch Führungskräfte

7.5.1Selbstverständnis von Führungskräften

7.5.2Alignment und Autonomie

7.5.3CDE: Containers, Differences, Exchanges

7.5.3.1CDE-Beispiel

7.5.4Leadership

7.6Vertragsgestaltung für agile Entwicklung

7.6.1Scrum im Vertrag

7.6.2Werkvertrag und Festpreis vs. Dienstvertrag und Bezahlung nach Aufwand

7.6.3Flexibilität des Vertragswerks

7.6.4Kosten- vs. nutzenorientierte Verträge

7.6.5Vorgehen wichtiger als Ergebnisse

7.7Das Kapitel in Stichpunkten

Anhang

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

A.1Scrum-Master-Aufgaben

A.1.1Teamebene

A.1.2Teamübergreifende Organisationsebene

A.1.3Anforderungsebene und Product Owner unterstützen

A.2Product-Owner-Aufgaben

A.2.1Produkteigenschaften

A.2.2Zusammenarbeit mit dem Team

A.2.3Kunden/Anwender

A.2.4Management sonstiger Stakeholder

A.3Aufgaben des Entwicklungsteams

A.3.1Arbeitsorganisation

A.3.2Technisch

A.3.3Bezogen auf Stakeholder

A.3.4Unterstützung des Product Owners

A.3.5Verbesserung

A.4Daily Scrum

A.5Sprint Planning

A.6Sprint-Review

A.7Sprint-Retrospektive

A.8Backlog Refinement

A.9Releaseplanung

A.10Product Backlog

A.11Sprint Backlog

A.12Produktinkrement

A.13Sprint-Burndown-Chart

A.14Release-Burnup-Chart

BLiteratur

Index

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 Projektbeteiligten müssen sich kontinuierlich abstimmen, damit kein Chaos ausbricht. Kooperation wird maximiert.

Durch die enge Zusammenarbeit der Projektbeteiligten 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 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: Das selbstorganisierte agile Team löst in kurzen Zyklen Probleme der Endkunden.

Abb. 1–3Agile Teams lösen Probleme der Endkunden.

Wer genau mit Endkunden 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 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]). Für die 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 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.

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

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]).

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 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 Mitarbeiterzufriedenheit 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 Gesetz (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 ändern. 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 entdeckt, nachdem sie produziert wurden. 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.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 überplanen 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 kostengünstiger beseitigen.

1.2.4Mehr Innovation

Wenn man mehrere Leute mit derselben Ausbildung und demselben Hintergrund in einen Raum steckt und sie bittet, kreativ zu sein, kommt meist nicht viel dabei heraus. Innovation entsteht aus Diversität und braucht Zusammenarbeit (siehe [Sawyer2008]).

Das cross-funktionale Team in Scrum bietet daher gute Voraussetzungen für die Entwicklung innovativer Produkte.

1.2.5Zufriedenere Mitarbeiter

Nach Dan Pink ist extrinsische Motivation (also Belohnungen als Anreize) hochgradig schädlich für Wissensarbeit (siehe [Pink2011]). Stattdessen benötigt man intrinsisch motivierte Mitarbeiter, und man kann die Wahrscheinlichkeit für intrinsische Motivation erhöhen, wenn drei Dinge gegeben sind:

Purpose

Ich muss den Zweck meiner Arbeit verstehen und sinnvoll finden.

Mastery

Ich muss an der Aufgabe wachsen können, darf aber nicht maßlos überfordert sein.

Autonomy

Ich kann das Wie der Aufgabenerledigung weitestgehend selbst bestimmen.

Diese drei Forderungen erfüllt Scrum sehr gut. Das Team kennt die Produktvision, entwickelt Features, die direkt Kundennutzen stiften, und hat Kundenkontakt im Sprint-Review. Dadurch wird der Forderung nach Purpose Genüge getan. Autonomie ist im Entwicklungsteam bezüglich des Wie der Arbeit gegeben, und der Scrum Master stellt sicher, dass diese Autonomie von außen nicht verletzt wird. Durch die selbstorganisierte Teamarbeit besteht außerdem die Chance, immer wieder Aufgaben zu finden, an denen die Teammitglieder wachsen können.

In der Konsequenz führt Scrum zu motivierteren, zufriedeneren Mitarbeitern. Natürlich gibt es vereinzelt Mitarbeiter, die mit Teamarbeit nicht gut zurechtkommen. Es werden also nicht unbedingt alle Mitarbeiter glücklich mit Scrum. Für den Großteil der Mitarbeiter sollte das aber schon gelten. Ist das nicht der Fall, stimmt vermutlich irgendetwas mit der Art und Weise nicht, wie Scrum praktiziert wird.

1.3Eignung